每日一句正能量

当一个人推诿责任的时候，他忘了勇于承担是一种习惯。

前言

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

作者介绍

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

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

---

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

Apache Doris 特性

Doris 数据流程如图 2-5-1 所示。

图 2-5-1 Doris 数据流程图

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

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

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

极简架构

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

图 2-5-2 Doris 极简架构

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

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

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

高效自运维

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

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

图 2-5-3 Doris 高效自运维

整个故障修复过程不会影响用户使用 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 执行引擎示意如图 2-5-4 所示。

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

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

图 2-5-4 Doris 内部 MPP 执行引擎示意

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

明细与聚合模型的统一

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

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

图 2-5-5 Doris 明细 + 聚合

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

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

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

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

便捷数据接入

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

图 2-5-6 便捷的数据接入

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 中的数据是 按行排列的，这种内存布局对向量化计算框架不友好，所以向量 化引擎改造的第一步就是把整个行式内存布局改为列式内存布 局，即采用图 2-5-7 中右边部分（Block）数据结构。可以看到， 在 Block 数据结构中数据是按列排列的，这种布局可以充分利用

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

图 2-5-7 列式内存分布

向量化的计算框架

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

图 2-5-8 向量化的计算框架

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

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

Cache 亲和度

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

虚函数调用

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

图 2-5-9 虚函数调用

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

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

SIMD 指令集

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

图 2-5-10 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、实时数据更新、查 询优化器、云原生等领域提供更多的功能，并进行更多的功能 优化。

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

作者介绍

栾小凡，Zilliz 合伙人与工程总监、LFAI & Data 基金会技 术咨询委员会成员、康奈尔大学计算机工程硕士。先后任职于 Oracle 美国总部、软件定义存储创业公司 Hedvig、阿里云数据库 团队，曾负责阿里云开源 HBase 和自研 NoSQL 数据库 Lindorm 的研发工作。

图书推荐

随着云计算和生成式 AI 的逐渐发展，基础软件的技术栈也在发生变化，市场现存的基础软件领域的图书相对较少，且多数最近两年没有更新。但是，基础软件领域已经发生了巨大变化，我们现在所讲的基础软件是以云、AI 为底座的基础软件，这些新的变化都可以在《基础软件之路：企业级实践及开源之路》这本书里找到答案。

购买链接

• 正版购买链接：https://item.jd.com/14328126.html

赠书活动

• 🎁本次送书1~4本，【取决于阅读量，阅读量越多，送的越多】👈
• ⌛️活动时间：截止到2024年3月02日
• ✳️参与方式：关注博主+三连（点赞、收藏、评论）

转载自：https://blog.csdn.net/u014727709/article/details/136233472
欢迎 👍点赞✍评论⭐收藏，欢迎指正