簡介：在3月2日的阿里云開源 PolarDB 企業(yè)級架構(gòu)發(fā)布會上，阿里云 PolarDB 內(nèi)核技術(shù)專家嚴華帶來了主題為《PolarDB HTAP詳解》的精彩演講。在PolarDB存儲計算分離架構(gòu)的基礎(chǔ)上，我們研發(fā)了基于共享存儲的MPP分布式執(zhí)行引擎，解決了單條SQL執(zhí)行時無法利用其它節(jié)點計算資源、無法發(fā)揮共享存儲池的IO大帶寬的問題，同時提供了彈性計算，彈性擴展的保障，使得PolarDB初步具備了 HTAP 的能力。本議題主要介紹PolarDB HTAP的功能特性和關(guān)鍵技術(shù)。

在3月2日的阿里云開源 PolarDB 企業(yè)級架構(gòu)發(fā)布會上，阿里云 PolarDB 內(nèi)核技術(shù)專家嚴華帶來了主題為《PolarDB HTAP詳解》的精彩演講。在PolarDB存儲計算分離架構(gòu)的基礎(chǔ)上，我們研發(fā)了基于共享存儲的MPP分布式執(zhí)行引擎，解決了單條SQL執(zhí)行時無法利用其它節(jié)點計算資源、無法發(fā)揮共享存儲池的IO大帶寬的問題，同時提供了彈性計算，彈性擴展的保障，使得PolarDB初步具備了 HTAP 的能力。本議題主要介紹PolarDB HTAP的功能特性和關(guān)鍵技術(shù)。

直播回顧視頻：開源PolarDB企業(yè)級架構(gòu)重磅發(fā)布-阿里云
PDF下載：?文件下載-阿里云開發(fā)者社區(qū)

以下根據(jù)發(fā)布會演講視頻內(nèi)容整理：

一、背景

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

因為原生的 PolarDB PG 系統(tǒng)在處理復(fù)雜的 AP 查詢時會遇到兩大挑戰(zhàn)：首先，單個 SQL 在原生 PG 執(zhí)行引擎下只能在單個節(jié)點上執(zhí)行，無論是單機串行還是單機并行，都無法利用其他節(jié)點的 CPU memory 等計算資源，只能縱向 Scale Up，不能橫向 Scale Out ；其次，PolarDB 底層是存儲池，理論上 IO 吞吐是無限大的。而單個 SQL 在原生 PG 執(zhí)行引擎下只能在單個節(jié)點上執(zhí)行，受限于單個節(jié)點的 CPU 和 memory 的瓶頸，無法充分發(fā)揮存儲側(cè)大 IO 帶寬的優(yōu)勢。

為了解決用戶實際使用中的痛點，PolarDB 決定做 HTAP。 當(dāng)前業(yè)界HTAP的解決方案主要有以下三種：

① TP 和 AP 在存儲計算上都分離，能夠?qū)崿F(xiàn)TP和AP完全隔離，互不影響。但實際使用中會存在一些問題。首先，TP的數(shù)據(jù)需要導(dǎo)入到AP系統(tǒng)中，會存在一定的延遲，導(dǎo)致時效性不高；其次需要增加冗余的 AP 系統(tǒng)，總成本也會增加；第三，增加了一套 AP 系統(tǒng)后，運維難度也會增加。

② TP 和 AP 在存儲計算上都共享，這樣可以做到成本最小化，資源利用最大化，但仍然存在兩點問題。首先，由于計算共享， AP 查詢和 TP 查詢同時運行時或多或少會存在相互影響；其次，當(dāng) AP 查詢比重增大時，系統(tǒng)需要擴計算節(jié)點存儲，因此需要重分布，導(dǎo)致無法快速彈性Scale Out。

③ TP 和 AP 在存儲上共享，在計算上分離。PolarDB 是存儲計算分離架構(gòu)，因此天然支持此方案。

二、原理

基于 PolarDB 存儲計算分離的架構(gòu)。我們研發(fā)了分布式 MPP 執(zhí)行引擎，提供了跨機并行執(zhí)行、彈性計算彈性擴展的保證，使得 PolarDB 初步具備了 HTAP 的能力。

上圖右是 PolarDB HTAP 的架構(gòu)圖。底層是池化了的共享存儲，TP 和 AP 共享一套存儲數(shù)據(jù)，在降低成本的同時能提供毫秒級的數(shù)據(jù)新鮮度，還提供了快速擴容計算節(jié)點的能力，這也是 PolarDB HTAP 第一個特性。

上層是讀寫分離的計算節(jié)點。PolarDB 具備兩套執(zhí)行引擎來處理 HTAP 查詢，其中單機執(zhí)行引擎在讀寫節(jié)點上進行處理高并發(fā)的 TP 查詢，分布式 MPP 執(zhí)行引擎在只讀節(jié)點上處理復(fù)雜的 AP 查詢，TP和 AP 的查詢天然進行了物理隔離，解耦了 TP 和 AP 的計算環(huán)境，杜絕了 CPU 和 memory 的相互影響，這是 PolarDB HTAP 的第二大特性：TP/AP物理隔離 。

PolarDB HTAP 的第三大特性是 Serverless 彈性擴展，消除了傳統(tǒng) MPP 數(shù)據(jù)庫 coordinate 的單點限制，可以在任何一個只讀節(jié)點上發(fā)起 MPP，可以彈性調(diào)整 MPP 節(jié)點范圍以及單機并行度，同時支持 Scale Out、Scale Up 。此處的彈性調(diào)整是及時生效的，并不需要進行數(shù)據(jù)重分布。

消除傾斜是 PolarDB HTAP 的第四大特性。PolarDB HTAP 在充分考慮 PG BufferPool 親和性的基礎(chǔ)上，能夠消除數(shù)據(jù)傾斜和計算傾斜，實現(xiàn)能者多勞的調(diào)度。

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

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

PolarDB 是共享存儲架構(gòu)，底層共享的數(shù)據(jù)可以被各個計算節(jié)點全量訪問。如果使用傳統(tǒng)的 MPP 執(zhí)行引擎，每個 Worker 都會掃描全量數(shù)據(jù)，會產(chǎn)生重復(fù)的數(shù)據(jù)，同時也沒有起到掃描時分治加速的效果，并不算真正意義上的 MPP 引擎。

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

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

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

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

首先，任意選擇一個節(jié)點作為 coordinator節(jié)點，它的 ReadLSN 會作為約定的 LSN，從所有 MPP 節(jié)點的快照版本號中選擇最小的版本號作為全局約定的快照版本號。通過 LSN 的等待回放和 Global Snaphot 同步機制，確保在任何一個節(jié)點發(fā)起 MPP 查詢時，數(shù)據(jù)和快照均能達到一致可用的狀態(tài)。

為了達到 serverless 的彈性擴展，我們還基于共享存儲的特點，將 coordinator節(jié)點全鏈路上各個模塊需要的外部依賴都放至共享存儲上。各個 Worker 節(jié)點運行時需要的參數(shù)也會通過控制鏈路從 coordinator 節(jié)點同步過來，從而使 coordinator 節(jié)點和 Worker 節(jié)點全鏈路無狀態(tài)化。

基于以上兩點設(shè)計，PolarDB的彈性擴展具備了以下幾大優(yōu)勢：

① 任何節(jié)點都可以成為coordinator 節(jié)點，解決了傳統(tǒng) MPP 數(shù)據(jù)庫 coordinator 的節(jié)點單點問題。

② PolarDB 可以橫向 Scale Out （算力彈性擴展），也可以縱向 Scale Up （單機并行度彈性擴展），并且彈性擴展是及時生效的，不需要重分布數(shù)據(jù)。

③ 允許業(yè)務(wù)有更多的彈性調(diào)度策略，不同的業(yè)務(wù)閾可以運行在不同的節(jié)點集合上。如上圖右側(cè)所示，業(yè)務(wù)域 SQL 1 可以選擇 RO1 和 RO2 節(jié)點來執(zhí)行 AP 查詢，業(yè)務(wù)域 SQL 2 可以選擇使用RO3 和 RO4 節(jié)點來執(zhí)行 AP 查詢。兩個業(yè)務(wù)域使用的計算節(jié)點可以實現(xiàn)彈性調(diào)度。

傾斜是傳統(tǒng) MPP 固有的問題，其原因主要是數(shù)據(jù)分布傾斜和數(shù)據(jù)計算傾斜。數(shù)據(jù)分布傾斜通常由數(shù)據(jù)打散不均衡導(dǎo)致，在 PG 中還會由于大對象 toast 表存儲引入一些不可避免的數(shù)據(jù)分布不均衡問題；計算傾斜通常由于不同節(jié)點上并發(fā)的事務(wù)、 buffer 、網(wǎng)絡(luò)、 IO 抖動導(dǎo)致。傾斜會導(dǎo)致傳統(tǒng) MPP 在執(zhí)行時的木桶效應(yīng)。

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

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

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

三、功能特性

經(jīng)過持續(xù)迭代的研發(fā)，目前 PolarDB HTAP 在支持 Parallel Query 上支持的功能特性主要有五大部分：

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

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

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

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

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

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

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

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

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

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

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

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

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

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。