題記

分析型資料庫AnalyticDB(下文簡稱ADB），是阿里巴巴自主研發、唯一經過超大規模以及核心業務驗證的PB級實時資料倉庫。截止目前，現有外部支撐客戶既包括傳統的大中型企業和政府機構，也包括眾多的網際網路公司，覆蓋外部十幾個行業。同時，ADB在阿里內部承接著廣告營銷、商家資料服務、菜鳥物流、盒馬新零售等眾多核心業務的高併發低延時的分析處理。

2018年，我們新增了深圳和灣區研發中心迎來更多專業精兵強將的加入，也受到了眾多業務場景挑戰極大的客戶鼎力支援，註定讓這一年在發展史上將留下深深的印記。在過去的這一年，ADB在架構以及產品化演進上，迎來了飛速發展，謹以此文記錄一起走過的2018年。

架構演進

一.接入層和SQL Parser

1.全面採用自研Parser元件-FastSQL

由於歷史原因，ADB的各模組中曾有多個Parser元件，例如當時儲存節點用的是Druid, 接入層SQL解析用的是Antlr Parser, 導致SQL相容性難提升。對於一個上線多年、服務於內外眾多資料業務的ADB來說，熟悉資料庫的同學都知道，替換Parser難度之大，堪比飛行中換引擎。

經過半年多的努力，ADB完成了將上述幾大Parser元件統一升級替換為FastSQL ( Base on Druid，經過開源社群8年的完善，語法支援已經非常完備)。升級為FastSQL後，在SQL相容性大幅度提升、複雜場景解析速度提升30-100倍的同時， FastSQL還能無縫結合優化器，提供常量摺疊、函式變換、表示式轉換、函式型別推斷、常量推斷、語義去重等功能支援，方便優化器生成最優的執行計劃。

2.實時寫入效能提升10倍

在ADB v2.7.4版本開始，在SQL Parser上做了深度技術優化，大幅度提升了INSERT環節的效能，在實際生產環境中效能10倍效能提升，以雲上4*C4為例，item表可以壓測到15w TPS。

3.海量資料流式返回

在ADB v2.7以前的版本，計算框架返回的資料，需要在記憶體中堆積，等待全部執行完才返回到客戶端。在併發大或者結果大時，可能有記憶體溢位的風險。從2.7版本開始，預設採用流式返回，資料實時返回客戶端，能降低延時，極大的提升了大結果集返回的呼叫穩定性。

二. Query Optimizer

2018年，一方面雲上雲下業務全面從ADB上一代的LM引擎，遷移至羲和MPP引擎，另一方面越來越多的客戶不希望走離線或者流計算清洗，實時數倉場景迸發，同時越來越多自動生成SQL的視覺化工具開始對接ADB，對優化器團隊提出了極高挑戰。

為了應對這些挑戰，在這一年裡優化器團隊從無到有，逐漸組建起來一支精練的國際化團隊。在不斷打造磨合過程中，ADB優化器這一年的斬獲如下：

1.建立並完善RBO Plus優化器

不同於傳統RBO優化器，在RBO Plus設計中實現了下列關鍵特性：

1). 引入代價模型和估算，利用ADB的高效儲存介面，引入dynamic selectivity & cardinality估算優化join reorder, 使得ADB可以應對多達10+表join的複雜查詢場景.

2). 針對MPP特別優化data shuffling，aggregation等執行計劃，相對於LM引擎業務場景效能接近零回退。

3). 從功能和效能兩個維度，對各種常見以及複雜關聯子查詢場景進行了深度優化，設計了一系列關聯規則演算法，在各種標準benchmark中相應的查詢中，部分場景up to 20X提升。

4). 針對超短時延(ms)點查，設計了parameterized plan cache，將這些場景的優化時間成本降低10倍以上。

2.打造CBO優化器

面對越來越複雜的業務查詢場景，RBO及RBO Plus有其相應的侷限和挑戰，CBO成為ADB優化器邁向通用商業優化器的關鍵，我們沒有采用雖廣泛使用但侷限性也很多的Calcite優化器，而是著手打造自主可控的CBO優化器，提升ADB的核心競爭力：

