关于后端:爱奇艺统一实时计算平台建设

摘要：本文整顿自爱奇艺资深研发工程师李恒，在 FFA 2022 平台建设专场的分享。本篇内容次要分为四个局部：

1. 对立实时计算平台建设
2. 近实时数据架构
3. 业务实际
4. 将来布局

点击查看直播回放和演讲 PPT

一、对立实时计算平台建设

这是爱奇艺实时计算平台的演变过程。

晚期咱们反对用户通过脚本和 Jar 包提交换工作，引擎以 Storm 和 Spark 为主。2017 年，咱们引入了 Flink，并且意识到 SQL 相比 Jar 包在开发和运维上有着显著劣势，于是咱们提供了 SQL 开发平台，反对用户通过 SQL 开发流工作。

接下来随着实时业务的爆发式增长，为了反对构建实时数仓 ，咱们上线了低代码开发平台，反对图形化开发作业。往年咱们对这些平台进行了零碎的整合，和优化设计，建设了对立的实时计算平台 RCP。

实时计算平台在爱奇艺实时数据体系中处于十分重要的一环，它反对用户开发和治理流工作，实现数据的实时摄取、加工、散发。在建设 RCP 平台之前，咱们面临这样几个问题：

• 实时平台多，用户应用老本和服务方保护老本很高。
• 数据扩散在各个平台，无奈共享。
• 规模大，征询量大，报障多。
• 工作数量多，版本杂，导致反对用户的老本高。
• 架构老，难以适应新的技术架构。

基于这样的背景，咱们开始建设对立的实时计算平台 RCP。

咱们心愿通过 RCP 平台达成三个指标：

• 第一，实现流数据、流工作的对立治理，促成共享，降低成本。
• 第二，通过优化的设计，更好地帮忙用户实现稳固、高效的数据生产。
• 第三，通过数据湖、流批一体等新技术，进一步晋升业务成果。

上图是 RCP 的整体架构，分为平台层、解析引擎、计算框架、调度层、运行层。

平台层用户操作的入口，提供数据表的治理，作业的开发和运维性能；引擎层是作业的解析引擎。计算框架层是 Flink 和 Spark Streaming；调度层咱们目前正在进行流批一体化建设，别离有流工作和批工作的调度器，负责工作的提交和状态监控；工作运行层次要在自建集群，大量在私有云上。

平台建设的第一局部工作是作业开发，联合服务用户的教训，咱们总结了以下四个痛点：

• 一部分用户，不相熟 SQL，他们心愿有门槛更低的开发方式。
• 很多作业中，数据表的字段多，导致 SQL 简短，难以保护。
• 开发中须要适配很多不同的版本，解决依赖抵触问题。
• 作业中有很多 hardcode 的局部，比方数据表的连贯信息和配置。

为了解决好这些问题，咱们设计了全视角开发模式，让用户从三层不同的视角来对待数据。

• 第一层，数据流视角。这是最具体的视角，开发者关注底层数据的具体解决逻辑，适宜通过底层 API 来实现。
• 第二层，数据表视角。开发者关注在数据表之间传递数据的逻辑，适宜通过 SQL 来解决。
• 第三层，数据流转视角。开发者更关注上游输出通过怎么的流转之后输入到上游，这里通过数据流程图的形式来形容，十分间接、高效。

上面具体为大家介绍下全视角开发模式。

• 第一种 API 开发，用户能够基于底层 API 进行齐全定制的开发，而后将 Jar 包提交到平台来运行，咱们反对 Flink 和 Spark Streaming 两种框架。
• 第二种 SQL 开发，适宜相熟 SQL 的开发者，为了晋升开发效率，咱们提供了 SQL 编辑器、语法校验、SQL 格式化等工具。
• 第三种 DAG 开发，这是门槛最低的形式，用户将数据流的加工逻辑通过流程图的形式来形容，达到了设计即开发的成果。

