日处理数据量超10亿:友信金服基于Flink构建实时用户画像系统的实践

  • 时间:
  • 浏览:0
  • 来源:大发5分6合APP下载_大发5分6合APP官方

2.0 版本数据防止流程

Apache Storm 的容错机制时需对每条数据进行应答(ACK),而且其吞吐量备受影响,在数据大吞吐量的场景下会有现象,而且不适用此项目的需求。

下图展示了 Flink 中 checkpointing 执行流程图:

端到端是指一端分类整理原始数据,另一端以报表 / 标签 / 接口的法律措施对有有哪些对数进行呈现与应用,连接两端的是里边实时流。在后续的工作中,我们 歌词 计划将现有的非实时数据源删剪切换到实时数据源,统一经过 Kafka 和 Flink 防止后再导入到 Phoenix/JanusGraph/HBase。强制所有数据源数据进入 Kafka 的四个 好地处于它不想可不可不都可否提高整体流程的稳定性与可用性:首先 Kafka 作为下游系统的缓冲,可不可不都可否 防止下游系统的异常影响实时流的计算,起到“削峰填谷”的作用;其次,Flink 自 1.4 版本开始正式支持与 Kafka 的端到端精确一次防止语义,在一致性方面上更有保证。

目前用户画像次责数据都不 从 Hive 数据仓库拿到的,数据仓库有一种是 T+1 模式,数据延时性较大,所以为了提高数据实时性,端到端的实时流防止很有必要。

Gephi

如下图所示,2.0 版本数据防止流程大次责承袭了 1.0 版本。新版本数据防止流程在以下有几次方面做了优化:

为了实现用户标签的整合,用户 ID 之间的强打通,我们 歌词 将用户 ID 标识看成图的顶点、ID pair 关系看作图的边,比如机会识别浏览器 Cookie 的用户使用手机号登陆了公司网站就形成了对应关系。这么 所有用户 ID 标识就构成了一张大图,其中每个小的连通子图 / 连通分支也不四个 用户的删剪标识 ID 信息。

Flink 算子链(Operator Chains)越长,Task 也会太满,相应的状况数据也就更多,Checkpointing 也会越慢。通过缩短算子链长度,可不可不都可否 减少 Task 数量,从而减少系统中的状况数据总量,间接的达到优化 Checkpointing 的目的。下面展示了 Flink 算子链的合并规则:

通过以上流程分析,我们 歌词 通过有一种法律措施来提高 Checkpointing 性能。有有哪些方案分别是:

这有四个 因为 :首先,RocksDBStateBackend 是内部管理存储,所以有一种 Checkpoint 存储法律措施都不 JVM 堆存储。受限于 JVM 堆内存的大小,Checkpoint 状况大小以及安全性机会会受到一定的制约;其次,RocksDBStateBackend 支持增量检查点。增量检查点机制(Incremental Checkpoints)仅仅记录对先前完成的检查点的更改,而都不 生成删剪的状况。与删剪检查点相比,增量检查点可不可不都可否 显著缩短 checkpointing 时间,但代价是时需更长的恢复时间。

根据不同业务的指标需求我们 歌词 直接从集团数据仓库抽取数据并落入 Kafka,机会直接从业务端以 CDC(Capture Data Change)的法律措施写入 Kafka。在计算层,数据被导入到 Flink 中,通过 DataStream 生成 ID-Mapping、用户标签碎片等数据,而且将生成数据存入 JanusGraph(JanusGraph 是以 HBase 作为后端存储的图数据库介质)与 Kafka,并由 Flink 消费落入 Kafka 的用户标签碎片数据,进行聚合生成最新的用户标签碎片(用户标签碎片是由用户画像系统获取来自多种渠道的碎片化数据块防止后生成的)。

目前,线上部署的用户画像系统中的数据绝大次责是来自于 Kafka 的实时数据。随着数据量太满,系统的压力也这么大,以至于跳出了 Flink 背压与 Checkpoint 超时等现象,因为 Flink 提交 Kafka 位移失败,从而影响了数据一致性。有有哪些线上跳出的现象而且你门开始关注 Flink 的可靠性、稳定性以及性能。针对有有哪些现象,我们 歌词 进行了删剪的分析并结合自身的业务特点,探索并实践出了所以相应的防止方案。

用户画像系统目前为集团线上业务提供用户实时标签数据服务。为此我们 歌词 的服务时需打通多种数据源,对海量的数字信息进行实时不间断的数据清洗、聚类、分析,从而将它们抽象成标签,并最终为应用方提供高质量的标签服务。在此背景下,我们 歌词 设计用户画像系统的整体架构如下图所示:

作者介绍:

杨毅:友信金服计算平台部 JAVA 工程师

穆超峰:友信金服计算平台部数据开发高级工程师

贺小兵:友信金服计算平台部数据开发工程师

胡夕:友信金服计算平台部技术总监

CheckPoint 存储法律措施有 MemoryStateBackend、FsStateBackend 和 RocksDBStateBackend。由官方文档可知,不同 StateBackend 之间的性能以及安全性是有很大差异的。通常状况下,MemoryStateBackend 适合应用于测试环境,线上环境则最好选择 RocksDBStateBackend。

首先,Source 中的事件进入 Flink 并被操作算子 1 防止且被序列化到 Buffer 中,而且操作算子 2 从有一种 Buffer 中读出该事件。当操作算子 2 防止能力缺乏的随后,操作算子 1 中的数据便无法放上 Buffer,从而形成背压。背压跳出的因为 机会有以下两点:

导读:当今生活节奏日益加快,企业面对不断增加的海量信息,其信息筛选和防止波特率低下的困扰与日俱增。机会用户营销缺乏细化,企业 App 中所以不合时宜或不合偏好的消息推送很大程度上影响了用户体验,甚至引发了用户流失。在此背景下,友信金服公司推行全域的数据体系战略,通过打通和整合集团各个业务线数据,利用大数据、人工智能等技术构建统一的数据资产,如 ID-Mapping、用户标签等。友信金服用户画像项目正是以此为背景成立,旨在实现“数据驱动业务与运营”的集团战略。目前该系统支持日防止数据量超 10 亿,接入上百种合规数据源。

基于以上有有哪些规则,我们 歌词 在代码层面上合并了相关度较大的所以 Task,使得平均的操作算子链长度大约缩短了 100%~70%。

Apache Flink 在流式计算上有明显优势:首先其流式计算属于真正意义上的单条防止,即每一根数据不会触发计算。在有一种 点上明显与 Spark 的微批流式防止法律措施不同。其次,Flink 的容错机制较为轻量,对吞吐量影响较小,使得 Flink 可不可不都可否 达到很高的吞吐量。最后 Flink 还拥有易用性高,部署简单等优势。相比之下我们 歌词 最终决定采用基于 Flink 的架构方案。

Gephi

1.0 版本数据防止流程在系统初期较好地满足了我们 歌词 的日常需求,但随着数据量的增长,该方案遇到了所以性能瓶颈:



传统基于 Hadoop 生态的离线数据存储计算方案已在业界大规模应用,但受制于离线计算的高波特率性,太满的数据应用场景已从离线转为实时。这里引用一张表格对目前主流的实时计算框架做个对比。

在 Flink 运行过程中,每四个 操作算子不会消费四个 里边 / 过渡状况的流,并对它们进行转换,而且生产四个 新的流。有一种 机制可不可不都可否 比拟为:Flink 使用阻塞队列作为有界的缓冲区。跟 Java 里阻塞队列一样,一旦队列达到容量上限,防止波特率较慢的消费者会阻塞生产者向队列发送新的消息或事件。下图展示了 Flink 中四个 操作算子之间的数据传输以及如保感知到背压的:

Apache Spark 总体生态更为完善,且在机器学习的集成和应用性暂时领先,但 Spark 底层还是采用微批(Micro Batching)防止的形式。

Flink 中 checkpointing 执行流程

经过以上优化,在每天亿级数据量下,用户画像可不可不都可否 做到实时信息实时防止并无持续背压,Checkpointing 平均时长稳定在 1 秒以内。

Checkpointing 时需对每个 Task 进行数据状况分类整理。单个 Task 状况数据太满则 Checkpointing 越慢。所以我们 歌词 可不可不都可否 通过增加 Task 并行度,减少单个 Task 状况数据的数量来达到缩短 CheckPointing 时间的效果。

鉴于有有哪些现象,我们 歌词 提出了 2.0 版本的防止方案。在 2.0 版本中,我们 歌词 通过利用 HBase 列式存储、修改图数据特性等优化方案尝试防止以上四个 现象。

实践中我们 歌词 通过以下法律措施防止背压现象。首先,缩短算子链会合理的合并算子,节省出资源。其次缩短算子链也会减少 Task(系统进程运行)之间的切换、消息的序列化 / 反序列化以及数据在缓冲区的交换次数,进而提高系统的整体吞吐量。最后,根据数据特性将不时需机会暂不时需的数据进行过滤,而且根据业务需求将数据分别防止,比如所以数据源时需实时的防止,所以数据是可不可不都可否 延迟的,最后通过使用 keyBy 关键字,控制 Flink 时间窗口大小,在上游算子防止逻辑中尽量合并更多数据来达到降低下游算子的防止压力。

在整体分类整理方案设计完成随后,我们 歌词 针对数据也设计了详尽的防止方案。在数据防止阶段,鉴于 Kafka 高吞吐量、高稳定性的特点,我们 歌词 的用户画像系所以一采用 Kafka 作为分布式发布订阅消息系统。数据清洗阶段利用 Flink 来实现用户唯一性识别、行为数据的清洗等,去除冗余数据。有一种 过程支持交互计算和多种冗杂算法,并支持数据实时 / 离线计算。目前我们 歌词 数据防止流程迭代了两版,具体方案如下:

Gephi

作者 | 杨毅,穆超峰,贺小兵,胡夕

整体数据来源中有 有一种:

ID-Mapping 数据由图特性模型构建,图节点中有 UserKey、Device、IdCard、Phone 等类型,分别表示用户的业务 ID、设备 ID、身份证以及电话等信息。节点之间边的生成规则是通过解析数据流中中有 的节点信息,以一定的优先级顺序进行节点之间的连接,从而生成节点之间的边。比如,识别了用户手机系统的 Android_ID,随后用户使用邮箱登陆了公司 App,在系统中找到了业务线 UID 就形成了和关系的 ID pair,而且系统根据节点类型进行优先级排序,生成 Android_ID、mail、UID 的关系图。数据图特性模型如下图所示:

整体架构分为五层:

服务层将存储层存储的用户标签碎片数据,通过 JanusGraph Spark On Yarn 模式,执行 TinkerPop OLAP 计算生成全量用户 Yids 列表文件。Yid 是用户画像系统中定义的集团级用户 ID 标识。结合 Yids 列表文件,在 Flink 中批量读取 HBase 聚合成删剪用户画像数据,生成 HDFS 文件,再通过 Flink 批量操作新生成的数据生成用户评分预测标签,将用户评分预测标签落入 Phoenix,随后数据便可通过统一数据服务接口进行获取。下图删剪地展示了有一种 流程。