Apache Doris：从诞生到云原生时代的演进、技术亮点与未来展望

前言

Apache Doris介绍

作者介绍

Apache Doris特性

Doris 数据流程

极简结构

高效自运维

高并发场景支持

MPP 执行引擎

明细与聚合模型的统一

便捷数据接入

Apache Doris 极速 1.0 时代

极速

列式内存布局

向量化的计算框架

Cache 亲和度

虚函数调用

SIMD 指令集

稳定

多源

关于 Apache Doris 开源社区

基于云原生向量数据库 Milvus 的云平台设计实践

作者介绍

图书推荐

本文节选自《基础软件之路：企业级实践及开源之路》一书，该书集结了中国几乎所有主流基础软件企业的实践案例，由 28 位知名专家共同编写，系统剖析了基础软件发展趋势、四大基础软件（数据库、操作系统、编程语言与中间件）的领域难题与行业实践以及开源战略、生态建设与人才培养。

前言

Apache Doris介绍

Apache Doris源于百度2008年启动的产品Palo在2018年捐献给Apache基金会，是一个基于 MPP 架构的高性能、实时的分析型数据库，他非常简单易用，而且性能还不错，仅需亚秒级响应时间即可获得查询结果，不仅支持高并发的查询场景，也可以支持高吞吐的复杂分析场景，比如你可以基于它做用户行为分析、日志检索平台、用户画像分析、订单分析等应用。

作者介绍

陈明雨，百度 Doris 团队前技术负责人、Apache Doris 项目管理委员会主席

注：本文整理自 Apache Doris 项目管理委员会主席陈明雨在 DIVE 全球基础软件创新大会（2022）的演讲，由李冬梅整理。

Apache Doris 是由百度自研并开源的一款 MPP（大规模并行处理技术）的分析型数据库产品，其项目已于 2022 年 6 月正式从 Apache 孵化器“毕业”，成为 Apache 顶级项目。

Apache Doris特性

Doris 数据流程

其中，上游数据源包括 OLTP 数据库中的数据、业务的应用日志、 Web 端的埋点日志以及本地文件等，通过批处理或流处理系统，比如 Hadoop 、Spark 、Flink 等，对数据进行加工以后，把数据“灌入”Doris 中。

Doris 可以直接对外提供查询服务，比如支持实时大屏的数据展示服务、多维报表分析、用户画像场景支持等。同时，用户还可以通过 Doris-Spark(Flink)-Connector 等连接组件，使用外部系统直接读取 Doris 中存储的数据。最后，用户还可以利用 Doris 高效的分布式 SQL 查询引擎，对外部数据源如 Hive 、Iceberg、 Elasticsearch 等提供查询加速服务。

我们选取了六个 Doris 的特点，向大家介绍 Doris 在分析型数据库领域的一些特点。

极简结构

Doris 的第一个特点就是它的极简架构，如图所示。

从上图可以看到，Doris 只有两类服务节点：FE（Frontend）节点和 BE（Backend ）节点。除了这两类节点以外， Doris 不再依赖任何第三方的服务。FE 、BE 节点都可以横向扩展，以应对不断增长的数据。

此外， Doris 支持 MySQL 协议和标准 SQL 语法，用户通过标准的 MySQL 客户端，或者各种语言的 MySQL 连接库，就可以方便地接入 Doris，并使用标准 SQL 进行数据分析。

通过极简的系统架构和较低的学习成本，用户可以方便、快速地把原有业务迁移到 Doris 上来。

高效自运维

在分布式系统中，存在很多系统故障，比如网络故障、磁盘故障、节点下线，甚至机房下线等。在这些故障发生的时候，分布式系统需要有一个很好的分布式管理层来自动进行故障恢复，

降低用户的运维成本。如图所示，在磁盘故障或者节点上下线时，Doris 可以自动地在分片（Tablet）级别对数据进行均衡或修复，保证整个集群能够在较短的时间内从故障中恢复过来，从而保证整个集群的可用性和可靠性。

整个故障修复过程不会影响用户使用 Doris，整个过程是一个透明的、自动的过程。对于一个分布式系统来说，较低的运维成本和较高的故障容忍度，可以极大地提升整个系统的健壮性，保证业务 7×24 小时提供可靠的服务。

高并发场景支持

市面上很多 OLAP 数据库都支持高吞吐的业务场景，而对高并发查询场景的支持并不是很友好。Doris 不仅支持高吞吐的业务场景，也提供了对高并发场景的支持。在单机情况下， Doris 可以支持 1000 QPS 的高并发点查询场景，同时可以通过横向扩展更多的计算节点来提高 QPS 的峰值。

