一、Doris 簡介

什么是 Apache Doris？簡單來說，Doris 是一款基于 MPP 架構(gòu)的高性能實(shí)時的分析型數(shù)據(jù)庫。

下圖是 Doris 的發(fā)展歷程。最早可以追溯到 2013 年。

它是百度內(nèi)部自研的一個多維分析平臺。經(jīng)過了幾年在百度內(nèi)部大規(guī)模的應(yīng)用和實(shí)踐，2017 年的時候，正式開源到 Github 上。在 2018 年 Doris 進(jìn)入到 Apache 孵化器，在孵化的過程中，不斷發(fā)展社區(qū)，培養(yǎng)用戶和開發(fā)者。到目前為止，在孵化期內(nèi)發(fā)布了七個重要的版本，每月的活躍開發(fā)者接近一百位。在 2022 年，Doris 從 Apache 孵化器畢業(yè)，成為一個頂級項(xiàng)目。成為頂級項(xiàng)目之后，我們也快速的推動社區(qū)的發(fā)展。在 2022 年 12 月份發(fā)布了 Doris 1.2.0 版本。這一版本中有很多重要功能更新。其中很重要的一部分就是對數(shù)據(jù)服務(wù)能力的優(yōu)化和支持。這也是本次分享的重點(diǎn)。

下圖中可以看到 Doris 在整個數(shù)據(jù)流中的定位：

它的上游有一些 OLTP 系統(tǒng)，日志系統(tǒng)，埋點(diǎn)系統(tǒng)。經(jīng)過一些流處理或者說批處理，比如 Sparquet，Hive，F(xiàn)link 等等。經(jīng)過加工和處理之后，會把處理后的結(jié)構(gòu)化數(shù)據(jù)存儲在 Doris 中。Doris 本身是一個擁有完備 MPP 架構(gòu)的數(shù)據(jù)倉庫。它可以直接對外提供報(bào)表分析、信息查詢，以及數(shù)據(jù)庫分析等功能。同時它也可以作為一個 SQL 引擎，對外部的數(shù)據(jù)源進(jìn)行查詢加速，包括 Hive ，Iceberg，Hudi 等等。也支持 MySQL，ElectricSearch 等外部數(shù)據(jù)源。同時，也提供了官方的 Flink Connector 和 Spark Connector。用戶可以通過這兩類 Connector，方便的去把 Doris 存儲中的數(shù)據(jù)和其它數(shù)據(jù)源的數(shù)據(jù)進(jìn)行聯(lián)邦分析查詢，保證 Doris 最終的數(shù)據(jù)不會成為數(shù)據(jù)孤島。

這就是 Doris 在整個數(shù)據(jù)流中的定位，以及它是如何在企業(yè)數(shù)據(jù)流中發(fā)揮價(jià)值的。

二、Doris 數(shù)據(jù)湖分析內(nèi)幕

接下來進(jìn)入本文的重點(diǎn)，也就是 Doris 的數(shù)據(jù)湖分析內(nèi)幕。

先來講一下什么叫數(shù)據(jù)湖分析。其實(shí) Doris 本身是一套完備的數(shù)據(jù)庫管理系統(tǒng)，包括查詢層和存儲層。在我們正常使用 Doris 的時候，只需要把數(shù)據(jù)灌入到 Doris 中來，就可以在 Doris 內(nèi)部對數(shù)據(jù)進(jìn)行管理、存儲和查詢，我們叫做內(nèi)置數(shù)據(jù)存儲（Internal Storage）或者說自管理的數(shù)據(jù)存儲（Self-Managed Storage）。在實(shí)際業(yè)務(wù)應(yīng)用中，還會有大量數(shù)據(jù)存儲在外部數(shù)據(jù)源中的，比如可能有很多歷史數(shù)據(jù)，本身已經(jīng)存在 Hive 系統(tǒng)中，或者是最近比較火的 Iceberg、Hudi 等數(shù)據(jù)湖格式中。如果用戶要把這些系統(tǒng)中的數(shù)據(jù)通過導(dǎo)入操作導(dǎo)入到 Doris 中來，代價(jià)是非常大的，因?yàn)閿?shù)據(jù)量可能是 TB 甚至 PB 級別的。把這些數(shù)據(jù)進(jìn)行一次清理加工的計(jì)算量和存儲開銷都是非常大的。所以很多用戶希望借助 Doris 的高速查詢能力，直接對外部數(shù)據(jù)源的數(shù)據(jù)進(jìn)行分析。這也是 Doris 數(shù)據(jù)湖分析、或者外部數(shù)據(jù)源加速分析的一個初衷。

