01
概述
数据是洞察用户、市场、运营决策的基础资料，在爱奇艺被广泛应用在推荐、广告、用户增长、营销等场景中。爱奇艺大数据业务之前采用 Lambda 架构，满足海量数据处理、时效性等方面需求，但开发维护及资源成本高，同时还存在数据孤岛问题。最近几年兴起的以 Iceberg、Hudi、Delta Lake 为代表的数据湖技术为构建统一的数据架构提供了基础。爱奇艺大数据团队在 2020 年引入 Iceberg 作为数据湖基座，并基于 Iceberg + Flink 构建了流批一体化数据生产架构替代传统的 Lambda 架构，打造了实时湖仓，已在 BI 数仓、会员、推荐、日志等多种场景落地。当前每日处理 PB 级的数据，延迟从小时级降低到 1 至 5 分钟，大幅提升数据流通效率。本文介绍了爱奇艺流批一体架构及实时湖仓建设实践过程。
02
传统 Lambda 架构：离线 + 实时两套数据生产链路
-
离线通路：使用 HDFS、Hive、Spark 等工具，按 ODS、DWD、DWS 分层的数仓架构构建了离线数仓。通过 Venus 日志采集、MySQLIO CDC 同步、Hubble 监控平台等工具将不同数据源集成到离线数仓，同时提供魔镜离线分析、Babel 离线计算两个开发平台支持数据应用开发。数仓中的 Hive 表按小时分区，从数据产生到业务场景应用通常有小时级的延时。 -
实时通路：数据价值随生命周期增长而迅速衰减，离线通路的延迟导致业务无法快速利用数据的价值，因此又构建了实时通路。参考离线数仓，使用 Kafka 和 Flink 搭建实时流式数仓。Venus、MySQLIO、Hubble 等数据集成工具支持不同数据源集成到实时流式数仓。在数据开发层面，新增 RCP 实时计算平台、RAP 实时分析平台，用于支持实时数据应用开发。实时数据通路可以达到秒级延时。
-
系统复杂度高：服务提供方需要提供多种组件，业务需要学习多个组件，并开发维护离线、实时两套程序。 -
数据一致性难保障：实时、离线两套代码，要做到数据处理逻辑统一、数据一致，存在较大挑战。 -
资源成本高：数据链路多个环节存在两套重复的存储和计算，成本较高。 -
数据延时大：实时数据虽然延时低，但是存储时间短，数据查询分析需求仍然依靠离线数据，具有 T+1 的延时。
03
实时湖仓一体化
-
可控的数据延时：snapshot 的生成速度决定了数据生成的延时，snapshot 生成越快，数据延时越低，最快可以到 1 分钟以内。 -
流批一体：Iceberg 既支持 Spark、Flink 引擎以批模式读写数据，也支持以流模式读写数据，能做到存储层面的流批一体。 -
资源成本低：底层存储在 HDFS 上，支持列存储及数据压缩，理论上与 Hive 的存储成本相当，远小于 Kafka 的存储成本。Iceberg 在元数据层加入了统计信息，可用于查询优化，查询成本比 Hive 低。 -
支持数据变更：Iceberg V2 格式的表支持行级数据变更，可以更好的集成数据库数据。
-
湖仓一体：既具备数据湖的灵活性，也具备数仓的结构化数据管理能力，可以统一存储结构化、半结构化、非结构化的数据，形成统一的数据底座，消除数据孤岛。 -
流批一体：将 Lambda 架构下的实时、离线两条数仓生产通路合并成一条，数仓的每个层次生产一份数据，既能用于按小时、天读数据的批计算，也能用于流式消费的实时计算。一套数仓避免了开发两套代码、计算逻辑对齐的问题，能大幅提高数据开发效率 -
资源成本低：相比于实时、离线两个数仓生产通路，流批一体的实时湖仓的数据生产、存储成本更低。相比Hive，Iceberg 元数据层更丰富的统计信息，也有助于查询性能提升，降低查询成本。 -
延时低：Iceberg 支持分钟级的数据可见性，通过实时写入 Iceberg，实时湖仓可以达到分钟级的延时。数据的使用方不需要在应用侧采用流、批数据融合的方式支持最新的全量数据，简化业务侧处理逻辑。
挑战
-
单任务生产多表问题：在爱奇艺的埋点、容器日志等数据源中，不同业务的日志混合在一起，需要按日志特征拆分到不同业务的 ODS 层表。单个任务消费一个数据源可能拆分出 500 多张表，最大的任务需要拆分到3000 多张表，总共拆分到上万张表。当前的 Flink Iceberg Sink 仅支持写入到一张表，而一个 Flink 任务也无法添加如此多的 Iceberg Sink。因此，如何解决单任务生产多表的问题是我们面临的首要难题。 -
数据生产进度评估：需要在实时生产数据的过程中评估数据生产进度，以便数据的使用方了解湖仓中数据的完整度，触发下游批任务。 -
流式消费的积压监控：对于下游的流式消费任务，需要像消费 Kafka 一样给出消费积压监控。 -
数据完备性保障：在 Lambda 架构下，在数据通路故障时，可以通过重新调度批计算修正数据，保证数据的最终完备性。实时湖仓架构也需要有保证数据完备性的机制。
04
解决方案
单任务生产多表
-
定义 MultiTableRow 类型。相比 Row，增加了所属的 Table 名称。 -
为避免每个 Writer 算子的 Task 写入过多表，出现小文件过多、内存使用过大及性能问题，在 Writer 算子之前加入 Partitioner 算子。通过 Partitioner 算子将相同表的数据路由到固定几个 Writer Task，一个 Writer Task 只处理部分表的写入。 -
Writer 算子基于 MultiTableRow 中的表名字加载表，将数据写入到对应表的文件。在 Checkpoint 时，首先按表名汇总各表新写入的文件构建 MultiTableWriteResult 对象，MultiTableWriteResult 对象相比 WriterResult 增加了表名信息。然后按表名 Shuffle 后发送给 Committer 算子。 -
Committer 算子的并行度不为 1，为默认并行度。在 Checkpoint 时，每个 Committer 算子的 Task 基于收到的MultiTableWriteResult 汇总各表的写入文件，提交到对应的表生成新的 Snapshot。
数据生产进度评估
流式消费积压监控
-
Split Enumerator：发现 Iceberg 表的新 Snapshot，读取 Snapshot 中的文件，并切分成 Split 块。 -
Reader：接收 Split Enumerator 分配的 Split 块，读取 Split 块中的数据，发送到下游算子。
数据完备性保障
图 10 数据修正
05
落地效果
-
Venus：Venus 是爱奇艺的日志平台，负责后端日志采集、存储、分析。原来日志统一存储在 Elasticsearch，与大数据体系割裂，现在大部分日志都统一入湖，对应实时湖仓的 ODS 层表。容器类日志原来先采集到统一的Kafka topic，然后按业务分割到业务 topic，再写入 Elasticsearch。迁移到实时湖仓架构后，从统一 Kafka topic 按业务拆分后直接写入 Iceberg，省掉了业务 topic 环节。Venus 总共写入超过 1 万张 Iceberg 表，每日写入 PB 级日志，延时 5 分钟，每年节省上千万成本。Venus 入湖改造的详细介绍见之前发布的文章《 爱奇艺数据湖实战 - 基于数据湖的日志平台架构演进 》 -
Pingback：Pingback 是爱奇艺埋点数据的统称，大部分埋点数据需要经过数仓架构 ODS、DWD、DWS 分层处理。我们按照数仓层次从前到后、业务重要程度从低到高的顺序使用实时湖仓 Iceberg 表替代 Hive 表。同时，也推动了部分能接受分钟级延时的业务从 Kafka 数据迁移到 Iceberg 表。目前已上线 1300 多张 Iceberg 表，每日新增数百 TB 数据，每一层的 Iceberg 表最低延时 1 分钟。 -
数据库数据：Flink CDC 支持全量、增量数据的透明切换并实时写入 Iceberg，数据库数据入湖统一切换成了 Flink CDC。目前已同步广告、会员、用户增长等业务的近百张表。
06
未来规划
-
继续上线更多业务场景，完全替代 Hive，并替代接受分钟级延时的 Kafka 数据。 -
将 Flink CDC 从 2.x 升级到 3.x，支持 Schema 自动变更，降低数据库数据入湖的维护代价。 -
Iceberg 不支持更新部分列、基于变更数据继续构建 Pipeline 等功能，限制了一些应用场景，正在引入新兴的数据湖技术 Paimon 作为这类场景的替补。
本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