1) 建立高效的統計資訊收集體系，平衡準確性與收集代價，為CBO提供“基礎資訊設施”；

2) 構建Cascades架構的CBO框架，將其打造成可擴充套件的優化平臺。

三. 羲和MPP引擎

這一年，ADB架構全面從上一代的LM引擎切換至羲和MPP引擎，羲和引擎一方面既要支撐完成切換，滿足客戶更靈活自由查詢的重任，又要通過大幅度的效能優化來消除引擎切換帶來的某些場景下的效能開銷。

1.全Binary計算

基於Binary 的計算，省去Shuffle 的序列化和反序列化開銷，並且與儲存深度繫結，做到儲存計算一體化，整個計算過程沒有多餘的序列化和反序列化開銷。

2.內部池化

通過定長的記憶體切片完成池化，在計算過程中減少了連續記憶體擴容帶來的消耗，同時通過池化完全自主管控記憶體，避免了在複雜SQL場景下的GC消耗。

3.CodeGen深度優化

1). Cache使用，通過對運算元，表示式的CodeGen常量抽取，快取CodeGen生成的程式碼，在高併發場景下避免了每次都需要動態編譯程式碼的開銷，為支援高併發和QPS的業務打好了基礎。

2). 通過運算元融合減少運算元之間物化的開銷。

4.其它優化

1). 按列計算，通過列式計算與JVM團隊合作引入JDK11支援新的SIMD指令集進行計算優化

2). 自動演算法優化，根據資料分佈，資料取樣自動優化部分執行演算法和記憶體；

3). 運算元自適應的Spill，支援動態的記憶體分配和搶佔，支援join，agg等運算元落盤；

4). 引入新的序列化和反序列框架替換原有的JSON協議，引入新的Netty替換原有Jetty

5). 支援執行時統計資訊收集，包括運算元級，stage級，query級的記憶體、cpu cost統計，支援部分自動識別慢SQL。

四. 玄武儲存引擎

為了滿足業務高併發寫入、低延時的查詢，ADB做了讀寫分離架構設計。在歷史的版本中，讀寫分析架構下有2個問題：1. 寫入到可見是非同步的, 部分場景有讀寫強一致性的訴求。2.增量資料寫入較大的情況下，查詢變慢。同樣，今年儲存引擎在增量資料的實時性和效能上也做出了重大突破。

1.支援讀寫強一致性

最新的ADB版本中，設計了一套完備的一致性讀寫分離架構，如下圖所示：

藍色線代表寫入鏈路，橙色線代表讀取鏈路。以一次寫入和讀取為例，當用戶新寫入某表的資料後，立即發起查詢，此時FN會收集該表在所有BN上的最新寫入版本號(step 3)，並將該版本號(標記為V1)資訊隨同查詢請求一同發往對應的CN節點(step 4)，CN比對該表在本地的消費版本(記為V2)和請求的版本號。

若V1>V2，CN消費到該最新寫入資料(step 5)後提供查詢；若V1

2.提升增量資料區的查詢效能

在 ADB 的儲存節點對於突發的大批量實時寫入，在增量資料區可能短時間內積累較多資料。如果查詢發生在增量資料區，大量的table scan讀取會拖慢整個資料分析效能。為此增量資料區引入 RocksDB 構建增量資料的索引，保證增量資料區的訪問效能，通過LSM-Tree 的分層儲存結果，提供良好的寫入效能，及較好的查詢能力。

五. 分散式Meta服務

歷史版本元資料穩定性挑戰大，各模組各自訪問元資料存在race condition，meta壓力大，DDL體驗差。今年我們重構了元資料模組，上線GMS服務提供元資料統一管理，同時提供分散式DDL能力，並通過分散式快取降低meta庫壓力，提供高效元資料訪問效率。

全域性元資料服務釋出

1). Global Meta Service (GMS)上線生產，提供分散式DDL和資料排程能力，同步建刪表提升使用者體驗。

2). 表分割槽分配演算法改進，為計算排程優化，支援多表組場景下的資料均勻分佈

3). 資料更新(上線)，資料重分佈(Rebalance)穩定性大大提升

六. 硬體加速

