Doris 解析 | Apache Doris 極速1.0版本解析與未來規劃

語言: CN / TW / HK

分享嘉賓: 陳明雨 Apache Doris PMC 成員

編輯整理:劉閏豐 酷開科技

出品平臺:DataFunTalk

導讀: 本次分享的主題是Apache Doris極速1.0版本的解析與未來的規劃。

今天的分享主要圍繞下面幾方面內容展開:

  • Apach Doris特性一覽

  • Apache Doris1.0版本解析

  • Apache Doris未來規劃

  • Apache Doris開源社群

首先介紹下Apache Doris,下圖為Apache Doris官網上的一張圖,可以看出Doris在整個大資料設計中的地位。

從上游TP系統資料、業務埋點資料、web端日誌等通過批處理/流處理系統,經過加工之後儲存到doris中,doris可以直接對外提供查詢服務,包括實時大屏、多維報表、流量統計、自助查詢、使用者畫像等。

同時doris作為帶有儲存的資料服務,可以通過doris提供的connector(spark, flink等)讀取doris中資料和其他大資料系統中的資料進行聯邦查詢,來避免資料孤島的情況。

並且,doris自身也有完備的MPP查詢層,我們可以通過外表的方式來對其他的資料來源進行資料分析,比如可以通過ODBC協議來連線支援所有ODBC的資料庫mysql, oracle, sql Server等,同時也對ES進行了深度的整合,為ES提供了一個分散式的sql查詢層,可以解決ES在sql查詢方面的不足,也可以利用ES在全文檢索、索引上的一種高效的處理效能。

這就是目前Doris在整個大資料處理中的定位。

接下來從doris的功能出發,介紹一下為什麼選擇doris以及doris有那些特性。

01

Apache Doris 特性一覽

這裡我們將對doris的6個功能逐一進行介紹。

1. 極簡架構

極簡架構,是我們在設計之初為使用者提供的一個優勢和便利。從上圖可以看出Doris的架構是非常簡單的。

整個架構主要有兩類角色:FE(Frontend)和BE(Backend)。其中,FE主要負責元資料的儲存,使用者請求的接入,以及查詢計劃的解析。BE則主要負責查詢計劃的執行,資料的儲存。

除了這兩個程序之外, Doris不再依賴任何第三方服務 。也就是說我們的部署和運維相對而言都是比較簡單的。同時在上層也提供了mysql協議的相容。支援標準的sql語法方便使用者零成本地接入到系統中來。

2.高效自運維

上圖可以看到,使用者的資料可以通過使用者建表時定義的分割槽分桶來進行資料切片,終端使用者的資料是以分片的形式儲存在整個分散式叢集中的各個節點中,並且節點之間的分片可以自動均衡和修復,比如當前有3個BE節點,當我們增加第四個BE節點的時候,系統會自動按分片粒度將資料均勻分佈在新增伺服器上來保證多個伺服器的負載是接近的和相同的,同時在出現某一個數據的副本損壞的時候,doris內部也會在短時間內將副本補齊到一個健康狀態來保證副本的可用性和可靠性。 整個過程不需要人工介入,同時整個過程也不會影響到使用者的查詢,匯入等功能。

所以在容災和自運維方面相對便利。

3. 高併發場景支援

我們知道一個olap領域的資料庫更偏向於高吞吐、複雜場景下的快速處理,doris除了這種複雜的AD-hoc查詢,同時也能提供高併發的點查,在單機情況下可以支援1000QPS的請求支援,並且是可橫向擴充套件的。主要得益於2個方面:

①分割槽裁剪

我們可以通過查詢優化器,以及資料的分割槽分桶的形式,將查詢條件定位到具體分割槽及分桶中,這樣一個查詢所佔用的資源將足夠小,因為最終只是定位到某一臺機器的某一個片上,這樣整個叢集支援高併發的請求就可以變多。

②資料Ca che

在doris中分為不同種類的資料Cache,比如最基礎的sql Cache,相同的sql查詢可以直接從cache中獲取計算好的查詢結果。第二種是類似於partition cache的方式,智慧的根據查詢條件去cache中獲取歷史分割槽資料的結果,這也是doris在高併發查詢場景下的一些特色。

4. MPP執行引擎

Doris中是有一個完備的MPP執行引擎的 從上圖可以看到,我們的查詢優化器對一個sql生成樹狀的邏輯計劃以後,根據資料分佈及優化規則拆分為物理執行計劃。 首先,一個物理執行計劃可以在叢集中多個BE節點同時執行,同時在一個BE內部我們還會把查詢計劃的分片進一步拆分成多個instance,以保證在單個節點內部再一次進行並行,達到單機多核CPU的特性。

同時我們也引用到了Exchange節點,該節點使得MPP的完備性得到了提升,保證資料通過shuffle的方式重新分佈在更多的節點上,而不僅僅只侷限於資料儲存所在的計算資源。

5.明細與聚合資料

doris本身是支援預聚合的語義的 如果同學們使用過kylin、druid就可以知道它們會將資料預先計算好。 在doris中,使用者可以將明細的資料直接儲存在base表,doris支援在明細表上選擇任意維度列和指標列生成物化檢視,也就是上圖中的上卷表,並且doris可以保證生成的所有的物化檢視和明細表中的資料是強一致的,也就是說通過匯入的事務性保證奪標之前資料一致性,這樣使用者也不需要擔心基礎表資料更新,上卷表還沒更新導致資料查詢的不一致性,這在doris中是不存在的。

對於使用者來說,所有查詢都是針對base表而言,查詢優化器會智慧地分析查詢模式自動匹配到對應的物化檢視上來進行資料的返回,一方面通過資料一致性,其次是查詢自動路由,來保證在一個系統中進行明細資料和聚合資料的統一處理和分析,也降低了運維壓力,比如是否感知物化檢視、表更新等問題。

6. 便攜資料接入

從圖中可以看出doris支援了非常多的資料匯入方式,使用者資料不管是在物件儲存、kafka儲存,還是流批處理系統中,我們都可以通過一個sql命令將資料灌入倒doris中,比如我們支援kafka不丟不重進行一鍵訂閱,同時也提供了flink/spark connector可以接入更豐富的資料來源寫入到doris中,也可以通過broker load進行大批量的一次性的資料匯入,也可以通過stream load進行近似流式的匯入。

以上通過簡單的6點介紹,概括了doris的一些特性,接下來我們進入今天的重點,對doris在前段時間剛剛通過的1.0版本的解析。

02

Apache Doris1.0版本解析

1.0版本也是Doris進入孵化器以來第一個1位大版本。在該版本中,主要提供三大特點:極速、穩定、多源。

1. 極速:向量化引擎

第一點就是極速,其本質就是我們在1.0版本中引進了全新的向量化引擎。向量化引擎在業界是有很多應用的,包括前幾年比較火的clickhouse系統,是把整個向量化技術帶到了工業生產領域,讓大家在實際生產環境中去應用向量化技術來得到收益,所以我們在設計向量化引擎中也借鑑了非常多的clickhouse的優秀設計,來保證我們的查詢效能得到質的提升。向量化引擎我們從5部分來為大家進行介紹。

①列式記憶體佈局

可以看到在原來的行存計算模型中,資料在記憶體中的表現方式是行的表現方式,在整個向量化執行引擎中,把它改成了列的表現方式,後面我們會講到它的優勢。

②向量化計算框架

同時在列式的表現方式中,我們還改進了向量化計算框架,可以看到當我們計算a, b兩列中b列的abs函式時會在原有的block基礎上,增加一個結果列,將b列的填充結果增加到結果列中,然後再進行b列的結果刪除。

③Cache親和度

列式的佈局和向量化計算框架,提供了以下好處,第一個是cache親和度,在行存計算模式中,當我們計算某一列時,需要將整行載入到記憶體中,並且通過offset和偏移去找到對應的列,然後再將那一列的值取出進行計算,這樣可以看出,當我們載入整行資料時,其實只用到了某一列,這對cache親和度是不好的,也就是一個cache行中有效佔比比較低,而在列式佈局中,是一次性載入這一列,這樣cache親和度有明顯提升。我們可以在一個cache行中去快取更多有效資料,如果熟悉系統的同學我們應該知道不同的cache級別訪存的延遲會有指數級的提升,所以通過cache親和度提升了系統的計算效率。

④虛擬函式呼叫

在行儲存中,計算某一列值需要進行大量的switch case或者虛擬函式的呼叫,我們需要在動態執行時去判斷該列的型別,根據不同的型別去呼叫具體實函式的實現。所以虛擬函式是需要在執行時才能知道型別的,編譯器無法在編譯期間靜態獲取一些資訊進行優化,還有就是虛擬函式無法做內聯,那麼編譯器就會在編譯期間丟失很多有用資訊無法做進一步優化,我們在做虛擬函式呼叫的時候還會涉及很多查表的功能,查虛擬函式表會嚴重打破多級流水,整個CPU的分支命中率和預測率都會下降,從而影響執行效率。

