一 前言

2021年雙十一剛剛落幕，已連續多年穩定支援雙十一大促的雲原生資料倉庫AnalyticDB，今年雙十一期間仍然一如既往的穩定。除了穩定順滑的基本盤之外，AnalyticDB還有什麼亮點呢？下面我們來一一揭秘。

二 長風破浪 | AnalyticDB再戰雙十一

今年雙十一，AnalyticDB的戰場橫跨阿里數字經濟體、公共雲和混合雲，三個戰場都穩如泰山、成績斐然。在阿里數字經濟體內，AnalyticDB支撐的業務幾乎覆蓋了所有BU，諸如手淘訂單搜尋、菜鳥、淘特、盒馬、飛豬、貓超、阿里雲等近200個雙11相關的核心業務；在公有云上，AnalyticDB支撐著數雲、聚水潭等諸多電商相關的核心業務；在專有云上，AnalyticDB主要支援中國郵政集團的各類業務。今年AnalyticDB支撐的業務負載特別多元化，從單庫百萬級峰值TPS的實時資料寫入到核心交易鏈路的高併發線上訂單檢索和關鍵字精準推薦，從各種業務場景下的複雜實時分析到各種人群和標籤資料的大批次離線Batch&ETL任務以及資料匯入匯出任務，這種五花八門的業務負載，甚至離線上混合負載同時執行的場景，對AnalyticDB提出了巨大的挑戰。

面對這些業務場景和技術挑戰，AnalyticDB迎難而上，今年以來，全面擁抱雲原生構建極致彈性，全面推進儲存計算分離架構，透過冷熱溫分層儲存大幅降低儲存成本，透過升級向量化引擎和最佳化器框架大幅提升計算效能，全面推進離線上一體化架構，進一步提升在一套技術架構下同時穩定執行線上實時查詢和離線批次計算任務的能力。正是有了這些技術積累和沉澱，AnalyticDB在今年的雙十一戰場上才能更加穩定從容，各項業務指標繼續再創新高，今年雙十一期間累計實時寫入21萬億條資料，批次匯入113萬億條資料，完成350億次線上查詢和2500萬個離線任務，累計590PB資料參與計算。

不論是從支援業務場景的複雜度上看，還是從資料規模和計算規模上看，AnalyticDB作為離線上一體化架構下的新一代雲原生資料倉庫已經越來越成熟，可以為各種業務提供核心報表計算、實時分析決策、活動大屏與系統監控、智慧營銷等通用能力。同時，今年AnalyticDB重點結合手淘訂單搜尋和推薦、實時訂單同步等核心業務場景，以技術創新為核心，幫助業務解決了不少長期困擾的棘手問題，助力業務在使用者體驗、綠色低碳、業務創新、安全穩定等方面取得新突破。

1 體驗第一：看AnalyticDB如何最佳化手淘交易訂單搜尋

手淘訂單搜尋支援使用者輸入關鍵詞或訂單號查詢歷史訂單，是通過歷史訂單關聯商品和店鋪從而產生復購的重要流量入口之一。不過由於使用者的歷史訂單資訊量非常大，達數千億之多，而使用者往往僅記得商品或店鋪的模糊資訊，導致使用者輸入的關鍵詞要麼不準確可能搜不到訂單，要麼關鍵字很短導致查詢到訂單很多響應時間很長，極大影響手淘使用者的產品體驗，長期為使用者所詬病。

AnalyticDB基於新實時引擎+行存表+非結構化索引+寬表檢索的線上能力，首次實現了線上和歷史交易訂單的統一儲存、分析，賦能交易業務中臺對全網使用者十年全量的交易訂單進行多維搜尋，並根據使用者的搜尋關鍵字進行精準推薦。大促峰值期間使用者反饋“訂單查不到”的輿情同比大幅下降，查詢效能也得到大幅提升，大大提升了手淘訂單搜尋的使用者體驗。

2 綠色低碳：看AnalyticDB如何助力業務降本增效

公共雲客戶數雲贏家2。0全域CRM平臺透過採用以雲原生資料倉庫AnalyticDB為核心的整體方案，在雙11期間對客戶洞察和細分、自動化營銷等核心功能進行全面升級。基於雲原生、資源池化和冷熱資料分離能力，業務研發週期比往常縮短39%，整體成本下降50%，運營效率提升3倍，解決了採購實施成本過高難題，助力商家快速響應業務變化，降本增效成果顯著。

