Apache Doris 实时数仓场景建设四大新体系 & 湖仓一体化建设四大落地解决方案

引言

各位资深架构师看官老爷好，又见面了~

之前我们讲了很多构建方面的经验，但是在湖仓一体化建设上没有过多的去描述具体怎样演进，怎样落地，能做哪些事，那今天这篇就来详细唠唠基于 Apache Doris 的湖仓演进方案，至最后演进至 All In One Doris 的架构。

Apache Doris 是当下实时数据仓库建设过程中的工业界标杆产品，可实现秒级全链路的实时数仓构建，具备有效解决数据迟到、乱序、削峰等场景的处理能力。在数据可见性要求秒级的数据应用场景中，Apache Doris 具有极强的投产性价比，可有效为企业提供降本增效的技术架构设计方案。

同时 Apache Doris 在湖仓一体化能力建设过程中，通过不同能力组合，构建了多种落地方案来处理不同业务场景带来的技术挑战，所以在湖仓透明加速场景和湖仓一体化设计场景中，Apache Doris 可提供多种可落地、性价比高、收益明显的方案来解决不同场景下的痛点问题。

结合 Apache Doris 社区几千家用户的实际生产经验，我们总结得出了基于 Doris 构建实时数据仓库的四大新体系，同时在构建湖仓一体化过程中，可落地借鉴的四大应用场景解决方案，接下来为大家一一揭晓。

传统建设方案痛点

在传统离线数仓构建过程中，往往会遇到三方面的痛点：

基于 Apache Doris 构建实时数仓的新四大体系

使用 Apache Doris 来进行整体改造项目架构，可利用本身具备的多项特性的不同组合来完成架构升级改造。

体系一：统一查询网关

Apache Doris 在对接应用层的场景中，为了使上层应用能尽可能屏蔽下层感知，Doris 具备了 SQL 方言兼容和联邦查询的能力，同时使用高度兼容 MySQL 的语法和协议来完成与应用之间的通讯。

联邦查询能力

Doris 当前具备与数十种数据源进行联邦查询的能力，联邦查询是指使用单一组件完成不同数据组件之间的关联查询，可极大的降低数据在查询过程中需要在同一个组件内方可完成查询时数据流转的复杂度，降低查询难度，只需要注册相应的数据源至 Doris 中即可。

当前 Doris 具备数据湖产品、主流 OLTP、主流 OLAP、部分云产品的联邦查询能力，如 Hive、Delta、Iceberg、Hudi、Paimon 等湖产品，如 MySQL、Oracle、DB2、SQLServer、OceanBase、PostgreSQL 等 OLTP 产品，如 ClickHouse、Trino、Presto、SAP Hana 等 OLAP 产品，以及 MaxCompute、阿里云 DLF 等云产品。

方言兼容能力

在很多传统数仓的构建过程中，由于使用的组件纷繁复杂，企业内部会积累大量的各个组件的应用人才，如果因为组件的升级迭代而不得不重新学习一门查询或者开发语言的话，那整体成本将会非常高，基于这个痛点问题，Doris 设计了 SQL 转换器来减轻重新学习开发语言的成本，可以依旧沿用原有的 SQL 语法来做查询和开发任务，当前已适配支持 Presto、Trino、Hive、Spark、Postgres、Clickhouse 等组件语法。

体系二：统一存算平台

图片

Apache Doris 具备了大宽表查询、关联查询、高并发等值点查、联邦查询、日志检索、ELT/ETL 分层跑批等不同查询场景中的特性能力，并在不同场景中都做到了同类型场景下的效率或收益的整体领先，同时着重做了在集群内的多租户、资源管控以及权限管控能力，所以 Apache Doris 当下已具备完整替换多种组件构建而成的存算平台的能力，使用新的架构可大幅度提升数据流转的效率、降低数据多份存储的冗余度、加速查询时的时效性、减少平台运维的复杂度，综合收益非常高。

宽表查询

Apache Doris 团队在 2022 年 10 月和 2024 年 5 月参加过两次由 ClickHouse 社区发起的 ClickBench 榜单打榜，两次均取得了全球 OLAP MPP 数据库大宽表 TOP1 的优异成绩，用事实证明 Doris 在大宽表查询领域的确具备强大查询实力。

图片

2024 年 5 月 ClickBench 榜单截图（SelectDB 视同为 Apache Doris）

关联查询

Apache Doris 在设计之初，就着重设计了 JOIN 等关联查询算子的执行能力，故此 Doris 天然就是一个分布式 MPP 架构下的 OLAP 查询引擎，在关联查询计算时，可根据数据副本的分布情况，精准的下发物理执行计划给各个计算节点，由不同节点先行执行本地的关联算子任务，不同分布的节点全部执行完成后，再将各个节点的执行结果通过网络 Shuffle 到选举出的主节点上，由主节点完成最后的汇总计算。

TPC-H 测试集是一个专门为测试数据库在 AdHoc 场景下 JOIN 关联能力的标准测试集，Apache Doris 在当前版本的测试中，成绩要远优于其他同类数据库，在 1TB 的数据量下，22 个 Query 执行综合时长仅用时 76 秒，性能是Presto的22倍、Greenplum的17倍、Clickhouse的70倍。

高并发等值点查

Apache Doris 研发了表级别行列混存的特性，同时基于该特性研发了查询解析规划缓存、查询短路径优化等专属于高并发点查场景的优化能力，基于这些特性能力，Doris 实现了在主键模型下 KV 点查并发度和延迟大幅度的突破，在 YCSB 测试集下，可做到单台 16C64G 机器部署 1FE 1BE 节点，达到 3w QPS 平均 20ms 延迟的领先成绩。

在该特性的加持下，Apache Doris 可以在 API 数据服务、用户画像点查、实时维表关联等场景替换 Hbase、ElasticSearch 等高并发点查组件。

图片

行列混存特性

联邦查询

Apache Doris 具备对标 Presto/Trino 的联邦查询 Catalog 能力，当前可实现与数据湖产品、OLAP数据库产品、OLTP数据库产品以及ES、阿里云部分云产品的联邦查询能力，在 JBDC-Catalog、Hive-Catalog 联邦场景中，还可以实现数据查询回写的能力，该能力可大幅度降低构建异源数据库统一查询网关的复杂度，可根据业务场景需要来设计不同的应用思路。

图片

Apache Doris 联邦查询实现逻辑图

在标准测试集下，Apache Doris 的联邦查询能力对比 Presto/Trino 而言，有 3-5 倍的速度提升。

图片

Apache Doris 联邦查询对比 Trino/Presto

日志检索

Apache Doris 实现了以 Loki 为代表的轻量级倒排索引特性，可实现对 PB 级、百亿级日志的快速检索能力，同时 OLAP 数据库集成倒排索引处理日志的能力的技术实现在业界属于首创。

相较于 ELK 的日志解决方案，Apache Doris 日志解决方案着重解决了数据大规模导入效率、日志存储空间、查询语法兼容性等诸多场景痛点，通过 ElasticSearch 官网提供的 BenchMark 测试集以及 AWS 提供的日志场景测试集测试结果对比而言，Apache Doris 在查询效率上比 ElasticSearch 快 2-3 倍，在存储空间上比 ElasticSearch 少80%，在导入效率上比 ElasticSearch 高 5 倍，综合性价比收益超 10 倍以上，故此 Apache Doris 在日志检索场景已具备极强的场景处理能力和极致性价比。

图片

Apache Doris 与 ElasticSearch 在日志检索方案的对比

分层跑批

Apache Doris 为实现具备在大数据量下的复杂跑批能力，研发了新 CBO、Pipeline、PipelineX、算子落盘、异步物化视图、内置 JOB 任务等一系列特性来满足该场景，同时通过实现 MemTable 等特性，大幅度增强了 INSERT INTO SELECT、StreamLoad 等导入场景的能力，当前在 TPC-DS 复杂 SQL 查询场景中已取得了业界领先的优异成绩。

INSERT INTO SELECT

在分层数仓构建过程中，数据的导入效率占据了分层流转整体速度的很大一部分占比，基于该痛点，Apache Doris 团队着重优化了在导入过程中的各个部分算子的执行能力以及整体执行路径，如研发 MemTable 特性来大幅度缩减数据导入时的执行链路，在内存中前置完成数据攒批过程，通过 StreamWriter 数据流的方式进行传递，相较于过往通过 FileWriter 的方式有超 100% 的性能提升。

异步物化视图

Apache Doris 研发了异步物化视图特性来解决数据预计算的问题，可通过自定义 SQL 逻辑来完成多表数据加工处理的预聚合任务。

Doris 当前实现了内表关联物化、内外表关联物化、外表关联物化、物化视图级联等不同表结构下的物化能力，同时支持通过配置定时调度时间或 Base 表更新数据比例来完成更新操作，可在保证数据时效性的诉求下尽可能减少高频现查复杂 SQL 的资源消耗，可用该特性实现离在线一体化数仓的构建方案。

图片

异步物化视图分层应用示意图

内置JOB任务

Apache Doris 提供了内置 JOB 任务的特性，可利用该特性来完成部分自定义查询、定时导入任务等任务逻辑的执行，可不借助三方组件即完成部分简单定时任务的设置。

算子落盘

在大规模数据跑批任务中，传统 OLAP 数据引擎并不具备算子落盘的能力，只能依靠纯内存来完成整体任务的计算，而在小规模资源情况下，复杂查询或者跑批计算经常会因为资源不够执行失败，基于该痛点问题，Apache Doris 研发了算子落盘能力，可在小规模资源下完成大规模数据和复杂查询的跑批能力，进一步降低构建一体化数仓时的资源成本和架构组件运维成本，整体收益非常明显。

多租户能力

Apache Doris 为实现尽可能减少平台组件运维压力、保障不同业务条线和应用场景的查询稳定性，也研发了诸如 Resource Group 和 WorkLoad Group 等特性来处理上述场景的痛点问题。可通过制定不同的资源隔离策略来解决多租户下的资源划分问题。

Resource Group

Resource Group 资源划分是依托于数据存储多副本的特性来完成资源隔离的，属于资源硬隔离。

即将不同的节点机器划分为不同的 Group，数据在存储时根据资源组的划分将数据副本落入不同组内，再通过绑定不同用户给不同资源组来实现节点级的资源隔离。

图片

Resource Group

WorkLoad Group

WorkLoad Group 资源隔离是依托于 CGroup 等系统内核级资源隔离能力来完成动态资源划分的策略能力，可将整个集群的资源视为一个资源池，将 CPU、Mem、IO等资源池化，通过配置不同 Group 的资源量来完成对不同业务场景和查询用户的资源限制。

同时该资源限制能力，可同时实现资源软限和资源硬限的能力，软限时不同的资源组可侵占彼此空余资源来完成查询加速，硬限时不同资源组内资源互相绝对隔离，可有效保证查询时资源争抢的问题。

除此之外，Apache Doris 团队还实现了查询队列机制、查询智能降级等各种更灵活的任务配比方式，借助该特性能力，Apache Doris 彻底解决了 MPP 架构的 OLAP 数据库查询资源无法管控分配的问题，可同时保证跑批任务与即席任务的安全执行。

图片

WorkLoad Group

Computer Node

Apache Doris 为进一步满足在存算一体架构下，构建湖仓一体化能力时计算资源快速弹性扩缩容的需求，设计了只负责计算的 Computer Node 节点，该特性实现后既保留存了算一体的性能，又大幅度提升资源弹性扩缩容的能力。

计算节点作为一种特殊类型的 BE 节点，没有数据存储能力，只负责数据计算。因此，可以将计算节点看做是无状态的 BE 节点，可以方便的进行节点的增加和删除。

计算节点可以用于查询外部数据源，如 Hive、Iceberg、JDBC 等。Doris 不负责外部数据源数据的存储，因此，可以使用计算节点方便的扩展对外部数据源的计算能力。同时，计算节点也可以配置缓存目录，用于缓存外部数据源的热点数据，进一步加速数据读取。

图片

Computer Node

存算分离

Apache Doris 在 3.0 版本将 SelectDB-Cloud 的存算分离版本回馈至开源版本中，在存算分离架构下，存储资源和计算资源分离，各自弹性，更极致性价比，但往往作为依赖足够稳定、高吞吐的共享存储基座，通常公有云上才有，计算资源可以通过多 cluster 机制实现负载隔离，读写分离等机制。

图片

Apache Doris 3.0 存算分离

体系三：湖仓一体化建设

图片

在湖仓一体场景构建中，根据不同的业务形态和业务诉求，可设计多种湖仓一体化的方案来解决业务问题，如数据湖透明加速、跑批任务加速回写、湖仓存算形态设计、湖仓一体化分层构建等不同解决方案，这些方案皆是基于上述 Apache Doris 统一查询网关、存算一体化以及完整生态的能力下设计而出的。（较之体系二，数据湖回写能力将彻底完成湖仓一体化的融合构建，可注意两图在数据流转时的箭头）

方案一：数据湖透明加速方案

湖仓一体化构建过程中，在不影响现有业务运行稳定性下，往往只需要通过引入 Apache Doris 做 OLAP 数据查询加速引擎即可完成对数据湖数据的查询加速，主要实现方案为：

图片

1. 1. 利用联邦查询和SQL方言兼容特性，对外构建提供服务的统一查询网关能力，对内构建管控所有异源数据的汇集能力，由内至外实现百川入海。
2. 2. 利用数据湖 Catalog 能力完成数据查询透明加速能力，以 Hive 为例，先获取 HMS 元数据信息，通过 SQL 解析后将 Doris-SQL 信息转化为 HMS 信息，获取实际 Parquet、Orc 等格式文件的实际存储地址，将文件直接读取加载至 Doris 计算节点内存中，利用向量化引擎、PipelineX等特性完成加速查询，同时还可借助 ComputerNode 节点能力隔离出独享计算资源完成计算，不影响其他业务的正常运行。
3. 3. 若有频繁查询的结果集，可利用 PartitionCache 将结果集和原始数据缓存至 Doris 集群中，后续再有相关查询即无需通过网络 IO 做二次传输，可加速查询效率。

方案二：跑批任务加速回写方案

通过众多 Doris 用户生产实践反馈得知，在同等数据量、同等查询任务、同等机器资源量以及同等查询并发度的情况下，Doris 跑批任务速度比 Hive 快 8-10 倍，比 Spark 快 2-3 倍。该效率归功于向量化引擎、PipelineX、CBO、智能化分区分桶等各种黑科技的加持。

在上述场景的收益比下，湖仓一体化构建方案中还可以借助 Doris 强大的跑批性能完成批任务的加速执行：

图片

1. 1. 通过 Catalog 湖仓联邦能力，可将原有执行任务切换至 Doris 执行，通过 Doris 透明加速能力，完成结果集计算，若有其他维表关联或者异源数据关联计算诉求，可不通过数据同步的方案来具备关联计算的基础条件，直接通过联邦查询能力即可完成，减少数据同步任务的开发量和跑批任务的复杂度。
2. 2. 当前 Doris 已支持 Hive 数据湖的回写能力，可通过 Doris 完成 Hive 数据湖的计算后，将结果集回写至 Hive 数仓中供其他业务线共享使用。
3. 3. 切入一部分新实时业务或者离线实时化改造业务直接写入 Doris 实时数仓完成实时业务构建。

方案三：湖仓冷热形态存储方案

在部分企业实践过程中，比较关注数据的存储成本，往往 Doris 内仅存储过往半年或者一年内的数据，更往前的历史数据都希望在较为低廉的存储系统中进行存储，或者进行科学计算场景的应用。

但是在上述诉求下，还希望继续通过 Doris 完成整体的查询，比如季度报表、年度报表等数据，不要求查询效率和内表一样快速，但是要求在业务使用时不再进行查询语句上大幅度的改变，最好是能自动冷备，数据还不冗余存储，查询时可自动路由，那基于上述要求可如下完成方案思路设计：

图片

1. 1. 若希望自动冷热分层至 S3 或者 HDFS 等数据湖存储介质上，可利用 Doris 的冷热分层特性来满足，创建存储介质的 Resource 后，通过给表绑定 Resource 资源，指定 ColdDownTime 或者 TTL 时间，使其自动完成冷备。该方案在查询时无需额外操作，Doris 会自动路由远端数据加载至内存，与热数据一起完成计算。
2. 2. 若希望历史数据可参与共享计算，完成科学学习计算等场景的应用，可通过回写 Hive 或者 Export 至 HDFS/S3 上，导出为 Parquet、Orc 等公共格式，参与其他场景的共享计算。在查询时，可通过 TVF 或者 Catalog 关联完成数据加载计算。

方案四：湖仓一体化分层构建方案

在湖仓一体化分层构建方案中，主要有贴源层数据共享使用的诉求，即数据湖是统一数据入口，所有原始明细数据都在数据湖组件中留存一份，其他数据仓库和数据科学计算或者应用都基于该数据完成计算：

图片

1. 1. 利用 Doris 的 Catalog 能力将数据湖中 ODS 层数据根据分层加工逻辑，通过调度任务能力或者异步物化视图能力加工为 DW 层数据，并将该层数据落盘至 Doris 内表中。
2. 2. 后续通过加工完的 DW 层数据在 Doris 集群内部实现上层数仓构建，可依赖异步物化视图的构建或者任意支持 MySQL 协议的调度平台进行加工，或者使用 DBT 等 ELT 工具来完成上层数仓构建。

体系四：离在线一体化实时数仓

当下已有越来越多的企业基于 Apache Doris 建设离在线一体化的实时数据仓库。

在数百TB的总量数据大小内，Apache Doris 具备极强的数据综合处理能力，无论是内表的查询能力、联邦查询能力，或是大规模跑批能力、高并发点查能力，Doris 在不同场景都有着极为顶尖的数据处理能力，故此使用 Apache Doris 构建离在线一体化实时数据仓库是一个极具性价比的选择。

图片

1. 1. 上游数据无论是数据库、数据湖、消息中间件、数据计算引擎，还是日志采集工具、应用程序、Http API，Doris 都具备完备的生态来顺利接入数据，提供了例如 StreamLoad、RoutineLoad、BrokerLoad、INSERT INTO、TVF 等诸多的导入写入能力。
2. 2. 在 Doris 内部可完成数据的宽表加工计算、维表更新计算、明细聚合计算、多表关联计算等涵盖了所有数据应用场景的计算方式，同时联邦查询还可以降低从 TP 库临时关联查询时的数据流转复杂度，在数据导入和内部流转时还具有 MemTable 等特性来进一步加速导入的时效性，提升 ELT/ETL 的加工处理效率。
3. 3. 无论是存算一体部署架构下，亦或是采用存算分离部署架构，Apache Doris 都可利用对象存储或 HDFS 来进一步降低存储成本，且整体操作对上层应用全部屏蔽，可做到无感冷热、无感存算分离，且在存算分离架构下，实现了业界领先的架构设计，将商业化运行了两年的商业化数据库 SelectDB-Cloud 核心代码 Merge 回社区版，在云原生环境下有不输于存算一体的计算能力。
4. 4. 对外提供服务时仅需业务应用支持有 MySQL 协议的数据源即可完成兼容配对，无论是代码中使用 MySQL JDBC/ODBC，或是 BI 工具中使用 MySQL 数据源、Doris 数据源，在业务应用使用过程中不需要过高的学习成本来完成 Doris 的初步上手，在具备 MySQL 语法使用的基础上即可高效开发使用 Doris 实时数据仓库。
5. 5. 运维角度而言，Doris 仅有 FE 和 BE 两个主要进程，且互相之间无强依赖关系，同时 Doris 也不依赖任何三方组件，进程之间可独立完成查询高可用和数据高可靠的能力，在数据高可靠方面，Doris 具备节点、磁盘两级的数据负载均衡能力和自动 Rebalance 能力，具备多副本自动坏片修复的能力，故此 Doris 在运维方面成本极低。

小结

本篇基于 Apache Doris 现有特性，梳理了在大量企业中真实实践的应用场景，总结而言大致可分为四步：

1. 1. 引入 Doris 零入侵式做统一加速网关
2. 2. 逐步替换同能力组件降低架构复杂度
3. 3. 基于Hive或湖产品完成湖仓融合构建
4. 4. 收敛至 Doris 完成 All In One Doris 离在线一体化建设

Apache Doris 后续会在 CBO 持续优化、算子落盘、Binlog 日志解析、资源隔离、稳定性增强、存算分离等方面进一步努力，希望在基于当前具备四大体系、四大方案的基础之上，提供更多在实际落地生产过程中更具性价比的解决方案和应用体系，同时欢迎广大的开发同学试用 Doris 的 2.1 版本新特性，同步期待正在紧锣密鼓研发中 3.0 年度版本，如有在使用和开发过程中遇到任何问题，都可以通过微信群和官方论坛 ask.selectdb.com 来和 Doris 研发团队零距离即时沟通。