阿里云數(shù)據(jù)庫已連續(xù)多年穩(wěn)定支撐天貓雙11，歷經(jīng)極端流量場景淬煉。除了保障穩(wěn)定順滑的基本盤，今年大促期間數(shù)據(jù)庫通過全面云原生化，大幅提升用戶體驗，讓技術(shù)幫助業(yè)務(wù)產(chǎn)生更有價值的消費者體驗，持續(xù)通過技術(shù)創(chuàng)新賦能用戶，引領(lǐng)技術(shù)發(fā)展路徑。

雙11已圓滿落幕，但技術(shù)的探索，仍未止步。

“阿里云數(shù)據(jù)庫” 公眾號特此推出《好科技的新起點——2021雙11阿里云數(shù)據(jù)庫技術(shù)揭秘》系列干貨文章，為你講述年度“技術(shù)大考”背后的故事，敬請關(guān)注！

1

前言

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

2

長風(fēng)破浪 | AnalyticDB再戰(zhàn)雙十一

今年雙十一，AnalyticDB的戰(zhàn)場橫跨阿里數(shù)字經(jīng)濟體、公共云和混合云，三個戰(zhàn)場都穩(wěn)如泰山、成績斐然。在阿里數(shù)字經(jīng)濟體內(nèi)，AnalyticDB支撐的業(yè)務(wù)幾乎覆蓋了所有BU，諸如手淘訂單搜索、菜鳥、淘特、盒馬、飛豬、貓超、阿里云等近200個雙11相關(guān)的核心業(yè)務(wù)；在公有云上，AnalyticDB支撐著數(shù)云、聚水潭等諸多電商相關(guān)的核心業(yè)務(wù)；在專有云上，AnalyticDB主要支持中國郵政集團的各類業(yè)務(wù)。今年AnalyticDB支撐的業(yè)務(wù)負載特別多元化，從單庫百萬級峰值TPS的實時數(shù)據(jù)寫入到核心交易鏈路的高并發(fā)在線訂單檢索和關(guān)鍵字精準推薦，從各種業(yè)務(wù)場景下的復(fù)雜實時分析到各種人群和標簽數(shù)據(jù)的大批量離線Batch&ETL任務(wù)以及數(shù)據(jù)導(dǎo)入導(dǎo)出任務(wù)，這種五花八門的業(yè)務(wù)負載，甚至離在線混合負載同時執(zhí)行的場景，對AnalyticDB提出了巨大的挑戰(zhàn)。
面對這些業(yè)務(wù)場景和技術(shù)挑戰(zhàn)，AnalyticDB迎難而上，今年以來，全面擁抱云原生構(gòu)建極致彈性，全面推進存儲計算分離架構(gòu)，通過冷熱溫分層存儲大幅降低存儲成本，通過升級向量化引擎和優(yōu)化器框架大幅提升計算性能，全面推進離在線一體化架構(gòu)，進一步提升在一套技術(shù)架構(gòu)下同時穩(wěn)定運行在線實時查詢和離線批量計算任務(wù)的能力。正是有了這些技術(shù)積累和沉淀，AnalyticDB在今年的雙十一戰(zhàn)場上才能更加穩(wěn)定從容，各項業(yè)務(wù)指標繼續(xù)再創(chuàng)新高，今年雙十一期間累計實時寫入21萬億條數(shù)據(jù)，批量導(dǎo)入113萬億條數(shù)據(jù)，完成350億次在線查詢和2500萬個離線任務(wù)，累計590PB數(shù)據(jù)參與計算。
不論是從支持業(yè)務(wù)場景的復(fù)雜度上看，還是從數(shù)據(jù)規(guī)模和計算規(guī)模上看，AnalyticDB作為離在線一體化架構(gòu)下的新一代云原生數(shù)據(jù)倉庫已經(jīng)越來越成熟，可以為各種業(yè)務(wù)提供核心報表計算、實時分析決策、活動大屏與系統(tǒng)監(jiān)控、智能營銷等通用能力。同時，今年AnalyticDB重點結(jié)合手淘訂單搜索和推薦、實時訂單同步等核心業(yè)務(wù)場景，以技術(shù)創(chuàng)新為核心，幫助業(yè)務(wù)解決了不少長期困擾的棘手問題，助力業(yè)務(wù)在用戶體驗、綠色低碳、業(yè)務(wù)創(chuàng)新、安全穩(wěn)定等方面取得新突破。

1  體驗第一：看AnalyticDB如何優(yōu)化手淘交易訂單搜索

手淘訂單搜索支持用戶輸入關(guān)鍵詞或訂單號查詢歷史訂單，是通過歷史訂單關(guān)聯(lián)商品和店鋪從而產(chǎn)生復(fù)購的重要流量入口之一。不過由于用戶的歷史訂單信息量非常大，達數(shù)千億之多，而用戶往往僅記得商品或店鋪的模糊信息，導(dǎo)致用戶輸入的關(guān)鍵詞要么不準確可能搜不到訂單，要么關(guān)鍵字很短導(dǎo)致查找到訂單很多響應(yīng)時間很長，極大影響手淘用戶的產(chǎn)品體驗，長期為用戶所詬病。
AnalyticDB基于新實時引擎+行存表+非結(jié)構(gòu)化索引+寬表檢索的在線能力，首次實現(xiàn)了在線和歷史交易訂單的統(tǒng)一存儲、分析，賦能交易業(yè)務(wù)中臺對全網(wǎng)用戶十年全量的交易訂單進行多維搜索，并根據(jù)用戶的搜索關(guān)鍵字進行精準推薦。大促峰值期間用戶反饋“訂單查不到”的輿情同比大幅下降，查詢性能也得到大幅提升，大大提升了手淘訂單搜索的用戶體驗。

2  綠色低碳：看AnalyticDB如何助力業(yè)務(wù)降本增效

公共云客戶數(shù)云贏家2.0全域CRM平臺通過采用以云原生數(shù)據(jù)倉庫AnalyticDB為核心的整體方案，在雙11期間對客戶洞察和細分、自動化營銷等核心功能進行全面升級?；谠圃?、資源池化和冷熱數(shù)據(jù)分離能力，業(yè)務(wù)研發(fā)周期比往?？s短39%，整體成本下降50%，運營效率提升3倍，解決了采購實施成本過高難題，助力商家快速響應(yīng)業(yè)務(wù)變化，降本增效成果顯著。
阿里集團內(nèi)部一個核心業(yè)務(wù)的數(shù)據(jù)分析服務(wù)每天需要執(zhí)行大量ETL離線作業(yè)，同時需要支持大量實時數(shù)據(jù)寫入，以滿足準實時的人群圈選服務(wù)和在線人群透視服務(wù)需求，支持數(shù)據(jù)實時寫入和離在線混合負載的AnalyticDB一直是該服務(wù)的不二之選。今年雙十一期間，AnalyticDB 承擔(dān)了該服務(wù)數(shù)十PB數(shù)據(jù)讀寫請求，數(shù)百萬次的離在線混合查詢，完成PB級數(shù)據(jù)量的ETL作業(yè)。得益于 AnalyticDB 3.0的云原生彈性能力，結(jié)合存儲/計算/優(yōu)化器 的全鏈路優(yōu)化，成本同比去年雙十一下降近50%。

3  唯快不破：看庫倉一體化架構(gòu)如何支持高吞吐實時業(yè)務(wù)

今年雙十一首次采用AnalyticDB+DMS庫倉一體化架構(gòu)替換了DRC+ESDB實現(xiàn)全實時歷史訂單搜索等核心場景，快速搭建毫秒級延遲的實時數(shù)據(jù)鏈路和數(shù)據(jù)應(yīng)用，讓實時數(shù)據(jù)的價值得到充分發(fā)揮，助力業(yè)務(wù)在更加實時的數(shù)據(jù)應(yīng)用場景和更加極致的用戶體驗上產(chǎn)生新變化、取得新突破。
在交易訂單搜索業(yè)務(wù)中，根據(jù)交易業(yè)務(wù)特點搭建了多路數(shù)據(jù)同步鏈路并采用AnalyticDB主備容災(zāi)部署方案，雙十一大促期間輕松支持RPS達數(shù)百萬的峰值流量，全程毫秒級延遲。