阿里集團內部一個核心業務的資料分析服務每天需要執行大量ETL離線作業，同時需要支援大量實時資料寫入，以滿足準實時的人群圈選服務和線上人群透視服務需求，支援資料實時寫入和離線上混合負載的AnalyticDB一直是該服務的不二之選。今年雙十一期間，AnalyticDB 承擔了該服務數十PB資料讀寫請求，數百萬次的離線上混合查詢，完成PB級資料量的ETL作業。得益於 AnalyticDB 3。0的雲原生彈效能力，結合儲存/計算/最佳化器 的全鏈路最佳化，成本同比去年雙十一下降近50%。

3 唯快不破：看庫倉一體化架構如何支援高吞吐實時業務

今年雙十一首次採用AnalyticDB+DMS庫倉一體化架構替換了DRC+ESDB實現全實時歷史訂單搜尋等核心場景，快速搭建毫秒級延遲的實時資料鏈路和資料應用，讓實時資料的價值得到充分發揮，助力業務在更加實時的資料應用場景和更加極致的使用者體驗上產生新變化、取得新突破。

在交易訂單搜尋業務中，根據交易業務特點搭建了多路資料同步鏈路並採用AnalyticDB主備容災部署方案，雙十一大促期間輕鬆支援RPS達數百萬的峰值流量，全程毫秒級延遲。

三 常勝之秘 | AnalyticDB最新核心技術解析

1 離線上服務化儲存

AnalyticDB的儲存層今年完成了服務化改造，具備一份資料、一套儲存格式同時支援實時更新、互動式查詢、離線ETL及明細點查多場景一體化能力。基於儲存服務層、行列混存、分層儲存、自適應索引等技術，可同時支援線上低延遲+強一致和離線高吞吐兩種資料讀寫場景。

儲存服務：離線上統一訪問介面

介面層方面，AnalyticDB儲存向上提供統一的資料訪問介面，資料互動採用Apache Arrow［1］資料格式，基於零複製技術實現高效傳輸，計算層可以基於Arrow記憶體列式的介面進行CPU友好的向量化計算加速；元資料相容Hive MetaService的Thrift互動協議，開源計算引擎可以無縫對接AnalyticDB儲存系統。

服務層方面，AnalyticDB儲存採用類LSM架構［2］，把儲存分為實時資料和歷史資料兩部分，實時資料儲存在線上儲存節點上，作為“熱”資料，支援低延遲資料訪問，且支援強一致CURD。歷史資料儲存在OSS或HDFS等低成本的分散式檔案系統上，作為“冷”資料，支援高吞吐資料訪問。同時，AnalyticDB儲存服務層還支援謂詞、投影、聚合、Top N等計算下推能力，減少資料的掃描和讀取量，進一步加速查詢。

行列混存：離線上統一儲存格式

既然提供了一體化的儲存服務，必然會涉及到線上低延遲查詢和離線高吞吐計算場景，AnalyticDB儲存格式採用PAX格式［3］兼顧了離線上兩種場景。

線上場景，與索引配合提供高效的檢索查詢能力。AnalyticDB的儲存格式每個Chunk定長儲存，能夠和索引深度融合，可以基於行號隨機查詢，保證高效的隨機讀效能，可以很好地滿足線上多維度篩選的場景。此外，還提供了豐富的統計資訊，可以和索引配合做疊加最佳化，從而進一步加速查詢。

離線場景，AnalyticDB的儲存格式可以按照Chunk粒度切分資料讀取的並行度，多Chunk並行訪問，提高離線讀的吞吐效能。AnalyticDB的一張表支援多個分割槽，且分割槽內支援多Segment，可以透過切分Segment來提高資料寫入的並行度，從而提高離線寫的吞吐效能。此外，每個Chunk提供了Min/Max等粗糙集索引資訊，可以利用這些索引資訊減少離線讀的資料掃描量和IO資源消耗。

自適應索引

AnalyticDB另一個特色之一是自研自適應索引框架，支援五種索引型別：字串倒排索引、Bitmap索引、數字型別KDTree索引、JSON索引和向量索引；不同型別的索引可以支援多種條件（交、並、差）下列級索引的任意組合；相較於傳統資料庫，AnalyticDB的優勢在於，無需手工構建組合索引（組合索引需要精巧的設計、且容易引起索引資料的空間膨脹）、且支援OR/NOT等更多條件的索引下推。為了降低使用者使用門檻，AnalyticDB在建表時可以一鍵自動開啟全列索引，查詢時透過Index CBO自適應動態篩選索引下推，確定下推的索引鏈會透過謂詞計算層進行流式漸進多路歸併輸出。

冷熱分層：降低使用者成本、按量計費

