建站
咨詢
售后
建站咨詢
新聞中心
?背景
說到升艙，我們首先想到的是飛機經濟艙升級到商務艙、頭等艙。阿里云企業(yè)級云原生數(shù)據(jù)倉庫AnalyticDB（以下簡稱ADB）[1]在幫助以金融機構為主的行業(yè)數(shù)字化轉型和傳統(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ù)倉大廠在國內技術市場投入的減少，疊加政策等因素，同時金融、運營商等行業(yè)面臨數(shù)據(jù)規(guī)模增長，數(shù)字化轉型，和傳統(tǒng)數(shù)倉升級需求，需要選型下一代數(shù)據(jù)管理和分析系統(tǒng)，另外由于國內外市場和政策的區(qū)別，我國金融、運營商、政務等行業(yè)的數(shù)倉構建，主要以混合云為主。在此背景下，企業(yè)級云原生數(shù)據(jù)倉庫AnalyticDB提出了升艙計劃，旨在承擔和幫助金融、運營商、政務等行業(yè)構建下一代數(shù)據(jù)管理和分析系統(tǒng)，以應對不斷增長的數(shù)據(jù)規(guī)模，業(yè)務數(shù)字化轉型，和傳統(tǒng)數(shù)倉替換升級需求。7月19日，“千倉萬庫，輕云直上——阿里云數(shù)據(jù)庫升艙計劃實戰(zhàn)峰會”即將在線上召開。
產品介紹
整體架構
AnalyticDB PostgreSQL版（簡稱ADB）在開源Greenplum[2]和PostgreSQL[3]基礎上進行自主研發(fā)，語法層面對兩者保持兼容，功能層面為開源Greenplum超集，同時兼容大部分Oracle、Teradata語法與功能，支持業(yè)務應用以盡可能少的改造工作量對已有數(shù)倉業(yè)務進行遷移升級。其整體架構如下圖：
?圖1 整體架構
ADB由協(xié)調節(jié)點和計算節(jié)點兩大組件構成，協(xié)調節(jié)點負責全局事務管理，全局元數(shù)據(jù)存儲，SQL解析，重寫，優(yōu)化，執(zhí)行計劃生成與調度，計算節(jié)點主要包含執(zhí)行引擎和存儲引擎，其中執(zhí)行引擎既支持Greenplum/PostgreSQL功能強大的原生引擎，又支持數(shù)據(jù)分析場景性能優(yōu)化的自研向量化引擎，多態(tài)化存儲引擎則支持本地行存堆表、列存壓縮表，和外部表，以及基于存儲計算分離架構下的云原生表。協(xié)調節(jié)點和計算節(jié)點通過雙副本保障高可用，同時通過水平和垂直擴展提供計算和存儲資源的線性擴容。
ADB與阿里云生態(tài)系統(tǒng)高度集成，支持以OSS為備份存儲介質的分布式一致性備份恢復（包括全量和增量備份），同時支持通過DBS備份到NAS，HDFS等第三方存儲介質。對于存儲在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的整體架構和內部組件，傳統(tǒng)數(shù)倉遷移替換，或者構建下一代數(shù)據(jù)管理分析系統(tǒng)，除了要具備高可用易擴展的分布式系統(tǒng)架構和功能完備性能出眾的內核引擎外，還需要有開放的生態(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產生的實時數(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)聚合的復雜分析場景。
產品形態(tài)與硬件平臺
ADB除了在公共云提供國內和國際站的SaaS服務外，也通過阿里云飛天企業(yè)版(ApsaraStack)和敏捷版(DBStack)支持混合云輸出，滿足線下部署需求。與部分傳統(tǒng)數(shù)倉需要專有硬件平臺不同，ADB本身支持x86通用硬件部署，同時也支持Arm架構，以及國產化鯤鵬平臺，海光處理器，麒麟系統(tǒng)等。通用硬件和國產化平臺的支持，也是金融等領域數(shù)倉升級的重要參考因素。
核心技術
通過上面概括性的產品介紹，我們對ADB的整體架構，使用場景與生態(tài)工具，產品形態(tài)與硬件平臺支持有了基本了解。下面進一步深入到其在“升艙”項目中的部分硬核技術，包括自研向量化執(zhí)行引擎，多態(tài)化存儲引擎，基于代價的自適應優(yōu)化器，租戶間不同實例和租戶內不同負載的資源隔離，以及存儲計算分離形態(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é)調節(jié)點下發(fā)的SQL分布式執(zhí)行計劃，最終通過協(xié)調節(jié)點匯總返回查詢結果，通過分布式并行執(zhí)行大大提升了單機PostgreSQL的性能瓶頸。但在每個計算節(jié)點執(zhí)行引擎內部，依然是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ù)調用處理一條記錄，到一次函數(shù)調用處理一批數(shù)據(jù)，同時JIT則直接避免了函數(shù)調用，總體函數(shù)調用次數(shù)和開銷[8]減少。
- 內存的分配回收，也從每條記錄的分配回收，到每批記錄的分配和回收，整體減少內存分配回收次數(shù)和碎片管理開銷[9]。
- 在按批處理模型下，代碼實現(xiàn)能更好地以向量化方式實現(xiàn)，一方面有利于CPU進行數(shù)據(jù)預取，另一方面盡可能減少程序的條件跳轉（來自if...else...，switch等分支判斷）和無條件跳轉（來自函數(shù)調用），讓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中，在緩存命中情況下性能為從內存讀取的10~30倍[13]，同時對該批次數(shù)據(jù)進行相同指令的處理，也能讓CPU更好的流水線執(zhí)行，減少CPU Hazards[14]。JIT代碼生成針對表達式處理場景，則直接避免了解釋執(zhí)行模式下的函數(shù)高頻函數(shù)調用（Function Calls）。
多態(tài)化存儲引擎
PostgreSQL原生存儲引擎為堆表（Heap Table）[15]，主要為OLTP場景，核心組件包含默認8KB為單位行級MVCC的數(shù)據(jù)頁Page，緩存管理器Buffer Manager，和預寫日志WAL，以及以Btree為主的索引。Greenplum基于PostgreSQL構建了分布式數(shù)據(jù)庫，主要為OLAP場景，在存儲層主要做了如下技術改造：
1.協(xié)調節(jié)點新增全局元數(shù)據(jù)和全局事務狀態(tài)管理，以支持分布式架構下在協(xié)調節(jié)點的事務管理，SQL解析和執(zhí)行計劃生成等需要讀取元數(shù)據(jù)系統(tǒng)表的操作。
2.新增分布式架構下表的水平分布機制（支持哈希，隨機和復制分布策略，對業(yè)務層透明），以及節(jié)點內部垂直分區(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ù)湖分析能力，同時新增了云原生存儲計算分離表（云原生架構產品形態(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