GPU雖然已經廣泛用於通用計算，但是通常是用於圖形處理、機器學習和高效能運算等領域。如何將GPU的強大計算能力和ADB進行有機結合，並不是一個容易解決的問題。要想用好GPU，在GPU資源管理、程式碼生成、視訊記憶體管理、資料管理、執行計劃優化等方便，均有諸多挑戰。

2018年，ADB引入了GPU作為計算加速引擎，原本依賴離線分析引擎、隔天才能完成的計算，現在只需要秒級延遲即可完成，成功將資料價值線上化，為客戶帶來了巨大的價值。

1.GPU資源管理

如何讓去訪問GPU資源是首先要解決的問題。 ADB通過jCUDA呼叫CUDA API，用於管理和配置GPU裝置、GPU kernel的啟動介面封裝。該模組作為Java和GPU之間的橋樑，使得JVM可以很方便地呼叫GPU資源。

2.CodeGen

ADB的執行計劃是為CPU做準備的，無法在GPU上執行。而且由於GPU架構的特殊性，GPU的程式設計模型也和CPU不同。為了解決這一問題，引入新的CodeGen模組。CodeGen先是藉助LLVM API將物理計劃編譯成LLVM IR，IR經過優化以後通過轉換成PTX程式碼。然後呼叫CUDA將PTX程式碼轉換成本地可執行程式碼，並啟動其中的GPU計算函式。

CodeGen可以針對不同的處理器生成不同的程式碼，在GPU不可用時，也可以轉至CPU進行執行。相對傳統火山模型，ADB的CodeGen模組有效減少函式呼叫的開銷、充分利用GPU的併發能力。另外Code Generator利用了運算元融合，如group-by聚合、join再加聚合的融合，大大減少中間結果（特別是Join的連線結果）的拷貝和視訊記憶體的佔用。

3.視訊記憶體管理

ADB開發了VRAM Manager用於管理各GPU的視訊記憶體。有別於現在市面上其他GPU資料庫系統使用GPU的方式，為了提升視訊記憶體的利用率、提升併發能力，結合ADB多分割槽、多執行緒的特點，我們設計基於Slab的VRAM Manager來統一管理所有視訊記憶體申請。

效能測試顯示分配時間平均為1ms，明顯快於GPU自帶的視訊記憶體分配介面的700ms，有利於提高系統整體併發度。

4.Plan優化

SQL從FN傳送到CN，Task Manager先根據計算的資料量以及查詢特徵選擇由CPU還是GPU處理，然後根據邏輯計劃生成適合GPU執行的物理計劃。GPU Engine收到物理計劃後先對執行計劃進行重寫。如果計劃符合融合特徵，則啟動複合運算元融合，從而大量減少運算元間臨時資料的傳輸成本。

產品化能力升級

一. 易用性提升

1.全面切換羲和MPP引擎

從2.6.2版本開始，集團內和公有云全部預設MPP引擎，徹底告別上一代LM引擎的各種查詢限制。MPP對SQL寫法支援更加自由靈活，ADB客戶迎來Full MPP時代。

2.SQL相容性大幅度提升

接入層、儲存層Parser模組全部升級為FastSQL後， 外加切換MPP成功，ADB v2.7以後的SQL相容性較歷史版本有了非常大提升。SQL其他優化還包括支援了流式後不再限制查詢結果集返回、分頁相容MySQL等等。

3.自動擴縮容、升降配

6月份釋出了重磅功能: 自動擴縮容+靈活升降配。除了擴縮基本能力外，客戶還可以在規格之間切換。例如從10c4 切換至4c8, 可以從4c8切換至10c4，同時實時表還支援在高效能SSD例項和大儲存SATA例項間來回切換。

上線效果：配置切換做到讀不中斷，寫入中斷約1-2分鐘，後續通過動態漂移分割槽，寫入也能做到完全不停服。

4.新版控制檯和DMS上線

公有云新版的控制檯展示的內容更加豐富，支援控制檯打點，檢視使用者畫像；增加了更多和使用者互動的地方。使用者管理，acl和子賬號授權更加便捷等。DMS全新改版，體驗大幅度提升，方便匯入匯出，支援SQL提示和SQL記憶功能。

5.釋出面向使用者側的監控告警系統