所以在向量化引擎中,我們引用了大量的靜態模板,使大量虛擬函式的呼叫變成了在編譯期間靜態的型別轉換,這樣可以保證我們的優化器在編譯期間直接編譯出最優程式碼,其次可以在執行期間減少分支錯誤的預測等問題,使效率得到進一步提升。

⑤SIMD指令

SIMD指令集分為兩個部分,第一部分是C++的編譯器,可以自動的實現一些SIMD指令集的優化,比如在上圖例子中:for迴圈設計兩個陣列的計算,該兩個陣列在記憶體中是連續儲存的,第二沒有兩個變數之間的數值依賴,其次for計算相對簡單,那麼編譯器則會自動的做一些多指令集的優化,可以看到在自動做了SIMD指令集優化後可以得到3倍的一個性能提升。我們不需要顯式地呼叫SIMD指令集,而是通過改變一些程式設計習慣等讓編譯器自動幫我們做效能的提升。

第二點是手動的SIMD指令集。在一些稍微複雜的函式下,編譯器沒有足夠的智慧幫我們做指令集優化的時候,我們可以手動的呼叫SIMD指令來進行優化,比如上圖,兩個字串比較函式中,可以通過手寫SIMD指令集的方式來做改進。

以上就是對向量化引擎簡單得介紹,如果大家感興趣可以去下圖中的連結進行進一步的學習。

在最後 ,我們看一下使用向量化引擎的效果,其實在1.0版本中我們的向量化引擎還處於一個實驗階段,它是一個完備的功能集,但還有很多優化點在持續的改進,在當前版本中,首先我們可以看到在SSD的Benchmark上,也就是在多表關聯的查詢場景下,大部分查詢都有著一倍以上的效能提升。

如果在單表查詢場景下,比如日誌分析場景,或者大寬表分析場景下,可以看到我們向量化引擎的提升是非常明顯的,可以達到10倍的效能提升。所以在生產環境上,平均的觀感體驗可以達到3-5倍的提升。當然這並不是我們最終的資料,我們也會在後續的1.1和1.2版本中進行持續向量化優化,在後續版本中會帶來更多的向量化提升。這就是1.0版本在極速方面做的工作。

2. 穩定:記憶體可控

doris本身是一個MPP架構的執行引擎,整個執行過程是完全依賴於記憶體的,無論匯入還是查詢,資料的cache都是佔用記憶體開銷的,所以它本質是對記憶體使用比較高的一個系統,在之前版本使用過的同學可能會發現在一些高負載場景下經常會出現Out Of Memory的錯誤導致程序掛掉繼而重啟,所以記憶體控制在之前版本是做的不好的。

在1.0版本我們把它作為專項進行了改造,我們的目標是對OOM Say No!通過一系列技術方案來保證整個程序是在記憶體控制範圍內的,避免出現OOM的現象。

我們通過mem Tracker樹形結構來充分控制整個系統各個模組,各個任務之間記憶體的呼叫關係和控制,比如在程序級別會有一個總的Process Tracker,在Process Tracker下會掛分模組的Tracker,例如針對查詢的Query Tracker,針對匯入的Load Tracker,任務的Task Tracker和 Cache Tracker。如圖中的Query Trackers,我們還會針對每一個查詢上的計劃分片,或者說執行分片上進一步增加細粒度的tracker,比如可以增加聚合運算元的記憶體佔用,掃描運算元的記憶體佔用,這樣可以精細化到每個查詢中的運算元使用,保證查詢記憶體可用。

其次每個mem tracker是掛在總的process tracker下的,所以所有的查詢也會受到總的記憶體的控制,具體實現細節實際是在把每個mem tracker線上程執行的時候掛載到Thread Local 的變數上,這樣一個執行緒內所有系統申請都會通過Thread Local進行捕獲,同時我們呼叫TcMallocHook的方式來去把所有new, delete這些申請給hook起來,不會遺失任何一個實際記憶體使用,這樣帶來的好處:

①可觀測區域性記憶體佔用 。在新的版本中可以精確的定位到記憶體具體是被查詢,還是匯入還是被cache佔用,通過可觀測性來快速定位問題。

