字节跳动数据湖技术选型的思考

发布时间：2025-11-02 14:40:43 来源：创站工坊 作者：数据库

字节跳动数据集成的字节现状

在2018年，我们基于Flink构造了异构数据源之间批式同步通道，跳动主要用于将在线数据库导入到离线数仓，数据术选思考和不同数据源之间的湖技批式传输。

在2020年，字节我们基于Flink构造了MQ-Hive的跳动实时数据集成通道，主要用于将消息队列中的数据术选思考数据实时写入到Hive和HDFS，在计算引擎上做到了流批统一。湖技

到了2021年，字节我们基于Flink构造了实时数据湖集成通道，跳动从而完成了湖仓一体的数据术选思考数据集成系统的构建。

字节跳动数据集成系统目前支持了几十条不同的湖技数据传输管道，涵盖了线上数据库，字节例如Mysql Oracle和MangoDB；消息队列，跳动例如Kafka RocketMQ；大数据生态系统的数据术选思考各种组件，例如HDFS、HIVE和ClickHouse。

在字节跳动内部，数据集成系统服务了几乎所有的业务线，包括抖音、今日头条等大家耳熟能详的应用。

整个系统主要分成3种模式——批式集成、流式集成和增量集成。

随着业务的快速发展，这条链路暴露出来的问题也越来越多。

为了解决这些问题，我们希望对增量模式做一次彻底的架构升级，将增量模式合并到流式集成中，从而可以摆脱对Spark的依赖，在计算引擎层面做到统一。站群服务器

改造完成后，基于Flink的数据集成引擎就能同时支持批式、流式和增量模式，几乎可以覆盖所有的数据集成场景。

同时，在增量模式上，提供和流式通道相当的数据延迟，赋予用户近实时分析能力。在达到这些目标的同时，还可以进一步降低计算成本、提高效率。

经过一番探索，我们关注到了正在兴起的数据湖技术。

关于数据湖技术选型的思考我们的目光集中在了Apache软件基金会旗下的两款开源数据湖框架Iceberg和Hudi中。Iceberg和Hudi两款数据湖框架都非常优秀。但两个项目被创建的目的是为了解决不同的问题，所以在功能上的侧重点也有所不同。

一番对比下来，两个框架各有千秋，并且离我们想象中的数据湖最终形态都有一定距离，于是我们的核心问题便集中在了以下两个问题：

经过多次的内部讨论，我们认为：Hudi在处理CDC数据上更为成熟，并且社区迭代速度非常快，特别是最近一年补齐了很多重要的功能，与Flink的集成也愈发成熟，最终我们选择了Hudi作为我们的数据湖底座。

01 - 索引系统

我们选择Hudi，最为看重的就是Hudi的索引系统。

这张图是一个有索引和没有索引的对比。在CDC数据写入的过程中，为了让新增的Update数据作用在底表上，我们需要明确知道这条数据是否出现过、出现在哪里，从而把数据写到正确的地方。

在合并的时候，我们就可以只合并单个文件，而不需要去管全局数据。如果没有索引，合并的操作只能通过合并全局数据，带来的就是全局的shuffle。在图中的例子中，没有索引的合并开销是有索引的两倍，并且如果随着底表数据量的增大，这个性能差距会呈指数型上升。

所以，在字节跳动的业务数据量级下，索引带来的性能收益是非常巨大的。Hudi提供了多种索引来适配不同的场景，每种索引都有不同的优缺点，索引的选择需要根据具体的数据分布来进行取舍，从而达到写入和查询的最优解。下面举两个不同场景的例子。

在日志数据去重的场景中，数据通常会有一个create_time的时间戳，底表的分布也是按照这个时间戳进行分区，最近几小时或者几天的数据会有比较频繁的更新，但是更老的数据则不会有太多的变化。冷热分区的场景就比较适合布隆索引、带TTL的State索引和哈希索引。

第二个例子是一个数据库导出的例子，也就是CDC场景。这个场景更新数据会随机分布，没有什么规律可言，并且底表的数据量会比较大，新增的数据量通常相比底表会比较小。在这种场景下，我们可以选用哈希索引、State索引和Hbase索引来做到高效率的全局索引。这两个例子说明了不同场景下，索引的选择也会决定了整个表读写性能。Hudi提供多种开箱即用的索引，已经覆盖了绝大部分场景，用户使用成本非常低。

02 - Merge On Read表格式

除了索引系统之外，Hudi的Merge On Read表格式也是一个我们看重的核心功能之一。这种表格式让实时写入、近实时查询成为了可能。在大数据体系的建设中，写入引擎和查询引擎存在着天然的冲突：

为了在这种天然的冲突下找到最佳的取舍，Hudi支持了Merge On Read的文件格式。

MOR格式中包含两种文件：一种是基于行存Avro格式的log文件，一种是基于列存格式的base文件，包括Parquet或者ORC。log文件通常体积较小，包含了新增的更新数据。base文件体积较大，包含了所有的历史数据。

03 - 增量计算

索引系统和Merge On Read格式给实时数据湖打下了非常坚实的基础，增量计算则是这个基础之上的Hudi的又一个亮眼功能：

​增量计算赋予了Hudi类似于消息队列的能力。用户可以通过类似于offset的时间戳，在Hudi的时间线上拉取一段时间内的新增数据。在一些数据延迟容忍度在分钟级别的场景中，基于Hudi可以统一Lambda架构，同时服务于实时场景和离线场景，在储存上做到流批一体。

结语在选择了基于Hudi的数据湖框架后，我们基于字节跳动内部的场景，打造定制化落地方案。我们的目标是通过Hudi来支持所有带Update的数据链路。

相关文章