為提升客戶的自助化服務能力，使用者側的監控支援的指標有CPU使用量、查詢和寫入量、資料傾斜、Top Slow SQL等。

6.全網資料庫監控大盤上線

這是全網資料庫的眼睛，彈內雲上資料庫執行狀況一覽無遺。通過對資料庫和系統層各種指標的埋點分析，時刻監控著資料庫的執行狀況，如下圖所示(demo資料)，同時支援將異常指標推送客戶釘釘群，大幅度提升了運營值班效率。

7.釋出可用區

這一年公共雲釋出多可用區支援，徹底解決單個region賣空的問題，企業客戶還可以有選擇的利用可用區做服務容災。

二. 釋出新的核心功能

1.向量分析

今年9月正式釋出向量分析能力，使得結構化與非結構化資料具備融合分析的能力。基於向量聚類規律的向量分割槽規則，按照聚類結果分割槽，讓距離相近的向量就近儲存。在某專有云專案裡，支援1:10億的人臉識別，QPS過萬，延遲在100毫秒內，資料量達到數TB級別。

同時首次支撐銀泰、盒馬等新零售場景的人臉識別、演算法推薦、與結構化資料實時融合分析，毫秒級打通線上線下會員體系，支撐實時資料化線下互動、營銷。

2.全文檢索

ADB v2.7.4版本後，通過SQL語言提供全文檢索功能，將常用的結構化資料分析操作，與靈活的非結構化資料分析操作統一，使用同一套SQL語言操作多種型別資料，降低了學習和開發成本。一方面提供結構化資料、非結構化文字的融合檢索、多模分析能力，另一方面基於MPP+DAG技術提供了完善的分散式計算能力，同時內建了來自淘寶、天貓搜尋的智慧分片語件，分詞效果更好，速度更快。

3.新資料型別 JSON & Decimal

在2.7版本，正式釋出JSON資料型別，完整的支援了包括Object、NULL、Array在內的所有JSON型別的檢索分析，為業務提供了 Schema less的極大靈活性，同時也提供了快速的檢索效能。為了更好方便金融客戶，同樣在2.7版本里，ADB正式釋出Decimal資料型別，向傳統資料庫的資料型別相容性上又邁出了重要的一步。

三. 生態建設

1.資料接入

客戶資料往往有多種多樣，儲存在各種地方。為了追求更低成本、更高效率的資料接入能力，打造實時數倉的能力，ADB今年在資料接入上做了諸多的完善。
1). Copy From OSS & MaxCompute 開發完成，元旦後上線。

2). ADB Uploader釋出，方便本地檔案快速匯入。

3). ADB釋出Logstash外掛，方便日誌資料format後直接寫入ADB，中間無需經過MQ或者HUB。

4). ADB Client SDK釋出並開源，客戶端寫入程式設計邏輯簡化，聚合寫入效能大幅度提升。

5). Batch表匯入穩定性大大提升，同時完成MaxCompute SDK升級和OpenMR切換。

6). Connector Service上線，提供統一資料來源接入層

接下來ADB計劃基於現有框架接入更多資料來源（圖中灰色部分）

2.行業雲接入

完成金融雲、物流雲、聚石塔三大行業雲接入，使得金融、物流、電商中小企業也能享受到低成本的實時資料分析能力，提升企業精細化資料運營的水平。

望未來

2018年，對AnalyticDB來說註定是非同凡響的一年，在架構演進、穩定性、生態建設以及相容性上均取得了長足的進步。這一年我們成功入選全球權威IT諮詢機構Forrester釋出"The Forrester Wave™: CloudData Warehouse,Q4 2018"研究報告的Contenders象限，以及Gartner釋出的分析型資料管理平臺報告 (Magic Quadrant forData Management Solutions for Analytics)，開始進入全球分析市場。

展望未來，我們接下來將繼續在分析效能、穩定性、以及產品化(易用性、資料通道、任務管理、視覺化等周邊生態建設) 上繼續做廣、做深！ADB旨在幫客戶將整個資料分析和價值化從傳統的離線分析帶到下一代的線上實時分析模式。謝謝一路陪我們成長的客戶！感恩，感謝！

點選即可0元試用AnalyticDB