簡介：在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企業級架構重磅發布-阿里云
PDF下載：?文件下載-阿里云開發者社區

以下根據發布會演講視頻內容整理：

一、背景

很多PolarDB 的用戶都有 TP 和 AP 共用的需求，他們白天使用 PolarDB處理高并發的 TP 請求，晚上 TP 流量下降、機器空閑后繼續使用 PolarDB 進行 AP 的報表分析。但是，即使這樣，依然沒有最大化利用空閑機器資源。

因為原生的 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 存儲計算分離的架構。我們研發了分布式 MPP 執行引擎，提供了跨機并行執行、彈性計算彈性擴展的保證，使得 PolarDB 初步具備了 HTAP 的能力。

上圖右是 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 親和性的基礎上，能夠消除數據傾斜和計算傾斜，實現能者多勞的調度。

PolarDB HTAP 原理的核心是分布式 MPP 執行引擎，它是典型的火山引擎。 AB 兩張表先做 join 再做聚合輸出，這也是 PG 單機執行引擎的執行流程。

在傳統的 MPP 執行引擎中，數據被打散到不同的節點上，不同節點上的數據可能具有不同的分布屬性，比如哈希分布、隨機分布、復制表分布等。傳統的 MPP 執行引擎會針對不同表的數據分布特點，在計劃中插入算子來保證上層算子對數據的分布特征無感知。

PolarDB 是共享存儲架構，底層共享的數據可以被各個計算節點全量訪問。如果使用傳統的 MPP 執行引擎，每個 Worker 都會掃描全量數據，會產生重復的數據，同時也沒有起到掃描時分治加速的效果，并不算真正意義上的 MPP 引擎。

因此，在在 PolarDB 分布式 MPP 執行引擎中，我們借鑒了火山模型論文的思想，對所有掃描算子進行并發處理，引入了PxScan算子來屏蔽共享存儲。PxScan算子將 share-storage 的數據映射為 share-nothing 的數據，通過 Worker之間的協調，將目標表劃分為多個虛擬分區數據塊，每個 Worker 掃描各自虛擬分區數據塊，從而實現了跨機分布式并行scan。

PxScan算子掃描出來的數據會通過 shuffle 算子來重分布，再在每個 Worker 上如同執行單機一樣，按照火山模型來執行。

以上就是PolarDB 分布式 MPP 執行引擎的核心：shuffle 算子屏蔽數據分布，PxScan 算子屏蔽共享存儲。

傳統 MPP 只能在指定節點發起 MPP 查詢，因此每個節點上都只能有單個 Worker 掃描一張表。為了支持云原生下 serverless彈性擴展的需求，我們引入了分布式事務一致性保證。

首先，任意選擇一個節點作為 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 查詢。兩個業務域使用的計算節點可以實現彈性調度。

傾斜是傳統 MPP 固有的問題，其原因主要是數據分布傾斜和數據計算傾斜。數據分布傾斜通常由數據打散不均衡導致，在 PG 中還會由于大對象 toast 表存儲引入一些不可避免的數據分布不均衡問題；計算傾斜通常由于不同節點上并發的事務、 buffer 、網絡、 IO 抖動導致。傾斜會導致傳統 MPP 在執行時的木桶效應。

PolarDB 設計實現了自適應掃描機制。如上圖右所示，采用coordinator節點來協調Worker節點詢問的工作模式。在掃描數據時，coordinator節點會在內存中創建一個任務管理器，根據掃描任務對 Worker 節點進行調度。coordinator節點內部分為兩個線程，data線程主要負責服務數據鏈路、收集匯總元組，control線程負責服務控制鏈路、控制每一個掃描算子的掃描進度。

掃描塊的 Worker 能夠掃描多個數據塊，實現能者多勞。比如上圖中 RO1 與RO3 的 Worker 都各自掃描了4個數據塊， ROI2由于計算傾斜可以掃描更多數據塊，因此它最終掃描了 6 個數據塊。

PolarDB 自適應掃描機制還考慮了 PG BufferPool 的親和性，保證每個 Worker 盡量掃描固定的數據塊，從而最大化命中BufferPool中的緩存，降低 IO 開銷。

三、功能特性

經過持續迭代的研發，目前 PolarDB HTAP 在支持 Parallel Query 上支持的功能特性主要有五大部分：

① 基礎算子全支持。不僅包括 scan 類算子、Join類、聚合類，還包括 SubqueryScan、HashJoin 等。

② 共享存儲算子優化。包括 shuffle 算子共享、ShareSeqScan 共享、 ShareIndexScan等。其中ShareSeqScan 共享、 ShareIndexScan共享是指在大表 join 小表時，小表采用類似于復制表的機制來減少廣播開銷，進而提升性能。

③ 分區表支持。不僅包括對Hash/Range/List三種分區方式的完整支持，還包括對多級分區靜態裁剪、分區動態裁剪的支持。除此之外，PolarDB 分布式 MPP 執行引擎還支持分區表的Partition Wise Join。

④ 并行度彈性控制。包括全局級別、表級別、會話級別、查詢級別的并行度控制。

⑤ Serverless 彈性擴展。不僅包括任意節點發起 MPP、MPP 節點范圍內的任意組合，還包括集群拓撲信息的自動維護，以及支持共享存儲模式、主備庫模式、三節點模式。

既然是 HTAP ，則必然不能缺少對 DML 的 MPP 支持。基于 PolarDB讀寫分離架構和 HTAP serverless 彈性擴展的設計， PolarDB parallel DML支持一寫多讀、多寫多讀兩種特性。一寫多讀是指在 RO節點上有多個讀 Worker ，但在 RW節點上只有一個寫 Worker ；多寫多讀是指在 RO 節點上有多個讀 Worker ，在 RW節點上也有多個寫 Worker 。多寫多讀場景下，讀的并發度和寫的并發度是完全解耦的。不同的特性適用不同的場景，用戶可以根據自己的業務特點來選擇不同的PDML功能特性。

PolarDB 分布式 MPP執行引擎，不僅可以用于 query 和 DML ，還可以用于索引構建加速。ALTP業務中有大量的索引，而索引創建過程大約有 80% 的時間消耗在排序和構建索引頁上，20%消耗在寫索引頁上。如右上圖， PolarDB 利用 RO 節點進行數據分布式 MPP 加速排序，采用流程化的技術來構建索引頁，采用批量寫入技術來提高索引頁的寫入速度。

目前構建索引加速這一特性中，PolarDB 已經對常用 B 樹索引的普通創建以及 B 樹索引的在線創建兩種功能進行了支持。

通過上圖與PolarDB原生的單機并行進行對比，可以看出分布式MPP的優勢所在。我們使用線上 PolarDB 16g 和 256g 內存的 16 個 RO 實例，搭建了 1 TB 的 TPCH 環境進行測試對比。相比單機并行，分布式 MPP 并行充分利用了所有 RO 節點的計算資源和底層共享存儲 RO 帶寬，從根本上解決了前文提到的 HTAP 挑戰。在 TPCH 22 條 SQL 中，有 3 條 SQL 加速了 60 多倍，19條 SQL 加速了 10 多倍，平均加速 23 倍。此外，我們也測試了彈性擴大給計算資源帶來的變化。通過增加 CPU 總核數，從 16 核增加到 128 核， TPCH 的總運營時間線性提升，每一個 SQL 也呈線性提升，這也驗證了 PolarDB HTAP serverless 彈性擴展的特性。

測試中發現,當 CPU 的總核數增加到 256 核時，性能提升并不大。原因是此時 PolarDB 共享存儲的 IO 帶寬已經打滿，成為了瓶頸。這也從側面說明了 PolarDB 分布式 MPP 執行引擎的計算能力是非常強的。

此外，我們將 PolarDB 的分布式 MPP 與傳統數據庫的 MPP 進行了對比，同樣使用 16g 和 256g 內存的 16 個節點。 1 TB 的 TPCH 數據在保持與傳統 MPP 數據庫相同的單機并行度為 1 的情況下，PolarDB的性能是傳統 MPP 數據庫的90%。其中最本質的原因是傳統 MPP 數據庫的分布默認是哈希分布，當兩張表的joinkey 是各自的分布鍵時，可以不用 shuffle 直接進行 Local Wise Join 。而 PolarDB 底層是共享存儲池， PxScan 并行掃描出來的數據等價于隨機分布，必須 shuffle 重分布后才能像傳統 MPP 數據庫一樣進行后續的處理。因此, TPCH 涉及到表join時， PolarDB 相比傳統 MPP 數據庫多了一次網絡 shuffle 的開銷。

PolarDB分布式 MPP 能夠進行彈性擴展，數據不需要重分布。因此在這有限的 16 臺機器上執行 MPP 時，PolarDB 還可以繼續擴展單機并行度，充分利用機器的資源；當 PolarDB的單機并行度為 8 時，它的性能是傳統 MPP 數據庫的 5-6 倍；當 PolarDB單機并行度呈線性增加時，PolarDB總的性能也呈線性增加，只需要修改配置參數，即可及時生效。

針對PolarDB HTAP 對構建索引加速特性的支持，我們也進行了性能測試。在 500 GB 的數據量下，當索引的字段有1、2、4個時，分布式 MPP 并行相比單機并行構建索引性能提升了5倍左右；當構建索引的字段增加到8個時，性能提升了4倍左右。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的阿里云数据库开源发布：PolarDB HTAP的功能特性和关键技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。