Doris x Paimon湖仓一体建设技术要点

「湖仓一体」这个概念大家应该都不陌生了。我们在之前的文章中提高过，关于如何实现「湖仓一体」，方案并不是统一的，和你当前的技术栈以及业务场景息息相关。

其中基于Doris x Paimon(或者其他的数据湖组件例如Hudi等)，是其中一个可选的方案。本文写的就是这种方案主要解决的问题和用到的能力。

基于Doris x Paimon的湖仓设计

Doris在设计湖仓一体时，主要考虑如下四个应用场景：

•湖仓查询加速：Doris 作为一个非常高效的 OLAP 查询引擎，有着非常好的 MPP 向量化的分布式的查询层，可以直接利用 Doris 非常高效的查询引擎，对湖上数据进行加速分析。

•统一数据分析网关：提供各类异构数据源的查询和写入能力，支持用户将这些外部数据源统一到 Doris 的元数据映射结构上，当用户通过 Doris 查询这些外部数据源时，能够提供一致的查询体验。

•统一数据集成：首先通过数据湖的数据源连接能力，能够让多数据源的数据以增量或全量的方式同步到 Doris，并且利用 Doris 的数据处理能力对这些数据进行加工。加工完的数据一方面可以直接通过 Doris 对外提供查询，另一方面也可以通过 Doris 的数据导出能力，继续为下游提供全量或增量数据服务。通过 Doris 可以减少对外部工具的依赖，可以直接将上下游数据，以及包括同步、加工、处理在内的整条链路打通。

•更加开放的数据平台：众多数据仓库有着各自的存储格式，用户如果想要使用一个数据仓库，第一步就需要把外部数据通过某种方式导入到数据仓库中才能进行查询。这样就是一个比较封闭的生态，数据仓库中数据除了数仓自己本身可以查询以外，其它外部工具是无法进行直接访问的。一些企业在使用包括 Doris 在内的一些数仓产品的时候就会有一些顾虑，比如数据是否会被锁定到某一个数据仓库里，是否还有便捷的方式进行导出。通过湖仓一体生态的接入，可以用更加开放的数据格式来管理数据，比如可以用 Parquet/ORC 格式来去存储数据，这样开放开源的数据格式可以被很多外部系统去访问。另外，Iceberg，Hudi 等都提供了开放式的元数据管理能力，不管元数据是存储在 Doris 本身，还是存储在 Hive Meta store，或者存储在其它统一元数据中心，都可以通过一些对外公开的 API 对这些数据进行管理。通过更加开放的数据生态，可以帮助企业更快地接入一个新的数据管理系统，降低企业数据迁移的成本和风险。

基于Doris x Paimon的湖仓一体方案，重在 「加速查询」 和 「统一建模」，而后者的能力也是基于前者。

退一步讲，即时仅仅是基于Doris做加速查询也是非常值得考虑落地的。

Doris本身的能力

数据源打通

Doris 通过多源数据目录（Multi-Catalog）功能，支持了包括 Apache Hive、Apache Iceberg、Apache Hudi、Apache Paimon、LakeSoul、Elasticsearch、MySQL、Oracle、SQL Server 等主流数据湖、数据库的连接访问。

Doris社区自Paimon0.5版本开始接入Paimon生态，并实时跟进Paimon的最新特性，对于Paimon的支持非常完善。

查询加速

在性能优化方面，Doris在远程IO、数据缓存、元数据缓存方面都做了非常多的工作。

•IO优化：针对 HDFS 或者对象存储系统的特性，Doris 实施了涵盖小 IO 合并、IO 预取、延迟物化等诸多优化举措，助力用户在未命中缓存的情况下读取远端数据时，依旧能够实现较为良好的吞吐效果或者较低的延迟。

•数据缓存：Doris 内置有轻量的本地数据缓存功能，能够将远端存储的热点数据块缓存至本地高速磁盘。对于热点数据的查询，若命中缓存，其查询性能可与 Doris 内表格式相媲美。

•元数据缓存：无论访问 DLF 还是其他元数据服务，远端访问的稳定性往往难以得到切实保证。鉴于此，团队在 Doris 内部实施了元数据缓存操作，对分区信息以及文件列表信息进行缓存，从而避免频繁进行文件列表操作，以实现大表能够在毫秒级时间内返回查询计划或者所需访问的文件列表等内容。

•物化视图：Doris 支持基于 Paimon、Iceberg、Hive 等表格式构建异步物化视图，并支持分区级别的增量构建。物化视图使用 Doris 内部格式存储，用户可以直接查询物化视图的数据获得最佳的查询能性能。也可以通过透明改写能力，在不改变原始查询语句的情况下，由 Doris 的查询优化器将查询自动路由到最合适的物化视图上，进行透明查询加速。

经过测算，在基于Iceberg表格式的1TB的TPCDS标准测试集上，其执行99个查询的总体运行耗时仅为Trino的1/3。实际用户场景中，在使用一半资源的情况下，相比Presto平均查询延迟降低了20%，95分位延迟更是降低50%。

更加详细的解释可以参考：https://doris.apache.org/zh-CN/docs/lakehouse/lakehouse-overview

统一建模

官方的分享是这样的：

「数据分层建模，ODS层在 LakeHouse 中，DWD，DWS，ADS 层的数据加工和数据服务在可以在Doris中，充分利用其性能优势，此外还可以将其加工好的数据再通过Write-Back的机制写回到LakeHouse中，实现备份归档或者供其他的数据系统继续处理使用。」

事实上，即使在分层建模中，我们也不太期望Doris承担过多的数仓本来的职责，主要原因是考虑到基于Hive的数仓开发模式已经非常成熟并且配套能力例如血缘、DQC监控等非常成熟。但是在单一业务场景或者小范围内这么做的确没有问题。

最终基于Doris、Flink和Paimon的湖仓一体解决方案就出炉了：

•数据处理层通过Flink和Paimon同时支持Streaming和Batch读写；

•通过Doris可以实现对Paimon表的分层加工，并且进行回写。

以上就是基于Doris x Paimon的湖仓方案的要点。

更多关于湖仓一体建设访问Flink+Paimon/Hudi+Doris湖仓架构落地的一些总结 | 巨人肩膀