AnalyticDB提供的冷熱分層儲存能力［4］［5］可以為使用者帶來更高性價比的體驗。使用者可以按表粒度、表的二級分割槽粒度獨立選擇冷、熱儲存介質，比如指定使用者表資料全部儲存在熱儲存介質，或指定表資料全部儲存在冷儲存介質，或指定表的一部分分割槽資料儲存在熱儲存介質，另一部分分割槽資料儲存在冷儲存介質，完全可以按業務需求自由指定，並且冷熱策略可以自由轉換。同時，熱資料和冷資料的空間使用是按量計費的。業務可以根據自己的業務特點，基於AnalyticDB的冷熱儲存分層技術管理業務資料的生命週期，需要頻繁訪問的資料分割槽指定為熱資料儲存在熱儲存介質以加速查詢，不需要頻繁訪問的資料分割槽指定為冷資料儲存在冷儲存介質以降低儲存成本，透過資料分割槽的生命週期管理機制自動清理過期的資料。

2 離線上混合負載

線上場景的計算負載（比如線上查詢）對響應時間要求高，對資料讀取和計算引擎的要求就是快；而離線場景的計算負載（比如ETL任務）對響應時間不敏感，但對計算吞吐有較高要求，不僅資料計算量大，資料讀取和寫入量也可能很大，任務執行時間長。離線上兩種完全不同場景的負載要在一套系統、一個平臺上同時執行一直以來都是一個巨大的挑戰。目前業界的主流解決方案仍然是：離線任務執行在離線大資料計算平臺（比如hadoop/spark/hive）上，線上查詢執行在另外一個或多個單獨的OLAP系統（比如ClickHouse/Doris）上。不過在這種架構下，多個系統內部的資料儲存和格式不統一，計算邏輯表示（比如SQL標準）也不統一，導致資料需要在多個系統之間相互匯入匯出，計算邏輯也需要分別適配對應的系統，資料鏈路冗長，資料計算和使用成本高，資料的時效性也不好。

為了解決此類問題，AnalyticDB今年全面升級離線上混合負載能力，除了儲存層提供離線上統一儲存格式和統一訪問介面用以解決離線上混合負載的資料讀取和寫入問題，計算層也完成了全面升級，相同的SQL查詢可以同時支援Interactive和Batch兩種執行模式，透過資源組、讀寫負載分離、多佇列隔離和查詢優先順序等機制對不同型別的負載進行資源隔離和管控，透過分時彈性滿足不同負載的擴縮容和錯峰需求。同時，計算引擎全面升級為向量化引擎，大幅提升計算效能。

相同SQL兩種執行模式

AnalyticDB支援Interactive和Batch兩種執行模式，以分別滿足線上查詢和離線計算的不同場景需求。Interactive模式下，查詢以MMP（Massive Parallel Processing）方式執行，所有Task同時排程啟動，流式讀取資料並計算輸出結果，所有計算都在記憶體中進行，儘可能減少查詢執行時間，適合線上場景負載。Batch模式下，計算任務以BSP（Bulk Synchronous Parallel）方式執行，整個任務會根據語義切分成多個階段（Stage），根據Stage間的依賴關係進行排程和執行，上游Stage執行完才會執行下游Stage，Stage之間的資料傳遞需要落盤，計算過程中記憶體不足時也會將中間狀態落盤，因此任務整體的執行時間會較長，但對CPU和記憶體等計算資源的需求相對較少，適合資料大、計算資源相對有限的離線場景。

在AnalyticDB內部，不論是Interactive模式還是Batch模式，表達計算邏輯的SQL是統一，產生的邏輯執行計劃也是完全一樣的，只是根據不同的模式生成不同的物理執行計劃，且計算引擎中絕大部分的運算元實現也是相同的，也為統一升級到向量化計算引擎奠定架構基礎。

全新向量化查詢引擎

向量化是當代查詢引擎最佳化查詢效能的熱點技術之一，相關思路最早可以追溯到Array programming在科學計算領域的研究，在資料庫領域的探索則緣起於MonetDB/X100［6］。目前工業界各主流系統都擁有自己的向量化實踐，但仍缺乏標準的形式化定義。一般來講，它被認為是查詢引擎面向CPU microarchitecture一系列最佳化方案的統稱，涉及Batch based iterator model［7］，CodeGen，Cache-awareness演算法［8］以及SIMD指令集應用等技術應用，以及計算/儲存一體化的架構設計。而探索並識別這些技術間正交/依賴的關係是利用好向量化技術取得顯著效能提升的關鍵問題。

