阿里雲資料庫開源重磅釋出：PolarDB HTAP的功能特性和關鍵技術
簡介：在3月2日的阿里雲開源 PolarDB 企業級架構釋出會上，阿里雲 PolarDB 核心技術專家嚴華帶來了主題為《PolarDB HTAP詳解》的精彩演講。在PolarDB儲存計算分離架構的基礎上，我們研發了基於共享儲存的MPP分散式執行引擎，解決了單條SQL執行時無法利用其它節點計算資源、無法發揮共享儲存池的IO大頻寬的問題，同時提供了彈性計算，彈性擴充套件的保障，使得PolarDB初步具備了 HTAP 的能力。本議題主要介紹PolarDB HTAP的功能特性和關鍵技術。
在3月2日的阿里雲開源 PolarDB 企業級架構釋出會上，阿里雲 PolarDB 核心技術專家嚴華帶來了主題為《PolarDB HTAP詳解》的精彩演講。在PolarDB儲存計算分離架構的基礎上，我們研發了基於共享儲存的MPP分散式執行引擎，解決了單條SQL執行時無法利用其它節點計算資源、無法發揮共享儲存池的IO大頻寬的問題，同時提供了彈性計算，彈性擴充套件的保障，使得PolarDB初步具備了 HTAP 的能力。本議題主要介紹PolarDB HTAP的功能特性和關鍵技術。
直播回顧視訊：
以下根據釋出會演講視訊內容整理：
一、背景
因為原生的 PolarDB PG 系統在處理複雜的 AP 查詢時會遇到兩大挑戰：首先，單個 SQL 在原生 PG 執行引擎下只能在單個節點上執行，無論是單機序列還是單機並行，都無法利用其他節點的 CPU memory 等計算資源，只能縱向 Scale Up，不能橫向 Scale Out ；其次，PolarDB 底層是儲存池，理論上 IO 吞吐是無限大的。而單個 SQL 在原生 PG 執行引擎下只能在單個節點上執行，受限於單個節點的 CPU 和 memory 的瓶頸，無法充分發揮儲存側大 IO 頻寬的優勢。
為了解決使用者實際使用中的痛點，PolarDB 決定做 HTAP。 當前業界HTAP的解決方案主要有以下三種：
① TP 和 AP 在儲存計算上都分離，能夠實現TP和AP完全隔離，互不影響。但實際使用中會存在一些問題。首先，TP的資料需要匯入到AP系統中，會存在一定的延遲，導致時效性不高；其次需要增加冗餘的 AP 系統，總成本也會增加；第三，增加了一套 AP 系統後，運維難度也會增加。
② TP 和 AP 在儲存計算上都共享，這樣可以做到成本最小化，資源利用最大化，但仍然存在兩點問題。首先，由於計算共享， AP 查詢和 TP 查詢同時執行時或多或少會存在相互影響；其次，當 AP 查詢比重增大時，系統需要擴計算節點儲存，因此需要重分佈，導致無法快速彈性Scale Out。
③ TP 和 AP 在儲存上共享，在計算上分離。PolarDB 是儲存計算分離架構，因此天然支援此方案。
二、原理
上圖右是 PolarDB HTAP 的架構圖。底層是池化了的共享儲存，TP 和 AP 共享一套儲存資料，在降低成本的同時能提供毫秒級的資料新鮮度，還提供了快速擴容計算節點的能力，這也是 PolarDB HTAP 第一個特性。
上層是讀寫分離的計算節點。PolarDB 具備兩套執行引擎來處理 HTAP 查詢，其中單機執行引擎在讀寫節點上進行處理高併發的 TP 查詢，分散式 MPP 執行引擎在只讀節點上處理複雜的 AP 查詢，TP和 AP 的查詢天然進行了物理隔離，解耦了 TP 和 AP 的計算環境，杜絕了 CPU 和 memory 的相互影響，這是 PolarDB HTAP 的第二大特性：TP/AP物理隔離 。
PolarDB HTAP 的第三大特性是 Serverless 彈性擴充套件，消除了傳統 MPP 資料庫 coordinate 的單點限制，可以在任何一個只讀節點上發起 MPP，可以彈性調整 MPP 節點範圍以及單機並行度，同時支援 Scale Out、Scale Up 。此處的彈性調整是及時生效的，並不需要進行資料重分佈。
消除傾斜是 PolarDB HTAP 的第四大特性。PolarDB HTAP 在充分考慮 PG BufferPool 親和性的基礎上，能夠消除資料傾斜和計算傾斜，實現能者多勞的排程。
在傳統的 MPP 執行引擎中，資料被打散到不同的節點上，不同節點上的資料可能具有不同的分佈屬性，比如雜湊分佈、隨機分佈、複製表分佈等。傳統的 MPP 執行引擎會針對不同表的資料分佈特點，在計劃中插入運算元來保證上層運算元對資料的分佈特徵無感知。
PolarDB 是共享儲存架構，底層共享的資料可以被各個計算節點全量訪問。如果使用傳統的 MPP 執行引擎，每個 Worker 都會掃描全量資料，會產生重複的資料，同時也沒有起到掃描時分治加速的效果，並不算真正意義上的 MPP 引擎。
因此，在在 PolarDB 分散式 MPP 執行引擎中，我們借鑑了火山模型論文的思想，對所有掃描運算元進行併發處理，引入了PxScan運算元來遮蔽共享儲存。PxScan運算元將 share-storage 的資料對映為 share-nothing 的資料，通過 Worker之間的協調，將目標表劃分為多個虛擬分割槽資料塊，每個 Worker 掃描各自虛擬分割槽資料塊，從而實現了跨機分散式並行scan。
PxScan運算元掃描出來的資料會通過 shuffle 運算元來重分佈，再在每個 Worker 上如同執行單機一樣，按照火山模型來執行。
以上就是PolarDB 分散式 MPP 執行引擎的核心：shuffle 運算元遮蔽資料分佈，PxScan 運算元遮蔽共享儲存。
首先，任意選擇一個節點作為 coordinator節點，它的 ReadLSN 會作為約定的 LSN，從所有 MPP 節點的快照版本號中選擇最小的版本號作為全域性約定的快照版本號。通過 LSN 的等待回放和 Global Snaphot 同步機制，確保在任何一個節點發起 MPP 查詢時，資料和快照均能達到一致可用的狀態。
為了達到 serverless 的彈性擴充套件，我們還基於共享儲存的特點，將 coordinator節點全鏈路上各個模組需要的外部依賴都放至共享儲存上。各個 Worker 節點執行時需要的引數也會通過控制鏈路從 coordinator 節點同步過來，從而使 coordinator 節點和 Worker 節點全鏈路無狀態化。
基於以上兩點設計，PolarDB的彈性擴充套件具備了以下幾大優勢：
① 任何節點都可以成為coordinator 節點，解決了傳統 MPP 資料庫 coordinator 的節點單點問題。
② PolarDB 可以橫向 Scale Out （算力彈性擴充套件），也可以縱向 Scale Up （單機並行度彈性擴充套件），並且彈性擴充套件是及時生效的，不需要重分佈資料。
③ 允許業務有更多的彈性排程策略，不同的業務閾可以執行在不同的節點集合上。如上圖右側所示，業務域 SQL 1 可以選擇 RO1 和 RO2 節點來執行 AP 查詢，業務域 SQL 2 可以選擇使用RO3 和 RO4 節點來執行 AP 查詢。兩個業務域使用的計算節點可以實現彈性排程。
PolarDB 設計實現了自適應掃描機制。如上圖右所示，採用coordinator節點來協調Worker節點詢問的工作模式。在掃描資料時，coordinator節點會在記憶體中建立一個工作管理員，根據掃描任務對 Worker 節點進行排程。coordinator節點內部分為兩個執行緒，data執行緒主要負責服務資料鏈路、收集彙總元組，control執行緒負責服務控制鏈路、控制每一個掃描運算元的掃描進度。
掃描塊的 Worker 能夠掃描多個數據塊，實現能者多勞。比如上圖中 RO1 與RO3 的 Worker 都各自掃描了4個數據塊， ROI2由於計算傾斜可以掃描更多資料塊，因此它最終掃描了 6 個數據塊。
PolarDB 自適應掃描機制還考慮了 PG BufferPool 的親和性，保證每個 Worker 儘量掃描固定的資料塊，從而最大化命中BufferPool中的快取，降低 IO 開銷。
三、功能特性
① 基礎運算元全支援。不僅包括 scan 類運算元、Join類、聚合類，還包括 SubqueryScan、HashJoin 等。
② 共享儲存運算元優化。包括 shuffle 運算元共享、ShareSeqScan 共享、 ShareIndexScan等。其中ShareSeqScan 共享、 ShareIndexScan共享是指在大表 join 小表時，小表採用類似於複製表的機制來減少廣播開銷，進而提升效能。
③ 分割槽表支援。不僅包括對Hash/Range/List三種分割槽方式的完整支援，還包括對多級分割槽靜態裁剪、分割槽動態裁剪的支援。除此之外，PolarDB 分散式 MPP 執行引擎還支援分割槽表的Partition Wise Join。
④ 並行度彈性控制。包括全域性級別、表級別、會話級別、查詢級別的並行度控制。
⑤ Serverless 彈性擴充套件。不僅包括任意節點發起 MPP、MPP 節點範圍內的任意組合，還包括叢集拓撲資訊的自動維護，以及支援共享儲存模式、主備庫模式、三節點模式。
目前構建索引加速這一特性中，PolarDB 已經對常用 B 樹索引的普通建立以及 B 樹索引的線上建立兩種功能進行了支援。
測試中發現,當 CPU 的總核數增加到 256 核時，效能提升並不大。原因是此時 PolarDB 共享儲存的 IO 頻寬已經打滿，成為了瓶頸。這也從側面說明了 PolarDB 分散式 MPP 執行引擎的計算能力是非常強的。
PolarDB分散式 MPP 能夠進行彈性擴充套件，資料不需要重分佈。因此在這有限的 16 臺機器上執行 MPP 時，PolarDB 還可以繼續擴充套件單機並行度，充分利用機器的資源；當 PolarDB的單機並行度為 8 時，它的效能是傳統 MPP 資料庫的 5-6 倍；當 PolarDB單機並行度呈線性增加時，PolarDB總的效能也呈線性增加，只需要修改配置引數，即可及時生效。
本文為阿里雲原創內容，未經允許不得轉載。