6000字，詳解數據倉庫明星產品背後的技術奧祕

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

本文由百度智能雲高級產品經理——魯志敬 在百度開發者沙龍線上分享的演講內容整理而成。內容深度解讀Polo產品的技術架構與產品特性。希望本次分享能夠讓聽衆對Palo有一個基本認識，並掌握一定的數據倉庫設計方法。

文：魯志敬

視頻回放：https://developer.baidu.com/live.html?id=12

本次分享的主題是：百度數據倉庫Palo技術特性解讀。內容主要分爲以下三個方面：

• 產品介紹與發展歷程
• 應用場景介紹
• Palo技術特性解讀
  
  
  
  
  

01

產品發展歷程

百度數據倉庫Palo 是基於業內領先的OLAP數據庫 Apache Doris（Powered By Apache Doris） 構建的MPP架構雲數據倉庫，致力於幫助企業快速且低成本地構建極速易用的雲上數據分析平臺，加速企業數智化進程。

• 支持標準SQL並完全兼容MySQL協議

• 僅需秒級甚至毫秒即可返回海量數據下的查詢結果

• 有效支持多維分析、實時分析、交互式分析等多種數據分析場景

發展歷程

  

  階段一：助力內部業務

Palo的歷史可以追溯到2008年，當時是解決百度鳳巢統計報表的專用系統，隨着百度業務飛速發展，內部對系統進行了多次迭代，逐漸承擔起百度內部業務的統計報表和多維分析需求，成爲百度內部第一個OLAP分析平臺。

    階段二： 做大做強

2013 年，Palo進行了 MPP 框架的升級，2017 以百度 Palo 的名字在 GitHub 上進行了開源，於此同時在百度智能雲上發佈了雲端託管服務“百度數據倉庫Palo”。2018 年把Palo貢獻給 Apache 基金會，更名爲Apache Doris。

02

應用場景

數據分析需求的演進趨勢

• 查詢結果可以快速響應
  提升查詢效率一直是分析型數據庫發展的第一動力。從過去查詢一個報表、跑SQL需要半個小時、幾十分鐘到現在的秒級甚至毫秒級，這給帶來效率的提升是巨大的。
  
  
• 實時業務洞察
  數據價值會隨時間推移而降低，T+1已經不能滿足業務對高時效性的要求。
  
  
• 靈活需求應對
  業務趨勢預知與系統建設滯後的矛盾，需求交付週期較長。
  
  
• 全民化的數據探索
  更低的分析門檻和學習成本，更高的併發支持。
  
  
  
  

Palo在企業大數據體系中的多種應用場景

• 數倉查詢加速
  
  
  解決傳統數倉和數據平臺查詢效率低下的困境，達到海量數據低至毫秒/秒級查詢耗時，海量數據無縫應用，極大幅度加速數據決策效率。
  
  
• 實時數倉構建
  
  
  支持流式數據高效導入、業務指標實時聚合，保證業務數據得以實時洞察，並可以減少數據處理鏈路、統一數據流向，簡化大數據平臺架構。
  
  
• 多源聯邦查詢
  
  
  構建跨多個數據源的統一查詢入口，實現實時數據和離線數據的聯邦分析，滿足數據分析人員更多元化的查詢需求。
  
  
• 交互式數據分析
  
  
  以藉助一些BI可視化工具的能力去構建交互式數據分析應用，對海量數據進行自助探查和多維度分析，實現對業務的深層探索和快速決策。
  
  

03

技術特性解讀

系統架構

在架構方面，Palo只有兩個主進程模塊。一個是 Frontend（FE），另一個是 Backend（BE）。

•  Frontend（FE）
  
  
  可以理解爲Palo 的管控節點，主要負責用戶請求的接入、查詢計劃的解析、元數據的存儲和集羣管理相關工作。
  
  
•  Backend（BE）
  
  
  主要負責數據存儲、查詢計劃的執行。
  
  

這兩類進程都是可以橫向擴展的。除此之外， Palo不依賴任何第三方系統（如 HDFS、Zookeeper等） 。這種高度集成的架構設計極大的簡化了一款分佈式系統的運維成本。

極致性能背後的核心技術

對於一個分析型數據庫，最核心的三個組成部分就是 存儲引擎、查詢引擎和查詢優化器 ，這也是Palo極致性能的決定因素。

存儲引擎

