作者 |  恒義

?背景

說到升艙，我們首先想到的是飛機經(jīng)濟艙升級到商務艙、頭等艙。阿里云企業(yè)級云原生數(shù)據(jù)倉庫AnalyticDB（以下簡稱ADB）[1]在幫助以金融機構為主的行業(yè)數(shù)字化轉(zhuǎn)型和傳統(tǒng)數(shù)倉升級項目中，也引用了“升艙（倉）”這個概念。

長期以來，企業(yè)級數(shù)據(jù)倉庫構建主要以Teradata、Oracle、DB2、Vertica、Greenplum等為主，這些系統(tǒng)一方面功能完備，穩(wěn)定可靠，另一方面成本高，部分有專用硬件限制，同時需要應對業(yè)務幾何級數(shù)據(jù)量規(guī)模增長。以Hadoop生態(tài)為代表的的大數(shù)據(jù)系統(tǒng)主要解決了數(shù)據(jù)分析的大規(guī)模數(shù)據(jù)量問題，在功能完備性，易用性和維護性上與這些傳統(tǒng)數(shù)倉相比，還是有差距。所以大部分金融機構都是在保留已有MPP數(shù)倉核心業(yè)務的基礎上，嘗試部署Hadoop系統(tǒng)用于創(chuàng)新業(yè)務探索，同時解決數(shù)據(jù)增長帶來的成本問題。近年來，一方面國外涌現(xiàn)出了以AWS Redshift，Snowflake，Google BigQuery，Azure Synapse為代表的云原生數(shù)倉（公共云形態(tài)），有對傳統(tǒng)數(shù)倉和Hadoop系統(tǒng)線下形態(tài)的替代和革命之勢。另一方面隨著上述傳統(tǒng)數(shù)倉大廠在國內(nèi)技術市場投入的減少，疊加政策等因素，同時金融、運營商等行業(yè)面臨數(shù)據(jù)規(guī)模增長，數(shù)字化轉(zhuǎn)型，和傳統(tǒng)數(shù)倉升級需求，需要選型下一代數(shù)據(jù)管理和分析系統(tǒng)，另外由于國內(nèi)外市場和政策的區(qū)別，我國金融、運營商、政務等行業(yè)的數(shù)倉構建，主要以混合云為主。在此背景下，企業(yè)級云原生數(shù)據(jù)倉庫AnalyticDB提出了升艙計劃，旨在承擔和幫助金融、運營商、政務等行業(yè)構建下一代數(shù)據(jù)管理和分析系統(tǒng)，以應對不斷增長的數(shù)據(jù)規(guī)模，業(yè)務數(shù)字化轉(zhuǎn)型，和傳統(tǒng)數(shù)倉替換升級需求。7月19日，“千倉萬庫，輕云直上——阿里云數(shù)據(jù)庫升艙計劃實戰(zhàn)峰會”即將在線上召開。

產(chǎn)品介紹

整體架構

AnalyticDB PostgreSQL版（簡稱ADB）在開源Greenplum[2]和PostgreSQL[3]基礎上進行自主研發(fā)，語法層面對兩者保持兼容，功能層面為開源Greenplum超集，同時兼容大部分Oracle、Teradata語法與功能，支持業(yè)務應用以盡可能少的改造工作量對已有數(shù)倉業(yè)務進行遷移升級。其整體架構如下圖：

?圖1 整體架構

ADB由協(xié)調(diào)節(jié)點和計算節(jié)點兩大組件構成，協(xié)調(diào)節(jié)點負責全局事務管理，全局元數(shù)據(jù)存儲，SQL解析，重寫，優(yōu)化，執(zhí)行計劃生成與調(diào)度，計算節(jié)點主要包含執(zhí)行引擎和存儲引擎，其中執(zhí)行引擎既支持Greenplum/PostgreSQL功能強大的原生引擎，又支持數(shù)據(jù)分析場景性能優(yōu)化的自研向量化引擎，多態(tài)化存儲引擎則支持本地行存堆表、列存壓縮表，和外部表，以及基于存儲計算分離架構下的云原生表。協(xié)調(diào)節(jié)點和計算節(jié)點通過雙副本保障高可用，同時通過水平和垂直擴展提供計算和存儲資源的線性擴容。

ADB與阿里云生態(tài)系統(tǒng)高度集成，支持以OSS為備份存儲介質(zhì)的分布式一致性備份恢復（包括全量和增量備份），同時支持通過DBS備份到NAS，HDFS等第三方存儲介質(zhì)。對于存儲在OSS上的ORC，Parquet，JSON，CSV格式用戶數(shù)據(jù)，和MaxCompute上的用戶表和分區(qū)，支持并行高速并行導入加載到本地，或者通過列過濾、謂詞下推直接對OSS上的數(shù)據(jù)進行數(shù)據(jù)湖分析。在云原生架構形態(tài)下，云原生表則在計算節(jié)點本地則只有緩存數(shù)據(jù)（計算節(jié)點無狀態(tài)化），全量數(shù)據(jù)存儲在低成本的OSS上。

使用場景與生態(tài)集成