这得益于 Doris 内部的一些技术实现。如通过分区裁剪，可以保证用户的查询最终仅落到某一个具体的数据分片上，避免不必要的数据读取。

此外， Doris 内部还提供了不同类型的缓存。例如，数据文件块级别的缓存，可以减少热点数据的磁盘 I/O 开销；SQL 结果缓存直接将查询结果进行缓存，对于相同的查询语句，可以直接返回缓存的结果；分区缓存可以缓存历史分区的数据，并在用户查询时，将历史分区缓存的数据和最新分区的实时数据合并，返回最终的结果。

通过缓存机制，降低查询时的磁盘 I/O 开销，并减少需要实时计算的数据量，保证单个查询的资源开销足够小，以提升同一时刻，整个系统能够承载的查询数量。

此外，在后续的 2.0 版本中，Doris 将通过包括短路规划、查询计划缓存、PreparedStatement 等更多技术，进一步提升高并发场景的支持能力，使得 Doris 能够在一些偏服务化（Serving）的场景中发挥作用。

MPP 执行引擎

Doris 具有完备的 MPP 查询执行框架，可以充分利用集群内的计算资源，完成高吞吐的多维数据分析请求。

MPP 查询执行框架的一个重要特点是其拥有对数据的重分布（ Shuffle）能力。首先，数据扫描算子将数据从对应的存储节点读出，数据重分布，可以将数据发送到更多的计算节点，从而利用更多的计算资源完成上层算子的计算。数据重分布能力，使得查询所能利用的计算资源不再和数据存储资源绑定，从而提升集群的资源利用率。Doris 内部 MPP 执行引擎示意如下图所示。

此外，因为 Doris 采用无共享（Share-Nothing）的架构，每个节点都独立存储、管理整个数据集的一部分，所以 Doris 的 MPP 查询执行框架会将查询计划切片，不同的切片可以在不同的节点上并行处理各自节点上存储的数据。同时，在同一个节点内，

Doris 还会将一个切片进一步拆分，充分利用多核 CPU 的能力。通过节点间和节点内的并行执行，进一步增强 Doris 的数据处理能力。

在后续版本中，Doris 还将引入 Pipeline 执行框架。该执行框架会在现有的并行执行能力基础上，为 Doris 提供细粒度的资源管控、隔离能力，进一步发挥 Doris 查询执行框架的能力。

明细与聚合模型的统一

Doris 的第五个特点是明细与聚合模型的统一。在实际业务操作中，用户可以首先将细粒度的原始数据存储在 Doris 中，这一部分数据称为明细数据，对应的表称为明细表。在明细表基础上，用户可以进一步建立针对任意维度的聚合表（或称物化视图）。

这里我们通过一个示例进行说明。如图所示，原始的明细表包含 ID、日期、城市和消费四列。其中 ID、日期和城市是维度列，消费是指标列。

如果用户查询“某一个日期的消费的总和”，则可以在明细表上建立一个由“日期”和“消费”列组成的物化视图。这个物化视图会自动地将相同“日期”的“消费”数据进行预聚合（累加， SUM），然后把累加后的数据直接物化存储在节点上。当用户查询某一日期的消费总和时，可以直接读取已经预先算好的数据，这样能够极大地加速数据查询。在整个查询过程中，不需要进行实时的数据累加计算，而是直接获取最终结果。同时，明细数据依然保留在明细表中，用户依然可以自由查询明细数据。这就是明细和聚合的统一。

Doris 也通过导入操作的事务性机制，来保证明细表和所有物化视图的数据的一致性。当用户将数据导入明细表时， Doris 会自动生成对应的物化视图的数据，并保证明细表和所有物化视图的数据原子性生效。这样用户无须担心脏数据，或者数据不一致的问题。

此外， Doris 还支持针对物化视图的查询的自动路由。用户无须指定要查询的具体物化视图 Doris 的查询优化器能够自动选择最合适的物化视图并返回正确的数据。

目前上述能力仅限于单表上的操作。Doris 会在 2.0 版本中提供多表物化视图的能力，支持对物化视图定义连接（Join）、聚合、过滤等操作，进一步提升在复杂数据查询场景下的能力。

便捷数据接入

Doris 在数据接入方面做了非常多的工作，来保证任何一个数据源都可以很快地接入 Doris，如图所示。比如 Doris 支持例行导入作业，通过一条简单的 SQL 语句就可以订阅 Kafka 中的数据，并提供精确一次（Exactly-Once）的消费语义，实时地消费和存储流式数据。同时，Doris 提供了 Flink 和 Spark 连接器（Connector），通过这些连接器，用户可以通过批处理和流处理系统来读取 Doris 中的数据，或写入数据到 Doris 中。