AnalyticDB實現了核心運算元的全面向量化，包括Scan，Exchange，Group-by/Agg，以及Join運算元；方案裡結合應用了Batch Processing，Adaptive Strategy，Codegen以及Cache-awareness演算法，並透過與JVM團隊共建，基於AJDK intrinsic能力［9］創新地實現了演算法關鍵路徑上SSE2，AVX512等指令集的應用。顯著提升查詢執行過程中CPU IPL和MPL，熱點運算元Agg/Join的吞吐效能提升2x-15x。

混合負載隔離和穩定性保障

多種負載在同一架構下執行，甚至在同一時刻執行，不可避免存在資源競爭、相互影響的問題。AnalyticDB有一套較為完整的的機制和策略來保證叢集的穩定性，並且儘可能滿足不同業務負載的SLA要求。

首先，在混合負載場景或例項內部多租戶場景下，可以透過資源組進行有效的業務負載隔離。不同資源組之間的計算資源在物理上完全隔離，避免不同型別或業務的負載之間產生相互影響。不同的業務可以透過繫結賬號、提交查詢時指定資源組等多種方式指定執行在對應的資源組上。

其次，AnalyticDB內部會自動區分寫入負載（部分insert和delete）、查詢負載（比如select查詢）和讀寫負載（部分insert/update/delete），不同型別的負載任務自動分派到不同的佇列上，且分配不同的執行優先順序和計算資源。具體來看，寫入請求有單獨的加速寫入鏈路和資源保證，查詢負載預設有較高的執行優先順序，而讀寫負載則預設是較低的執行優先順序。另外，在執行過程中，AnalyticDB會根據叢集的當前負載情況和查詢任務已執行的時長，動態降低執行時間較長的查詢任務的執行優先順序，以緩解Slow Query或Bad Query對其它查詢產生的不利影響。

最後，很多業務都有非常明顯的呈現週期性的波峰波谷，特別是離線計算任務往往是週期性進行排程和執行的，業務高峰期時資源需求暴增可能導致業務不穩定，業務低峰期時資源閒置又導致額外的成本。AnalyticDB提供分時彈性功能，可以幫助使用者在業務高峰期資源不足時擴容資源以保證業務負載穩定執行，在業務低峰期時縮減資源以節約成本。透過合理的業務規劃和資源組管理，使用者甚至可以讓某些資源組在低峰期時釋放所有資源，極大地節約成本。

3 全新最佳化器框架

近年來，自治（Autonomous）能力已經成為資料庫發展的重要方向和趨勢。與傳統資料庫相比，雲資料庫提供一站式託管服務，也對自治能力提出了更高的要求。為此，AnalyticDB 研發了全新的最佳化器架構，向更加智慧化的自治資料庫方向邁進，為使用者帶來更好的體驗。

AnalyticDB 最佳化器進行了大面積的重構升級，主體上拆分成 RBO （Rule-based optimizer） 和 CBO （Cost-based optimizer）。RBO 負責做確定性的最佳化。比如，將過濾條件儘可能下推，以減少後續運算元的運算量。CBO 負責做不確定性的最佳化。比如，調整 JOIN 運算的順序。調整的收益是不確定的，所以需要透過代估模組來決策。為了讓這兩大模組更好的工作，給予使用者更好的體驗，AnalyticDB 引入了全新的四大特性。

特性1：Histogram

直方圖的引入，可以有效提升代估的質量，讓 CBO 選出更好的計劃。直方圖可以有效解決使用者資料值的分佈不均問題，有效解決代估中“均勻分佈假設”問題。為了驗證直方圖效果，AnalyticDB還構建了一套代估質量評價系統。在灰度例項中，代估綜合錯誤率降幅可達50%以上。

特性2：Autonomous statistics

如何管理好表的統計資訊，也是一個非常頭疼的問題。如果把這個問題拋給使用者，讓使用者執行命令去收集統計資訊，會給使用者帶來巨大的困擾。為此，AnalyticDB引入了統計資訊自治框架，來管理這個事情。AnalyticDB會盡可能降低收集動作對使用者的影響，帶來最好的體驗。AnalyticDB會識別出每一列需要收集的統計資訊等級，不同等級收集開銷不同。同時也會識別出統計資訊是否過期，來決定是否要重新收集。

特性3：Incremental statistics

傳統的統計資訊收集方式，需要進行全表掃描。全表掃描開銷大，對使用者影響大，不符合提升使用者體驗的初衷。為此，AnalyticDB引入了增量統計資訊框架，可以只更新單個分割槽的統計資訊，然後透過全域性合併技術，得到整個表全域性的統計資訊。這樣可以大幅降低收集的開銷，減少對使用者的影響。