在早期的 1.0.0 版本中，Doris 就已經(jīng)支持了對外部數(shù)據(jù)源的一些訪問，比如對 Hive 外表的創(chuàng)建，對 Iceberg 外表的創(chuàng)建，或者對 MySQL 外表的創(chuàng)建。但是在老版本中創(chuàng)建這些外部數(shù)據(jù)源的映射時，只能通過表級別的映射。這會帶來一個問題，比如這些表可能多達(dá)幾十上百張，甚至是上千張，如果采用這種方式，用戶需要對每一張表通過 create external table 這種方式去單獨(dú)地建立一個映射關(guān)系，這是一個很費(fèi)時費(fèi)力的工作。

所以在 Doris 的新版本中，通過引入 Catalog 的概念，簡化這一操作，讓用戶可以通過一行命令就能快速開始對外部數(shù)據(jù)進(jìn)行分析。

Catalog 是標(biāo)準(zhǔn) SQL 定義中的三個層級之一，就是 Catalog-Database-Table。我們將 Catalog 分為兩大類，一類是 Internal Catalog，另一類是 External Catalog。其中 Internal Catalog 是管理 Doris 的內(nèi)部表。External Catalog 可以直接映射到一個數(shù)據(jù)源。比如一個 Hive 集群、 ES 集群、 MySQL 數(shù)據(jù)庫等等。通過數(shù)據(jù)源映射，Doris 內(nèi)部會自動的把外部的 database 和 table 進(jìn)行同步。所以在上圖中可以看到，中間這一層， database 和 table 用虛線來表示。也就是當(dāng)創(chuàng)建完 Catalog 后，Doris 內(nèi)部會自動把數(shù)據(jù)源中的 database，table 的信息全都同步過來，從而省去了單獨(dú)手動映射每一張表的繁瑣工作，快速接入到這些外部數(shù)據(jù)源進(jìn)行查詢。通過這種方式，可以極大的降低對外部數(shù)據(jù)源接入的門檻兒。

下圖是新版本中架構(gòu)變動的 Metadata 全景圖：

External Catalog 現(xiàn)已支持幾種主要數(shù)據(jù)源和元數(shù)據(jù)中心。第一類就是 Hive Metastore 或者是兼容 Hive Metastore 的元數(shù)據(jù)中心。比如云上的 AWS Glue、阿里云的 Data Lake Formation 等。通過接入元數(shù)據(jù)中心，可以方便地把元數(shù)據(jù)中心中記錄的庫表信息自動同步到 Doris 里來。支持的表格式包括 Hive 的表、Iceberg 的表、Hudi 的表等等。這些表都可以進(jìn)行統(tǒng)一的管理。第二類是 JDBC Catalog，理論上可以接入任何支持 jdbc 連接協(xié)議的數(shù)據(jù)庫。當(dāng)前只支持了 MySQL，接下來很快會支持 PostgreSQL、SQL Server、Oracle、ClickHouse 等等這些支持 jdbc 連接協(xié)議的數(shù)據(jù)庫。第三類是 ElasticSearch。Doris 在之前版本中就對 ES 有非常好的支持，可以為 ES 提供一個完備的分布式的 查SQL 詢能力。在新版本中，通過引入 ES catalog，更方便的去對接 ES 數(shù)據(jù)源。這樣用戶不用再一張一張表的去做元數(shù)據(jù)的映射，可以很快地幫助用戶去分析這些外部數(shù)據(jù)源的數(shù)據(jù)。同時，在代碼設(shè)計(jì)層面，Doris 也對整個 Catalog 做了一層抽象，包括 Catalog 層級、database 層級和 table 層級都做了接口的抽象。開發(fā)者可以通過這些接口，擴(kuò)展自己的數(shù)據(jù)源。

第二個架構(gòu)變動就是數(shù)據(jù)訪問上的功能統(tǒng)一。

Doris 是一個極速 OLAP 數(shù)據(jù)庫，擁有性能優(yōu)異的分布式查詢引擎。我們希望對外部數(shù)據(jù)源的查詢加速，能夠充分利用現(xiàn)有查詢引擎的優(yōu)勢。在查詢引擎中，上層計(jì)算節(jié)點(diǎn)的算子的優(yōu)化，比如 join 的優(yōu)化，聚合節(jié)點(diǎn)的優(yōu)化、scan 調(diào)度的優(yōu)化等等，與數(shù)據(jù)源本身是無關(guān)的，它本身是查詢層的一些優(yōu)化。所以我們對查詢層進(jìn)行了代碼結(jié)構(gòu)的重構(gòu)，把一些公共部分提取出來，這些公共部分可以幫助我們?nèi)ダ?Doris 完備的極速向量化引擎、基于代價(jià)的查詢優(yōu)化器、以及各類算子的優(yōu)化。同時，也重構(gòu)了底層的 scan 任務(wù)的調(diào)度，如 scan 的并發(fā)度、CPU 時間分片的調(diào)度等，以確保這些功能能夠被內(nèi)部數(shù)據(jù)和外部數(shù)據(jù)源共同使用。

在做完這些架構(gòu)調(diào)整之后，對于外表查詢或者數(shù)據(jù)湖上的數(shù)據(jù)查詢，開發(fā)者只需要關(guān)注數(shù)據(jù)源自身的一些訪問特性。比如對于 Hive 表查詢，我們可以實(shí)現(xiàn)一個 FileScanNode 的，專注于對遠(yuǎn)端存儲上的文件的掃描優(yōu)化。對于特定的數(shù)據(jù)格式，我們只需要實(shí)現(xiàn)對于特定數(shù)據(jù)格式的 format reader。如此一來，開發(fā)者在接入一個數(shù)據(jù)源時，只需專注于處理數(shù)據(jù)，掃描相關(guān)的一些優(yōu)化和數(shù)據(jù)源訪問的一些特性的優(yōu)化，而不需要去關(guān)心整個查詢層的優(yōu)化措施。通過這個架構(gòu)調(diào)整，對一個新的數(shù)據(jù)源接入，只需要大概一周的時間就可以完成，同時可以利用到所有已經(jīng)存在的優(yōu)化能力去加速數(shù)據(jù)源的查詢。

接下來看一下數(shù)據(jù)源訪問的整體流程：

熟悉 Doris 的同學(xué)都知道，Doris 分為兩個部分：FE 節(jié)點(diǎn)和 BE 節(jié)點(diǎn)。FE 節(jié)點(diǎn)是 java 寫的，主要負(fù)責(zé)用戶請求的接入，元數(shù)據(jù)管理，查詢查詢計(jì)劃生成；BE 節(jié)點(diǎn)是 C++ 寫的，負(fù)責(zé)數(shù)據(jù)的存儲和查詢計(jì)劃的執(zhí)行，它是一個高性能的分布式查詢執(zhí)行進(jìn)程。

