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

一 ?前言

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.

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的双11专刊｜云原生数据仓库AnalyticDB支撑双11，大幅提升分析实时性和用户体验的全部內容，希望文章能夠幫你解決所遇到的問題。

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