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

  • 时间:
  • 浏览:0
  • 来源:uu快3开奖_uu快3娱乐_输钱

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

Gephi

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

通过以上流程分析,亲戚亲戚大家通过一种生活 最好的办法来提高 Checkpointing 性能。哪几个方案分别是:

基于以上哪几个规则,亲戚亲戚大家在代码层面上合并了相关度较大的你这些 Task,使得平均的操作算子链长度共要缩短了 150%~70%。

实践中亲戚亲戚大家通过以下最好的办法避免背压哪几个的问题报告 。首先,缩短算子链会合理的合并算子,节省出资源。其次缩短算子链也会减少 Task(进程)之间的切换、消息的序列化 / 反序列化以及数据在缓冲区的交换次数,进而提高系统的整体吞吐量。最后,根据数据形状将不需用不可能 暂不需用的数据进行过滤,但会 根据业务需求将数据分别避免,比如你这些数据源需用实时的避免,你这些数据是不用 延迟的,最后通过使用 keyBy 关键字,控制 Flink 时间窗口大小,在上游算子避免逻辑中尽量合并更多数据来达到降低下游算子的避免压力。

2.0 版本数据避免流程

目前用户画像每种数据都在从 Hive 数据仓库拿到的,数据仓库一种生活 是 T+1 模式,数据延时性较大,统统为了提高数据实时性,端到端的实时流避免很有必要。

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

Checkpointing 需用对每个 Task 进行数据情形埋点。单个 Task 情形数据不用 则 Checkpointing 越慢。统统亲戚亲戚大家不用 通过增加 Task 并行度,减少单个 Task 情形数据的数量来达到缩短 CheckPointing 时间的效果。

1.0 版本数据避免流程在系统初期较好地满足了亲戚亲戚大家的日常需求,但随着数据量的增长,该方案遇到了你这些性能瓶颈:

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

如下图所示,2.0 版本数据避免流程大每种承袭了 1.0 版本。新版本数据避免流程在以下哪几个方面做了优化:

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

鉴于哪几个哪几个的问题报告 ,亲戚亲戚大家提出了 2.0 版本的避免方案。在 2.0 版本中,亲戚亲戚大家通过利用 HBase 列式存储、修改图数据形状等优化方案尝试避免以上哪几个多多多哪几个的问题报告 。

作者介绍:

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

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

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

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

Gephi

首先,Source 中的事件进入 Flink 并被操作算子 1 避免且被序列化到 Buffer 中,但会 操作算子 2 从你这些 Buffer 中读出该事件。当操作算子 2 避免能力不够的事先,操作算子 1 中的数据便无法插进 Buffer,从而形成背压。背压跳出的意味不可能 有以下两点:

端到端是指一端埋点原始数据,另一端以报表 / 标签 / 接口的最好的办法对哪几个对数进行呈现与应用,连接两端的是顶端实时流。在后续的工作中,亲戚亲戚大家计划将现有的非实时数据源详细切换到实时数据源,统一经过 Kafka 和 Flink 避免后再导入到 Phoenix/JanusGraph/HBase。强制所有数据源数据进入 Kafka 的哪几个多多多好占据 于它不用 提高整体流程的稳定性与可用性:首先 Kafka 作为下游系统的缓冲,不用 避免下游系统的异常影响实时流的计算,起到“削峰填谷”的作用;其次,Flink 自 1.4 版本开始 正式支持与 Kafka 的端到端精确一次避免语义,在一致性方面上更有保证。

Flink 中 checkpointing 执行流程

整体架构分为五层:

为了实现用户标签的整合,用户 ID 之间的强打通,亲戚亲戚大家将用户 ID 标识看成图的顶点、ID pair 关系看作图的边,比如不可能 识别浏览器 Cookie 的用户使用手机号登陆了公司网站就形成了对应关系。事先所有用户 ID 标识就构成了一张大图,其中每个小的连通子图 / 连通分支可是哪几个多多多用户的详细标识 ID 信息。

在整体埋点方案设计完成事先,亲戚亲戚大家针对数据也设计了详尽的避免方案。在数据避免阶段,鉴于 Kafka 高吞吐量、高稳定性的特点,亲戚亲戚大家的用户画像系统统一采用 Kafka 作为分布式发布订阅消息系统。数据清洗阶段利用 Flink 来实现用户唯一性识别、行为数据的清洗等,去除冗余数据。你这些 过程支持交互计算和多种繁复算法,并支持数据实时 / 离线计算。目前亲戚亲戚大家数据避免流程迭代了两版,具体方案如下:

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

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

整体数据来源饱含一种生活 :

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

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



Gephi

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

你这些 个多多多多意味:首先,RocksDBStateBackend 是内部人员存储,你这些一种生活 Checkpoint 存储最好的办法都在 JVM 堆存储。受限于 JVM 堆内存的大小,Checkpoint 情形大小以及安全性不可能 会受到一定的制约;其次,RocksDBStateBackend 支持增量检查点。增量检查点机制(Incremental Checkpoints)仅仅记录对先前完成的检查点的更改,而都在生成详细的情形。与详细检查点相比,增量检查点不用 显著缩短 checkpointing 时间,但代价是需用更长的恢复时间。

Apache Flink 在流式计算上有明显优势:首先其流式计算属于真正意义上的单条避免,即每十根数据一定会触发计算。在你这些 点上明显与 Spark 的微批流式避免最好的办法不同。其次,Flink 的容错机制较为轻量,对吞吐量影响较小,使得 Flink 不用 达到很高的吞吐量。最后 Flink 还拥有易用性高,部署简单等优势。相比之下亲戚亲戚大家最终决定采用基于 Flink 的架构方案。

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

目前,线上部署的用户画像系统中的数据绝大每种是来自于 Kafka 的实时数据。随着数据量不用 ,系统的压力也如此大,以至于跳出了 Flink 背压与 Checkpoint 超时等哪几个的问题报告 ,意味 Flink 提交 Kafka 位移失败,从而影响了数据一致性。哪几个线上跳出的哪几个的问题报告 让亲戚亲戚大家开始 关注 Flink 的可靠性、稳定性以及性能。针对哪几个哪几个的问题报告 ,亲戚亲戚大家进行了详细的分析并结合自身的业务特点,探索并实践出了你这些相应的避免方案。

在 Flink 运行过程中,每哪几个多多多操作算子一定会消费哪几个多多多顶端 / 过渡情形的流,并对它们进行转换,但会 生产哪几个多多多新的流。你这些 机制不用 虚实结合 为:Flink 使用阻塞队列作为有界的缓冲区。跟 Java 里阻塞队列一样,一旦队列达到容量上限,避免速率单位单位较慢的消费者会阻塞生产者向队列发送新的消息或事件。下图展示了 Flink 中哪几个多多多操作算子之间的数据传输以及如何感知到背压的:

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

Apache Storm 的容错机制需用对每条数据进行应答(ACK),但会 其吞吐量备受影响,在数据大吞吐量的场景下会有哪几个的问题报告 ,但会 不适用此项目的需求。