上面描述了ADB的整體架構和內(nèi)部組件，傳統(tǒng)數(shù)倉遷移替換，或者構建下一代數(shù)據(jù)管理分析系統(tǒng)，除了要具備高可用易擴展的分布式系統(tǒng)架構和功能完備性能出眾的內(nèi)核引擎外，還需要有開放的生態(tài)集成和管理工具配套。下圖從數(shù)據(jù)同步，到數(shù)據(jù)加工，再到數(shù)據(jù)查詢分析，端到端描述了ADB在數(shù)據(jù)處理各個階段的生態(tài)集成，配套工具和場景支持能力。

圖2 使用場景與生態(tài)集成

1、數(shù)據(jù)同步階段，數(shù)據(jù)通過實時寫入或批量加載方式入庫，形成ODS（Operational Data Model）層。典型的數(shù)據(jù)源包括：MySQL/SQL Server/PostgreSQL/Oracle等OLTP業(yè)務數(shù)據(jù)庫，業(yè)務App產(chǎn)生的實時數(shù)據(jù)，在OSS/MaxCompute/Hadoop上的歸檔或原始數(shù)據(jù)，以及來自Kafka/Flink等的流式數(shù)據(jù)。ADB通過MVCC，兩階段提交(2PC)，和全局事務管理(GTM)機制提供分布式事務能力(默認隔離級別Read Committed)，同時在實時寫入場景支持Upsert覆蓋寫(Insert on Conflict，功能等同于Oracle的Merge Into)，批量導入場景支持外表，文件，自定義程序輸出等多種并行高速加載。

2、數(shù)據(jù)加工階段，在庫中對ODS層數(shù)據(jù)進行加工，形成CDM（Common Data Model）和ADS（Application Data Service）層，典型操作包括INSERT INTO SELECT, CREATE TABLE AS等。3、數(shù)據(jù)查詢分析階段，按業(yè)務需求對庫中數(shù)據(jù)進行查詢分析，或供下游系統(tǒng)消費處理，典型的查詢分析場景包括交互式分析，BI報表，數(shù)據(jù)類業(yè)務應用等。ADB既通過存儲引擎索引排序等特性支持高并發(fā)低延時的多維度點查范圍查場景，也通過向量化執(zhí)行引擎，CBO自適應優(yōu)化器，列式存儲支持大數(shù)據(jù)量多表關聯(lián)聚合的復雜分析場景。

產(chǎn)品形態(tài)與硬件平臺

ADB除了在公共云提供國內(nèi)和國際站的SaaS服務外，也通過阿里云飛天企業(yè)版(ApsaraStack)和敏捷版(DBStack)支持混合云輸出，滿足線下部署需求。與部分傳統(tǒng)數(shù)倉需要專有硬件平臺不同，ADB本身支持x86通用硬件部署，同時也支持Arm架構，以及國產(chǎn)化鯤鵬平臺，海光處理器，麒麟系統(tǒng)等。通用硬件和國產(chǎn)化平臺的支持，也是金融等領域數(shù)倉升級的重要參考因素。

核心技術

通過上面概括性的產(chǎn)品介紹，我們對ADB的整體架構，使用場景與生態(tài)工具，產(chǎn)品形態(tài)與硬件平臺支持有了基本了解。下面進一步深入到其在“升艙”項目中的部分硬核技術，包括自研向量化執(zhí)行引擎，多態(tài)化存儲引擎，基于代價的自適應優(yōu)化器，租戶間不同實例和租戶內(nèi)不同負載的資源隔離，以及存儲計算分離形態(tài)的云原生架構。

向量化執(zhí)行引擎

PostgreSQL在上世紀八十年代誕生時數(shù)倉分析OLAP場景尚未出現(xiàn)，其主要用于處理OLTP場景，執(zhí)行引擎是Record-Oriented（Tuple-at-a-time）的火山模型，Greenplum在PostgreSQL基礎上構建了MPP分布式數(shù)據(jù)庫，在執(zhí)行引擎層引入了Motion節(jié)點，使得集群中每個計算節(jié)點都能像單機PostgreSQL一樣運行，共同完成由協(xié)調(diào)節(jié)點下發(fā)的SQL分布式執(zhí)行計劃，最終通過協(xié)調(diào)節(jié)點匯總返回查詢結果，通過分布式并行執(zhí)行大大提升了單機PostgreSQL的性能瓶頸。但在每個計算節(jié)點執(zhí)行引擎內(nèi)部，依然是PostgreSQL原生的Record-Oriented模型（即每個算子每次處理一條記錄），該執(zhí)行模型對與以點查或少數(shù)據(jù)量處理場景為主的TP場景沒有問題，但對于以大數(shù)據(jù)量處理場景為主的OLAP場景，單條記錄處理的開銷較大，綜合性能和效率較低。后期基于Postgres構建的數(shù)據(jù)分析系統(tǒng)，如Redshift，Vertica，Vectorwise（準確來說是基于Postgres的前身Ingres），都對PG原有執(zhí)行引擎進行了替換改造，Redshift主要是基于Code Generation（JIT, Just-in-Time Compilation）和Vectorized Scan，Vectorwise則是純粹的向量化執(zhí)行。PostgreSQL 11也支持了表達式的JIT[4]，用以加速SQL中的表達式處理。

ADB在保留原生Greenplum/PostgreSQL引擎的同時，自研了Block-Oriented(Batch-at-a-time)向量化執(zhí)行引擎，用于處理大數(shù)據(jù)量分析場景。下圖以兩邊關聯(lián)后做聚合的簡單SQL為例，做了兩者對比。