以 Hive 為例，當(dāng)我們通過 Doris 去查詢一張 Hive 表的時候，首先用戶請求進(jìn)入到 FE，第一步是通過 Hive Metastore 去獲取 table 的 schema，接著獲取 partition。獲取到 partition 以后，F(xiàn)E 會根據(jù) SQL 中的分區(qū)的值的謂詞條件對分區(qū)進(jìn)行裁剪，得到最終的分區(qū)列表。拿到分區(qū)列表以后，再去訪問 Hive Metastore 去獲取分區(qū)所對應(yīng)的文件列表。獲取到文件列表以后，第五步就是在 FE 中對文件掃描任務(wù)進(jìn)行拆分，均勻分布到所有的 BE 節(jié)點(diǎn)上，保證一個查詢?nèi)蝿?wù)，可以充分的利用整個集群的計(jì)算資源進(jìn)行數(shù)據(jù)查詢。任務(wù)分配完以后會下發(fā)給 BE，BE 的邏輯就比較簡單，只需要對指定文件進(jìn)行掃描、過濾和讀取。第七步，它會直接去訪問 HDFS 或者 S3 上的數(shù)據(jù)，進(jìn)行數(shù)據(jù)的讀取。接下來上層會有一些中文節(jié)點(diǎn)，agg 節(jié)點(diǎn)，join 節(jié)點(diǎn)等等的一些查詢執(zhí)行。最終把它的結(jié)果返回給用戶。這就是 Doris 通過 Hive Metastore 去查詢 Hive 外表的整體流程。

接下來介紹一下在整個流程中 Doris 有哪些優(yōu)化。

第一點(diǎn)優(yōu)化就是對元數(shù)據(jù)和數(shù)據(jù)訪問的優(yōu)化。一些表的元數(shù)據(jù)信息是非常大的，比如一張 Hive 表可能有十萬個分區(qū)，如果把十萬個分區(qū)信息在一開始的時候就全都同步到的 FE 節(jié)點(diǎn)，對 FE 節(jié)點(diǎn)內(nèi)存壓力會非常大。因?yàn)?Doris 中所有的元數(shù)據(jù)都是在內(nèi)存存放的，如果把這些外部數(shù)據(jù)源的信息全都一次性同步過來的話，F(xiàn)E 的元數(shù)據(jù)壓力會非常大。所以我們在 FE 上做了多種類型的 cache。

第一種是 schema cache，對于外表的所有列信息的 cache。這些 cache 全都是按需加載的。比如我們有一千張表，只需要訪問到其中的一張表的時候，我們才會把這張表的 schema 緩存到 FE 的緩存集中。這樣可以保證內(nèi)存中只有需要用到的 schema。

第二個是 partition value cache。當(dāng)查詢一個外表時需要對分區(qū)進(jìn)行裁剪。分區(qū)裁剪只需使用分區(qū)值。所以我們單獨(dú)實(shí)現(xiàn)了一個 partition value cache 專門去緩存分區(qū)值的信息，用于分區(qū)裁剪。分區(qū)值的內(nèi)存空間占用是非常少的。通過分區(qū)值裁剪，可以得到最終需要訪問的分區(qū)列表。

當(dāng)?shù)玫椒謪^(qū)列表以后，就進(jìn)入到第三步，即需要訪問 partition cache 去拿到完整的分區(qū)信息。拿到這些信息以后，我們就來到第四步，就是 file cache。一個分區(qū)下面會有多個文件。我們拿到了分區(qū)的位置信息以后，就可以通過 file cache，去獲取這個分區(qū)下的所有的文件的信息（文件路徑）。拿到文件路徑后，我們在 FE 中會做任務(wù)的拆分。最終會把這些文件列表拆分以后，發(fā)給 BE。

BE 節(jié)點(diǎn)負(fù)責(zé)文件的讀取和訪問。這里我們也實(shí)現(xiàn)了兩個大類的緩存的優(yōu)化。

第一個是數(shù)據(jù)預(yù)讀（prefetch buffer），在訪問 HDFS 和 S3 時，本質(zhì)是一個 RPC 請求。第一個優(yōu)化點(diǎn)就是如何能夠盡量減少 RPC 的開銷。一次 RPC 開銷本身的 overhead 很重。所以我們增加了一個預(yù)取緩存，把多個小的 Remote IO 請求合并成一個大的 IO 請求，把原先可能幾個字節(jié)的請求，合并成 4KB 到 1MB 的數(shù)據(jù)請求一次性讀取過來，在本地內(nèi)存中形成一個緩存。后續(xù)的 IO 可以直接在內(nèi)存緩存中去獲取數(shù)據(jù)，極大的減少 remote IO 的次數(shù)。

第二個是文件塊級別的緩存（file block cache）。在訪問 HDFS 或者 S3 上的數(shù)據(jù)文件時，可能只需訪問其中的一小部分。比如一個列存格式的 parquet 文件，如果只需要訪問其中的三列數(shù)據(jù)，那么只會讀取整個文件的一部分，Doris 會在第一次文件讀取時，將讀取的文件塊緩存到本地磁盤。緩存文件的文件名是文件的路徑，加上讀取偏移量的組合標(biāo)識。之后如果有相同的文件訪問，會先查看本地是否已經(jīng)有緩存的數(shù)據(jù)文件。如果有，則直接去讀本地文件，減少訪問遠(yuǎn)端數(shù)據(jù)的開銷。通過 file block cache，可以極大地提升一些熱數(shù)據(jù)的訪問效率。

第二個優(yōu)化點(diǎn)就是 native 的 file format reader。以 parquet 為例，在老版本的 Doris，是通過 Apache arrow 庫內(nèi)置的 parquet reader 完成讀取的。這個 Reader 的實(shí)現(xiàn)會有一些額外的開銷。比如它會多一層內(nèi)存格式的轉(zhuǎn)換。因?yàn)樗谧x取的時候，首先需要把遠(yuǎn)端的文件轉(zhuǎn)換成內(nèi)部的 arrow 的格式。然后再把 arrow 的格式轉(zhuǎn)換成 Doris 的內(nèi)部內(nèi)存格式。第二是 Apache arrow 內(nèi)置的 parquet reader 對一些新的 Parquet 特性是不支持的，比如不支持 page index、不支持 parquet 的 bloom filter 的讀取、不支持這種更精細(xì)的字典編碼的優(yōu)化等等。

基于以上考慮，我們在 Doris 內(nèi)部實(shí)現(xiàn)了一個 native 的 C++ 的 parquet reader。首先是能直接轉(zhuǎn)換內(nèi)部存儲格式，對于讀取到的數(shù)據(jù)，直接轉(zhuǎn)為內(nèi)部內(nèi)存格式，減少一次內(nèi)存格式的拷貝和轉(zhuǎn)換開銷；第二點(diǎn)，我們能夠利用 bloom filter 進(jìn)行更精確的數(shù)據(jù)過濾。用戶寫數(shù)據(jù)的時候，對某一列使用的 bloom filter，可以利用 bloom filter 去對數(shù)據(jù)進(jìn)行過濾。其次我們也支持了基于字典編碼的謂詞過濾，可以把謂詞下推到 parquet reader 中。把謂詞中的，比如 “a=‘北京’” 這樣的一個條件改成一個對應(yīng)字典編碼的值。比如  “a=‘100’”，后續(xù)用 ‘100’ 在文件內(nèi)部進(jìn)行數(shù)據(jù)過濾。因?yàn)檎麛?shù)型的過濾效果是比字符串的過濾效果要好很多的。過濾完了以后，在最終返回結(jié)果的時候，我們再把字典編碼值轉(zhuǎn)換成真正的數(shù)據(jù)的值。這樣來達(dá)到加速的效果。