同样一段逻辑，别离通过 SQL 和 DAG 来开发，在理论生产中，数据表通常有上百个字段，SQL 会比拟简短，难以保护；而通过 DAG 的形式，数据处理流程十分清晰，迭代保护效率高。

全视角开发上线后，应用这三种开发方式的用户都比拟多，它实现的成果有以下四点：

• 升高了开发门槛，连 SQL 语法也不须要深刻把握。
• 针对不同场景，用户能够抉择效率最高的开发方式。
• 对于 SQL 和 DAG 工作开发，平台提供了一些晋升效率的工具，如 SQL 语法校验，格式化等；DAG 中算子的 schema 能够逐级往下流传，不须要用户去手动编辑字段。
• 所有类型的作业底层对接对立的元数据中心，用户创立的数据表和 UDF 是通用的。不同类型的作业通过解析之后，运行起来也是等效的。

平台建设的第二局部工作是数据源治理，咱们实现了一套数据对立集成计划，分为三个模块。

• Catalog，它是一个长久化的元数据中心，是对立拜访数据表和函数的入口。
• 数据表，它代表各类状态的数据流和数据集，归属于某个我的项目，应用时通过 Catalog 名，我的项目名，数据表名三级限定符来拜访。
• Connector，它是拜访数据表的具体实现，蕴含如下性能，一是按指定的数据格式解析数据，比方 json, PB, 另外，适配 hadoop2 和 hadoop3 两大集群版本，适配了 Flink 1.12，1.15 这两个引擎版本，以及各类数据源版本，比方 HBase 等等。

上图是用户在平台上治理数据表的页面，能够看到平台反对用户集中化的治理各类数据表，包含实时队列，KV 库，离线存储等。每个数据表归属于某个我的项目，所有者负责保护，实现了我的项目间数据表的权限隔离。其余我的项目的用户，通过审批后，也能申请拜访这些数据表，从而实现共享。

拜访数据表的具体实现是在工作提交中实现的，用户上线作业后，平台会解析出作业应用的所有数据表和函数，查问 Catalog，获取数据表的具体信息，而后从文件服务器获取对应的 Connector Jar 和 UDF Jar，和引擎 Jar 一起提交。这个流程有这样三个特点：

• 对所有类型的工作是共用的，Connector 的代码是齐全复用的。
• 对工作里每个数据表的 Connector 按需加载，灵便拆卸。
• 平台对立来实现了不同版本的适配和解决依赖抵触，加重了用户的开发累赘。

平台建设的第三局部工作是工作治理，次要思考工作的启动、运行、故障和修复这四个阶段的需要。

工作启动时，要能指定生产地位，以及从之前的状态复原。工作运行时，须要对工作的运行状态进行监控；能便捷查问到运行指标和日志。产生故障时，能及时发现并发出报警告诉，最好平台还能进行故障诊断。最初，还能有一些伎俩能修复或者加重故障影响。

工作的启停，咱们做了如下优化。

工作运行时的状态数据，平台对立进行托管，用户无需关怀。进行时会主动触发状态保留，再启动时会尝试从上次的状态中复原，最大水平防止状态的失落；工作启动时反对用户指定生产的位点，从而实现灵便生产。

在工作的运行治理中，指标和监控报警是十分重要的一环。

在整体的架构中，指标投递和报警策略次要依赖 prometheus，报警告诉依赖爱奇艺外部的报警服务实现。平台反对了丰盛的报警策略配置，包含流量的稳定；数据源的生产提早；以及 CPU，内存相干的指标。报警订阅方面反对灵便配置报警级别，告诉策略等。另外，这一套架构咱们同样适配了 Spark 流工作。

工作日志采集这部分，为了让用户更便捷地查看日志，平台将所有工作的日志进行了采集，通过 Log4j KafkaAppender 实时将工作日志发送到 Kafka，通过解析后，发送到 ES，在 ES 中对工作名等字段进行索引，在工作治理页面上，用户就能不便地检索日志了。

这套流程有这样几个特点：

