字节跳动基于Doris的湖仓分析探索实践

发布时间：2025-11-03 17:11:05 来源：码上建站 作者：系统运维

01 Doris简介

Apache Doris具备以下几个特点：

Doris 由 Frontend（以下简称FE）和 Backend（以下简称BE）组成，WordPress模板其中FE负责接受用户请求、编译、优化、分发执行计划、元数据管理、BE节点的管理等功能，BE负责执行由FE下发的执行计划，存储和管理用户数据。

​

02 数据湖格式Hudi简介

Hudi是下一代流式数据湖平台，为数据湖提供了表格式管理的能力，提供事务，ACID，MVCC，数据更新删除，增量数据读取等功能。支持Spark, Flink, Presto, Trino等多种计算引擎。

​

Hudi根据数据更新时行为不同分为两种表类型：

针对Hudi的两种表格式，存在3种不同的查询类型：

03

Doris分析Hudi数据的技术背景

在数仓业务中，随着业务对数据实时性的要求越来越高，T+1数仓业务逐渐往小时级、分钟级，甚至秒级演进。实时数仓的应用也越来越广，也经历了多个发展阶段。源码下载目前存在着多种解决方案。

Lambda将数据处理流分为在线分析和离线分析两条不同的处理路径，两条路径互相独立，互不影响。

离线分析处理T+1数据，使用Hive/Spark处理大数据量，不可变数据，数据一般存储在HDFS等系统上。如果遇到数据更新，需要overwrite整张表或整个分区，成本比较高。

在线分析处理实时数据，使用Flink/Spark Streaming处理流式数据，分析处理秒级或分钟级流式数据，数据保存在Kafka或定期（分钟级）保存到HDFS中。​

该套方案存在以下缺点：

随着在线分析业务越来越多，Lambda架构的弊端就越来越明显，增加一个指标需要在线离线分别开发，维护困难，离线指标可能和在线指标对不齐，部署复杂，组件繁多。于是站群服务器Kappa架构应运而生。

Kappa架构使用一套架构处理在线数据和离线数据，使用同一套引擎同时处理在线和离线数据，数据存储在消息队列上。​

Kappa架构也有一定的局限：

针对Lambda架构和Kappa架构的缺陷，业界基于数据湖开发了Iceberg, Hudi,  DeltaLake这些数据湖技术，使得数仓支持ACID, Update/Delete，数据Time Travel, Schema Evolution等特性，使得数仓的时效性从小时级提升到分钟级，数据更新也支持部分更新，大大提高了数据更新的性能。兼具流式计算的实时性和批计算的吞吐量，支持的是近实时的场景。

以上方案中其中基于数据湖的应用最广，但数据湖模式无法支撑更高的秒级实时性，也无法直接对外提供数据服务，需要搭建其他的数据服务组件，系统较为复杂。基于此背景下，部分业务开始使用Doris来承接，业务数据分析师需要对Doris与Hudi中的数据进行联邦分析，此外在Doris对外提供数据服务时既要能查询Doris中数据，也要能加速查询离线业务中的数据湖数据，因此我们开发了Doris访问数据湖Hudi中数据的特性。

04 Doris分析Hudi数据的设计原理

基于以上背景，我们设计了Apache Doris中查询数据湖格式Hudi数据，因Hudi生态为java语言，而Apache Doris的执行节点BE为C++环境，C++ 无法直接调用Hudi java SDK，针对这一点，我们有三种解决方案。

该方案需要完整实现一套Hudi C++ client，开发周期较长，后期Hudi行为变更需要同步修改Hudi C++ client，维护较为困难。

该方案需要在Broker中增加读写Hudi数据的功能，目前Broker定位仅为fs的操作接口，引入Hudi打破了Broker的定位。第二，数据需要在BE和Broker之间传输，性能较低。

该方案需要在BE进程中维护JVM，有JVM调用Hudi java client对Hudi进行读写。读写逻辑使用Hudi社区java实现，可以维护与社区同步；同时数据在同一个进程中进行处理，性能较高。但需要在BE维护一个JVM，管理较为复杂。

该方案可以由BE直接读取hudi表的parquet文件，性能最高。但当前不支持base file和delta file的合并读取，因此仅支持COW表Snapshot Queries和MOR表的Read Optimized Queries，不支持Incremental Queries。

综上，我们选择方案四，第一期实现了COW表Snapshot Queries和MOR表的Read Optimized Queries，后面联合Hudi社区开发base file和delta file合并读取的C++接口。

05 Doris分析Hudi数据的技术实现

Doris中查询分析Hudi外表使用步骤非常简单。

建表时指定engine为Hudi，同时指定Hudi外表的相关信息，如hive metastore uri，在hive metastore中的database和table名字等。

建表仅仅在Doris的元数据中增加一张表，无任何数据移动。

建表时支持指定全部或部分hudi schema，也支持不指定schema创建hudi外表。指定schema时必须与hiveMetaStore中hudi表的列名，类型一致。

Example：

Plaintext

CREATE TABLE example_db.t_hudi

ENGINE=HUDI

PROPERTIES (

"hudi.database" = "hudi_db",

"hudi.table" = "hudi_table",

"hudi.hive.metastore.uris" = "thrift://127.0.0.1:9083"

);

CREATE TABLE example_db.t_hudi (

column1 int,

column2 string)

ENGINE=HUDI

PROPERTIES (

"hudi.database" = "hudi_db",

"hudi.table" = "hudi_table",

"hudi.hive.metastore.uris" = "thrift://127.0.0.1:9083"

查询Hudi数据表时，FE在analazy阶段会查询元数据获取到Hudi外表的的hive metastore地址，从Hive metastore中获取hudi表的schema信息与文件路径。

​

06 后期规划

目前Apche Doris查询Hudi表已合入社区，当前已支持COW表的Snapshot Query，支持MOR表的Read Optimized Query。对MOR表的Snapshot Query暂时还未支持，流式场景中的Incremental Query也没有支持。

后续还有几项工作需要处理，我们和社区也在积极合作进行中：

今天的分享就到这里，谢谢大家。

相关文章