企查查基于 Apache Iceberg 与 Arctic 构建实时湖仓实践

摘要

本文主要介绍了企查查基于 Apache Iceberg+Arctic[1] 在的实时湖仓的落地与实践，我们积累出了一些经验希望通过本篇文章和大家分享。

主要围绕以下几个方面展开：

1. 背景及业务痛点
2. 遇见 Apache Iceberg
3. 遇见 Arctic
4. 在企查查的落地与实践
5. 未来规划

背景及业务痛点

在企查查，数据来源主要包括云上环境和 IDC 机房的各种数据源，数据源包括 MySQL，TiDB 集群，MongoDB 集群和日志数据。数据被收集到 Kafka 集群，分别用于主要基于 Spark 引擎的离线计算和基于 Flink 引擎的实时计算。计算结果通过同步组件再同步到不同的数据库引擎中，为不同的产品提供查询服务。

ODS 入仓流程如下：

随着公司业务发展、用户数量持续增长以及数仓建设不断完善，元数据种类的增长，痛点也越发明显。主要包括以下的几个方面：

第一，稳定性。抽取数据时间集中，对数据库压力较大。数据源的全量入仓场景，对源库的批量拉取，造成了数据库非常不稳定的问题。

第二，时效性。离线 T+1，增量合并也只能达到小时级别，而且链路长，维护成本高。

第三，业务赋能。不允许业务直接对线上的 TiDB、MongoDB 数据库的数据进行查询，会影响到集群稳定，但是业务方（产品、测试）有需要对线上的数据进行即席查询。

遇见 Apache Iceberg

开源数据湖项目主要以 Delta Lake、Hudi、Iceberg 为代表，这三者各自提供了一种数据湖的Table Format，三者各有各的背景和特点。

Delte Lake 主要绑定 Spark 引擎，企查查内部实时计算主要以 Flink 引擎为主，在长期发展上不匹配，从而导致我们第一个排查 Delta Lake。（2.0开源之后，社区也在积极拥抱 Flink 计算引擎)

主要对 Hudi 和 Iceberg 两者进行了调研，在查看了一些对比的案例[2]和内部测试之后，以下几个是我们最终选择 Iceberg 的原因（仅针对调研时两者的状态进行，不代表当前现状）：

• Iceberg Table format 更加开放，设计上面做了很好的抽象，没有强绑定某一个特定的引擎，更容易对接内部多个计算引擎 Flink、Spark、Trino。
• V2 版本对于 CDC 场景的接入有比较完善的支持了。
• Iceberg 已准备进行 1.0.0 的 release。
• Hudi 查询表名后面指定后缀_rt / _cow，还会有一些默认的字段，我们更希望对 hive 有更好的兼容性的 Table format，从而减少用户使用成本。
• 引擎侧 ORC 格式的支持进度 Hudi 是慢于 Iceberg，内部主要为 ORC 存储。

遇见 Arctic

在 CDC 数据实时同步入湖场景中，CDC 数据包含有大量的删除更新操作，在 Iceberg 中会生成 Delete 文件，这些文件告诉读取方要跳过的已被替换或删除的行，读取时要合并 Data 文件和 Delete 文件。Flink Job 每次 Commit 都会带来小文件，随着数据持续写入到 Iceberg 表中&#