• 存儲格式：列式存儲
  
  在分析場景，列存往往只會讀取需要的列，跳過無用數據，會比行存掃描更少的數據量，減少IO開銷以提高性能。
  同時數據按照列進行連續存儲，因爲類型相同，因此可以獲得極高的壓縮率，節省磁盤空間。
  
  
• 自適應編碼
  對不同的列類型還提供了不同的編碼方式，如 INT 類型會使用 BitShuffle 的編碼方式，而字符串類型會使用字典編碼。更進一步的，Palo還會自動根據列的值來切換編碼類型。
  在編碼基礎上還進一步通過LZ4算法進行壓縮，最高提供1:8的數據壓縮比。也就是說，10G數據進入Palo可能只佔用1G多，這樣可以極大節省磁盤空間。
  
  
  這種列式的存儲組織形式還爲上層計算的性能優化提供了很大的便利，特別是在向量化查詢和延遲物化等方面。
  
  

• 文件組織
  文件組織形式上，Palo的文件格式和 Parquet 比較類似。一個數據版本會被分割成最大 256MB 一個的 Segment，每個 Segment 對應一個物理文件。
  Segment 通常分爲 Header、DataRegion、IndexRegion、Footer 這幾個區域。
  Data Region 用於按列存儲數據，每一列又被分爲多個 Page。
  
  
  Index Region 則負責存儲數據的索引，Palo提供了豐富的索引結構來幫助加速數據的讀取和過濾。
  
  
• 索引類型
  索引的類型大體可以分爲 智能索引 和 二級索引 兩種，其中智能索引是在 Palo 數據寫入時自動生成的，無需用戶干預，包括前綴稀疏索引、Min Max索引等。而二級索引是用戶可以選擇性的在某些列上添加的輔助索引，需要用戶自主選擇是否創建，比如像Bloom Filter、BitMap倒排索引等。

查詢引擎

Palo的查詢引擎是 基於 MPP 的火山模型 ，是從早期版本的 Apache Impala 演化而來，也是在各種數據庫系統中應用最廣泛的模型。

• Exchange節點
  相對於一些分佈式 Gette-Setter 框架，最顯著的區別在於其實現了 Exchange 節點。
  在Palo中，一個SQL語句會先生成一個邏輯執行計劃，然後根據數據的分佈，形成一個物理執行計劃。
  
  
  物理執行計劃會有多個 Fragment，而 Fragment 直接的數據傳輸則是由 Exchange 節點完成的。
  有了 Exchange 節點，最大的收益是整個查詢框架擁有了數據 Reshuffle 的能力，通過這個能力，查詢的計算節點不在侷限於數據的存儲節點，從而能夠更好的利用多節點資源進行並行數據處理。
  
  
  在Palo中，物理執行計劃中的 Fragment 會被髮往多個 BE 節點並行執行。不同 Fragment 之間的數據通過 Exchange 節點，根據規則 Shuffle 到對應的上層 Fragment 中。
  
  
  除了節點間並行，Palo還支持在一個節點內部繼續拆分 Fragment，從而進行節點內的並行執行，以充分利用一個節點上的多 CPU 資源。

• 算子優化

  除了整體的執行框架通過並行設計來提高查詢效率外，Palo還對很多具體的查詢算子進行了優化。

  最典型的就是聚合算子和Join算子。

  聚合算子是一種阻塞型的算子，他需要等到全部數據處理完成後，纔會將數據發送給上層節點。

  在Palo，聚合算子會被拆分成兩級聚合。第一級聚合會在數據所在節點先進行一次本地聚合，來減少發送到第二層聚合時需要傳輸的數據量，而第二層聚合會將相同的 Key 匯聚到同一個節點，進行最終的聚合計算。

  在第一級聚合算子中，如果發現數據的聚合效果很低，即使聚合後也無法有效降低需要傳輸的數據量時，則會自動的停止第一級聚合，而將算子轉換爲一個非阻塞的流式算子，直接將讀取到的數據發送到上層節點，從而避免了不必要的阻塞等待時間。

針對 Join 算子，Palo也進行了大量優化，其中 Runtime Filter 是其中很重要的一種優化方式。

在兩個表的 Join 操作中，我們通常將右表稱爲 BuildTable，而左表稱爲 ProbeTable。

在實現上：

1. 首先讀取右表的數據，在內存中構建一個 HashTable（Build）。
2. 讀取左表的每一行數據，並在 HashTable 中進行連接匹配，來返回符合連接條件的數據。

通常來說，左表的數據量會大於右表的數據。

Runtime Filter 的設計思路：

在右表構建 HashTable 的同時，爲連接列生成一個過濾結構。之後把這個過濾列結構下推給左表。這樣一來，左表就可以利用這個過濾結構，對數據進行過濾，從而減少 Probe 節點需要傳輸和比對的數據量。這種過濾結構被稱爲 Runtime Filter。

針對不同的數據，Palo也實現了不同的 Filter 類型，如 In Predicate，Bloom Filter 和 Min Max，用戶可以根據不同場景進行選擇。

Runtime Filter 可以適用於大部分 Join 場景，包括節點的自動穿透，將 Filter 穿透下推到最底層的掃描節點，或者在分部的 Shuffle Join 中，將多個節點產生的 Filter 進行合併後再下推等。

向量化執行引擎

向量化執行引擎，顧名思義，向量化就是算法從一次對一個值進行運算轉換爲一次對一組值進行運算的過程。

向量化執行引擎有以下幾方面的優勢：

1. 減少火山模型中的虛函數調用數量；

2. 以塊爲單位處理數據，提供了cache命中率，從Cache中讀取數據和從內存中讀取數據，性能有10-100倍提升；

3. 多行併發處理，契合了CPU亂序執行與併發執行的特性。

4. 同時處理多行數據，使SIMD有了用武之地。

在Palo中我們正在開發全新的向量化執行引擎，目前已經實現 寬表模型上的向量化查詢， Join和存儲層向量化正在開發中，預計2021年底就可以全面實現向量化。

查詢優化器

對於一個SQL查詢，會在SQL詞法和語法解析完成後生成抽象語法樹，再進一步轉換成關係代數表達式，然後生成邏輯執行計劃。

查詢優化器主要用於從邏輯執行計劃到物理執行計劃的轉換，生成最優的執行計劃交由查詢引擎執行。在這個過程中查詢優化器的作用在很大程度上決定了查詢性能。

基於規則優化RBO就是會將原有表達式裁剪掉，遍歷一系列規則 (Rule)，只要滿足條件就轉換。而基於代價優化CBO會將原有表達式保留，基於統計信息和代價模型，生成最小的執行計劃。

Palo查詢優化器能夠同時進行 基於規則和基於代價的查詢優化 ，這裏我們簡單列了一些優化點，例如常量摺疊、子查詢改寫、謂詞下推以及Join Reorder、Colocate Join和Bucket Shuffle Join 等。

04

簡單易用

通過上述在查詢引擎、存儲引擎以及查詢優化器上做的諸多優化，實現了極致的查詢性能。但性能不是數據庫的全部，對用戶來說，易用性纔是決定是否持續使用的關鍵，Palo從系統設計之初就一直以用戶的易用性作爲出發點。

從一個用戶分析的全週期來看，一般可以簡單歸納成四個方面，從 數據建模→數據導入→用戶上手分析→持續使用以及維護升級 ，Palo的易用性無處不在。

數據建模

通過這個建表語句，就能快速建立起分佈式表。相對於MySQL建表語句，在Palo中只增加了一些分佈式系統所具有的特性，比如分區分桶等，有過分佈式使用經驗的非常易於上手，就算沒有使用過也能快速掌握。

Palo目前支持三類數據模型：

• Aggregate 模型
  可以通過預聚合，極大地降低聚合查詢時所需掃描的數據量和查詢的計算量，非常適合有固定模式的報表類查詢場景。
• Unique Key模型
  針對需要唯一主鍵約束的場景，可以保證主鍵唯一性約束主鍵唯一模型，實現精準去重和行級別數據更新；
• Duplicate 模型
  可以保留全量明細數據，適合任意維度的 Ad-hoc 查詢。雖然同樣無法利用預聚合的特性，但是不受聚合模型的約束，可以發揮列存模型的優勢。

物化視圖是將預先計算（根據定義好的 SELECT 語句）好的數據集，存儲在一個對用戶透明卻有真實數據的視圖表格中。

物化視圖主要是爲了滿足用戶，既能對原始明細數據的任意維度分析，也能快速的對固定維度進行分析查詢，在統一視角下對明細、聚合數據進行分析。

用戶查詢時，Palo會根據當前查詢的語句去自動選擇一個最優的物化視圖，從物化視圖中讀取數據並計算。如果發生數據導入或刪除， 物化視圖會自動更新 ，保證原始表和物化視圖表的數據一致性。

Palo支持兩層的數據劃分。
第一層是 Partition，支持 Range 和 List 的劃分方式。
第二層是 Bucket分桶，將數據通過Hash進行水平劃分，數據分片Tablet均勻在集羣中打散。

數據導入

Palo提供多種數據導入方案，可以針對不同的數據源進行選擇，同時在數據導入過程中提供原子性保證。不論是使用 Broker Load 進行批量導入，還是使用 INSERT 語句進行單條導入，都是一個完整的事務操作。導入事務可以保證一批次內的數據原子生效，不會出現部分數據寫入的情況。

同時，一個導入作業都會有一個 Label。這個 Label 是在一個數據庫（Database）下唯一的，用於唯一標識一個導入作業。Label 可以由用戶指定，部分導入功能也會由系統自動生成。

Label 是用於保證對應的導入作業，僅能成功導入一次。一個被成功導入的 Label，再次使用時，會被拒絕並報錯  Label already used 。通過這個機制，可以在 測做到  At-Most-Once  語義。如果結合上游系統的  At-Least-Once  語義，則可以實現導入數據的  Exactly-Once  語義。

用戶分析

Palo支持標準SQL ，例如單表聚合、排序、過濾以及多表Join、子查詢等都支持，並且SQL語法向MySQL兼容，無額外學習成本。

Adhoc 這類高吞吐的即席查詢和庫內 ETL 場景也是 Palo 的強項。

Palo能夠支持複雜 SQL 語法，包括窗口函數、Grouping Set 等高級語法功能，同時還可以通過 UDF 或 UDAF 來自定義拓展 Palo 的功能。

高併發場景也是Palo的優勢。 Palo是少有的能夠支持高並發現在服務場景的OLAP系統，單節點可以支持上千QPS的查詢請求。

高併發的支持得益於 Palo 的分區分桶裁剪功能。利用查詢條件，Palo可以將查詢固定到極少數分片上，從而顯著降低單個查詢對系統資源的消耗，提升集羣整體的併發查詢能力。

Palo還支持 SQL 級別和 Partition 級別的 Cache。其中 SQL Cache 以 SQL 語句的 Hash 值作爲 Key，直接緩存 SQL 結果，非常適合更新頻率不高，但是查詢非常頻繁的場景。

而 Partition 級別的 Cache，會智能的將 SQL 結果中不同分區的結果數據緩存起來，之後的查詢，可以利用已緩存分區的數據加上新分區實時查詢的數據得到最終的結果，從而降低重複數據的實時查詢需求，減少對系統資源的消耗。

在用戶行爲分析場景，Palo支持BitMap數據類型。可以通過Bitmap進行快速分析，同時Palo內置了很多 Bitmap 相關的函數，用於計算畫像、漏斗、留存等。

在Palo的最新版本中還增加了多租戶和資源隔離的特性。

Palo不僅可以支持集羣內節點級別的資源組劃分，還可以針對單個查詢的資源限制。

維護升級

作爲一款分佈式系統，Palo的升級方式卻極其簡單， 只需要替換二進制程序，滾動重啓集羣即可。

在設計上， Palo完全向前兼容 ，所以也可以通過灰度升級的方式進行新版本的驗證和測試。而 Palo本身的一些失敗重試和故障路由，也極大程度的降低了在升級過程中對業務的影響。

同時Palo自身的分佈式管理框架，可以自動的管理數據副本的分佈、修復和均衡。比如對於副本損壞的情況，Palo會自動感知並進行修復。

而對於節點擴容，僅需一條SQL命令即可完成，Palo會自動進行數據分片的均衡，整個過程完全不影響系統服務，無需運維人員進行任何額外的操作。

安全穩定的雲上託管服務

除此之外還充分利用了雲平臺優勢，例如按需取用的海量資源、更加可控的資源管理等，結合百度智能雲增加了許多雲上特性。包括功能豐富的雲上管控平臺、基於對象存儲BOS的 冷熱數據分離架構以及高效易用的企業級生態組件。

以上是老師的全部分享內容，有問題歡迎在評論區提出。

 往期推薦 

🔗

實時音視頻抗弱網技術揭祕

音視頻終端引擎優化實踐

“智感超清”之HDR技術落地實踐

掃描二維碼，備註：大數據開發，立即加入大數據產品&技術交流羣。

本文分享自微信公衆號 - 百度開發者中心（baidudev）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。