②嚴格監控實際記憶體申請,杜絕記憶體超限 。通過hook方式嚴格將記憶體進行限制,並且不會有超限的問題。

3. 多源:大資料生態

第三部分是大資料生態,在1.0版本我們也開放了對hive外表,iceberg外表的的查詢功能,本質是想解決使用者引用doris的時候,但是資料已經在其他儲存系統中存放,這樣在之前版本中如果想使用外部資料來源,則需要匯入doris才可以使用,資料遷移成本高。

① 解決資料不遷移過程中能夠加速原有系統的查詢加速能力。

② 逐步形成完善的湖倉一體生態 。在1.0版本中我們已經支援了hive 和 iceberg的資料來源,那麼針對iceberg也支援自動同步hive外表,hive表不需要一張張做對映建立,而只需要提供hive metedata地址則可以實現自動同步,我們在後續版本也會逐步完善doris的生態。

這就是doris在1.0大版本中整個的更新,整個1.0版本相對於0.15版本社群有116位貢獻者,貢獻了大概663個commit,除了上述3點介紹的功能之外,還有非常多的功能和效能提升,歡迎大家前往doris官網探索。

03

Apache Doris 未來規劃

接下來簡單介紹下Apache Doris在未來的規劃。

1. 湖倉一體

雖然目前已經引入了hive 和 iceberg 的功能支援,但是相對來說功能較簡單,在接下來的工作中,會引入Multi-Catalog機制,該機制類似於presto這種sql加速系統,可以將多源的資料統一到catalog抽象,可以保證更方便接入外部資料來源。現在也是在聯絡社群同學開發hudi的支援。同時也會陸續引入merge on read的支援,目前可以理解為都是在讀取copy on read的表,通過引入merge on read可以讀取到資料湖實時更新的資料。

2. 存算分離

存算分離本質上引用的是越來越多的上雲的需求。我們可以通過低價的S3的儲存,達到低成本的收益,其次根據雲上的彈性擴容提供無狀態的計算節點的橫向擴容,通過低成本+彈性來滿足存算分離的需求。我們也可以根據共享資料來保證多個業務共享,但是通過獨立的計算資源來計算。

3.  實時寫入

這點來源的需求是我們看到在日誌場景或者是lot場景等場景,多個數據源進行併發的向同一個系統寫入,doris現在還是一個近似微批的系統,需要去限制批次時間,這樣使用者體驗就會相對較差,在後續會嘗試支援高併發實時寫入場景。 還有在面臨一些訂單場景,我們可以UNIQUE key主鍵模型來近似達到資料更新的效果。 unique key是一個merge on read 的模型,寫入速度較快,但是查詢效率會差一些,後續我們會支援copy on write 的資料更新,來吸收一定的寫的吞吐來提高查詢的能力。

4.  穩定性與可觀測性

我們會繼續提升系統穩定性,在高負載情況下保證系統平穩執行。同時提高系統可觀測性,包括引入tracing來快速的定位系統問題,這就是doris至少在今年需要做的一些事情。

04

Apache Doris 開源社群

最後介紹一下我們的開源社群現狀,這是在4月份的一個截圖, 目前contributors人數已經突破300,月活躍貢獻者人數已達70人,目前畢業已經在推進了,到最後階段,如果一切順利在下個月則可以完成一系列的畢業流程,希望可以給使用者提供一個很好的體驗。

我們希望我們的社群不光是冷冰冰的程式碼,也是資料庫愛好者、OLAP愛好者、開發者共同的社群,這是github網址和2022年的Roadmap地址,感興趣可以關注我們的Apache Doris微信公眾號,幫助大家更好地去了解和使用doris。

今天的分享就到這裡,謝謝大家。

在文末分享、點贊、在看,給個3連擊唄~

01 / 分享嘉賓

陳明雨

Apache Doris PMC 成員

陳明雨,Apache Doris PMC 成員。前百度資深研發工程師。8年分散式系統研發經驗,一直專注於分散式可擴充套件分析型資料庫領域。

02 / 免費下載資料

03 / 報名看直播 免費領PPT

04 / 關於我們

DataFun: 專注於大資料、人工智慧技術應用的分享與交流。發起於2017年,在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會,已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章700+,百萬+閱讀,14萬+精準粉絲

  分享、點贊、在看 ,給個 3連擊 :point_down: