導讀

分析型數據庫AnalyticDB（下文簡稱“ADB”），是阿里巴巴自主研發、唯一經過超大規模以及核心業務驗證的PB級實時數據倉庫。截止目前，現有外部支撐客戶既包括傳統的大中型企業和政府機構，也包括眾多的互聯網公司，覆蓋了十幾個行業。

同時，ADB在阿里內部承接著廣告營銷、商家數據服務、菜鳥物流、盒馬新零售等眾多核心業務的高并發低延時分析處理。

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

作者：阿里巴巴高級產品專家——繆長風

架構演進

一、接入層和SQL Parser

全面采用自研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.支持讀寫強一致性

最新的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.全網數據庫監控大盤上線

這是全網數據庫的眼睛，彈內云上數據庫運行狀況一覽無遺。通過對數據庫和系統層各種指標的埋點分析，時刻監控著數據庫的運行狀況，高亮顯示異常數據庫，同時支持將異常指標推送客戶釘釘群，大幅度提升了運營值班效率。

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象限（相關閱讀：厲害了！阿里分析型數據庫AnalyticDB入選Forrester云化數倉象限），以及Gartner發布的分析型數據管理平臺報告 (Magic Quadrant forData Management Solutions for Analytics)，開始進入全球分析市場。

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

原文發布時間為：2018-01-09
本文作者：繆長風
了解相關信息可以關注“ 阿里巴巴數據庫技術”。

總結

以上是生活随笔為你收集整理的回首2018 | 分析型数据库AnalyticDB：不忘初心 砥砺前行...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。