作者 |  恒義

?背景

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

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

產品介紹

整體架構

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

?圖1 整體架構

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

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

使用場景與生態集成

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

圖2 使用場景與生態集成

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

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

產品形態與硬件平臺

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

核心技術

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

向量化執行引擎

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

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

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

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

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

圖4 Vectorization與JIT實現示例

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

多態化存儲引擎

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

1.協調節點新增全局元數據和全局事務狀態管理，以支持分布式架構下在協調節點的事務管理，SQL解析和執行計劃生成等需要讀取元數據系統表的操作。

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

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

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

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

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

圖5 多態化存儲引擎

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

稀疏索引

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

排序合并

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

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

1.讓大部分數據處于有序狀態（理想狀態是所有數據都有序）

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

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

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

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

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

圖6 排序合并 & 查詢加速

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

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

實時物化視圖

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

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

圖7 實時物化視圖

工作流程分為如下步驟：

1.視圖創建：首先用戶根據業務常用查詢SQL創建對應的用于加速的實時增量物化視圖

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

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

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

Auto Analyze&Vacuum

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

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

OSS外表

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

圖8 OSS外表

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

備份恢復

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

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

圖9 物理備份恢復

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

自適應優化器

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

圖10 自適應優化器

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

多租戶資源隔離

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

圖11 多租戶與資源隔離

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

云原生架構升級

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

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

圖12 云原生架構升級

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

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

下面介紹下傳統企業數倉到ADB的升艙流程，一張圖表達如下：

圖13 升艙流程

總體分為四步：

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

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

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

4.業務完成割接到ADB。

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

總結

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

參考鏈接：

[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