阿裡雲資料庫已連續多年穩定支撐天貓雙11，曆經極端流量場景淬煉。除了保障穩定順滑的基本盤，今年大促期間資料庫通過全面雲原生化，大幅提升使用者體驗，讓技術幫助業務産生更有價值的消費者體驗，持續通過技術創新賦能使用者，引領技術發展路徑。
雙11已圓滿落幕，但技術的探索，仍未止步。“阿裡雲資料庫” 公衆号特此推出《好科技的新起點——2021雙11阿裡雲資料庫技術揭秘》系列幹貨文章，為你講述年度“技術大考”背後的故事，敬請關注！
雙11專刊｜雲原生資料倉庫AnalyticDB支撐雙11，大幅提升分析實時性和使用者體驗一 前言二 長風破浪 | 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資源消耗。
雙11專刊｜雲原生資料倉庫AnalyticDB支撐雙11，大幅提升分析實時性和使用者體驗一 前言二 長風破浪 | AnalyticDB再戰雙十一三 常勝之秘 | AnalyticDB最新核心技術解析四 總結和展望參考文獻相關閱讀：
自适應索引
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.