作者 |  恒義

?背景

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

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

產(chǎn)品介紹

整體架構(gòu)

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

?圖1 整體架構(gòu)

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

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

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

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

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

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

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

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

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

核心技術(shù)

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

向量化執(zhí)行引擎

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面就ADB在存儲(chǔ)引擎層的部分自研能力做進(jìn)一步技術(shù)探討。

稀疏索引

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

排序合并

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

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

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

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

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

4.對(duì)前端業(yè)務(wù)負(fù)載影響（如鎖，資源競(jìng)爭(zhēng)等）最小化

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

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

圖6 排序合并 & 查詢加速

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

自動(dòng)排序合并是當(dāng)列存引擎要同時(shí)支持批處理和實(shí)時(shí)處理的場(chǎng)景時(shí)不可或缺的能力，用來(lái)讓其在讀寫性能間獲得最佳平衡。

實(shí)時(shí)物化視圖

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

ADB針對(duì)本地行存堆表也構(gòu)建了實(shí)時(shí)物化視圖功能，整體設(shè)計(jì)實(shí)現(xiàn)如下圖：

圖7 實(shí)時(shí)物化視圖

工作流程分為如下步驟：

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

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

3.查詢自動(dòng)改寫：當(dāng)前執(zhí)行SELECT查詢SQL時(shí)，根據(jù)SQL本身和庫(kù)中存在的物化視圖定義，搜索可用于改寫的物化視圖，完成改寫，加速查詢。若沒(méi)有可用物化視圖或者輸入SQL不支持自動(dòng)改寫，依然查詢?cè)頂?shù)據(jù)。

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

Auto Analyze&Vacuum

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

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

OSS外表

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

圖8 OSS外表

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

備份恢復(fù)

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

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

圖9 物理備份恢復(fù)

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

自適應(yīng)優(yōu)化器

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

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

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

多租戶資源隔離

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

圖11 多租戶與資源隔離

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

云原生架構(gòu)升級(jí)

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

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

圖12 云原生架構(gòu)升級(jí)

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

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

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

圖13 升艙流程

總體分為四步：

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

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

3.業(yè)務(wù)雙跑驗(yàn)證。在此階段可引入灰度機(jī)制，過(guò)渡到業(yè)務(wù)割接。

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

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

總結(jié)

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

參考鏈接：

[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