共计 12129 个字符，预计需要花费 31 分钟才能阅读完成。
简介： bilibili 万亿级传输散发架构的落地，以及 AI 畛域如何基于 Flink 打造一套欠缺的预处理实时 Pipeline。
本文由 bilibili 大数据实时平台负责人郑志升分享，本次分享外围解说万亿级传输散发架构的落地，以及 AI 畛域如何基于 Flink 打造一套欠缺的预处理实时 Pipeline。本次分享次要围绕以下四个方面：
一、B 站实时的前世与今生
二、Flink On Yarn 的增量化管道的计划
三、Flink 和 AI 方向的一些工程实际
四、将来的倒退与思考
GitHub 地址
https://github.com/apache/flink
欢送大家给 Flink 点赞送 star~
一、B 站实时的前世与今生
1. 生态场景辐射
说起实时计算的将来，关键词就在于数据的实效性。首先从整个大数据倒退的生态上，来看它的外围场景辐射：在大数据倒退的初期，外围是以面向天为粒度的离线计算的场景。那时候的数据实效性少数都是以运算以天为单位，它更加重视工夫和老本的均衡。
随着数据利用，数据分析以及数据仓库的遍及与欠缺，越来越多的人对数据的实效性提出了更高的要求。比方，当须要做一些数据的实时举荐时，数据的实效将决定它的价值。在这种状况下，整个实时计算的场景就广泛诞生。
但在理论的运作过程当中，也遇到了很多场景，其实并没有对数据有十分高的实时性要求，在这种状况下必然会存在数据从毫秒，秒或者天的新的一些场景，实时场景数据更多是以分钟为粒度的一些增量计算的场景。对于离线计算，它更加重视老本；对实时计算，它更加重视价值实效；而对于增量计算，它更加重视去均衡老本，以及综合的价值和工夫。
2. B 站的时效性
在三个维度上，B 站的划分是怎么的？对于 B 站而言，目前有 75% 的数据是通过离线计算来进行撑持的，另外还有 20% 的场景是通过实时计算，5% 是通过增量计算。
- 对于实时计算的场景，次要是利用在整个实时的机器学习、实时举荐、广告搜寻、数据利用、实时渠道剖析投放、报表、olap、监控等；
- 对于离线计算，数据辐射面广，次要以数仓为主；
- 对于增量计算，往年才启动一些新的场景，比如说 binlog 的增量 Upsert 场景。
3. ETL 时效性差
对于实效性问题，其实晚期遇到了很多痛点，外围集中在三个方面：
- 第一，传输管道不足计算能力。晚期的计划，数据根本都是要按天落到 ODS，DW 层是凌晨过后的第二天去扫描前一天所有 ODS 层的数据，也就是说，整体数据没方法前置荡涤；
- 第二，含有大量作业的资源集中暴发在凌晨之后，整个资源编排的压力就会十分大；
- 第三、实时和离线的 gap 是比拟难满足的，因为对于大部分的数据来说，纯实时的老本过高，纯离线的实效又太差。同时，MySQL 数据的入仓时效也不太够。举个例子，好比 B 站的弹幕数据，它的体量十分夸大，这种业务表的同步往往须要十几个小时，而且十分的不稳固。
4. AI 实时工程简单
除了实效性的问题 晚期还遇到了 AI 实时工程比较复杂的问题：
- 第一，是整个特色工程计算效率的问题。同样的实时特色的计算场景，也须要在离线的场景上进行数据的回溯，计算逻辑就会反复开发；
- 第二，整个实时链路比拟长。一个残缺的实时举荐链路，涵盖了 N 个实时和 M 个离线的十几个作业组成，有时候遇到问题排查，整个链路的运维和管控老本都十分高；
- 第三、随着 AI 人员的增多，算法人员的投入，试验迭代很难横向扩大。
5. Flink 做了生态化的实际
在这些要害痛点的背景下，咱们集中针对 Flink 做了生态化的实际，外围包含了整个实时数仓的利用以及整个增量化的 ETL 管道，还有面向 AI 的机器学习的一些场景。本次的分享会更加偏重增量管道以及 AI 加 Flink 的方向上。下图展现了整体的规模，目前，整个传输和计算的体量，在万亿级的音讯规模有 30000+ 计算核数，1000+ job 数以及 100 多个用户。
二、Flink On Yarn 的增量化管道的计划
1. 晚期的架构
先来看一下整个管道晚期的架构，从下图能够看出，数据其实次要是通过 Flume 来生产 Kafka 落到 HDFS。Flume 用它的事务机制，来确保数据从 Source 到 Channel，再到 Sink 时候的一致性，最初数据落到 HDFS 之后，上游的 Scheduler 会通过扫描目录下有没有 tmp 文件，来判断数据是否 Ready，以此来调度拉起上游的 ETL 离线作业。
2. 痛点
在晚期遇到了不少痛点：
第一个比拟要害的是数据品质。
- 最先用的是 MemoryChannel，它会存在数据的失落，之后也试过用 FileChannel 的模式，但性能上无奈达到要求。此外在 HDFS 不太稳固的状况下，Flume 的事务机制就会导致数据会 rollback 回滚到 Channel，肯定水平上会导致数据一直的反复。在 HDFS 极度不稳固的状况下，最高的反复率会达到百分位的概率；
- Lzo 行存储，晚期的整个传输是通过分隔符的模式，这种分隔符的 Schema 是比拟弱束缚的，而且也不反对嵌套的格局。
- 第二点是整个数据的时效，无奈提供分钟级的查问，因为 Flume 不像 Flink 有 Checkpoint 斩断的机制，更多是通过 idle 机制来管制文件的敞开；
- 第三点是上游的 ETL 联动。前文有提到，咱们更多是通过扫描 tmp 目录是否 ready 的计划，这种状况下 scheduler 会大量的和 NameNode 调用 hadoop list 的 api，这样会导致 NameNode 的压力比拟大。
3. 稳定性相干的痛点
在稳定性上也遇到很多问题：
- 第一，Flume 是不带状态的，节点异样或者是重启之后，tmp 没法失常敞开；
- 第二，晚期没有附丽大数据的环境，是物理部署的模式，资源伸缩很难去把控，老本也会绝对偏高；
- 第三，Flume 和 HDFS 在通信上有问题。比如说当写 HDFS 呈现梗塞的状况，某一个节点的梗塞会反压到 Channel，就会导致 Source 不会去 Kafka 生产数据，进行拉动 offset，肯定水平上就会引发 Kafka 的 Rebalance，最初会导致全局 offset 不往前推动，从而导致数据的沉积。
4. 万亿级的增量管道 DAG 视图
在如上的痛点下，外围计划基于 Flink 构建了一套万亿级的增量管道，下图是整个运行时的 DAG 视图。
首先，在 Flink 架构下，KafkaSource 杜绝了 rebalance 的雪崩问题，即使整个 DAG 视图中有某个并发度呈现数据写 HDFS 的梗塞，也不会导致全局所有 Kafka 分区的梗塞。此外的话，整个计划实质是通过 Transform 的模块来实现可扩大的节点。
- 第一层节点是 Parser，它次要是做数据的解压反序列化等的解析操作；
- 第二层是引入提供给用户的定制化 ETL 模块，它能够实现数据在管道中的定制荡涤；
- 第三层是 Exporter 模块，它反对将数据导出到不同的存储介质。比方写到 HDFS 时，会导出成 parquet；写到 Kafka，会导出成 pb 格局。同时，在整个 DAG 的链路上引入了 ConfigBroadcast 的模块来解决管道元数据实时更新、热加载的问题。此外，在整个链路当中，每分钟会进行一次 checkpoint，针对增量的理论数据进行 Append，这样就能够提供分钟级的查问。
5. 万亿级的增量管道整体视图
Flink On Yarn 的整体架构，能够看出其实整个管道视图是划分以 BU 为单位的。每个 Kafka 的 topic，都代表了某一种数据终端的散发，Flink 作业就会专门负责各种终端类型的写入解决。视图外面还能够看到，针对 blinlog 的数据，还实现了整个管道的组装，能够由多个节点来实现管道的运作。
6. 技术亮点
接下来来看一下整个架构计划外围的一些技术亮点，前三个是实时性能层面的一些特色，后三个次要是在一些非功能性层面的一些优化。
- 对于数据模型来说，次要是通过 parquet，利用 Protobuf 到 parquet 的映射来实现格局收敛；
- 分区告诉次要是因为一条管道其实是解决多条流，外围解决的是多条流数据的分区 ready 的告诉机制；
- CDC 管道更多是利用 binlog 和 HUDI 来实现 upsert 问题的解决；
- 小文件次要是在运行时通过 DAG 拓扑的形式来解决文件合并的问题；
- HDFS 通信理论是在万亿级规模下的很多种关键问题的优化；
- 最初是分区容错的一些优化。
6.1 数据模型
业务的开发次要是通过拼装字符串，来组装数据的一条条记录的上报。前期则是通过了模型的定义和治理，以及它的开发来组织的，次要是通过在平台的入口提供给用户去录制每一条流、每个表，它的 Schema，Schema 会将它生成 Protobuf 的文件，用户能够在平台下来下载 Protobuf 对应的 HDFS 模型文件，这样，client 端的开发齐全就能够通过强 Schema 形式从 pb 来进行束缚。
来看一下运行时的过程，首先 Kafka 的 Source 会去生产实际上游传过来的每一条 RawEvent 的记录，RawEvent 外面会有 PBEvent 的对象，PBEvent 其实是一条条的 Protobuf 的记录。数据从 Source 流到的 Parser 模块，解析后会造成 PBEvent，PBEvent 会将用户在平台录入的整个 Schema 模型，存储在 OSS 对象零碎上，Exporter 模块会动静去加载模型的变更。而后通过 pb 文件去反射生成的具体事件对象，事件对象最初就能够映射落成 parquet 的格局。这里次要做了很多缓存反射的优化，使整个 pb 的动静解析性能达到六倍的晋升。最初，咱们会将数据会落地到 HDFS，造成 parquet 的格局。
6.2 分区告诉优化
后面提到管道会解决上百条流，晚期 Flume 的架构，其实每个 Flume 节点，很难去感应它本人解决的进度。同时，Flume 也没方法做到全局进度的解决。然而基于 Flink，就能够通过 Watermark 的机制来解决。
首先在 Source 会基于音讯当中的 Eventime 来生成 Watermark，Watermark 会通过每一层的解决传递到 Sink，最初会通过 Commiter 模块，以单线程的形式来汇总所有 Watermark 音讯的进度。当它发现全局 Watermark 曾经推动到下个小时的分区的时候，它会下发一条音讯到 Hive MetStore，或者是写入到 Kafka，来告诉上小时分区数据 ready，从而能够让上游的调度能够更快的通过音讯驱动的形式来拉起作业的运行。
6.3 CDC 管道上的优化
下图右侧其实是整个 cdc 管道残缺的链路。要实现 MySQL 数据到 Hive 数据的残缺映射，就须要解决流和批处理的问题。
首先是通过 Datax 将 MySQL 的数据全量一次性同步到的 HDFS。紧接着通过 spark 的 job，将数据初始化成 HUDI 的初始快照，接着通过 Canal 来实现将 Mysql 的 binlog 的数据拖到的 Kafka 的 topic，而后是通过 Flink 的 Job 将初始化快照的数据联合增量的数据进行增量更新，最初造成 HUDI 表。
整个链路是要解决数据的不丢不重，重点是针对 Canal 写 Kafka 这块，开了事务的机制，保证数据落 Kafka topic 的时候，能够做到数据在传输过程当中的不丢不重。另外，数据在传输的下层其实也有可能呈现数据的反复和失落，这时候更多是通过全局惟一 id 加毫秒级的工夫戳。在整个流式 Job 中，针对全局 id 来做数据的去重，针对毫秒级工夫来做数据的排序，这样能保证数据可能有序的更新到的 HUDI。
紧接着通过 Trace 的零碎基于 Clickhouse 来做存储，来统计各个节点数据的进出条数来做到数据的准确比照。
6.4 稳定性 – 小文件的合并
后面提到，革新成 Flink 之后，咱们是做了每分钟的 Checkpoint，文件数的放大十分重大。次要是在整个 DAG 当中去引入 merge 的 operater 来实现文件的合并，merge 的合并形式次要是基于并发度横向合并，一个 writer 会对应一个 merge。这样每五分钟的 Checkpoint，1 小时的 12 个文件，都会进行合并。通过种形式的话，能够将文件数极大的管制在正当的范畴内。
6.5 HDFS 通信
理论运作过程当中常常会遇到整个作业沉积比较严重的问题，理论剖析其实主是和 HDFS 通信有很大的关系。
其实 HDFS 通信，梳理了四个要害的步骤：初始化 state、Invoke、Snapshot 以及 Notify Checkpoint complete。
外围问题次要产生在 Invoke 阶段，Invoke 会达到文件的滚动条件，这时候会触发 flush 和 close。close 理论和 NameNode 通信的时候，会经常出现梗塞的状况。
Snapshot 阶段同样会遇到一个问题，一个管道上百条流一旦触发 Snapshot，串行执行 flush 和 close 也会十分的慢。
外围优化集中在三个方面：
- 第一，缩小了文件的斩断，也就是 close 的频次。在 Snapshot 阶段，不会去 close 敞开文件，而更多的是通过文件续写的形式。这样，在初始化 state 的阶段，就须要做文件的 Truncate 来做 Recovery 复原。
- 第二，是异步化 close 的改良，能够说是 close 的动作不会去梗塞整个总链路的解决，针对 Invoke 和 Snapshot 的 close，会将状态治理到 state 当中，通过初始化 state 来进行文件的复原。
- 第三，针对多条流，Snapshot 还做了并行化的解决，每 5 分钟的 Checkpoint，多条流其实就是多个 bucket，会通过循环来进行串行的解决，那么通过多线程的形式来革新，就能够缩小 Checkpoint timeout 的产生。
6.6 分区容错的一些优化
理论在管道多条流的状况下，有些流的数据并不是每个小时都是间断的。
这种状况会带来分区，它的 Watermark 没有方法失常推动，引发空分区的问题。所以咱们在管道的运行过程当中，引入 PartitionRecover 模块，它会依据 Watermark 来推动分区的告诉。针对有些流的 Watermark，如果在 ideltimeout 还没有更新的状况下，Recover 模块来进行分区的追加。它会在每个分区的开端达到的时候，加上 delay time 来扫描所有流的 Watermark，由此来进行兜底。
在传输过程当中，当 Flink 作业重启的时候，会遇到一波僵尸的文件，咱们是通过在 DAG 的 commit 的节点，去做整个分区告诉前的僵尸文件的清理删除，来实现整个僵尸文件的清理，这些都属于非功能性层面的一些优化。
三、Flink 和 AI 方向的一些工程实际
1. 架构演进时间表
下图是 AI 方向在实时架构残缺的工夫线。
- 早在 2018 年，很多算法人员的试验开发都是作坊式的。每个算法人员会依据本人相熟的语言，比如说 Python，php 或 c++ 来抉择不同的语言来开发不同的试验工程。它的保护老本十分大，而且容易呈现故障；
- 2019 年上半年，次要是基于 Flink 提供了 jar 包的模式来面向整个算法做一些工程的反对，能够说在整个上半年的初期，其实更多是围绕稳定性，通用性来做一些反对；
- 2019 年的下半年，是通过自研的 BSQL，大大降低了模型训练的门槛，解决 label 以及 instance 的实时化来进步整个试验迭代的效率；
- 2020 年上半年，更多是围绕整个特色的计算，流批计算买通以及特色工程效率的晋升，来做一些改良；
- 到 2020 年的下半年，更多是围绕整个试验的流程化以及引入 AIFlow，不便的去做流批 DAG。
2. AI 工程架构回顾
回顾一下整个 AI 工程，它的晚期的架构图其实体现的是整个 AI 在 2019 年初的架构视图，其本质是通过一些 single task 的形式，各种混合语言来组成的一些计算节点，来撑持着整个模型训练的链路拉起。通过 2019 年的迭代，将整个近线的训练齐全的替换成用 BSQL 的模式来进行开发和迭代。
3. 现状痛点
在 2019 年底，其实又遇到了一些新的问题，这些问题次要集中在性能和非性能两个维度上。
在性能层面：
- 首先从 label 转到产生 instance 流，以及到模型训练，到线上预测，乃至真正的试验成果，整个链路十分的长且简单；
- 第二，整个实时的特色、离线特色、以及流批的一体，波及到十分多的作业组成，整个链路很简单。同时试验和 online 都要做特色的计算，后果不统一会导致最终的成果呈现问题。此外，特色存在哪里也不好找，没方法去追溯。
在非功能性层面，算法的同学常常会遇到，不晓得 Checkpoint 是什么，要不要开，有啥配置。此外，线上出问题的时候也不好排查，整个链路都十分的长。
- 所以第三点就是，残缺的试验进度须要波及的资源是十分多的，然而对算法来说它基本就不晓得这些资源是什么以及须要多少，这些问题其实都都对算法产生很大的困惑。
4. 痛点归纳
归根结底，集中在三个方面：
- 第一是一致性的问题。从数据的预处理，到模型训练，再到预测，各个环节其实是断层的。当中包含数据的不统一，也包含计算逻辑的不统一；
- 第二，整个试验迭代十分慢。一个残缺的试验链路，其实对算法同学来说，他须要把握货色十分多。同时试验背地的物料没方法进行共享。比如说有些特色，每个试验背地都要反复开发；
- 第三，是运维和管控的老本比拟高。
残缺的试验链路，背地其实是蕴含实时的一条工程加离线的一条工程链路组成，线上的问题很难去排查。
5. 实时 AI 工程的雏形
在这样的一些痛点下，在 20 年次要是集中在 AI 方向下来打造实时工程的雏形。外围是通过上面三个方面来进行冲破。
- 第一是在 BSQL 的一些能力上，对于算法，心愿通过面向 SQL 来开发以此升高工程投入；
- 第二是特色工程，会通过外围解决特色计算的一些问题来满足特色的一些反对；
- 第三是整个试验的合作，算法的目标其实在于试验，心愿去打造一套端到端的试验合作，最终心愿做到面向算法可能“一键试验”。
6. 特色工程 - 难点
咱们在特色工程中遇到了一些难点。
- 第一是在实时特色计算上，因为它须要将后果利用到整个线上的预测服务，所以它对提早以及稳定性的要求都十分的高；
- 第二是整个实时和离线的计算逻辑统一，咱们常常遇到一个实时特色，它须要去回溯过来 30 天到到 60 天的离线数据，怎么做到实时特色的计算逻辑能同样在离线特色的计算下来复用；
- 第三是整个离线特色的流批一体比拟难买通。实时特色的计算逻辑常常会带有窗口时序等等一些流式的概念，然而离线特色是没有这些语义的。
7. 实时特色
这里看一下咱们怎么去做实时特色，图中的右侧是最典型的一些场景。比如说我要实时统计用户最近一分钟、6 小时、12 小时、24 小时，对各个 UP 主相干视频的播放次数。针对这样场景，其实外面有两个点：
第一、它须要用到滑动窗口来做整个用户过来历史的计算。此外，数据在滑动计算过程当中，它还须要去关联 UP 主的一些根底的信息维表，来获取 UP 主的一些视频来统计他的播放次数。归根结底，其实遇到了两个比拟大的痛。
- 用 Flink 原生的滑动窗口，分钟级的滑动，会导致窗口比拟多，性能会损耗比拟大。
- 同时细粒度的窗口也会导致定时器过多，清理效率比拟差。
- 第二是维表查问，会遇到是多个 key 要去查问 HBASE 的多个对应的 value，这种状况须要去反对数组的并发查问。
在两个痛点下，针对滑动窗口，次要是革新成为 Group By 的模式，加上 agg 的 UDF 的模式，将整个一小时、六小时、十二小时、二十四小时的一些窗口数据，寄存到整个 Rocksdb 当中。这样通过 UDF 模式，整个数据触发机制就能够基于 Group By 实现记录级的触发，整个语义、时效性都会晋升的比拟大。同时在整个 AGG 的 UDF 函数当中，通过 Rocksdb 来做 state，在 UDF 当中来保护数据的生命周期。此外还扩大了整个 SQL 实现了数组级别的维表查问。最初的整个成果其实能够在实时特色的方向上，通过超大窗口的模式来反对各种计算场景。
8. 特色 - 离线
接下来看一下离线，左侧视图上半局部是残缺的实时特色的计算链路，能够看出要解决同样的一条 SQL，在离线的计算上也可能复用，那就须要去解决相应的一些计算的 IO 都可能复用的问题。比方在流式上是通过 Kafka 来进行数据的输出，在离线上须要通过 HDFS 来做数据的输出。在流式上是通过 KFC 或者 AVBase 等等的一些 kv 引擎来反对，在离线上就须要通过 hive 引擎来解决，归根结底，其实须要去解决三个方面的问题：
- 第一，须要去模仿整个流式生产的能力，可能反对在离线的场景上来生产 HDFS 数据；
- 第二，须要解决 HDFS 数据在生产过程当中的分区有序的问题，相似 Kafka 的分区生产；
- 第三，须要去模仿 kv 引擎维表化的生产，实现基于 hive 的维表生产。还须要解决一个问题，当从 HDFS 拉取的每一条记录，每一条记录其实生产 hive 表的时候都有对应的 Snapshot，就相当于是每一条数据的工夫戳，要生产对应数据工夫戳的分区。
9. 优化
9.1 离线 - 分区有序
分区有序的计划其实次要是基于数据在落 HDFS 时候，前置做了一些革新。首先数据在落 HDFS 之前，是传输的管道，通过 Kafka 生产数据。在 Flink 的作业从 Kafka 拉取数据之后，通过 Eventtime 去提取数据的 watermark，每一个 Kafka Source 的并发度会将 watermark 汇报到 JobManager 当中的 GlobalWatermark 模块，GlobalAgg 会汇总来自每一个并发度 Watermark 推动的进度，从而去统计 GlobalWatermark 的停顿。依据 GlobalWatermark 的停顿来计算出当中有哪些并发度的 Watermark 计算过快的问题，从而通过 GlobalAgg 下发给 Kafka Source 管制信息，Kafka Source 有些并发度过快的状况下，它的整个分区推动就升高速度。这样，在 HDFS Sink 模块，在同工夫片上收到的数据记录的整个 Event time 基本上有序的，最终落到 HDFS 还会在文件名下来标识它相应的分区以及相应的工夫片范畴。最初在 HDFS 分区目录下，就能够实现数据分区的有序目录。
9.2 离线 - 分区增量生产
数据在 HDFS 增量有序之后，实现了 HDFStreamingSource，它会针对文件做 Fecher 分区，针对每个文件都有 Fecher 的线程，且每个 Fecher 线程会统计每一个文件。它 offset 解决了游标的进度，会将状态依据 Checkpoint 的过程，将它更新到的 State 当中。
这样就能够实现整个文件生产的有序推动。在回溯历史数据的时候，离线作业就会波及到整个作业的进行。理论是在整个 FileFetcher 的模块当中去引入一个分区完结的标识，且会在每一个线程去统计每一个分区的时候，去感应它分区的完结，分区完结后的状态最初汇总到的 cancellationManager，并进一步会汇总到 Job Manager 去更新全局分区的进度，当全局所有的分区都到了开端的游标时候，会将整个 Flink 作业进行 cancel 敞开掉。
9.3 离线 – Snapshot 维表
后面讲到整个离线数据，其实数据都在 hive 上，hive 的 HDFS 表数据的整个表字段信息会十分的多，但理论做离线特色的时候，须要的信息其实是很少的，因而须要在 hive 的过程先做离线字段裁剪，将一张 ODS 的表荡涤成 DW 的表，DW 的表会最初通过 Flink 运行 Job，外部会有个 reload 的 scheduler，它会定期的去依据数据以后推动的 Watermark 的分区，去拉取在 hive 当中每一个分区对应的表信息。通过去下载某 HDFS 的 hive 目录当中的一些数据，最初会在整个内存当中 reload 成 Rocksdb 的文件，Rocksdb 其实就是最初用来提供维表 KV 查问的组件。
组件外面会蕴含多个 Rocksdb 的 build 构建过程，次要是取决于整个数据流动的过程当中的 Eventtime，如果发现 Eventtime 推动曾经快到小时分区完结的开端时候，会通过懒加载的模式去被动 reload，构建下一个小时 Rocksdb 的分区，通过这种形式，来切换整个 Rocksdb 的读取。
10. 试验流批一体
在下面三个优化，也就是分区有序增量，类 Kafka 分区 Fetch 生产，以及维表 Snapshot 的根底下，最终是实现了实时特色和离线特色，共用一套 SQL 的计划，买通了特色的流批计算。紧接着来看一下整个试验，残缺的流批一体的链路，从图中能够看出最下面的粒度是整个离线的残缺的计算过程。第二是整个近线的过程，离线过程其实所用计算的语义都是和近线过程用实时生产的语义是完全一致的，都是用 Flink 来提供 SQL 计算的。
来看一下近线，其实 Label join 用的是 Kafka 的一条点击流以及展示流，到了整个离线的计算链路，则用的一条 HDFS 点击的目录和 HDFS 展示目录。特色数据处理也是一样的，实时用的是 Kafka 的播放数据，以及 Hbase 的一些稿件数据。对于离线来说，用的是 hive 的稿件数据，以及 hive 的播放数据。除了整个离线和近线的流批买通，还将整个近线产生的实时的数据成果汇总到 OLAP 引擎上，通过 superset 来提供整个实时的指标可视化。其实从图能够看出残缺的简单流批一体的计算链路，当中蕴含的计算节点是十分的简单和庞多的。
11. 试验合作 – 挑战
下阶段挑战更多是在试验合作上，下图是将后面整个链路进行简化后的形象。从图中能够看出，三个虚线的区域框内，别离是离线的链路加两个实时的链路，三个残缺的链路形成作业的流批，实际上就是一个工作流最根本的过程。外面须要去实现工作流残缺的形象，包含了流批事件的驱动机制，以及，对于算法在 AI 畛域上更多心愿用 Python 来定义残缺的 flow，此外还将整个输出，输入以及它的整个计算趋于模板化，这样能够做到不便整个试验的克隆。
12. 引入 AIFlow
整个工作流上在下半年更多是和社区单干，引入了 AIFlow 的整套计划。
右侧其实是整个 AIFlow 残缺链路的 DAG 视图，能够看出整个节点，其实它反对的类型是没有任何限度的，能够是流式节点，也能够是离线节点。此外的话，整个节点与节点之间通信的边是能够反对数据驱动以及事件驱动的。引入 AIFlow 的益处次要在于，AIFlow 提供基于 Python 语义来不便去定义残缺的 AIFlow 的工作流，同时还包含整个工作流的进度的调度。
在节点的边上，相比原生的业界的一些 Flow 计划，他还反对基于事件驱动的整个机制。益处是能够帮忙在两个 Flink 作业之间，通过 Flink 当中 watermark 解决数据分区的进度去下发一条事件驱动的音讯来拉起下一个离线或者实时的作业。
此外还反对周边的一些配套服务，包含告诉的一些音讯模块服务，还有元数据的服务，以及在 AI 畛域一些模型核心的服务。
13. Python 定义 Flow
来看一下基于 AIFlow 是如何最终定义成 Python 的工作流。左边的视图是一个线上我的项目的残缺工作流的定义。第一、是整个是 Spark job 的定义，当中通过配置 dependence 来形容整个上游的依赖关系，它会下发一条事件驱动的音讯来拉起上面的 Flink 流式作业。流式作业也同样能够通过音讯驱动的形式来拉起上面的 Spark 作业。整个语义的定义十分的简略，只须要四个步骤，配置每节点的 confg 的信息，以及定义每节点的 operation 的行为，还有它的 dependency 的依赖，最初去运行整个 flow 的拓扑视图。
14. 基于事件驱动流批
接下来看一下残缺的流批调度的驱动机制，下图右侧是残缺的三个工作节点的驱动视图。第一个是从 Source 到 SQL 到 Sink。引入的黄色方框是扩大的 supervisor，他能够收集全局的 watermark 进度。当整个流式作业发现 watermark 能够推动到下一个小时的分区的时候，它会下发一条音讯，去给到 NotifyService。NotifyService 拿到这条音讯之后，它会去下发给到下一个作业，下一个作业次要会在整个 Flink 的 DAG 当中去引入 flow 的 operator，operator 在没有收到上个作业下发了音讯之前，它会梗塞整个作业的运行。直到收到音讯驱动之后，就代表上游其实上一个小时分区曾经实现了，这时下个 flow 节点就能够驱动拉起来运作。同样，下个工作流节点也引入了 GlobalWatermark Collector 的模块来汇总收集它的解决的进度。当上一个小时分区实现之后，它也会下发一条音讯到 NotifyService，NotifyService 会将这条音讯去驱动调用 AIScheduler 的模块，从而去拉起 spark 离线作业来做 spark 离线的收尾。从里你们能够看出，整个链路其实是反对批到批，批到流以及流到流，以及流到批的四个场景。
15. 实时 AI 全链路的雏形
在流和批的整个 flow 定义和调度的根底上，在 2020 年初步构建进去了实时 AI 全链路的雏形，外围是面向试验。算法同学也能够基于 SQL 来开发的 Node 的节点，Python 是能够定义残缺的 DAG 工作流。监控，告警以及运维是一体化的。
同时，反对从离线到实时的买通，从数据处理到模型训练，从模型训练到试验成果的买通，以及面向端到端的买通。右侧是整个近线试验的链路。上面是将整个试验链路产出的物料数据提供给在线的预测训练的服务。整体会有三个方面的配套：
- 一是根底的一些平台性能，包含试验治理，模型治理，特色治理等等；
- 其次也包含整个 AIFlow 底层的一些 service 的服务；
- 再有是一些平台级的 metadata 的元数据服务。
四、将来的一些瞻望
在将来的一年，咱们还会更加集中在两个方面的一些工作。
- 第一是数据湖的方向上，会集中在 ODS 到 DW 层的一些增量计算场景，以及 DW 到 ADS 层的一些场景的冲破，外围会联合 Flink 加 Iceberg 以及 HUDI 来作为该方向的落地。
- 在实时 AI 平台上，会进一步去面向试验来提供一套实时的 AI 合作平台，外围是心愿打造高效，可能提炼简化算法人员的工程平台。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
