关于数据湖:查询性能较-TrinoPresto-310-倍提升Apache-Doris-极速数据湖分析深度解读

从上世纪 90 年代初 Bill Inmon 在《building the Data Warehouse》一书中正式提出数据仓库这一概念，至今已有超过三十年的工夫。在最后的概念里，数据仓库被定义为「一个面向主题的、集成的、绝对稳固的、反映历史变动的数据汇合，用于反对管理决策」，而数据湖最后是为了解决数仓无奈存储海量且异构的数据而构建的集中式存储系统。

时代的倒退与用户数据利用诉求的演进，催生了数据架构的一直变革，也衍生了更简单的技术状态。能够清晰看到古代数据架构从计算到存储都在向着交融对立的方向倒退，新的数据湖范式被提出，这也是 Lakehouse 诞生的背景。作为一种全新的、开放式的数据管理架构，Lakehouse 提供了更强的数据分析能力与更好的数据治理能力，也保留了数据湖的灵活性与开放式存储，为用户带来更多价值：

• 从存储的角度：对立数据集成，防止冗余存储以及跨零碎间 ETL 带来的沉重工程和失败危险；
• 从治理的角度：反对 ACID、Schema Evolution 与 Snapshot，数据与元数据皆可治理；
• 从利用的角度：多引擎拜访反对、可插拔，通过对立接口进行数据拜访，同时实用于多种工作负载 Workload；
• ……

如果咱们把 Lakehouse 从零碎层面进行解构，会发现除了须要 Apache Iceberg、Apache Hudi 以及 Delta Lake 等数据湖表格局（Table Format）以外，高性能剖析引擎更是充分发挥湖上数据价值的要害。

作为一款极速易用的开源实时 OLAP 数据库，Apache Doris 自 0.15 版本即开始尝试在 Apache Iceberg 之上摸索与数据湖的能力联合。而通过多个版本的优化迭代，Apache Doris 在数据湖剖析曾经获得了长足的停顿，一方面在数据读取、查问执行以及优化器方面做了诸多优化，另一方面则是重构了整体的元数据连贯框架并反对了更多内部存储系统。因而 Apache Doris 曾经齐全具备了构建极速易用的 Lakehouse 架构的能力，并且也已在多个用户的实在业务场景中失去验证和推广，咱们心愿通过 Apache Doris 能为用户在更多场景中带来价值：

1. 湖仓查问减速

   1.   利用 Apache Doris 优良的分布式执行引擎以及本地文件缓存，联合数据湖凋谢格局提供的多种索引能力，对湖上数据及文件提供优良的查问减速能力，相比 Hive、Presto、Spark 等查问引擎实现数倍的性能晋升。

2. 对立数据分析网关

   1.   利用 Apache Doris 构建欠缺可扩大的数据源连贯框架，便于疾速接入多类数据源，包含各种支流关系型数据库、数据仓库以及数据湖引擎（例如 Hive、Iceberg、Hudi、Delta Lake、Flink Table Store 等），提供基于各种异构数据源的疾速查问和写入能力，将 Apache Doris 打造成对立的数据分析网关。

3. 对立数据集成

   1.   基于可扩大的连贯框架，加强 Doris 在数据集成方面的能力，让数据更便捷的被生产和解决。用户能够通过 Doris 对上游的多种数据源进行对立的增量、全量同步，并利用 Doris 的数据处理能力对数据进行加工和展现，也能够将加工后的数据写回到数据源，或提供给上游零碎进行生产。该能力使得 Apache Doris 可能成为业务的对立数据枢纽，升高数据流转老本。

4. 更加凋谢的数据生态

   1.   通过对 Parquet/ORC 等数据格式以及凋谢的元数据管理机制的反对，用户不必再放心数据被特定数据库引擎锁定，无奈被其余引擎拜访，也不必再为数据的迁徙和格局转换付出昂扬的工夫和算力老本，升高用户的数据迁徙老本和对数据流通性的顾虑，更便捷、释怀地享受 Apache Doris 带来的极速数据分析体验。