• 日志是异步发送的，不会影响工作的失常运行。
• 日志可查的范畴比拟大，目前反对查问以后到最近一周的历史日志。
• 查问剖析不便，反对关键词检索；能够集中剖析 JobManager 和全副 TaskManager 的日志。
• 另外，目前咱们正在做的一项工作，是对异样日志做主动的剖析，帮忙用户更快定位问题。

目前 RCP 平台上线了靠近一年的工夫，曾经代替了全副旧的实时平台。有来自各业务团队的近 300 个开发者，他们在 RCP 上构建了 5000 多个实时工作，这些工作总共解决的数据流量峰值达到了 8 千万条每秒，平台日均解决万亿条数据。

二、近实时数据架构

咱们公司传统的数仓体系中，数据起源次要是爱奇艺各类 app 等终端的埋点日志以及各个服务的后盾日志，通过日志采集服务别离采集到 Kafka 和 hdfs，造成实时和离线两条数据生产线，最初提供给上游利用，这是典型的 Lambda 架构。

次要存在的问题是两套数据生产线开发保护老本高，指标不统一，以及传统实时，离线链路固有的问题。

为了解决这些问题，咱们引入了 Iceberg, Flink CDC 等技术，构建了一个近实时的数据通路，咱们是这样定义它的：

• 数据的范畴，涵盖分钟级到历史全量数据。
• 计算上，只须要开发一次，工作能流式运行，也能批式运行。
• 数据起源上，反对变更数据。

计算方面，咱们采纳 Flink 作为对立的计算引擎，在 Flink 1.15 版本，曾经提供了较为齐备的流批对立 API，具备较成熟的批处理能力。

平台侧，RCP 正在反对流批一体化的开发，在开发时能别离配置两种运行模式下 读取数据源的规定，比方批运行时按分区读取数据表，流运行时读取表的新增数据，别离进行批式运行和流式运行。从而实现一次开发，两种形式运行。

在存储上，咱们目前以 Iceberg 作为近实时的存储。它次要有三个特点：

• 实现存量数据加增量数据的对立存储。
• 反对流式和批式的读写，从而与两种运行模式的计算工作适配。
• 反对行级更新，从而能导入 MySQL 等数据库的数据。

引入 Iceberg 后，咱们做了一些适配工作：

• 对 Iceberg 表进行了平台化治理。包含建表、配置数据的 TTL、文件合并策略等等。
• 反对构建近数据生产 Pipeline，比方分区写入实现后能够生成 done 标记。增量生产时，能够进行延时监控。
• 利用 alluxio 减速 Iceberg 表的查问，在理论业务查问中，起到了比拟显著的成果。

接下来是 MySQL 数据接入。很多业务数据在 MySQL 中的，为了对这些数据进行查问剖析，个别会把它们同步到大数据系统中。常见的做法会有两个链路，存量数据通过离线形式同步到 Hive，增量数据实时同步到 ES，Kudu 等存储中。

这个计划次要存在以下几个问题：

• 存量和增量数据在两份存储中，应用不不便。
• 保护两个同步链路，保护老本较高。
• 难以保障数据一致性，特地是存量同步切换到增量同步的时候。

通过调研，咱们认为 Flink CDC 技术非常适合咱们的场景，能够解决方才提到的问题。次要思考到它有以下几个劣势：

• 能很好的实现先同步存量数据，再无缝对接到增量同步，且端到端数据统一。
• Flink CDC2.0 版本之后，实现了无锁同步计划，对源库的影响较小。
• 反对边同步边数据加工，一个工作实现数据同步、加工、散发，架构简洁。

为了将 Flink CDC 集成到 RCP 平台，咱们做了以下工作：

• 将过后 Flink CDC 的版本和 Flink 1.15 做了适配。
• 对 MySQL CDC 类型数据表进行了对立集成，平台对接了 MySQL 服务，买通账号和权限流程，从而标准和简化了用户应用。
• 解决了咱们在实践中遇到的数据同步失败的问题。

