什么是 Apache Doris？繁难来说，Doris 是一款基于 MPP 架构的高性能实时的剖析型数据库。
下图是 Doris 的开展历程。最早可以追溯到 2013 年。
它是百度外部自研的一个多维剖析平台。经过了几年在百度外部大规模的运行和通常，2017 年的时刻，正式开源到 Github 上。在 2018 年 Doris 进入到 Apache 孵化器，在孵化的环节中，不时开展社区，造就用户和开发者。到目前为止，在孵化期内发布了七个关键的版本，每月的生动开发者凑近一百位。在 2022 年，Doris 从 Apache 孵化器毕业，成为一个顶级名目。成为顶级名目之后，咱们也加快的推进社区的开展。在 2022 年 12 月份发布了 Doris 1.2.0 版本。这一版本中有很多关键配置更新。其中很关键的一局部就是对数据服务才干的优化和允许。这也是本次分享的重点。
下图中可以看到 Doris 在整个数据流中的定位：
它的抢先有一些 OLTP 系统，日志系统，埋点系统。经过一些流处置或许说批处置，比如 Sparquet，Hive，Flink 等等。经过加工和处置之后，会把处置后的结构化数据存储在 Doris 中。Doris 自身是一个领有完备 MPP 架构的数据仓库。它可以间接对外提供报表剖析、消息查问，以及数据库剖析等配置。同时它也可以作为一个 SQL 引擎，对外部的数据源启动查问减速，包括 Hive ，Iceberg，Hudi 等等。也允许 MySQL，ElectricSearch 等内部数据源。同时，也提供了官方的 Flink Connector 和 Spark Connector。用户可以经过这两类 Connector，繁难的去把 Doris 存储中的数据和其它数据源的数据启动联邦剖析查问，保障 Doris 最终的数据不会成为数据孤岛。
这就是 Doris 在整个数据流中的定位，以及它是如何在企业数据流中施展价值的。
接上去进入本文的重点，也就是 Doris 的数据湖剖析内情。
先来讲一下什么叫 数据湖剖析 。其实 Doris 自身是一套完备的数据库治理系统，包括查问层和存储层。在咱们反经常常使用 Doris 的时刻，只要要把数据灌入到 Doris 中来，就可以在 Doris 外部对数据启动治理、存储和查问，咱们叫做内置数据存储（Internal Storage）或许说自治理的数据存储（Self-Managed Storage）。在实践业务运行中，还会有少量数据存储在外部数据源中的，比如或许有很多历史数据，自身曾经存在 Hive 系统中，或许是最近比拟火的 Iceberg、Hudi 等数据湖格局中。假设用户要把这些系统中的数据经过导入操作导入到 Doris 中来，代价是十分大的，由于数据量或许是 TB 甚至 PB 级别的。把这些数据启动一次性清算加工的计算量和存储开支都是十分大的。所以很多用户宿愿借助 Doris 的高速查问才干，间接对外部数据源的数据启动剖析。这也是 Doris 数据湖剖析、或许外部数据源减速剖析的一个初衷。
在早期的 1.0.0 版本中，Doris 就曾经允许了对外部数据源的一些访问，比如对 Hive 外表的创立，对 Iceberg 外表的创立，或许对 MySQL 外表的创立。然而在老版本中创立这些外部数据源的映射时，只能经过表级别的映射。这会带来一个疑问，比如这些表或许多达几十上百张，甚至是上千张，假设驳回这种模式，用户要求对每一张表经过 create external table 这种模式去独自地建设一个映射相关，这是一个很费时费劲的上班。
所以在 Doris 的新版本中，经过引入 Catalog 的概念，简化这一操作，让用户可以经过一行命令就能加快开局对外部数据启动剖析。
Catalog 是规范 SQL 定义中的三个层级之一，就是 Catalog-Database-Table。咱们将 Catalog 分为两大类，一类是 Internal Catalog，另一类是 External Catalog。其中Internal Catalog是治理 Doris 的外部表。External Catalog可以间接映射到一个数据源。比如一个 Hive 集群、 ES 集群、 MySQL 数据库等等。经过数据源映射，Doris 外部会智能的把外部的>
下图是新版本中架构变化的 Metadata 全景图：
ernal Catalog 现已允许几种关键数据源和元数据中心。第一类就是 Hive Metastore 或许是兼容 Hive Metastore 的元数据中心。比如云上的 AWS Glue、阿里云的>第二个架构变化就是数据访问上的配置一致。
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 有哪些优化。
第一点优化就是对元数据和数据访问的优化。一些表的元数据消息是十分大的，比如一张 Hive 表或许有十万个分区，假设把十万个分区消息在一开局的时刻就全都同步到的 FE 节点，对 FE 节点内存压力会十分大。由于 Doris 中一切的元数据都是在内存寄存的，假设把这些外部数据源的消息全都一次性性同步过去的话，FE 的元数据压力会十分大。所以咱们在 FE 上做了多种类型的 cache。
第一种是schema cache，关于外表的一切列消息的 cache。这些 cache 全都是按需加载的。比如咱们有一千张表，只要要访问到其中的一张表的时刻，咱们才会把这张表的 schema 缓存到 FE 的缓存集中。这样可以保障内存中只要要求用到的 schema。
第二个是partition value cache。当查问一个外表时要求对分区启动裁剪。分区裁剪只要经常使用分区值。所以咱们独自成功了一个 partition value cache 专门去缓存分区值的消息，用于分区裁剪。分区值的内存空间占用是十分少的。经过火区值裁剪，可以失掉最终要求访问的分区列表。
当失掉分区列表，就进入到第三步，即要求访问 partition cache 去拿到完整的分区消息。拿到这些消息，咱们就到来第四步，就是 file cache。一个分区上方会有多个文件。咱们拿到了分区的位置消息，就可以经过 file cache，去失掉这个分区下的一切的文件的消息（文件门路）。拿到 文件门路后，咱们在 FE 中会做义务的拆分。最终会把这些文件列表拆分，发给 BE。
BE 节点担任文件的读取和访问。这里咱们也成功了两个大类的缓存的优化。
第一个是数据预读（prefetch buffer），在访问 HDFS 和 S3 时，实质是一个 RPC 恳求。第一个优化点就是如何能够尽量缩小 RPC 的开支。一次性 RPC 开支自身的 overhead 很重。所以咱们参与了一个预取缓存，把多个小的 Remote IO 恳求兼并成一个大的 IO 恳求，把原先或许几个字节的恳求，兼并成 4KB 到 1MB 的数据恳求一次性性读取过去，在本地内存中构成一个缓存。后续的 IO 可以间接在内存缓存中去失掉数据，极大的缩小 remote IO 的次数。
第二个是文件块级别的缓存（file block cache）。在访问 HDFS 或许 S3 上的数据文件时，或许只要访问其中的一小局部。比如一个列存格局的 parquet 文件，假设只要要访问其中的三列数据，那么只会读取整个文件的一局部，Doris 会在第一次性文件读取时，将读取的文件块缓存到本地磁盘。缓存文件的文件 名是文件的门路，加上读取偏移量的组合标识。之后假设有相反的文件访问，会先检查本地能否曾经有缓存的数据文件。假设有，则间接去读本地文件，缩小访问远端数据的开支。经过 file block cache，可以极大地优化一些热数据的访问效率。
第二个优化点就是native 的 file format reader。以 parquet 为例，在老版本的 Doris，是经过 Apache arrow 库内置的 parquet reader 成功读取的。这个 Reader 的成功会有一些额外的开支。比如它会多一层内存格局的转换。由于它在读取的时刻，首先要求把远端的文件转换成外部的 arrow 的格局。而后再把 arrow 的格局转换成 Doris 的外部内存格局。第二是 Apache arrow 内置的 parquet reader 对一些新的 Parquet 个性是不允许的，比如不允许 page index、不允许 parquet 的 bloom filter 的读取、不允许这种更精细的字典编码的优化等等。
基于以上思考，咱们在 Doris 外部成功了一个 native 的 C++ 的 parquet reader。首先是能间接转换外部存储格局，关于读取到的数据，间接转为外部内存格局，缩小一次性内存格局的拷贝和转换开支；第二点，咱们能够应用 bloom filter 启动更准确的数据过滤。用户写数据的时刻，对某一列经常使用的 bloom filter，可以应用 bloom filter 去对数据启动过滤。其次咱们也允许了基于字典编码的谓词过滤，可以把谓词下推到 parquet reader 中。把谓词中的，比如 “a=‘北京’” 这样的一个条件改成一个对应字典编码的值。比如 “a=‘100’”，后续用 ‘100’ 在文件外部启动数据过滤。由于整数型的过滤成果是比字符串的过滤成果要好很多的。过滤完了，在最终前往结果的时刻，咱们再把字典编码值转换成真正的数据的值。这样来到达减速的成果。
最后一点也是十分关键的一点，就是在 Parquet Reader 上允许了提前物化。提前物化是访问远端存储的时刻，缩小 IO 的一个十分关键的个性。尤其是在带谓词条件的宽表查问上。繁难来说，Doris 会优先读取带谓词条件的列。读取完这些列，咱们先对这些列启动过滤失掉最终过滤后的行号汇合，再去读取残余的其余的列。这样就能保障残余其余列都是只会去读取过滤后的数据。从而极大地缩小从远端去读取数据的 IO 开支。
第三点 就是弹性计算节点（compute node）。当咱们去访问外部数据源的时刻，Doris 自身是不会去存储这些数据的，所以不要求 BE 节点自身的存储才干。一旦咱们不再要求 BE 的存储才干，它就变成了一个有形态的节点。当一个节点是有形态的，删除节点或许参与节点时都要思考到数据如何安保下线，数据如何迁徙，从新 rebalance。而一个有形态节点可以十分繁难的启动弹性扩缩容。所以咱们在新的版本中给 BE 节点参与了两种类型：
第一种类型是 mix node，mix 就是规范的 BE 类型。既允许数据计算，也允许本地的文件存储；第二种类型叫 compute node，即计算节点，计算节点可以很繁难的启动弹性伸缩。比如可以很加快地在新机器或许云上创立一些新的 compute node。这些 compute node 可以分担访问远端存储的一些计算的开支。经过这种有形态的 BE 节点，可以加快去承接外部数据源的计算负载。来到达弹性伸缩的目标。
下图是咱们在版本发布之初做的一个测试。
可以看到在同一资源规格下，咱们去查问 Iceberg TPCH 100G 的数据集。相比 Trino，Doris 有三到五倍的性能优化。
最后看一下 Doris 对数据湖的一些配置的允许水平：
is 允许三个干流的外部数据服务或许数据仓库。第一个就是Hive，允许 Managed table 和 External table。允许 parquet、orc 和 text 格局的读取。Iceberg完整的允许 V1 Format，V2 允许了 position delete。Hudi临时只允许 MOR 的表，包括 COW Snapshot Query 以及 MOR Read Optimized Query。
三、Doris 社区开展以及前期开发布局
最后引见一下咱们在数据湖剖析这块的一些布局。
第一个布局就是增量数据访问。增量数据也是 Iceberg，Hudi 这类新兴的数据库系统所提供的**价值之一。它可以运行于 A/B Test，或许是用其 Time Travel 的才干、CDC 的才干来启动增量数据的处置和访问。Doris 在后续也要对这一类的配置启动允许。其次就是基于增量数据的视图查问。比如咱们会经过基于增量数据的多表的物化视图的更新，或许逻辑视图的权限控制等等，来协助用户很好的去治理数据湖上的数据，并且能够对数据启动很精细的访问。
第二点就是数据湖写入才干。刚才咱们引见这些配置时刻，其实都是在引见如何去访问和读取这些外部数据源的才干。假设用户想完整的访问治理这些数据源的话，必需在外部对接例如 Spark 这些系统启动数据写入。所以咱们后续宿愿在 Doris 外部提供一致的操作入口，来消弭用户操作数据的割裂感，来保障对数据库的写入操作和查问操作，都可以一致在 Doris 中成功。
最后一点是深化集成 Iceberg 的才干。宿愿以 Doris 自身作为 Iceberg 的元数据中心来提供托管 Iceberg 的才干，优化自身关于数据湖，或许说是对结构化、半结构化大规模数据的治理才干。
以上就是对 Doris 数据湖的一些引见。最后繁难引见一下 Doris 社区现状和未来布局。
Apache Doris 是国际最生动的开源社区之一。
累计奉献者人数曾经超越了四百位，平均每月的生动用户奉献者人数也超越了一百人。可以看到咱们每个月所提交的 commit 量和 push 量都是相当可观的，开展也是十分加快的。也欢迎对散布式数据库或许对 MPP、OLAP 数据库感兴味的同窗参与到社区中来，咱们可以一同去完善这样的一个数据库系统。
下图是 Doris 在 2022 年底到 2023 年终的一个大抵布局：
首先咱们在 2022 年的 Q4 季度，发布了 1.2.0 版本。在该版本中，成功了多元数据目录，其中就包括数据剖析这局部的一些才干；其次咱们还参与了半结构化数据的一些允许，包括 Array 和 Binary Json 格局的允许；咱们也允许了新的 unique 模型，可以协助用户在可变卦的或许可更新的数据中依然能启动加快的数据访问；其次咱们还允许了包括 JDBC 的 External table，以及 Java UDF 等一些新的个性。欢迎大家到官方去体验。
在 2023 年 Q1，咱们会发布新的优化器的 preview 版本。新的优化器齐全重构了现有的优化器的框架。成功了一个可插拔可裁减 CPU 的查问优化器。可以协助用户处置复杂 SQL 的失掉 best plan 的疑问；其次咱们也会发布 Pipeline 口头引擎的 preview 版本，使 Doris 能够更细力度的去布局 BE 节点的口头资源。保障 BE 节点可以充沛应用咱们的单机多核的个性，并且用户不再要求手动去设置查问并发度等等。比如在闲时，应用更多的 CPU 资源；在忙时，可以启动大小查问，这种灵活的资源隔离。前文提到的 compute node，在 Q1 季度会发布完整的 release 版本。还有 Vertical conduction，处置大宽表场景下的后盾数据merge的内存开支疑问。
在 2023 年 Q2，会发布 2.0.0 版本。除了刚才提到的优化器和 Pipeline 到达 GA 形态以外，还会有一些新的个性，比如半结构化数据的一些查问，存算分别的一些架构演进等等。宿愿在未来的一年能够继续给咱们的用户提供更方便、一致的剖析型数据库。
Q1：Doris 经过衔接外部的 Hive，能不能智能监控 Hive 的表结构或数据的变化？
A1：如今提供了手动的 refresh，可以手动 refresh Catalog 级别，DB 级别，table 级别和 partition 级别。最新的 1.2.2 版本，也允许经过 Hive Metastore 的 Hook 机制来智能监听 Hive 的元数据变化，到达一个增量的元数据同步的成果。
Q2：Doris 和 Flink 的对接模式介绍哪种？
A2：倡导用 Doris 官方提供的 Flink connector。在咱们的官方库上可以找到对应的代码库下载链接和发布版本。
Q3：Doris 读对象存储数据湖对性能和时延的影响会怎样样？
A3：在之前也讲了 Doris 的一些优化点，包括它的 read，消弭小的 IO，本地的 file block cache 等等。做这些配置的登程点都是为了尽量防止访问远端存储，以及防止少量的小 IO 远端访问。咱们做这些优化的初衷，都是为了能够尽量的去把大块数据一次性性的读过去，而后在本地启动处置。据咱们的测试状况来看，经过咱们的这些优化，Doris 对热数据的访问，简直是可以到达和本地表一样的访问性能。
Q4：Doris 怎样处置高并发的恳求？
A4：关于高并发恳求，可以分为两局部，第一局部要处置繁多查问所占用的资源开支的疑问。比如一个查问要求发送到一百台机器去查问，它的扇出特意大，并发是必需很低的。所以咱们会经过火区裁剪，分桶裁剪等，尽量把一个查问限度在某一台机器上，甚至是某一个数据分片上。这样单个查问的资源开支足够的小，那整个集群的全体的并发允许就会很高。第二，假设是在数据湖上的这种高频发查问的话，其实实质上还是会回归到关于远端存储 IO 的一些疑问过去。也就是尽量去缩小小 IO 的远端查问或许经过缓存来处置热数据查问，由于 remote IO 的 overhead 是没法彻底根除的。它跟远端存储的网络，访问的个性都有相关。所以说实质上还是要经过一些 cache 和 buffer 个性来去消弭这些远端存储的 IO 的次数以到达一个高并