圖3 執(zhí)行模型：Record-Oriented V.S. Block-Orientend對比Record-Oriented通過getNext()接口每次獲取和處理一條記錄，Block-Orientend模式通過getNextBlock()接口每次獲取一批記錄，同時每個執(zhí)行算子綜合運用向量化(Vectorization)[5]和即時編譯(JIT)[6]技術，對這一批記錄執(zhí)行相同處理邏輯，從以下收益出發(fā)，獲得更高效的資源使用，更快的執(zhí)行性能：

• 每次讀取和使用相同邏輯處理一批記錄數(shù)據(jù)，能獲得更高的CPU指令和數(shù)據(jù)緩存命中率[7]。
• 從一次函數(shù)調(diào)用處理一條記錄，到一次函數(shù)調(diào)用處理一批數(shù)據(jù)，同時JIT則直接避免了函數(shù)調(diào)用，總體函數(shù)調(diào)用次數(shù)和開銷[8]減少。
• 內(nèi)存的分配回收，也從每條記錄的分配回收，到每批記錄的分配和回收，整體減少內(nèi)存分配回收次數(shù)和碎片管理開銷[9]。
• 在按批處理模型下，代碼實現(xiàn)能更好地以向量化方式實現(xiàn)，一方面有利于CPU進行數(shù)據(jù)預取，另一方面盡可能減少程序的條件跳轉(zhuǎn)（來自if...else...，switch等分支判斷）和無條件跳轉(zhuǎn)（來自函數(shù)調(diào)用），讓CPU獲得更好的指令流水線執(zhí)行[10]，減少分支預測[11]失敗，同時也有利于編譯器生成SIMD[12]指令，提高執(zhí)行效率。

下圖分別展示了ADB Vectorization在分組聚合SQL場景進行算Hash，桶尋址，求Sum步驟的列式向量化執(zhí)行示例，和JIT在掃描過濾SQL場景進行表達式計算的示例。

圖4 Vectorization與JIT實現(xiàn)示例

向量化按批讀取和處理的行為，在本批次中讓需要處理的數(shù)據(jù)和處理指令都駐留在CPU L1/L2 Cache中，在緩存命中情況下性能為從內(nèi)存讀取的10~30倍[13]，同時對該批次數(shù)據(jù)進行相同指令的處理，也能讓CPU更好的流水線執(zhí)行，減少CPU Hazards[14]。JIT代碼生成針對表達式處理場景，則直接避免了解釋執(zhí)行模式下的函數(shù)高頻函數(shù)調(diào)用（Function Calls）。

多態(tài)化存儲引擎

PostgreSQL原生存儲引擎為堆表（Heap Table）[15]，主要為OLTP場景，核心組件包含默認8KB為單位行級MVCC的數(shù)據(jù)頁Page，緩存管理器Buffer Manager，和預寫日志W(wǎng)AL，以及以Btree為主的索引。Greenplum基于PostgreSQL構建了分布式數(shù)據(jù)庫，主要為OLAP場景，在存儲層主要做了如下技術改造：

1.協(xié)調(diào)節(jié)點新增全局元數(shù)據(jù)和全局事務狀態(tài)管理，以支持分布式架構下在協(xié)調(diào)節(jié)點的事務管理，SQL解析和執(zhí)行計劃生成等需要讀取元數(shù)據(jù)系統(tǒng)表的操作。

2.新增分布式架構下表的水平分布機制（支持哈希，隨機和復制分布策略，對業(yè)務層透明），以及節(jié)點內(nèi)部垂直分區(qū)機制（支持范圍和列表分區(qū)，后續(xù)高版本PostgreSQL自身也增加了分區(qū)機制）。兩者結合支持更大的數(shù)據(jù)規(guī)模和查詢過濾效率。

3.對行存堆表由默認頁大小由8KB設置為32KB，以獲得數(shù)據(jù)分析場景更好的掃描效率。

4.新增列存壓縮表，相比PostgreSQL原生的行存堆表，通過列裁剪和壓縮，進一步提升分析場景的掃描效率。另外列存表的元組(Tuple) ID保持與堆表一致為48位，可以直接適配PostgreSQL現(xiàn)有索引機制（包括Btree，Brin，GIN，GiST等）進行指定列值的索引掃描，加速點查場景。另外利用支持MVCC事務隔離機制的行存堆表作為列存的元數(shù)據(jù)輔助表，一來用于列存數(shù)據(jù)的尋址，二來引入Delete Bitmap通過標記刪除的方式讓列存在追加寫的基礎上支持了更新和刪除，同時列存數(shù)據(jù)也間接有了MVCC和事務隔離能力。

5.引入了PXF外表，用于訪問HDFS，Hive，MySQL，PostgreSQL等外部系統(tǒng)。

ADB在Greenplum基礎上，對本地列存壓縮表和行存堆表進行了進一步增強（包括列存排序合并，排序加速計算，MIN&MAX粗糙過濾，實時物化視圖，自動Analyze/Vacuum/Merge，Upsert等），對外表則新增了對阿里云OSS和MaxCompute的并行導入及數(shù)據(jù)湖分析能力，同時新增了云原生存儲計算分離表（云原生架構產(chǎn)品形態(tài)下支持），存儲按需計費，靈活彈性擴縮，支持數(shù)據(jù)共享。下圖為ADB多態(tài)化存儲引擎概覽。

