基于数据湖格式构建流式增量数仓—CDC

摘要：本文整理自阿里云开源大数据平台技术专家毕岩(寻径)在 Apache Con ASIA 的分享。本篇内容主要分为四个部分：

1. 湖格式& Hudi & CDC

2. 湖格式设计实现 CDC 的思考

3. Hudi CDC 实现

4. 湖格式 Streaming 的优化

2021年中 Databricks 发布了一篇基于 Delta Lake 实现 CDC 场景的介绍文档，2022年初我们在阿里云EMR 内部 Delta Lake 版本实现的 CDC 的能力，同期在 Apache Hudi 提案了 Hudi 基于 Spark 实现 CDC 的设计文档和实现代码。

结合这些经验，今天以 Apache Hudi 为主，分享一下数据湖格式上实现 CDC 的一些思考和注意点，以及一些流式 streaming 通用的优化点，和 Hudi CDC 的后续规划。

1

湖格式 & Hudi & CDC

---

该部分主要介绍下此次分享涉及到的一些概念，包括湖仓、数据湖格式、Apache Hudi，以及 Change Data Capture（CDC）的一些需要了解的东西。

湖仓 & 湖格式

相信大家对于数据仓库，数据湖，进而到两者结合的湖仓的演变有了一些了解，这里就不过多介绍了。湖仓（LakeHouse）有以下一些关键特性。

介绍几个关键特性：

1. ACID 事务：同一张表经常会同时有多个工作流来读写，事务保证了我们能够读、写到正确的数据；

2. Schema Enforcement 和数据管理：可以加上 Schema Evolution。Enforcement 在 Databicks 相关文章解释上等同于 Valication，在写入数据时，严格检测 schema 并要求和目标表定义的一致。Schema Evolution 允许修改表的字段信息（如增删字段，修改字段类型和描述等）。另外，湖仓还应提供健壮的湖表治理和审计的能力；

3. 支持结构/非结构数据，支持多类API：湖仓架构能够支持半/非结构化数据（如JSON，图像，语音等）的存储，以及提供除了基本SQL之外丰富的API来处理数据，应用在如机器学习等场景；

4. 批流一体：数据湖提出之初，很重要的就是替代 Lambda 架构，批流一体能够有效的简化流式和离线两条数据链路的开发和运维成本；

5. 存算分离：成本是各个公司都需要关注的。如果存储和计算都能按需伸缩，会更便于精细化控制成本。

我们发现大部分的湖仓关键特性是需要由底层存储之上的数据组织方式，即数据湖格式来提供的，我认为这也是 DeltaLake、Apache Hudi，Apache Iceberg 近两年兴起的主要背景和原因吧。

Apache Hudi

Apache Hudi 是一个构建于自管理数据库层之上的，使用增量数据流来构建数据湖的一个功能丰富的平台。相对于其他湖格式，Hudi具备更细粒度的数据布局（FileGroup），支持多种索引提升 Upsert 性能，以及在开源版本上较为丰富的自动化湖表管理能力。

CDC

Change Data Capture：定义了一种场景，即识别并捕获数据库表中数据的变更，并交付给下游进一步处理。CDC是对针对行级数据记录的。其中数据的变更信息，即 CDC 的数据结构，包括变更是什么样的操作（有三类：insert，update，delete），变更发生的时间点，以及变更前后的数据。显然对于insert操作该记录的变更信息中是没有旧值的，对于 delete 操作该记录的变更信息中是没有新值（当前值）的。

CDC 典型方法

CDC 不是数据湖格式特有的概念和场景，它存在已久。并且在传统数据库有些一些典型的方法：

1. 时间戳/版本号：是在表上添加一个类似于 created_time 和 last_modified_time 这样的字段，标识记录的创建时间和最新修改时间，查询时根据 modified_time 做过滤，得到变化的数据。这个方法有几个明显的缺点:

• • 不能感知到delete的变化。

  • 不能直接获取得到update的旧值，因此这类方案仅适用于没有delete操作，且不关注旧值的业务场景。

  • 由于没有快照或者版本的概念，不能准确的捕捉每次变更。

1. 表Diff：通过对比表的前后两个状态或者快照的数据来获取 CDC 数据。由于要做Diff，就会有快照间 Join 操作，该方法查询性能