特性4：Property derivation

如何讓計劃變得更優，屬性推導對此有著重要的意義。它就像電影中的彩蛋，需要你去發掘。我們透過這個特性可以發掘SQL中隱含的資訊，從而進一步最佳化計劃。比如，使用者 SQL 寫了 “A=B” 條件，之後又做了一次 “GROUP BY A，B”，那麼其實是可以簡化成 “GROUP BY A” 或 “GROUP BY B”。因為我們透過屬性推導，知道了A等價於B。

4 智慧診斷和最佳化

智慧診斷

AnalyticDB的智慧診斷功能融合邏輯執行計劃和物理執行計劃，從「Query級別」，「Stage級別」，「運算元級別」三個層次診斷分析，幫使用者快速定位問題Query、Stage和運算元，直接給出直觀的問題分析，如資料傾斜、索引不高效、條件沒下推等，並給出對應的調優建議。目前已經有20+診斷規則上線，涉及查詢相關的記憶體消耗、耗時、資料傾斜、磁碟IO以及執行計劃等多個方面，後續還有更多診斷規則陸續上線。

智慧最佳化

AnalyticDB的智慧最佳化功能提供針對資料庫、表結構的最佳化功能，為使用者提供降低叢集使用成本、提高叢集使用效率的調優建議。該功能基於SQL查詢的效能指標以及使用到的資料表、索引等資訊進行演算法統計分析，自動給出調優建議，減少使用者手動調優的負擔。智慧最佳化目前提供三種類型的最佳化建議：

1） 冷熱資料最佳化：分析資料表的使用情況，對長期未使用的資料表，建議將其遷移至冷盤儲存，約60%的例項可以透過該建議的提示，將 15 天未使用的資料表移至冷存，節省 3 成以上的熱存空間；

2）索引最佳化：分析資料索引的使用情況，對長期未使用的資料索引，建議將其刪除，約50%的例項可以透過該建議的提示，將 15 天未使用的索引進行刪除，節省 3 成以上的熱存空間；

3）分割槽最佳化：分析資料查詢實際需要使用的分佈鍵與資料表定義的分佈列之間的差異，對設計不合理的分佈鍵，建議變更該資料表的分佈鍵，以提高資料的查詢效能。

四 總結和展望

經過多年雙十一的淬鍊，AnalyticDB不僅抗住了一年高過一年的的極端負載和流量，也在不斷豐富的業務場景中逐步成長，不斷賦能到集團內外各種新老業務和場景中，逐步成長為新一代雲原生資料倉庫的佼佼者。接下來AnalyticDB將繼續以“人人可用的資料服務”為使命，進一步擁抱雲原生，構建資料庫+大資料一體化架構，建設極致彈性、離線上一體、高性價比、智慧自治等企業級能力，進一步賦能使用者挖掘資料背後的商業價值。

參考文獻

［1］ Apache Arrow。 https：//arrow。apache。org。

［2］ O‘Neil P ， Cheng E ， Gawlick D ， et al。 The log-structured merge-tree （LSM-tree）［J］。 Acta Informatica， 1996， 33（4）：351-385。

［3］ Ailamaki A ， Dewitt D J ， Hill M D ， et al。 Weaving Relations for Cache Performance。 2001。

［4］ Kakoulli E ， Herodotou H 。 OctopusFS： A Distributed File System with Tiered Storage Management［C］。 ACM， 2017。

［5］ Herodotou H ， Kakoulli E 。 Automating Distributed Tiered Storage Management in Cluster Computing［J］。 Proceedings of the VLDB Endowment， 2019。

［6］ Boncz P A ， Zukowski M ， Nes N J 。 MonetDB/X100： Hyper-Pipelining Query Execution［J］。 CIDR， 2005。

［7］ Zhou J ， Ross K A 。 Buffering database operations for enhanced instruction cache performance。 SIGMOD， 2004。

［8］ S。 Manegold， P。 A。 Boncz， and M。 L。 Kersten。 Optimizing database architecture for the new bottleneck： Memory access。 The VLDB Journal， 9（3）：231-246， 2000。

［9］ JVM intrinsic。 https：//www。baeldung。com/jvm-intrinsics。

雲原生&乘風者聯合徵文活動——說出你和「阿里云云原生」的故事

年末最重磅的徵文活動正式啟動了！！！阿里云云原生團隊聯合阿里雲開發者社群共同釋出的“雲原生乘風者計劃”，邀請廣大技術人，寫下你與阿里云云原生的故事。