最后一點(diǎn)也是非常重要的一點(diǎn)，就是在 Parquet Reader 上支持了延遲物化。延遲物化是訪問遠(yuǎn)端存儲的時候，減少 IO 的一個非常重要的特性。尤其是在帶謂詞條件的寬表查詢上。簡單來說，Doris 會優(yōu)先讀取帶謂詞條件的列。讀取完這些列以后，我們先對這些列進(jìn)行過濾得到最終過濾后的行號集合，再去讀取剩余的其他的列。這樣就能保證剩余其他列都是只會去讀取過濾后的數(shù)據(jù)。從而極大地減少從遠(yuǎn)端去讀取數(shù)據(jù)的 IO 開銷。

第三點(diǎn)就是彈性計(jì)算節(jié)點(diǎn)（compute node）。當(dāng)我們?nèi)ピL問外部數(shù)據(jù)源的時候，Doris 本身是不會去存儲這些數(shù)據(jù)的，所以不需要 BE 節(jié)點(diǎn)本身的存儲能力。一旦我們不再需要 BE 的存儲能力，它就變成了一個無狀態(tài)的節(jié)點(diǎn)。當(dāng)一個節(jié)點(diǎn)是有狀態(tài)的，刪除節(jié)點(diǎn)或者添加節(jié)點(diǎn)時都要考慮到數(shù)據(jù)如何安全下線，數(shù)據(jù)如何遷移，重新 rebalance。而一個無狀態(tài)節(jié)點(diǎn)可以非常方便的進(jìn)行彈性擴(kuò)縮容。所以我們在新的版本中給 BE 節(jié)點(diǎn)增加了兩種類型：

第一種類型是 mix node，mix 就是標(biāo)準(zhǔn)的 BE 類型。既支持?jǐn)?shù)據(jù)計(jì)算，也支持本地的文件存儲；第二種類型叫 compute node，即計(jì)算節(jié)點(diǎn)，計(jì)算節(jié)點(diǎn)可以很方便的進(jìn)行彈性伸縮。比如可以很快速地在新機(jī)器或者云上創(chuàng)建一些新的 compute node。這些 compute node 可以分擔(dān)訪問遠(yuǎn)端存儲的一些計(jì)算的開銷。通過這種無狀態(tài)的 BE 節(jié)點(diǎn)，可以快速去承接外部數(shù)據(jù)源的計(jì)算負(fù)載。來達(dá)到彈性伸縮的目的。

下圖是我們在版本發(fā)布之初做的一個測試。

可以看到在同一資源規(guī)格下，我們?nèi)ゲ樵?Iceberg TPCH 100G 的數(shù)據(jù)集。相比 Trino，Doris 有三到五倍的性能提升。

最后看一下當(dāng)前 Doris 對數(shù)據(jù)湖的一些功能的支持程度：

在 1.2.0 版本中，Doris 支持三個主流的外部數(shù)據(jù)服務(wù)或者數(shù)據(jù)倉庫。第一個就是 Hive，支持 Managed table 和 External table。支持 parquet、orc 和 text 格式的讀取。Iceberg 完整的支持 V1 Format，V2 支持了 position delete。Hudi 暫時只支持 MOR 的表，包括 COW Snapshot Query  以及 MOR Read Optimized Query。

三、Doris 社區(qū)發(fā)展以及后期開發(fā)規(guī)劃

最后介紹一下我們在數(shù)據(jù)湖分析這塊的一些規(guī)劃。

第一個規(guī)劃就是增量數(shù)據(jù)訪問。增量數(shù)據(jù)也是 Iceberg，Hudi 這類新興的數(shù)據(jù)庫系統(tǒng)所提供的核心價(jià)值之一。它可以應(yīng)用于 A/B Test，或者是用其 Time Travel 的能力、CDC 的能力來進(jìn)行增量數(shù)據(jù)的處理和訪問。Doris 在后續(xù)也要對這一類的功能進(jìn)行支持。其次就是基于增量數(shù)據(jù)的視圖查詢。比如我們會通過基于增量數(shù)據(jù)的多表的物化視圖的更新，或者邏輯視圖的權(quán)限控制等等，來幫助用戶很好的去管理數(shù)據(jù)湖上的數(shù)據(jù)，并且能夠?qū)?shù)據(jù)進(jìn)行很精細(xì)的訪問。

第二點(diǎn)就是數(shù)據(jù)湖寫入能力。剛才我們介紹這些功能時候，其實(shí)都是在介紹如何去訪問和讀取這些外部數(shù)據(jù)源的能力。如果用戶想完整的訪問管理這些數(shù)據(jù)源的話，必須在外部對接例如 Spark 這些系統(tǒng)進(jìn)行數(shù)據(jù)寫入。所以我們后續(xù)希望在 Doris 內(nèi)部提供統(tǒng)一的操作入口，來消除用戶操作數(shù)據(jù)的割裂感，來保證對數(shù)據(jù)庫的寫入操作和查詢操作，都可以統(tǒng)一在 Doris 中完成。

最后一點(diǎn)是深入集成 Iceberg 的能力。希望以 Doris 本身作為 Iceberg 的元數(shù)據(jù)中心來提供托管 Iceberg 的能力，提升自身對于數(shù)據(jù)湖，或者說是對結(jié)構(gòu)化、半結(jié)構(gòu)化大規(guī)模數(shù)據(jù)的管理能力。

以上就是對 Doris 數(shù)據(jù)湖的一些介紹。最后簡單介紹一下 Doris 社區(qū)現(xiàn)狀和未來規(guī)劃。

Apache Doris 是國內(nèi)最活躍的開源社區(qū)之一。

累計(jì)貢獻(xiàn)者人數(shù)已經(jīng)超過了四百位，平均每月的活躍用戶貢獻(xiàn)者人數(shù)也超過了一百人?？梢钥吹轿覀兠總€月所提交的 commit 量和 push 量都是相當(dāng)可觀的，發(fā)展也是非?？焖俚摹Ｒ矚g迎對分布式數(shù)據(jù)庫或者對 MPP、OLAP 數(shù)據(jù)庫感興趣的同學(xué)加入到社區(qū)中來，我們可以一起去完善這樣的一個數(shù)據(jù)庫系統(tǒng)。

下圖是 Doris 在 2022 年底到 2023 年初的一個大致規(guī)劃：

首先我們在 2022 年的 Q4 季度，發(fā)布了 1.2.0 版本。在該版本中，實(shí)現(xiàn)了多元數(shù)據(jù)目錄，其中就包括數(shù)據(jù)分析這部分的一些能力；其次我們還加入了半結(jié)構(gòu)化數(shù)據(jù)的一些支持，包括 Array 和 Binary Json 格式的支持；我們也支持了新的 unique 模型，可以幫助用戶在可變更的或者可更新的數(shù)據(jù)中依然能進(jìn)行快速的數(shù)據(jù)訪問；其次我們還支持了包括 JDBC 的 External table，以及 Java UDF 等一些新的特性。歡迎大家到官網(wǎng)去體驗(yàn)。

在 2023 年 Q1，我們會發(fā)布新的優(yōu)化器的 preview 版本。新的優(yōu)化器完全重構(gòu)了現(xiàn)有的優(yōu)化器的框架。實(shí)現(xiàn)了一個可插拔可擴(kuò)展 CPU 的查詢優(yōu)化器。可以幫助用戶解決復(fù)雜 SQL 的獲取 best plan 的問題；其次我們也會發(fā)布 Pipeline 執(zhí)行引擎的 preview 版本，使 Doris 能夠更細(xì)力度的去規(guī)劃 BE 節(jié)點(diǎn)的執(zhí)行資源。保證 BE 節(jié)點(diǎn)可以充分利用我們的單機(jī)多核的特性，并且用戶不再需要手動去設(shè)置查詢并發(fā)度等等。比如在閑時，利用更多的 CPU 資源；在忙時，可以進(jìn)行大小查詢，這種動態(tài)的資源隔離。前文提到的 compute node，在 Q1 季度會發(fā)布完整的 release 版本。還有 Vertical conduction，解決大寬表場景下的后臺數(shù)據(jù)merge的內(nèi)存開銷問題。

