摘要
本文主要介绍了企查查基于 Apache Iceberg+Arctic[1] 在的实时湖仓的落地与实践,我们积累出了一些经验希望通过本篇文章和大家分享。
主要围绕以下几个方面展开:
- 背景及业务痛点
- 遇见 Apache Iceberg
- 遇见 Arctic
- 在企查查的落地与实践
- 未来规划
背景及业务痛点
在企查查,数据来源主要包括云上环境和 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 表中&#