3

常勝之秘 | AnalyticDB最新核心技術(shù)解析

1  離在線服務(wù)化存儲

AnalyticDB的存儲層今年完成了服務(wù)化改造，具備一份數(shù)據(jù)、一套存儲格式同時支持實時更新、交互式查詢、離線ETL及明細點查多場景一體化能力?；诖鎯Ψ?wù)層、行列混存、分層存儲、自適應(yīng)索引等技術(shù)，可同時支持在線低延遲+強一致和離線高吞吐兩種數(shù)據(jù)讀寫場景。

存儲服務(wù)：離在線統(tǒng)一訪問接口

接口層方面，AnalyticDB存儲向上提供統(tǒng)一的數(shù)據(jù)訪問接口，數(shù)據(jù)交互采用Apache Arrow[1]數(shù)據(jù)格式，基于零拷貝技術(shù)實現(xiàn)高效傳輸，計算層可以基于Arrow內(nèi)存列式的接口進行CPU友好的向量化計算加速；元數(shù)據(jù)兼容Hive MetaService的Thrift交互協(xié)議，開源計算引擎可以無縫對接AnalyticDB存儲系統(tǒng)。
服務(wù)層方面，AnalyticDB存儲采用類LSM架構(gòu)[2]，把存儲分為實時數(shù)據(jù)和歷史數(shù)據(jù)兩部分，實時數(shù)據(jù)存儲在在線存儲節(jié)點上，作為“熱”數(shù)據(jù)，支持低延遲數(shù)據(jù)訪問，且支持強一致CURD。歷史數(shù)據(jù)存儲在OSS或HDFS等低成本的分布式文件系統(tǒng)上，作為“冷”數(shù)據(jù)，支持高吞吐數(shù)據(jù)訪問。同時，AnalyticDB存儲服務(wù)層還支持謂詞、投影、聚合、Top N等計算下推能力，減少數(shù)據(jù)的掃描和讀取量，進一步加速查詢。

行列混存：離在線統(tǒng)一存儲格式

既然提供了一體化的存儲服務(wù)，必然會涉及到在線低延遲查詢和離線高吞吐計算場景，AnalyticDB存儲格式采用PAX格式[3]兼顧了離在線兩種場景。
在線場景，與索引配合提供高效的檢索查找能力。AnalyticDB的存儲格式每個Chunk定長存儲，能夠和索引深度融合，可以基于行號隨機查找，保證高效的隨機讀性能，可以很好地滿足在線多維度篩選的場景。此外，還提供了豐富的統(tǒng)計信息，可以和索引配合做疊加優(yōu)化，從而進一步加速查詢。
離線場景，AnalyticDB的存儲格式可以按照Chunk粒度切分數(shù)據(jù)讀取的并行度，多Chunk并行訪問，提高離線讀的吞吐性能。AnalyticDB的一張表支持多個分區(qū)，且分區(qū)內(nèi)支持多Segment，可以通過切分Segment來提高數(shù)據(jù)寫入的并行度，從而提高離線寫的吞吐性能。此外，每個Chunk提供了Min/Max等粗糙集索引信息，可以利用這些索引信息減少離線讀的數(shù)據(jù)掃描量和IO資源消耗。

自適應(yīng)索引

AnalyticDB另一個特色之一是自研自適應(yīng)索引框架，支持五種索引類型：字符串倒排索引、Bitmap索引、數(shù)字類型KDTree索引、JSON索引和向量索引；不同類型的索引可以支持多種條件（交、并、差）下列級索引的任意組合；相較于傳統(tǒng)數(shù)據(jù)庫，AnalyticDB的優(yōu)勢在于，無需手工構(gòu)建組合索引（組合索引需要精巧的設(shè)計、且容易引起索引數(shù)據(jù)的空間膨脹）、且支持OR/NOT等更多條件的索引下推。為了降低用戶使用門檻，AnalyticDB在建表時可以一鍵自動開啟全列索引，查詢時通過Index CBO自適應(yīng)動態(tài)篩選索引下推，確定下推的索引鏈會通過謂詞計算層進行流式漸進多路歸并輸出。

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

AnalyticDB提供的冷熱分層存儲能力[4][5]可以為用戶帶來更高性價比的體驗。用戶可以按表粒度、表的二級分區(qū)粒度獨立選擇冷、熱存儲介質(zhì)，比如指定用戶表數(shù)據(jù)全部存儲在熱存儲介質(zhì)，或指定表數(shù)據(jù)全部存儲在冷存儲介質(zhì)，或指定表的一部分分區(qū)數(shù)據(jù)存儲在熱存儲介質(zhì)，另一部分分區(qū)數(shù)據(jù)存儲在冷存儲介質(zhì)，完全可以按業(yè)務(wù)需求自由指定，并且冷熱策略可以自由轉(zhuǎn)換。同時，熱數(shù)據(jù)和冷數(shù)據(jù)的空間使用是按量計費的。業(yè)務(wù)可以根據(jù)自己的業(yè)務(wù)特點，基于AnalyticDB的冷熱存儲分層技術(shù)管理業(yè)務(wù)數(shù)據(jù)的生命周期，需要頻繁訪問的數(shù)據(jù)分區(qū)指定為熱數(shù)據(jù)存儲在熱存儲介質(zhì)以加速查詢，不需要頻繁訪問的數(shù)據(jù)分區(qū)指定為冷數(shù)據(jù)存儲在冷存儲介質(zhì)以降低存儲成本，通過數(shù)據(jù)分區(qū)的生命周期管理機制自動清理過期的數(shù)據(jù)。

2  離在線混合負載

在線場景的計算負載（比如在線查詢）對響應(yīng)時間要求高，對數(shù)據(jù)讀取和計算引擎的要求就是快；而離線場景的計算負載（比如ETL任務(wù)）對響應(yīng)時間不敏感，但對計算吞吐有較高要求，不僅數(shù)據(jù)計算量大，數(shù)據(jù)讀取和寫入量也可能很大，任務(wù)執(zhí)行時間長。離在線兩種完全不同場景的負載要在一套系統(tǒng)、一個平臺上同時執(zhí)行一直以來都是一個巨大的挑戰(zhàn)。目前業(yè)界的主流解決方案仍然是：離線任務(wù)運行在離線大數(shù)據(jù)計算平臺（比如hadoop/spark/hive）上，在線查詢運行在另外一個或多個單獨的OLAP系統(tǒng)（比如ClickHouse/Doris）上。不過在這種架構(gòu)下，多個系統(tǒng)內(nèi)部的數(shù)據(jù)存儲和格式不統(tǒng)一，計算邏輯表示（比如SQL標準）也不統(tǒng)一，導(dǎo)致數(shù)據(jù)需要在多個系統(tǒng)之間相互導(dǎo)入導(dǎo)出，計算邏輯也需要分別適配對應(yīng)的系統(tǒng)，數(shù)據(jù)鏈路冗長，數(shù)據(jù)計算和使用成本高，數(shù)據(jù)的時效性也不好。
為了解決此類問題，AnalyticDB今年全面升級離在線混合負載能力，除了存儲層提供離在線統(tǒng)一存儲格式和統(tǒng)一訪問接口用以解決離在線混合負載的數(shù)據(jù)讀取和寫入問題，計算層也完成了全面升級，相同的SQL查詢可以同時支持Interactive和Batch兩種執(zhí)行模式，通過資源組、讀寫負載分離、多隊列隔離和查詢優(yōu)先級等機制對不同類型的負載進行資源隔離和管控，通過分時彈性滿足不同負載的擴縮容和錯峰需求。同時，計算引擎全面升級為向量化引擎，大幅提升計算性能。

相同SQL兩種執(zhí)行模式

AnalyticDB支持Interactive和Batch兩種執(zhí)行模式，以分別滿足在線查詢和離線計算的不同場景需求。Interactive模式下，查詢以MMP(Massive Parallel Processing)方式執(zhí)行，所有Task同時調(diào)度啟動，流式讀取數(shù)據(jù)并計算輸出結(jié)果，所有計算都在內(nèi)存中進行，盡可能減少查詢執(zhí)行時間，適合在線場景負載。Batch模式下，計算任務(wù)以BSP(Bulk Synchronous Parallel)方式執(zhí)行，整個任務(wù)會根據(jù)語義切分成多個階段（Stage），根據(jù)Stage間的依賴關(guān)系進行調(diào)度和執(zhí)行，上游Stage執(zhí)行完才會執(zhí)行下游Stage，Stage之間的數(shù)據(jù)傳遞需要落盤，計算過程中內(nèi)存不足時也會將中間狀態(tài)落盤，因此任務(wù)整體的執(zhí)行時間會較長，但對CPU和內(nèi)存等計算資源的需求相對較少，適合數(shù)據(jù)大、計算資源相對有限的離線場景。
在AnalyticDB內(nèi)部，不論是Interactive模式還是Batch模式，表達計算邏輯的SQL是統(tǒng)一，產(chǎn)生的邏輯執(zhí)行計劃也是完全一樣的，只是根據(jù)不同的模式生成不同的物理執(zhí)行計劃，且計算引擎中絕大部分的算子實現(xiàn)也是相同的，也為統(tǒng)一升級到向量化計算引擎奠定架構(gòu)基礎(chǔ)。

全新向量化查詢引擎

向量化是當(dāng)代查詢引擎優(yōu)化查詢性能的熱點技術(shù)之一，相關(guān)思路最早可以追溯到Array programming在科學(xué)計算領(lǐng)域的研究，在數(shù)據(jù)庫領(lǐng)域的探索則緣起于MonetDB/X100[6]。目前工業(yè)界各主流系統(tǒng)都擁有自己的向量化實踐，但仍缺乏標準的形式化定義。一般來講，它被認為是查詢引擎面向CPU microarchitecture一系列優(yōu)化方案的統(tǒng)稱，涉及Batch based iterator model[7]，CodeGen，Cache-awareness算法[8]以及SIMD指令集應(yīng)用等技術(shù)應(yīng)用，以及計算/存儲一體化的架構(gòu)設(shè)計。而探索并識別這些技術(shù)間正交/依賴的關(guān)系是利用好向量化技術(shù)取得顯著性能提升的關(guān)鍵問題。
AnalyticDB實現(xiàn)了核心算子的全面向量化，包括Scan，Exchange，Group-by/Agg，以及Join算子；方案里結(jié)合應(yīng)用了Batch Processing，Adaptive Strategy，Codegen以及Cache-awareness算法，并通過與JVM團隊共建，基于AJDK intrinsic能力[9]創(chuàng)新地實現(xiàn)了算法關(guān)鍵路徑上SSE2，AVX512等指令集的應(yīng)用。顯著提升查詢執(zhí)行過程中CPU IPL和MPL，熱點算子Agg/Join的吞吐性能提升2x-15x。

混合負載隔離和穩(wěn)定性保障

多種負載在同一架構(gòu)下運行，甚至在同一時刻運行，不可避免存在資源競爭、相互影響的問題。AnalyticDB有一套較為完整的的機制和策略來保證集群的穩(wěn)定性，并且盡可能滿足不同業(yè)務(wù)負載的SLA要求。
首先，在混合負載場景或?qū)嵗齼?nèi)部多租戶場景下，可以通過資源組進行有效的業(yè)務(wù)負載隔離。不同資源組之間的計算資源在物理上完全隔離，避免不同類型或業(yè)務(wù)的負載之間產(chǎn)生相互影響。不同的業(yè)務(wù)可以通過綁定賬號、提交查詢時指定資源組等多種方式指定運行在對應(yīng)的資源組上。
其次，AnalyticDB內(nèi)部會自動區(qū)分寫入負載（部分insert和delete）、查詢負載（比如select查詢）和讀寫負載（部分insert/update/delete），不同類型的負載任務(wù)自動分派到不同的隊列上，且分配不同的執(zhí)行優(yōu)先級和計算資源。具體來看，寫入請求有單獨的加速寫入鏈路和資源保證，查詢負載默認有較高的執(zhí)行優(yōu)先級，而讀寫負載則默認是較低的執(zhí)行優(yōu)先級。另外，在執(zhí)行過程中，AnalyticDB會根據(jù)集群的當(dāng)前負載情況和查詢?nèi)蝿?wù)已運行的時長，動態(tài)降低運行時間較長的查詢?nèi)蝿?wù)的執(zhí)行優(yōu)先級，以緩解Slow Query或Bad Query對其它查詢產(chǎn)生的不利影響。

最后，很多業(yè)務(wù)都有非常明顯的呈現(xiàn)周期性的波峰波谷，特別是離線計算任務(wù)往往是周期性進行調(diào)度和執(zhí)行的，業(yè)務(wù)高峰期時資源需求暴增可能導(dǎo)致業(yè)務(wù)不穩(wěn)定，業(yè)務(wù)低峰期時資源閑置又導(dǎo)致額外的成本。AnalyticDB提供分時彈性功能，可以幫助用戶在業(yè)務(wù)高峰期資源不足時擴容資源以保證業(yè)務(wù)負載穩(wěn)定執(zhí)行，在業(yè)務(wù)低峰期時縮減資源以節(jié)約成本。通過合理的業(yè)務(wù)規(guī)劃和資源組管理，用戶甚至可以讓某些資源組在低峰期時釋放所有資源，極大地節(jié)約成本。

3  全新優(yōu)化器框架

近年來，自治（Autonomous）能力已經(jīng)成為數(shù)據(jù)庫發(fā)展的重要方向和趨勢。與傳統(tǒng)數(shù)據(jù)庫相比，云數(shù)據(jù)庫提供一站式托管服務(wù)，也對自治能力提出了更高的要求。為此，AnalyticDB 研發(fā)了全新的優(yōu)化器架構(gòu)，向更加智能化的自治數(shù)據(jù)庫方向邁進，為用戶帶來更好的體驗。

AnalyticDB 優(yōu)化器進行了大面積的重構(gòu)升級，主體上拆分成 RBO (Rule-based optimizer) 和 CBO (Cost-based optimizer)。RBO 負責(zé)做確定性的優(yōu)化。比如，將過濾條件盡可能下推，以減少后續(xù)算子的運算量。CBO 負責(zé)做不確定性的優(yōu)化。比如，調(diào)整 JOIN 運算的順序。調(diào)整的收益是不確定的，所以需要通過代估模塊來決策。為了讓這兩大模塊更好的工作，給予用戶更好的體驗，AnalyticDB 引入了全新的四大特性。

特性1：Histogram

直方圖的引入，可以有效提升代估的質(zhì)量，讓 CBO 選出更好的計劃。直方圖可以有效解決用戶數(shù)據(jù)值的分布不均問題，有效解決代估中“均勻分布假設(shè)”問題。為了驗證直方圖效果，AnalyticDB還構(gòu)建了一套代估質(zhì)量評價系統(tǒng)。在灰度實例中，代估綜合錯誤率降幅可達50%以上。

特性2：Autonomous statistics

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

特性3：Incremental statistics

傳統(tǒng)的統(tǒng)計信息收集方式，需要進行全表掃描。全表掃描開銷大，對用戶影響大，不符合提升用戶體驗的初衷。為此，AnalyticDB引入了增量統(tǒng)計信息框架，可以只更新單個分區(qū)的統(tǒng)計信息，然后通過全局合并技術(shù)，得到整個表全局的統(tǒng)計信息。這樣可以大幅降低收集的開銷，減少對用戶的影響。

特性4：Property derivation

如何讓計劃變得更優(yōu)，屬性推導(dǎo)對此有著重要的意義。它就像電影中的彩蛋，需要你去發(fā)掘。我們通過這個特性可以發(fā)掘SQL中隱含的信息，從而進一步優(yōu)化計劃。比如，用戶 SQL 寫了 “A=B” 條件，之后又做了一次 “GROUP BY A,B”，那么其實是可以簡化成 “GROUP BY A” 或 “GROUP BY B”。因為我們通過屬性推導(dǎo)，知道了A等價于B。

4  智能診斷和優(yōu)化

智能診斷

AnalyticDB的智能診斷功能融合邏輯執(zhí)行計劃和物理執(zhí)行計劃，從「Query級別」,「Stage級別」，「算子級別」三個層次診斷分析，幫用戶快速定位問題Query、Stage和算子，直接給出直觀的問題分析，如數(shù)據(jù)傾斜、索引不高效、條件沒下推等，并給出對應(yīng)的調(diào)優(yōu)建議。目前已經(jīng)有20+診斷規(guī)則上線，涉及查詢相關(guān)的內(nèi)存消耗、耗時、數(shù)據(jù)傾斜、磁盤IO以及執(zhí)行計劃等多個方面，后續(xù)還有更多診斷規(guī)則陸續(xù)上線。

智能優(yōu)化

AnalyticDB的智能優(yōu)化功能提供針對數(shù)據(jù)庫、表結(jié)構(gòu)的優(yōu)化功能，為用戶提供降低集群使用成本、提高集群使用效率的調(diào)優(yōu)建議。該功能基于SQL查詢的性能指標以及使用到的數(shù)據(jù)表、索引等信息進行算法統(tǒng)計分析，自動給出調(diào)優(yōu)建議，減少用戶手動調(diào)優(yōu)的負擔(dān)。智能優(yōu)化目前提供三種類型的優(yōu)化建議：
1） 冷熱數(shù)據(jù)優(yōu)化：分析數(shù)據(jù)表的使用情況，對長期未使用的數(shù)據(jù)表，建議將其遷移至冷盤存儲，約60%的實例可以通過該建議的提示，將 15 天未使用的數(shù)據(jù)表移至冷存，節(jié)省 3 成以上的熱存空間；
2）索引優(yōu)化：分析數(shù)據(jù)索引的使用情況，對長期未使用的數(shù)據(jù)索引，建議將其刪除，約50%的實例可以通過該建議的提示，將 15 天未使用的索引進行刪除，節(jié)省 3 成以上的熱存空間；
3）分區(qū)優(yōu)化：分析數(shù)據(jù)查詢實際需要使用的分布鍵與數(shù)據(jù)表定義的分布列之間的差異，對設(shè)計不合理的分布鍵，建議變更該數(shù)據(jù)表的分布鍵，以提高數(shù)據(jù)的查詢性能。

經(jīng)過多年雙十一的淬煉，AnalyticDB不僅抗住了一年高過一年的的極端負載和流量，也在不斷豐富的業(yè)務(wù)場景中逐步成長，不斷賦能到集團內(nèi)外各種新老業(yè)務(wù)和場景中，逐步成長為新一代云原生數(shù)據(jù)倉庫的佼佼者。接下來AnalyticDB將繼續(xù)以“人人可用的數(shù)據(jù)服務(wù)”為使命，進一步擁抱云原生，構(gòu)建數(shù)據(jù)庫+大數(shù)據(jù)一體化架構(gòu)，建設(shè)極致彈性、離在線一體、高性價比、智能自治等企業(yè)級能力，進一步賦能用戶挖掘數(shù)據(jù)背后的商業(yè)價值。