Doris 同时提供流式的和批量的数据导入方式，不管数据是存在对象存储系统、HDFS 上，还是 Kafka 中，都可以通过适合的导入方式来便捷地加工处理数据，并存储到 Doris 中，以进行快速的查询分析。

Apache Doris 极速 1.0 时代

在已经发布的 Apache Doris 1.0 中，主要突出以下三个特点：极速、稳定和多源。

极速

在 1.0 版本中，Doris 引入了全新的向量化执行引擎，极大提升了查询性能。向量化技术的提出已有十几年的历史，而在近几年，通过 ClickHouse 等优秀的开源的数据库引擎，这一技术真正被带入生产级别的实践中，让大家真正意识到向量化能够给数据分析带来怎样的变革。

Doris 借鉴了包括 ClickHouse 在内的很多开源系统的优秀设计，同时也结合自身的特点，打造了一个完整的向量化执行引擎。通过对所有的算子和函数进行向量化改造， Doris 极大地提升了整体查询执行效率。这里我们从列式内存布局、向量化的计算框架、 Cache（高速缓存）亲和度、虚函数调用、SIMD 指令集等几个主要技术点，介绍 Doris 在向量化执行引擎方面的技术实现。

列式内存布局

Doris 的存储引擎采用的是列式存储。在数据分析领域，列式存储相比行式存储有诸多优势，比如更高的压缩比，数据可以按需读取以提升 I/O 的效率等。

虽然 Doris 采用列式存储，但在 1.0 版本之前，数据从磁盘读取到内存后，在内存中依然是以行的形式进行布局的，如图 2-5-7 中左边部分（RowBatch）所示。RowBatch 中的数据是按行排列的，这种内存布局对向量化计算框架不友好，所以向量化引擎改造的第一步就是把整个行式内存布局改为列式内存布局，即采用图中右边部分（Block）数据结构。可以看到，在 Block 数据结构中数据是按列排列的，这种布局可以充分利用

Cache 亲和度、 SIMD 指令集等特性，从而加速查询。

向量化的计算框架

基于改造后的列式内存布局， Doris 实现了全新的向量化计算框架，在新的计算框架中，所有算子之间的数据都是以 Block 的格式传递的，如图所示。

在上图的左边，原始的 Block 是 a 、b 两列，我们在 b 列上进行了一次 abs 函数计算。函数计算会生成一个新的列，来存

储计算后的结果。之后，我们会对列进行裁剪。比如，如果上层不再用到原始的 b 列，我们会把 b 列删除，最终往上一层算子只传递 a 列和 abs 函数计算后的结果列。通过这种方式，我们可以通过内存预分配、内存复用等多种手段对算子提速。

Cache 亲和度

Cache 亲和度也跟内存布局息息相关。前文提到，所有数据都是以列的方式，紧密排列在一个 Block 中的。所以在一次 CPU 指令中，可以尽可能地在一个 CPU 缓存行（Cache Line）中处理更多的数据。现代 CPU 有多级缓存，比如 L1 、L2、主存，每级缓存的数据处理的延迟都是指数级增加的，所以要尽可能地在更贴近 CPU 的缓存中完成更多的数据处理。

虚函数调用

虚函数调用问题也是 Doris 之前版本的计算框架存在的问题。现代 CPU 都提供多级流水能力以及分支预测能力。CPU 会根据依赖关系，将一条指令拆分到多个流水线（Pipeline）中并行处理，并且通过分支预测，抢先执行一些预测后的计算逻辑，如下图所示。

但是如果出现了预测失败，那么多级流水就会被打乱，从而严重降低整个 CPU 在一个时钟周期内的处理能力。每一次虚函数调用，都会有一个虚函数表的查找操作，这个查找操作会打断 CPU 的指令流水，降低 CPU 的分支预测和指令流水的性能。所

以在新的向量化执行框架中，Doris 引入了大量 C++ 模板和 C++ 11、 17 的新语言特性，避免运行时的虚函数调用，提升 CPU 分支预测的准确度，提高 CPU 的利用率。

SIMD 指令集

SIMD 指令能够在一条指令集中处理更多的数据。SIMD 指令集的实现分为两种，其中一种是自动向量化实现。现代化的 C++ 编译器，可以智能地将一些函数转换为 SIMD 指令。比如图 2-5-10 所示的例子中，for 循环是一个简单的两个数组的相加计算，编译器会自动地把这样一条指令变成一个 SIMD 指令。

通过 SIMD 指令，整个算法的耗时可以从 100 多 ms 降低到 30 多 ms ，获得三倍的性能提升。这也就是说，通过对代码级别的改造以及编译器的自动编译优化，可以显著提升一些简单计算场景下的性能。