圖5 多態(tài)化存儲引擎

下面就ADB在存儲引擎層的部分自研能力做進一步技術探討。

稀疏索引

Min&Max Skip Index是ADB在Greenplum列存上新增的第一個自研特性，類似于PostgreSQL9.5開始支持的BRIN，簡單來說為列存表相應列數(shù)據(jù)的每個存儲塊（如varblock）記錄該存儲塊中所有數(shù)據(jù)的最小值（MIN）和最大值（MAX），掃描時將過濾條件與每個存儲塊的MIN和MAX比較，過濾掉一定不包含該過濾條件存儲塊。對于可能包含該過濾條件的存儲塊，則進行具體數(shù)據(jù)讀取，解壓，掃描，比較，獲得具體的匹配記錄。目前主流列存均提供該項能力(如Redshift的Zone Maps[16]，ClickHouse的Skip Indexes[17])，這里不做過多展開。ADB除了記錄了每個存儲塊的MIN&MAX，也記錄了多個連續(xù)存儲塊總體的MIN&MAX，起到進一步快速過濾的效果。

排序合并

排序是列存引擎的關鍵能力，主流列存在建表時都支持定義排序鍵（如Redshift的Compound Sort Key[18]和Interleaved Sort Key[19]，Snowflake的Clustering Key[20], ClickHouse的Order By[21]），支持手工或者后臺自動合并排序，以獲得高效的掃描過濾。同時上面講的MIN&MAX Skip Index必須要依靠排序才能真正發(fā)揮作用（除非數(shù)據(jù)在寫入時就天然有序），試想數(shù)據(jù)無序情況下每個存儲塊的最大值最小值范圍可能都包含過濾條件，比較下來能Skip掉的數(shù)據(jù)塊很少，也就相當于MIN&MAX Skip Index沒有作用。

ADB在列存排序能力上支持組合排序（對應上述Redshift的Compound Sort）和多維排序（對應上述Redshift的Interleaved Sort，目前Databricks的Delta Lake[22]也有該能力），兩者的區(qū)別和使用場景可以參考Redshift的這篇Blog[23]，這里不做詳細展開。通常新寫進來的數(shù)據(jù)為無序狀態(tài)，ADB針對組合排序支持后臺自動排序合并（多維排序可在ETL步驟中執(zhí)行multisort <table>進行排序），一個好的自動合并排序策略需要達到如下四個目標：

1.讓大部分數(shù)據(jù)處于有序狀態(tài)（理想狀態(tài)是所有數(shù)據(jù)都有序）

2.減少數(shù)據(jù)文件數(shù)量和無效數(shù)據(jù)（來自delete和update）在數(shù)據(jù)文件中的占比（理想狀態(tài)是一個文件包含了所有有效且有序數(shù)據(jù)）

3.讓排序合并需要的資源開銷（包括IO，CPU，MEM）最小化

4.對前端業(yè)務負載影響（如鎖，資源競爭等）最小化

這塊目前業(yè)界做的較好且有公開資料有Snowflake的Automatic Clustering[24]，和SingleStore的Background Merger[25]。前者引入的Overlap-Depth的概念來實現(xiàn)上述目標#1，#2，#3，后者的optimistic/pessimistic策略則兼顧了上述所有目標。

ADB的具體實現(xiàn)為將列存數(shù)據(jù)分為Unsorted Region和Sorted Region兩部分，后臺自動排序合并Worker負責將Unsorted Region中的數(shù)據(jù)排序合并成一個Sorted Region的一個文件。在Sorted Region內(nèi)部又分為不同的Sorted Part，每個Sorted Part中的不同有序文件的MIN和MAX值沒有重疊，在掃描時可以把整個Sorted Part當成一個有序文件來處理，提高掃描效率。為了進一步提升Sorted Region內(nèi)數(shù)據(jù)的掃描過濾效率，Sorted Region內(nèi)不同Sorted Part中的文件會進行自動合并，以消除不同Sorted Part間的MIN&MAX重疊，成為一個新的Sorted Part。經(jīng)過早期上線后使用反饋，我們認為Unsorted Region到Sorted Region的排序合并相比Sorted Region內(nèi)部Sorted Parts間的合并優(yōu)先級更高，所以分別定義了Fast Worker和Common Worker來區(qū)分優(yōu)先級地處理兩種場景。同時整個排序過程不影響業(yè)務側(cè)DML操作，這樣也達成了上述的四個目標。整體排序合并如下圖下半部分：

圖6 排序合并 & 查詢加速