基于以上的场景定位，咱们须要进一步去思考在构建 Lakehouse 过程中须要如何去设计和革新零碎，具体包含：

• 如何反对更丰盛的数据源拜访以及更便捷的元数据获取形式；
• 如何晋升湖上数据的查问执行性能；
• 如何实现更灵便的资源调度与负载治理；

因而本文将重点介绍 Apache Doris 在 Lakehouse 上的设计思路和技术细节，同时会为大家介绍后续的倒退布局。

元数据连贯与数据拜访

截至最新的 1.2.2 版本，Apache Doris 曾经提供了十余种的数据湖格局和内部数据源的拜访反对。同时也反对通过 Table Value Function 间接对文件进行剖析。

为了反对这些数据源，Apache Doris 别离在 元数据连贯 和数据拜访 两方面做了大量的架构调整和性能优化 。

元数据连贯

元数据包含数据源的库、表信息、分区信息、索引信息、文件信息等。不同数据源的元信息格式、组织形式各有不同，对于元数据的连贯须要解决以下问题：

1. 对立的元数据结构：屏蔽不同数据源的元数据差别。
2. 可扩大的元数据连贯框架：低成本、疾速地接入数据源。
3. 高效的元数据拜访能力：提供牢靠、高效的元数据拜访性能，并反对实时同步元数据变更。
4. 自定义鉴权服务：可能灵便对接内部的权限管理系统，升高业务迁徙老本。

对立的元数据结构

在过来 Apache Doris 的元数据只有 Database（数据库）和 Table（表）两个层级，当内部数据目录 Schema 发生变化或者内部数据目录的 Database 或 Table 十分多时，须要用户手工进行一一映射，保护量十分大。因而在 Apache Doris 1.2.0 版本中新增了 Catalog（数据目录）层级，提供了疾速接入内部数据源的能力。

Catalog 层级的引入解决以下问题：

1. 数据源层级的映射：用户不再须要在 Database、Table 层级进行一一映射，能够通过 Catalog 间接映射整个数据源，主动同步其中的所有元信息，简化元数据映射逻辑
2. 数据源对立信息管理：在 Catalog 层级对立保护指定数据源的属性，如连贯信息、权限信息、同步形式等，更不便的治理多个数据源。

引入 Catalog 层级后，咱们也对 Doris 的元数据进行调整和划分：

1. Internal Catalog：原有的自治理的 Table 和 Database 都归属于 Internal Catalog。
2. External Catalog：用于对接其余非自治理的内部数据源。比方 HMS External Catalog 能够连贯到一个 Hive Metastore 治理的集群、Iceberg External Cataog 能够连贯到 Iceberg 集群等。

用户能够应用 SWITCH语句切换不同的 Catalog，也能够通过全限定名不便的进行 跨数据源的联邦查问，如：

SELECT * FROM hive.db1.tbl1 a JOIN iceberg.db2.tbl2 b
ON a.k1 = b.k1;

相干文档：https://doris.apache.org/zh-C…

可扩大的元数据连贯框架

基于新的元数据层级，用户能够通过 CREATE CATALOG语句不便的增加新的数据源：

CREATE CATALOG hive PROPERTIES (
    'type'='hms',
    'hive.metastore.uris' = 'thrift://172.21.0.1:7004',
);

在数据湖场景下，目前 Doris 反对的元数据服务包含：

• Hive Metastore 兼容的元数据服务
• Aliyun Data Lake Formation
• AWS Glue

同时，开发者也能够自行扩大 External Catalog，只须要实现对应的拜访接口，即可在 Doris 中疾速接入新的元数据服务。

高效的元数据拜访

元数据存储在内部数据源中，而对外部数据源的拜访受到网络、数据源资源等限度，性能和可靠性是不可控的。所以 Doris 须要提供高效、牢靠的元数据服务以保障线上服务的稳固运行，同时 Doris 也须要实时感知元数据的变更，晋升数据拜访的实时性。

Doris 通过内存中的 元数据缓存 提供高效的元数据服务。元数据缓存包含 列信息缓存 ， 分区缓存 ， 文件缓存。 通过元信息缓存，能够显著晋升元数据拜访性能并升高对外部元数据服务的申请压力，使得 Doris 能够应答数千张表，数十万分区场景下，毫秒级别的元数据查问 响应 。**

Doris 反对在 Catalog/Database/Table 级别，对元数据缓存进行手动刷新。同时，针对 Hive Metastore，Doris 还反对通过监听 Hive Metastore Event 主动同步元数据，提供元数据秒级实时更新能力。

自定义鉴权服务

内部数据源通常领有本人的权限治理服务，而很多企业也会应用对立的权限管理系统（例如 Apache Ranger）来治理多套数据系统。Doris 反对通过自定义鉴权插件对接企业外部已有的权限管理系统，从而能够低成本的接入现有业务，实现受权、审计、数据加密等操作。**

具体实现上，用户能够基于 Doris 的 AccessController 接口实现插件对接相应的权限管理系统，并在创立 Catalog 时，指定对应的鉴权插件。通过这种机制，所有通过 Doris 对外部数据源的拜访，都将对立应用自定义的插件实现鉴权、审计等操作。

数据拜访

内部数据源的数据拜访，次要集中在对存储系统的拜访反对上。在数据湖场景下，次要是对 HDFS 以及各种 S3 兼容的对象存储的反对。目前 Apache Doris 反对的存储系统如下，并且仍在一直减少中：

性能优化

在实现数据源的连贯和拜访后，下一个问题是咱们如何联合 Apache Doris 本身优异的查问性能以及各类存储系统的个性，进行针对性的查问性能优化，这也是在 构建 Lakehouse 过程中最须要解决的问题和衡量的因素。在具体实现过程中，Apache Doris 别离在 数据读取、执行引擎、优化器 方面进行了诸多优化。

数据读取

湖上数据通常存储在远端存储系统上，相较于本地存储，在数据的拜访提早、并发能力、IO 带宽上人造存在肯定劣势。因而，在数据读取上，Apache Doris 从缩小远端读取频率，升高读取量等方面登程进行了粗疏的优化。

Native File Format Reader

Parquet 和 ORC 是最常见的凋谢数据格式，这些数据格式自身提供了包含索引、编码、统计信息在内的多种个性，如何针对格局个性来晋升文件读取效率是性能优化的要害一步。在晚期的实现中，Apache Doris 是通过 Apache Arrow 来读取 Parquet/ORC 数据文件的，但这种形式存在以下问题：

1. 数据格式转换的开销：Arrow Reader 须要先将文件读取成 Arrow 的内存格局，再转换到 Doris 本人的内存格局，两次数据转换带来额定的开销。
2. 无奈反对高级文件格式个性。如不反对 Parquet 的 Page Index，不反对 Bloom Fitler，无奈实现谓词下推、提早物化等性能。

基于以上问题，咱们对 Flile reader 进行了重构，实现了全新的 Native File Format Reader。这里咱们以 Parquet Reader 为例，介绍 Doris 的文件格式读取方面所做的优化：

1. 缩小格局转换。新的 File Reader 间接将文件格式转换成 Doris 的内存格局，并能够间接利用字典编码等性能转换到对应的更高性能的内存格局，以晋升数据转换和解决的效率。
2. 细粒度的智能索引。反对了 Parquet 的 Page Index，能够利用 Page 级别的智能索引对 Page 进行过滤。相比之前只能在 Row Group 级别过滤，Page Index 过滤粒度更细、过滤成果更好。
3. 谓词下推和提早物化。提早物化的根本逻辑是先读取有过滤条件的列，再应用过滤后的行号读取其余列。这种形式能显著升高文件的读取量。这一点在近程文件读取场景下尤为重要，能够最大限度缩小不必要的数据读取。
4. 数据预读。 将屡次文件读取合并成一次，充分利用远端存储高吞吐、低并发的个性，进步数据的总体吞吐效率。

File Cache

利用本地高性能磁盘对远端存储系统中的文件进行本地缓存，能最大限度的缩小近程数据读取的开销，同时能够提供靠近 Doris 外部表数据的拜访性能。在本地文件缓存方面 Doris 进行了如下优化：

1. 文件块缓存（Block Cache）。反对对远端文件进行 Block 级别的缓存。Block 的大小会依据读取申请主动调整，从 4KB 到 4MB 不等。Block 级别的缓存能无效缩小缓存导致的读写放大问题，优化缓存冷启动场景下的数据读取提早。
2. 缓存一致性哈希。通过一致性哈希算法对缓存地位和数据扫描工作进行治理和调度，充分利用已缓存的数据提供服务，并防止节点高低线导致缓存大面积生效的问题，晋升缓存命中率和查问服务的稳定性。

通过 Flie Cache，在命中缓存的状况下，Apache Doris 能够提供和本地表统一的查问性能。

执行引擎

在执行引擎层面，咱们心愿可能齐全复用 Apache Doris 的向量化执行引擎以及各类执行层面的算子优化，为数据湖提供极速的查问体验。因而，Apache Doris 对数据扫描（Scan）节点进行了重构，使得每一种新的数据源的接入，开发者只须要关注数据源自身的拜访逻辑，无需反复地开发通用性能。

1. 通用查问能力的分层

包含内表在内的所有数据查问，都会应用雷同的 Join、Sort、Agg 等算子。惟一不同在于数据源的拜访形式上，例如对本地外部格局数据的读取，或存储在 S3 上的 Parquet 格局数据的读取。因而 Doris 将不同数据源的查问逻辑差别下推到最底层的 Scan 节点上。Scan 节点之上，所有查问逻辑对立，Scan 节点之下，由具体的实现类负责不同数据源的拜访逻辑。

1. Scan 算子的通用框架

对于 Scan 节点，不同数据源也有很多共性的方面，如子工作的拆分逻辑、子工作的调度、IO 的调度、谓词下推以及 Runtime Filter 的解决等。因而咱们也对这一部分架构进行了重构。首先，将共性局部都以接口的模式对外裸露，如子工作的拆分、下推谓词的解决等；其次，对子工作实现了对立的调度治理逻辑，能够由对立的调度器治理整个节点 Scan 工作的执行。调度器领有节点全局的信息，能够不便的实现更细粒度的 Scan 任务调度策略。在这样的对立的数据查问框架下，大概 1 人周就能够实现一种新数据源接入。

查问优化器

查问优化器层面的优化集中在 统计信息收集 和代价模型的推导 方面。

Apache Doris 反对对不同数据源的统计信息收集，如 Hive Metastore、Iceberg Metafile、Hudi MetaTable 中存储的统计信息等。同时在代价模型推导方面，咱们也针对内部数据源的个性做了粗疏的调整。基于这些优化，Doris 能够为简单的表面查问提供更优的查问布局。

性能比照

以上优先项，咱们别离在 宽表场景 （Clickbench）和 多表关联场景（TPC-H）下与 Presto/Trino 进行了 Hive 数据集的查问性能比照。

能够看到，在雷同计算资源和数据集下，无论是宽表场景或多表关联场景，绝大多数 SQL Apache Doris 的查问耗时都是大幅低于 Presto/Trino ，整体性能 相比 Presto/ Trino 有 3-10 倍的晋升。

负载治理与弹性计算

对外部数据源的查问并不依赖 Doris 的数据存储能力，这也为 Doris 实现弹性的无状态计算节点成为可能。在行将公布的 2.0 版本中，Apache Doris 还实现了弹性计算节点性能（Elastic Compute Node），能够专门用于反对内部数据源的查问负载。

因为计算节点是无状态的，因而咱们能够对这类节点进行疾速扩缩容，以灵便地应答峰谷期的查问负载，在查问性能与老本耗费之间获得更好的均衡。

同时，Doris 也针对 k8s 场景下的集群治理和节点调度进行了优化，Master 节点能够主动治理弹性计算节点的高低线，不便业务在云原生场景、混合云场景下都能便捷的治理集群负载。

案例实际

随着以上性能的欠缺与性能的晋升，Apache Doris 曾经被多家社区用户利用于数据湖剖析，在实在业务中施展着重要的作用，在此以某金融企业的风控场景为例。

金融风控场景往往对数据的实时性有着更高的要求，晚期基于 Greenplum 和 CDH 搭建的风控数据集市曾经无奈满足其高时效性的需要，T+1 的数据生产模式成为业务迅速倒退的掣肘，因而该企业于 2022 年引入 Apache Doris 并革新了整个数据生产和利用流程，实现对 Elasticsearch、Greenplum 以及 Hive 的联邦剖析，整体成果包含：

• 只需创立一个 Hive Catalog 即可对现存的数万张 Hive 表进行查问剖析，查问性能失去极大幅度晋升；
• 利用 Elasticsearch Catalog 实现对 ES 实时数据的联邦剖析，数据时效性从过来的分钟级晋升至秒级甚至毫秒级，满足了风控策略的实时性要求；
• 将日常跑批与统计分析进行解耦，升高资源耗费的同时使零碎稳定性失去进一步加强。

将来布局

后续 Apache Doris 将继续在 Lakehouse 方向进行迭代和降级，下一步的工作将围绕在 更丰盛的数据源反对 、 数据集成 和资源隔离与调度 等方面：

更丰盛的数据源反对

随着数据湖在各种业务场景中的一直落地，数据湖自身的性能也在一直迭代以满足越来越多样的业务需要。Doris 也将和各个开源社区严密单干，提供更欠缺的数据湖剖析反对。

• Hudi Merge-On-Read 表的 Incremental Query 反对
• 利用 Iceberg/Hudi 丰盛的索引性能，联合查问优化器提供更低提早的剖析性能。
• 反对包含 Delta Lake、Flink Table Store 等更多数据湖格局。

数据集成

具体到性能层面，数据集成能够分为数据的 读取 和写回 两局部。

数据读取方面，Doris 将进一步整合数据湖的数据拜访个性，包含：

• 数据湖 CDC 的接入以及增量物化视图的反对，为用户提供近实时的数据视图。
• 反对 Git-Like 的数据拜访模式，通过多版本、Branch 等机制，在数据安全、数据品质等方面为用户提供更便捷的数据管理模式。

数据写回性能的反对，帮忙 Doris 进一步欠缺对立数据分析网关的生态闭环。用户能够应用 Doris 作为对立数据管理入口，治理各个数据源中的数据，包含加工后数据的写回、数据导出等，对业务提供对立的数据视图。

资源隔离与调度

随着越来越多数据源的接入，Doris 也在逐渐承接不同的工作负载，比方在提供低提早的在线服务的同时，对 Hive 中 T-1 的数据进行批量解决。所以同集群内的资源隔离会愈发重要。

Doris 会继续优化弹性计算节点在不同场景下的调度治理逻辑，同时会反对更细粒度的节点内资源隔离，如 CPU、IO、内存等，帮忙 Doris 反对多样且稳固的工作负载。

退出咱们

目前社区已成立 Lakehouse SIG（湖仓兴趣小组），会集了来自多家企业的开发者，旨在独特打造 Apache Doris 的 Lakehouse 场景反对，欢送感兴趣的同学退出咱们。

# 相干链接：

SelectDB 官网：

https://selectdb.com 

Apache Doris 官网：

http://doris.apache.org

Apache Doris Github：

https://github.com/apache/doris