对于复杂的函数计算，编译器的自动向量化可能无法完成，因此需要开发者通过手写 SIMD 指令的方式，帮助提升一些算子的效率。通过编译器的自动向量化和手写向量化，可以极大地提升很多算子的效率。

通过向量化引擎的改造，Doris 在 ClickHouse 公司推出的

Clickbench（https://benchmark.clickhouse.com/ ）性能测试中，从众多数据库中脱颖而出，获得了前三的优异成绩。

稳定

Doris 1.0 的第二个主要特点就是“稳定”。

首先， Doris 的 MPP 执行引擎是基于内存的，即所有数据的处理都需要在内存中。不论是导入操作、查询操作，还是系统内部的任务，都会产生内存开销。所以 Doris 也是一个内存密集型的系统。如果没有一个优秀的内存管理框架，很容易出现 OOM （Out Of Memory）错误，从而降低在高负载场景下或者复杂查询场景下系统的稳定性。

在 1.0 版本中，Doris 重构了整体内存管理框架，目标就是 “对 OOM 说不”。

在 Doris 内部，我们通过 MemTracker 对内存进行管理和跟踪。MemTracker 是一个树状结构。根节点的 MemTracker 负责进程级别的内存总控，子节点由不同模块的 MemTracker 组成，比如查询模块的、导入模块的等。这些 Mem Tracker 共同组成了一个完整的内存管理和跟踪框架。

再进一步，不同模块的 MemTracker 还会有更细粒度的内存管理。比如针对查询模块，会对一个查询内部的多个执行分片，以及执行分片下面多个执行算子，生成一个树状的 MemTracker 结构，帮助我们观测一个查询任务的总内存开销、每一部分内存开销等，提升系统的可观测性。

在具体技术实现上，每一个工作线程开始运行工作任务时，都会生成线程级别的 MemTracker，同时还会基于 TcMalloc 的 Hook 机制，统一监控所有内存的申请和释放操作，保证不会遗漏任何一部分内存，使得整个内存是可控的且可被观测的。

内存管理的优化只是一个开始，后续 Doris 还会提供细粒度

的 CPU 管理、 I/O 管理以及负载隔离机制，使得不同的工作负载可以在同一个 Doris 集群中无干扰地运行，降低运维成本，提升使用体验。

多源

Doris 自 1.0 版本开始，就全面开展湖仓一体的生态建设。新版本中的多源数据目录（Multi-Catalog）功能，能够帮助用户自动同步和映射外部数据源的元信息，并提供多种优化技术来提升对外部数据源的查询能力。比如，通过元数据缓存的能力提升访问 HiveMetastore 等元数据服务的稳定性和性能。通过分区裁剪、谓词下推，以及对 Parquet 、ORC 等格式的文件裁剪、延迟物化、预读功能的支持，用户可以通过 Doris 获得比其他查询引擎快 3～10 倍的查询加速效果。

在新版本中， Doris 支持了 Hive 、Iceberg 、Hudi 、ES 、JDBC 等多种连接方式。用户可以将 Doris 作为查询加速层，在不进行数据迁移的情况下，直接分析湖上数据以及对多个数据源进行联邦查询。此外，在后续的版本中，Doris 会进一步支持湖仓能力，不仅提供对湖上数据的增量查询功能，而且提供自管理的数据湖表引擎，真正实现极速、统一的湖仓一体能力。

以上就是 Doris 在 1.0 时代最主要的三个方向的进展 —极速、稳定和多源。当然，除此之外， Doris 还在不断添加和优化更多特性，欢迎大家前往 doris.apache.org 官网进行探索。

2023 年， Doris 会进入 2.0 时代。2.0 将是一次全面的进化。Doris 会在多模数据分析、湖仓一体、ETL、实时数据更新、查询优化器、云原生等领域提供更多的功能，并进行更多的功能优化。

关于 Apache Doris 开源社区

Doris 在 2018 年进入 Apache 孵化器，并于 2022 年正式“毕业”，成为 Apache 顶级项目。整个社区的发展非常迅速，截至 2023 年 4 月，累计贡献者人数已接近 500，每月活跃开发者人数也超过 100 位。整个社区处于蓬勃发展的阶段，也欢迎更多的人加入社区，一起开发和使用 Doris。

作为一个 Apache 项目， Doris 也将秉承“社区大于代码”的 Apache 理念，不断面向开发者和用户推出更多的社区活动。

Doris 的 Github 地址是 https://github.com/apache/doris。

在 Github 上可以找到很多丰富的新手任务，不论是在校学生、职场新手，还是真正使用 Doris 的资深用户，都可以通过新手任务快速地加入 Doris 社区，在提升自身技术能力的同时，也帮助 Doris 社区更好地发展。