在 2023 年 Q2，會發(fā)布 2.0.0 版本。除了剛才提到的優(yōu)化器和 Pipeline 達(dá)到 GA 狀態(tài)以外，還會有一些新的特性，比如半結(jié)構(gòu)化數(shù)據(jù)的一些查詢，存算分離的一些架構(gòu)演進(jìn)等等。希望在未來的一年能夠繼續(xù)給我們的用戶提供更便捷、統(tǒng)一的分析型數(shù)據(jù)庫。

四、問答環(huán)節(jié)

Q1：Doris 通過連接外部的 Hive，能不能自動監(jiān)控 Hive 的表結(jié)構(gòu)或數(shù)據(jù)的變化？

A1：現(xiàn)在提供了手動的 refresh，可以手動 refresh Catalog 級別，DB 級別，table 級別和 partition 級別。最新的 1.2.2 版本，也支持通過 Hive Metastore 的 Hook 機(jī)制來自動監(jiān)聽 Hive 的元數(shù)據(jù)變動，達(dá)到一個增量的元數(shù)據(jù)同步的效果。

Q2：Doris 和 Flink 的對接方式推薦哪種？

A2：建議用 Doris 官方提供的 Flink connector。在我們的官方庫上可以找到對應(yīng)的代碼庫下載鏈接和發(fā)布版本。

Q3：Doris 讀對象存儲數(shù)據(jù)湖對性能和時延的影響會怎么樣？

A3：在之前也講了 Doris 的一些優(yōu)化點(diǎn)，包括它的 read，消除小的 IO，本地的 file block cache 等等。做這些功能的出發(fā)點(diǎn)都是為了盡量避免訪問遠(yuǎn)端存儲，以及避免大量的小 IO 遠(yuǎn)端訪問。我們做這些優(yōu)化的初衷，都是為了能夠盡量的去把大塊數(shù)據(jù)一次性的讀過來，然后在本地進(jìn)行處理。據(jù)我們的測試情況來看，經(jīng)過我們的這些優(yōu)化，Doris 對熱數(shù)據(jù)的訪問，幾乎是可以達(dá)到和本地表一樣的訪問性能。

Q4：Doris 怎么處理高并發(fā)的請求？

A4：關(guān)于高并發(fā)請求，可以分為兩部分，第一部分要解決單一查詢所占用的資源開銷的問題。比如一個查詢需要發(fā)送到一百臺機(jī)器去查詢，它的扇出特別大，并發(fā)是肯定很低的。所以我們會通過分區(qū)裁剪，分桶裁剪等，盡量把一個查詢限制在某一臺機(jī)器上，甚至是某一個數(shù)據(jù)分片上。這樣單個查詢的資源開銷足夠的小，那整個集群的整體的并發(fā)支持就會很高。第二，如果是在數(shù)據(jù)湖上的這種高頻發(fā)查詢的話，其實(shí)本質(zhì)上還是會回歸到關(guān)于遠(yuǎn)端存儲 IO 的一些問題上來。也就是盡量去減少小 IO 的遠(yuǎn)端查詢或者通過緩存來解決熱數(shù)據(jù)查詢，因?yàn)?remote IO 的 overhead 是沒法徹底根除的。它跟遠(yuǎn)端存儲的網(wǎng)絡(luò)，訪問的特性都有關(guān)系。所以說本質(zhì)上還是要通過一些 cache 和 buffer 特性來去消除這些遠(yuǎn)端存儲的 IO 的次數(shù)以達(dá)到一個高并發(fā)的效果。