上圖展示的另外一個功能是基于有序數(shù)據(jù)的查詢加速。數(shù)據(jù)有序，首先就是提升了MIN&MAX Skip Index的有效性，讓Scan在條件過濾時對文件的Skip和IO更精準。另外執(zhí)行引擎本身就有Sort算子，用于輔助實現(xiàn)SQL中的OrderBy，Group Agg，Merge Join，和Distinct等算子，如果存儲引擎數(shù)據(jù)本身就有序（或者大部分有序，因為在實時寫入場景下Unsorted Region是常態(tài)化存在的），那么執(zhí)行引擎在運行上述要求數(shù)據(jù)有序的算子時就可以利用這一點，減少額外Sort開銷，提升整體性能。所以這里ADB的做法是將這些算子需要的Sort算子下推到Scan中（我們叫做SortScan），讓Scan吐給上層算子的數(shù)據(jù)有序。對于一張有數(shù)據(jù)不斷實時寫入的表，通常每個節(jié)點上的數(shù)據(jù)同時分布于Sorted Region（大部分）和Unsorted Region（小部分）中，SortScan的具體實現(xiàn)如上圖，首先對Unsorted Region的數(shù)據(jù)進行快速排序（如果表數(shù)據(jù)寫入更新相對低頻，那么這部分工作通常是不需要的），然后和Sorted Region的數(shù)據(jù)一起進行歸并排序，讓吐出的數(shù)據(jù)整體有序，從而加速上層依賴排序的算子。另外，有序數(shù)據(jù)在執(zhí)行引擎處理時本身就能帶來很好的緩存命中率，從而提升性能，如Hash表計算，連續(xù)有序數(shù)據(jù)在基數(shù)比較低的情況下有較多重復，在Hash桶尋址時在一段連續(xù)數(shù)據(jù)范圍內(nèi)總是相同。

自動排序合并是當列存引擎要同時支持批處理和實時處理的場景時不可或缺的能力，用來讓其在讀寫性能間獲得最佳平衡。

實時物化視圖

如果說索引用來加速SQL數(shù)據(jù)掃描算子（Scan）的過濾能力(Index Scan)，那么物化視圖則是用來加速整個查詢SQL。PostgreSQL 10[26]和Greenplum 6.2[27]開始分別支持了物化視圖，但功能和使用場景比較有限，均需要手工全量刷新，并且不支持查詢自動改寫。實時物化視圖，一般需要具備自動增量刷新，和自動查詢改寫能力，更高階的還有后臺根據(jù)歷史SQL執(zhí)行情況，自動創(chuàng)建物化視圖。主流數(shù)據(jù)管理系統(tǒng)如Oracle[28]，Redshift[29]，Snowflake[30]在自動增量刷新和查詢改寫能力上均有相應體現(xiàn)。

ADB針對本地行存堆表也構建了實時物化視圖功能，整體設計實現(xiàn)如下圖：

圖7 實時物化視圖

工作流程分為如下步驟：

1.視圖創(chuàng)建：首先用戶根據(jù)業(yè)務常用查詢SQL創(chuàng)建對應的用于加速的實時增量物化視圖

2.視圖自動維護刷新：數(shù)據(jù)寫入更新刪除操作首先作用到User Table本身，同時生成對應的變更日志（包括新增數(shù)據(jù)和刪除數(shù)據(jù)）同步到Delta Log，增量合并刷新則讀取Delta Log，結合MV的具體定義，對每個支持的算子（包括過濾，投影，關聯(lián)和聚集）應用增量合并刷新算法，更新物化視圖內(nèi)容。

3.查詢自動改寫：當前執(zhí)行SELECT查詢SQL時，根據(jù)SQL本身和庫中存在的物化視圖定義，搜索可用于改寫的物化視圖，完成改寫，加速查詢。若沒有可用物化視圖或者輸入SQL不支持自動改寫，依然查詢原表數(shù)據(jù)。

ADB當前物化視圖的實現(xiàn)為強一致模型，和索引一樣，在加速查詢性能的同時，會對寫入性能有一定影響，類似機制本身是業(yè)務在寫入查詢性能兩者間的取舍。如果未來支持最終一致模型，則是在寫入性能和查詢實時性方面的取舍。

Auto Analyze&Vacuum

PostgreSQL本身支持Auto Analyze[31]和Auto Vacuum[32]，前者用于統(tǒng)計信息的自動收集，后者用于表數(shù)據(jù)被更新刪除后的空間自動回收再利用。Greenplum在將單機PostgreSQL改造成分布式架構的同時，并未對這兩項功能進行分布式改造，前者引入了gp_auto_stats_mode[33]來替代，后者則要求DBA定期執(zhí)行。gp_auto_stats_mode的機制是可設置當前表當前沒有統(tǒng)計信息時，則在第一次寫入數(shù)據(jù)結束時自動觸發(fā)Analyze，或者每次寫入更新的數(shù)據(jù)量到達一定數(shù)量時自動觸發(fā)Analyze。這個機制對應數(shù)倉批量導入和數(shù)據(jù)加工場景可以很好地工作，但是遇到實時寫入更新場景則有問題。早期ADB公共云線上在實時流式寫入場景經(jīng)常碰到的問題是表在第一次寫入少量數(shù)據(jù)時執(zhí)行了Analyze后就再也不執(zhí)行了（on_no_stats設置），或者因為實時場景每次寫入的數(shù)據(jù)量少，很少達到on_change設置下觸發(fā)Analyze的條件（gp_autostats_on_change_threshold）。這兩種情況帶來的問題就是統(tǒng)計信息不準，導致執(zhí)行計劃不佳，查詢性能低下（如該走Index Scan的走了Seq Scan，該走Redistribute Motion走了Broadcast Motion，該走Hash Join走了Nestloop Join等）。讓DBA定期做Vacuum也不符合云原生數(shù)據(jù)庫的定位。

基于此背景，ADB在分布式架構下增加了Auto Analyze和Auto Vacuum功能，能夠在每張表的數(shù)據(jù)量變化到達設定閾值（為累積計算，不像gp_auto_stats一樣要求在一次變更中達到）時自動觸發(fā)Analyze和Vacuum?？紤]到該功能為通用能力，上線后我們也將其代碼貢獻給了Greenplum開源社區(qū)。

OSS外表

阿里云OSS[34]是海量低成本對象存儲，亦是數(shù)據(jù)管理系統(tǒng)構建數(shù)據(jù)湖分析的最佳組合。ADB基于Postgres FDW[35]框架實現(xiàn)了分布式架構下的OSS FDW外表，與阿里云生態(tài)高度集成。該能力對應與Redshift的Spectrum[36]和Snowflake的External Table[37]。OSS外表整體場景和架構如下圖。

圖8 OSS外表

ADB存儲引擎在本地行存堆表和本地列存壓縮表的基礎上新增OSS外表，支持OSS多種格式（ORC，Parquet，CSV等）數(shù)據(jù)并行高速加載到本地，或者不加載直接在線分析，亦或者與本地表關聯(lián)分析（加載或分析時OSS上的文件自動均勻映射到對應計算節(jié)點處理），同時支持列存表對冷分區(qū)數(shù)據(jù)自動分層到OSS。為了加速在線分析性能，支持外表Analyze統(tǒng)計信息收集，分區(qū)裁剪，同時對ORC，Parquet列式存儲數(shù)據(jù)支持列裁剪和謂詞下推。除了OSS外表，ADB也支持阿里云Max Compute外表進行數(shù)據(jù)批量加載。

備份恢復

數(shù)據(jù)備份恢復是金融等行業(yè)對企業(yè)級數(shù)倉數(shù)據(jù)能力的普遍要求。單機PostgreSQL可以通過pg_basebackup + WAL歸檔支持Continuous Archiving and Point-in-Time Recovery (PITR)[38], 或者通過pg_dump做表級邏輯備份。Greenplum在基于單機PostgreSQL做分布式架構改造后，并未提供對應集群級物理備份和PITR能力，集群級邏輯備份則通過gpbackup and gprestore[39]提供集群/表級的并行邏輯備份和恢復。gpbackup運行期間系統(tǒng)無法建刪表或改表結構，也不能對用戶表做truncate等操作。早期ADB基于此做定期實例級邏輯備份恢復，公共云業(yè)務實例眾多，每個客戶的維護窗口不同，同時部分業(yè)務較難找到維護窗口，同時數(shù)據(jù)量越大，備份需要的時間也越長。為此ADB對gpbackup做的更細粒度的鎖優(yōu)化，讓備份期間對業(yè)務影響最?。ú蛔枞鸇DL等操作）。優(yōu)化本質(zhì)上是犧牲備份時部分表的一致性（如果遇到業(yè)務DDL的情況），但恢復時依然可手工處理，這樣取舍的背景是認為恢復是低頻操作，但備份是每周甚至一周多次的高頻操作。

邏輯備份恢復所能提供的RPO是較低的，一般默認一周備份一次（最壞情況下RPO也就是一周）。為此ADB開發(fā)了分布式一致性物理增量備份和PITR恢復，功能上達到單機PostgreSQL PITR的能力。整體設計實現(xiàn)如下圖：

圖9 物理備份恢復

一句話講明白就是每個節(jié)點（包括協(xié)調(diào)節(jié)點和計算節(jié)點）都定期做單機PostgreSQL的pg_basebackup + Continuous Archiving, 同時通過周期性的全局恢復點確?；謴蜁r的分布式一致性。從這個層面講PITR就是從原集群記錄的一系列一致性恢復點中選取一個進行恢復，所以理論RPO是最后一次一致性恢復點的時間，恢復點打點周期可設為分鐘到小時級。為了讓備份數(shù)據(jù)盡量小，ADB還實現(xiàn)了全量基礎備份的差異備份能力，對應表中距離上次未變更的數(shù)據(jù)部分在本次基礎備份中不重復備份。在備份數(shù)據(jù)存儲介質(zhì)層面，公共云為OSS，混合云則支持OSS，或者通過DBS[40]支持NAS和HDFS。

自適應優(yōu)化器

PostgreSQL自帶了基于代價估算的Planner優(yōu)化器，其開銷低性能好，對于TP場景和AP簡單分析場景非常高效。Greenplum在將PostgreSQL擴展成分布式架構的同時，也對Planner進行了相應改造，使其能夠生成包含Motion節(jié)點的分布式執(zhí)行計劃。同時Greenplum又新增了ORCA優(yōu)化器[41]，以應對CTE，多表關聯(lián)，動態(tài)分區(qū)裁剪等復雜分析場景，當然一般情況下啟動代價會比Planner高，同時在部分受限場景具備自動回退到Planner的能力。Planner和ORCA本身各有優(yōu)勢且功能完備，能夠覆蓋AP和TP全場景，所以ADB并沒有像執(zhí)行和存儲引擎那樣新增自研優(yōu)化器，而是在SQL解析和重寫階段根據(jù)SQL本身自動選擇最優(yōu)的優(yōu)化器來生成執(zhí)行計劃，同時為Planner增加Plan Hint干預能力，可在少數(shù)場景人工干預局部調(diào)整執(zhí)行計劃。整體邏輯如下圖：

圖10 自適應優(yōu)化器

自適應優(yōu)化器的行為可簡單概括為：AP復雜查詢，啟用ORCA優(yōu)化器，在部分復雜分析場景能生成更優(yōu)的執(zhí)行計劃；TP實時寫入更新刪除點查場景，以及AP簡單查詢分析場景，走PostgreSQL自帶的的經(jīng)過分布式改造的Planner優(yōu)化器，相比ORCA啟動時間短，對SQL整體RT影響小，同時具備HINT人工微調(diào)功能。

多租戶資源隔離

多租戶與資源隔離是云原生數(shù)倉的必備能力，ADB既支持租戶間不同實例的資源隔離，也支持租戶內(nèi)不同負載的資源隔離。前者（管控能力）在公共云通過IaaS層不同ECS實現(xiàn)，混合云則通過容器和Cgroup機制實現(xiàn)，后者（內(nèi)核能力）則基于Greenplum自帶的ResourceQueue[42]，ResourceGroup[43]以及Diskquota[44]實現(xiàn)。下圖以混合云敏捷版DBStack為例，描繪了多租戶下多實例的部署形態(tài)，以及在實例內(nèi)部通過ResourceGroup對不同業(yè)務工作負載的并發(fā)，CPU和內(nèi)存使用配額示例，以提供不同負載間的資源隔離和共享，同時通過DiskQuota可以定義不同用戶、不同Schema的存儲容量使用配額，以更好地規(guī)劃業(yè)務數(shù)據(jù)存儲。

圖11 多租戶與資源隔離

ADB早期版本主要依靠ResourceQueue來控制不容用戶的執(zhí)行隊列并發(fā)和CPU優(yōu)先級，目前開始逐步過渡到ResourceGroup，可提供更精細化和更高效的資源粒度控制。

云原生架構升級

Greenplum本身和Teradata，Vertica等傳統(tǒng)線下部署的數(shù)倉一樣，為經(jīng)典的Shared-Nothing架構，最初云數(shù)倉AWS Redshift也是如此。這類架構具備高性能，功能完備等優(yōu)點，同時也支持線性擴容，但由于數(shù)據(jù)存儲在本地，擴容時涉及到大量數(shù)據(jù)遷移，耗時較長，遷移中的表一般業(yè)務側(cè)需要讀寫等待。另外當不同業(yè)務部門部署多個集群實例確保資源隔離時，每個集群就是一個數(shù)據(jù)孤島，當業(yè)務涉及到相同數(shù)據(jù)的使用時，需要在跨集群實例間進行同步和冗余?；诖诵枨蠛拖拗疲圃鷶?shù)倉Snowflake[45]率先推出了存儲計算分離架構，數(shù)據(jù)和元數(shù)據(jù)持久化存儲由AWS S3和自建分布式KV系統(tǒng)FoundationDB提供，計算資源由獨立的Virtual Datawarehouse組成，彼此間資源隔離，同時通過共享的元數(shù)據(jù)和數(shù)據(jù)存儲又快速做到無冗余數(shù)據(jù)共享，因為本地節(jié)點無狀態(tài)，計算資源本身能做到快速彈性。隨著Snowflake存儲計算分離架構的演進，Redshift也由Shared-Nothing演進到RA3存儲計算分離形態(tài)，而傳統(tǒng)線下數(shù)倉Vertia也推出了Eon Mode[46]存儲計算分離形態(tài)。

基于上述背景，ADB在公共云目前推出了基于存儲計算分離架構的Serverless模式[47]，整體架構如下圖：

圖12 云原生架構升級

基本思路是讓計算節(jié)點無狀態(tài)化，元數(shù)據(jù)逐步抽出存儲到按區(qū)域部署的高性能分布式易擴展KV系統(tǒng)，數(shù)據(jù)存儲到低成本OSS，通過本地緩存加速持久化在OSS上的數(shù)據(jù)IO?；诖思軜嫞瑪?shù)據(jù)存儲按需付費，靈活彈性擴縮容，和數(shù)據(jù)共享也就走進現(xiàn)實。ADB的云原生架構升級和數(shù)據(jù)共享之前已有文章分享和演示，這里不做進一步展開，感興趣讀者可查看：從托管到原生，MPP架構數(shù)據(jù)倉庫的云原生實踐實操寶典 | 如何借助實例間數(shù)據(jù)共享，破解數(shù)倉數(shù)據(jù)流轉(zhuǎn)難題？[48]升艙流程

除了上面介紹的產(chǎn)品能力和技術外，AnalyticDB的Upsert實時寫入覆蓋，存儲過程，系統(tǒng)監(jiān)控診斷等能力也是數(shù)倉替換升級中非常重要的能力。

下面介紹下傳統(tǒng)企業(yè)數(shù)倉到ADB的升艙流程，一張圖表達如下：

圖13 升艙流程

總體分為四步：

1.對已有系統(tǒng)和業(yè)務遷移評估。阿里云提供了Adam遷移評估適配工具，支持Oracle和Teradata到ADB的大部分DDL和SQL自動轉(zhuǎn)換。

2.業(yè)務應用按需改造適配，同步進行DDL和已有系統(tǒng)數(shù)據(jù)到ADB的遷移。DTS數(shù)據(jù)同步傳輸服務支持Orcale到ADB的實時同步，亦可通過快速并行批量導入完成一次性遷移。同時ADB本身基于Greenplum內(nèi)核技術演進和云原生架構升級，第三方生態(tài)工具兼容性好。

3.業(yè)務雙跑驗證。在此階段可引入灰度機制，過渡到業(yè)務割接。

4.業(yè)務完成割接到ADB。

從升艙項目啟動至今，ADB目前已在金融（銀行，保險，證券），運營商，政務等行業(yè)有較多成功案例和標桿，既包括對已有業(yè)務系統(tǒng)中對Teradata，Oracle，DB2，Greenplum的替換升級，也有新業(yè)務的首次上線。

總結

本文從升艙背景，數(shù)倉技術演進，業(yè)務需求出發(fā)，首先介紹了阿里云云原生數(shù)據(jù)倉庫AnalyticDB的整體架構，使用場景與生態(tài)集成，產(chǎn)品形態(tài)與硬件平臺支持，然后逐一介紹了自研向量化執(zhí)行引擎，多態(tài)化存儲引擎，自適應優(yōu)化器，多租戶資源隔離和云原生架構升級等升艙中用到的核心技術。在自研技術層面，按單機PostgreSQL本身對應能力，Greenplum在PostgreSQL上改造后的對應能力，以及業(yè)界主流產(chǎn)品相關能力和技術，到AnalyticDB對應能力構建和具體技術設計實現(xiàn)路線進行技術講解。最后總結了具體升艙四步流程。希望通過本文能讓讀者對ADB從產(chǎn)品架構和核心技術能有全面了解，同時可用于評估業(yè)務升艙可行性。

參考鏈接：

[1]https://www.aliyun.com/product/gpdb

[2]https://arxiv.org/pdf/2103.11080.pdf

[3]https://www.postgresql.org/

[4]https://www.postgresql.org/docs/11/jit.html

[5]https://www.youtube.com/watch?v=Hn4l8XC3-PQ

[6]https://www.youtube.com/watch?v=DvhqgmRQuAk

[7]https://medium.com/@tilakpatidar/vectorized-and-compiled-queries-part-2-cd0d91fa189f

[8]https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.0?topic=performance-reducing-function-call-overhead

[9]https://en.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-1/

[10]https://www.geeksforgeeks.org/computer-organization-and-architecture-pipelining-set-1-execution-stages-and-throughput/

[11]https://www.geeksforgeeks.org/correlating-branch-prediction/

[12]http://ftp.cvut.cz/kernel/people/geoff/cell/ps3-linux-docs/CellProgrammingTutorial/BasicsOfSIMDProgramming.html

[13]https://cvw.cac.cornell.edu/codeopt/memtimes

[14]https://www.geeksforgeeks.org/computer-organization-and-architecture-pipelining-set-2-dependencies-and-data-hazard/

[15]https://www.interdb.jp/pg/pgsql01.html

[16]https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-engineerings-advanced-table-design-playbook-compound-and-interleaved-sort-keys/

[17]https://clickhouse.com/docs/en/guides/improving-query-performance/skipping-indexes/

[18]https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html

[19]https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html

[20]https://docs.snowflake.com/en/user-guide/tables-clustering-keys.html

[21]https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/

[22]https://docs.databricks.com/delta/optimizations/file-mgmt.html

[23]https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-engineerings-advanced-table-design-playbook-compound-and-interleaved-sort-keys/

[24]https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html

[25]https://docs.singlestore.com/managed-service/en/create-a-database/physical-database-schema-design/concepts-of-physical-database-schema-design/columnstore.html

[26]https://www.postgresql.org/docs/10/rules-materializedviews.html

[27]https://gpdb.docs.pivotal.io/6-2/ref_guide/sql_commands/CREATE_MATERIALIZED_VIEW.html

[28]https://oracle-base.com/articles/misc/materialized-views

[29]https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html

[30]https://docs.snowflake.com/en/user-guide/views-materialized.html

[31]https://www.postgresql.org/docs/current/routine-vacuuming.html

[32]https://www.postgresql.org/docs/current/routine-vacuuming.html

[33]https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-best_practices-analyze.html

[34]https://www.aliyun.com/product/oss

[35]https://www.postgresql.org/docs/current/postgres-fdw.html

[36]https://docs.aws.amazon.com/redshift/latest/dg/c-getting-started-using-spectrum.html

[37]https://docs.snowflake.com/en/user-guide/tables-external-intro.html

[38]https://www.postgresql.org/docs/current/continuous-archiving.html

[39]https://docs.vmware.com/en/VMware-Tanzu-Greenplum-Backup-and-Restore/1.25/tanzu-greenplum-backup-and-restore/GUID-admin_guide-managing-backup-gpbackup.html?hWord=N4IghgNiBcIOYAcBOBTAzgFwPapAXyA

[40]https://www.aliyun.com/product/dbs

[41]https://15721.courses.cs.cmu.edu/spring2017/papers/15-optimizer2/p337-soliman.pdf

[42]https://gpdb.docs.pivotal.io/6-11/admin_guide/workload_mgmt.html

[43]https://gpdb.docs.pivotal.io/6-11/admin_guide/workload_mgmt_resgroups.html

[44]https://github.com/greenplum-db/diskquota

[45]http://event.cwi.nl/lsde/papers/p215-dageville-snowflake.pdf

[46]https://www.vertica.com/wp-content/uploads/2018/05/Vertica_EON_SIGMOD_Paper.pdf

[47]https://help.aliyun.com/document_detail/383266.html

[48]https://mp.weixin.qq.com/s/h15UK4--Js5ApFwuY96GKA