上面咱们对近实时架构做个总结。首先，它实用的场景是对数据时效性和数据分析范畴，这两个需要比拟平衡的业务。即时效性不要求秒级提早，同时须要剖析较长时间范畴的数据，这类业务比拟适宜。

它相比传统 Lambda 架构的劣势次要体现在，一套流程带来的开发保护效率晋升，以及老本的升高。另外，它能提供时效性和完整性平衡的数据，且能反对接入传统数据库的数据。

同时，也存在一些有余，目前次要是两点：

• 减少了表保护老本，须要一直地进行文件合并。
• 存储上提供的能力还是不够全面。比方随机读取能力较弱。

三、业务实际

第一个案例是 BI 一般播放报表近实时通路建设。之前这是一个传统的 Lambda 架构，也遇到了咱们方才谈到的问题。通过和业务同学沟通，理解到这个业务提早从秒级降级到分钟级是能够承受的，因而咱们着手构建了近实时链路，来代替现有的流批两条链路。

在这个链路中，原始数据发送到 Kafka 之后，会保留一份到 hdfs，做故障复原。而后 ODS 层和 DWD 层都是基于 Iceberg 构建，整个链路是流式运行的。革新实现后的成果次要有 3 点：

• 整个通路的数据都是流动的，一份存储反对了近实时指标和离线指标的计算。
• 对立了数据口径，新通路的数据误差与原来的差距在 0.1% 以内。
• 老本显著升高，次要是资源老本和保护老本。

第二个案例是审核业务数据入湖的革新。这个业务的数据架构的审核数据会存到到 mongodb 中，在 ES 里构建二级索引，提供线上查问。旧计划的痛点是，常常会有出统计报表或者批量导出数据的需要，对线上服务形成较大压力。引入数据湖能较好地解决以后问题，原始数据流通过 Kafka，实时同步到 Iceberg 表中，通过 SparkSQL 进行即时剖析。达到了以下三个成果：

• 历史数据能够存在 Iceberg 表中，解除了线上存储的瓶颈。
• 批量扫描的查问都走 Iceberg，缓解了线上服务的查问压力。
• 反对即席查问，从而能反对疾速统计审核成果，数据批量导出等需要。

第三个是通过 Flink CDC 实现了库存计算业务的革新。整体流程上，业务 MySQL 库中的多张表须要做关联后，后果同步到 Redis 作维度表，实时流再来查问这个维度表。在革新前，是一个定时工作，每隔 10 分钟读取 MySQL 表的全量数据，多张表做关联后，后果写入 Redis，次要存在两个问题。

• 定时工作有不可避免的调度提早。
• 每次读取 MySQL 全表数据再做关联计算，计算量较大，效率比拟低。

因而，咱们在革新计划中，咱们引入了 Flink CDC , 进行一次存量同步后，无缝切换到增量同步，多张表的关联计算的后果写入 Redis，相比旧计划有显著的劣势：

• 整个过程是实时的，没有调度提早，整体提早从 20 分钟晋升到了秒级，因而计算结果的准确性大大提高了。
• 存量同步阶段实现后，后续都是基于增量数据计算，无需反复读取 MySQL 表的全量数据，计算效率显著晋升了。

四、将来布局

咱们布局了两个大的方向。

• 第一个方向是平台治理。数据层面，实现数据资产更好的治理，进一步晋升数据的共享率；工作层面，平台反对主动排障，加重用户的运维累赘；资源层面，实现计算资源的被动伸缩，更正当利用资源，降低成本。
• 第二个方向是实现流式数仓。这方面咱们跟社区的理念是统一的，心愿整个数据通路能实时流动起来，且每个环节的数据都可反对剖析，从而实现更高水平的流批对立，为业务发明新的价值。

点击查看直播回放和演讲 PPT

更多内容

<p style=”text-align:center”><img src=”https://img.alicdn.com/imgextra/i3/O1CN0102Wuzs1dUVfQKlv59_!!6000000003739-2-tps-1920-675.png” alt=”img” style=”zoom:100%;” /></p>

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc