Apache Doris 极速数据湖分析技术细节公开！( 二 ) _数据湖

下图是新版本中架构变动的 Metadata 全景图：

文章插图

External Catalog 现已支持几种主要数据源和元数据中心。第一类就是 Hive Metastore 或者是兼容 Hive Metastore 的元数据中心。比如云上的 AWS Glue、阿里云的 Data Lake Formation 等。通过接入元数据中心，可以方便地把元数据中心中记录的库表信息自动同步到 Doris 里来。支持的表格式包括 Hive 的表、Iceberg 的表、Hudi 的表等等。这些表都可以进行统一的管理。第二类是 JDBC Catalog，理论上可以接入任何支持 jdbc 连接协议的数据库。当前只支持了 MySQL，接下来很快会支持 PostgreSQL、SQL Server、Oracle、ClickHouse 等等这些支持 jdbc 连接协议的数据库。第三类是 ElasticSearch 。Doris 在之前版本中就对 ES 有非常好的支持，可以为 ES 提供一个完备的分布式的查SQL 询能力。在新版本中，通过引入 ES catalog，更方便的去对接 ES 数据源。这样用户不用再一张一张表的去做元数据的映射，可以很快地帮助用户去分析这些外部数据源的数据。同时，在代码设计层面，Doris 也对整个 Catalog 做了一层抽象，包括 Catalog 层级、database 层级和 table 层级都做了接口的抽象。开发者可以通过这些接口，扩展自己的数据源。
第二个架构变动就是数据访问上的功能统一。

文章插图

Doris 是一个极速 OLAP 数据库，拥有性能优异的分布式查询引擎。我们希望对外部数据源的查询加速，能够充分利用现有查询引擎的优势。在查询引擎中，上层计算节点的算子的优化，比如 join 的优化，聚合节点的优化、scan 调度的优化等等，与数据源本身是无关的，它本身是查询层的一些优化。所以我们对查询层进行了代码结构的重构，把一些公共部分提取出来，这些公共部分可以帮助我们去利用 Doris 完备的极速向量化引擎、基于代价的查询优化器、以及各类算子的优化。同时，也重构了底层的 scan 任务的调度，如 scan 的并发度、CPU 时间分片的调度等，以确保这些功能能够被内部数据和外部数据源共同使用。
在做完这些架构调整之后，对于外表查询或者数据湖上的数据查询，开发者只需要关注数据源自身的一些访问特性。比如对于 Hive 表查询，我们可以实现一个 FileScanNode 的，专注于对远端存储上的文件的扫描优化。对于特定的数据格式，我们只需要实现对于特定数据格式的 format reader 。如此一来，开发者在接入一个数据源时，只需专注于处理数据，扫描相关的一些优化和数据源访问的一些特性的优化，而不需要去关心整个查询层的优化措施。通过这个架构调整，对一个新的数据源接入，只需要大概一周的时间就可以完成，同时可以利用到所有已经存在的优化能力去加速数据源的查询。
接下来看一下数据源访问的整体流程：

文章插图

熟悉 Doris 的同学都知道，Doris 分为两个部分：FE 节点和 BE 节点。FE 节点是 JAVA 写的，主要负责用户请求的接入，元数据管理，查询查询计划生成；BE 节点是 C++ 写的，负责数据的存储和查询计划的执行，它是一个高性能的分布式查询执行进程。
以 Hive 为例，当我们通过 Doris 去查询一张 Hive 表的时候，首先用户请求进入到 FE，第一步是通过 Hive Metastore 去获取 table 的 schema，接着获取 partition 。获取到 partition 以后，FE 会根据 SQL 中的分区的值的谓词条件对分区进行裁剪，得到最终的分区列表。拿到分区列表以后，再去访问 Hive Metastore 去获取分区所对应的文件列表。获取到文件列表以后，第五步就是在 FE 中对文件扫描任务进行拆分，均匀分布到所有的 BE 节点上，保证一个查询任务，可以充分的利用整个集群的计算资源进行数据查询。任务分配完以后会下发给 BE，BE 的逻辑就比较简单，只需要对指定文件进行扫描、过滤和读取。第七步，它会直接去访问 HDFS 或者 S3 上的数据，进行数据的读取。接下来上层会有一些中文节点，agg 节点，join 节点等等的一些查询执行。最终把它的结果返回给用户。这就是 Doris 通过 Hive Metastore 去查询 Hive 外表的整体流程。
接下来介绍一下在整个流程中 Doris 有哪些优化。