簡(jiǎn)介：第12個(gè)雙11已圓滿結(jié)束，但對(duì)技術(shù)的探索永不止步。每年雙11，不僅僅是剁手族的狂歡節(jié)，更是數(shù)據(jù)人的“大考”，是檢驗(yàn)阿里云數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì)技術(shù)水平與技術(shù)創(chuàng)新實(shí)踐的舞臺(tái)。本站已陸續(xù)推出雙11護(hù)航背后的數(shù)據(jù)庫(kù)技術(shù)實(shí)踐與經(jīng)驗(yàn)分享系列干貨文章，敬請(qǐng)關(guān)注！今天為云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB的技術(shù)解析。

前言

每年雙十一購(gòu)物狂歡節(jié)都是云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB MySQL版（原分析型數(shù)據(jù)庫(kù)MySQL版）的一塊試金石。今年AnalyticDB除了在阿里數(shù)字經(jīng)濟(jì)體內(nèi)進(jìn)入更多核心交易鏈路，全力支撐雙十一以外，AnalyticDB全面擁抱云原生，構(gòu)建極致彈性，大幅降低成本，釋放技術(shù)紅利，重磅發(fā)布了諸多全新企業(yè)級(jí)特性，讓用戶及時(shí)擁有極高性價(jià)比的云原生數(shù)據(jù)倉(cāng)庫(kù)。

云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB

云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB是一種支持高并發(fā)低延時(shí)查詢的新一代云原生數(shù)據(jù)倉(cāng)庫(kù)，高度兼容MySQL協(xié)議以及SQL:2003 語(yǔ)法標(biāo)準(zhǔn)，可以對(duì)海量數(shù)據(jù)進(jìn)行即時(shí)的多維分析透視和業(yè)務(wù)探索，快速構(gòu)建企業(yè)云上數(shù)據(jù)倉(cāng)庫(kù)，實(shí)現(xiàn)數(shù)據(jù)價(jià)值的在線化。

AnalyticDB全面覆蓋數(shù)據(jù)倉(cāng)庫(kù)場(chǎng)景，包括報(bào)表查詢、在線分析、實(shí)時(shí)數(shù)倉(cāng)、ETL等，應(yīng)用范圍廣。AnalyticDB兼容MySQL和傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)生態(tài)，使用門檻低。

AnalyticDB全力支撐雙十一

2020年雙十一，AnalyticDB支持了阿里數(shù)字經(jīng)濟(jì)體內(nèi)幾乎所有BU的業(yè)務(wù)，承載了集團(tuán)的菜鳥、新零售供應(yīng)鏈、DT數(shù)據(jù)系列產(chǎn)品、數(shù)據(jù)銀行、生意參謀、人群寶、達(dá)摩院店小蜜、AE數(shù)據(jù)、盒馬、天貓營(yíng)銷平臺(tái)等130多個(gè)主要業(yè)務(wù)。從核心交易鏈路的高并發(fā)在線檢索到復(fù)雜實(shí)時(shí)分析應(yīng)用場(chǎng)景，表現(xiàn)非常穩(wěn)定。當(dāng)天各項(xiàng)指標(biāo)再創(chuàng)新高，AnalyticDB當(dāng)天的寫入TPS峰值到達(dá)2.14億，通過離在線一體化架構(gòu)，支持在線ETL及實(shí)時(shí)查詢Job數(shù)達(dá)到174571個(gè)/秒，離線ETL導(dǎo)入導(dǎo)出任務(wù)570267個(gè)，處理的實(shí)時(shí)數(shù)據(jù)量達(dá)到7.7萬(wàn)億行。

在本次雙十一中，在公有云上支持聚水潭、遞四方、EMS等諸多核心業(yè)務(wù)，在專有云上支持了中國(guó)郵政集團(tuán)的各類業(yè)務(wù)。AnalyticDB數(shù)據(jù)庫(kù)為這些業(yè)務(wù)方提供了數(shù)據(jù)處理ETL、實(shí)時(shí)在線分析、核心報(bào)表、大屏和監(jiān)控能力，為數(shù)十萬(wàn)商家和千萬(wàn)消費(fèi)者提供穩(wěn)定的離在線數(shù)據(jù)服務(wù)。

AnalyticDB面臨的挑戰(zhàn)

雙十一的一連串亮眼數(shù)據(jù)背后，AnalyticDB也面臨極大的挑戰(zhàn)，主要體現(xiàn)在：

1、進(jìn)入集團(tuán)核心交易鏈路
AnalyticDB開始正式接入集團(tuán)內(nèi)的核心交易鏈路，進(jìn)入集團(tuán)核心交易業(yè)務(wù)買家分析庫(kù)業(yè)務(wù)，這對(duì)AnalyticDB的實(shí)時(shí)高并發(fā)寫入、在線檢索的能力提出了極高的要求。雙十一總共超過600億條訂單記錄，其中雙十一1號(hào)0點(diǎn)和0點(diǎn)30分預(yù)付尾款的多波峰值達(dá)到500萬(wàn)TPS，是日常的100倍。Query 95分位RT在10ms以內(nèi)。

AnalyticDB全新研發(fā)的行存引擎首次表現(xiàn)亮眼，可支持千萬(wàn)級(jí)QPS在線高并發(fā)檢索和分析，關(guān)鍵技術(shù)點(diǎn)包括高并發(fā)查詢鏈路、全新的行存存儲(chǔ)、任意列TopN下推、聯(lián)合索引、智能索引選擇等，實(shí)現(xiàn)了單節(jié)點(diǎn)10000+QPS并可線性擴(kuò)展。在相同資源下，單表點(diǎn)查、聚合及TopN是開源ElasticSearch的2-5倍，存儲(chǔ)空間節(jié)省50%，寫入性能是其5-10倍，并且保證數(shù)據(jù)的實(shí)時(shí)可見和數(shù)據(jù)高可靠。

2、進(jìn)入更多生產(chǎn)作業(yè)環(huán)節(jié)
這一年來(lái)，AnalyticDB深入到菜鳥倉(cāng)儲(chǔ)的核心作業(yè)環(huán)節(jié)。倉(cāng)庫(kù)操作人員的數(shù)據(jù)看板、數(shù)據(jù)核對(duì)、發(fā)貨操作等都依賴AnalyticDB的高并發(fā)實(shí)時(shí)寫入、實(shí)時(shí)查詢和相關(guān)的數(shù)據(jù)分析能力，每秒峰值6000訂單。ADB作為菜鳥數(shù)倉(cāng)引擎，實(shí)時(shí)監(jiān)控億級(jí)包裹在倉(cāng)、攬、干、運(yùn)、配每個(gè)作業(yè)節(jié)點(diǎn)的狀態(tài)，確保每一筆訂單都能按時(shí)履約，極大提升了用戶體驗(yàn)。在11月1日的第一波流量峰值中，菜鳥倉(cāng)儲(chǔ)單實(shí)例的TPS 40萬(wàn)+，QPS 200；供應(yīng)鏈履約單實(shí)例TPS峰值160萬(wàn)，1200 QPS。

菜鳥數(shù)倉(cāng)數(shù)據(jù)架構(gòu)圖：

3、接入更多的導(dǎo)入任務(wù)
一些依賴數(shù)據(jù)洞察（類似DeepInsight）的業(yè)務(wù)，他們本身也是平臺(tái)方，上面每天都大量的導(dǎo)入任務(wù)，且這些任務(wù)需要在規(guī)定的時(shí)間內(nèi)導(dǎo)入完成，有些甚至配置了基線要求，不僅要求所有任務(wù)在規(guī)定的時(shí)間點(diǎn)導(dǎo)入完成，還要求每個(gè)任務(wù)在規(guī)定的時(shí)間點(diǎn)內(nèi)完成。這在原來(lái)AnalyticDB 2.0上（依靠跑MapReduce任務(wù)）是不可想象的，然而在AnalyticDB 3.0上可以輕松地跑完。AnalyticDB 3.0的任務(wù)導(dǎo)入做到更加輕量和實(shí)時(shí)。以11月8日的導(dǎo)入任務(wù)為例，9074個(gè)任務(wù)最長(zhǎng)的只需要921秒，最短的3秒完成，平均時(shí)長(zhǎng)39秒完成。

4、接入更多高吞吐的寫入業(yè)務(wù)
類似數(shù)據(jù)銀行之類的業(yè)務(wù)，每天會(huì)有大量的數(shù)據(jù)導(dǎo)入，導(dǎo)入的數(shù)據(jù)量巨大，對(duì)AnalyticDB的寫入吞吐量要求極高，雙十一前后數(shù)據(jù)銀行的AnalyticDB TPS峰值寫到近1000萬(wàn)，寫入流量達(dá)到1.3GB/s。數(shù)據(jù)銀行利用AnalyticDB實(shí)現(xiàn)人群畫像、自定義分析、觸發(fā)式計(jì)算、實(shí)時(shí)引擎和離線加速。單庫(kù)存儲(chǔ)了6PB+的數(shù)據(jù)，中間使用了大量的復(fù)雜SQL的交并差、group by、count、distinct、多張萬(wàn)億級(jí)別的大表的join操作。

5、在線離線混合負(fù)載
基于在線分析和離線ETL混合負(fù)載的能力，AnalyticDB支持了AE中臺(tái)的多個(gè)雙十一業(yè)務(wù)：商家端業(yè)務(wù)實(shí)現(xiàn)100 QPS的基于明細(xì)事件的商家端人群預(yù)估，將復(fù)雜的畫像從平均10秒鐘降低到平均3秒內(nèi)。相比于傳統(tǒng)將商家的事件加工為物化的標(biāo)簽，通過明細(xì)事件的分表過濾能力大幅度降低了基于事件的新人群的上線時(shí)間，從原先需要數(shù)據(jù)開發(fā)一周的工作量，降低到半天的數(shù)據(jù)配置。基于AnalyticsDB實(shí)現(xiàn)了AE用戶洞察人群的實(shí)時(shí)聚類，從原先離線的20分鐘離線聚類提升為分鐘級(jí)別的在線聚類，并實(shí)現(xiàn)了權(quán)益分包算法的準(zhǔn)實(shí)時(shí)化，從原先離線的20分鐘分包，提升為在線的分鐘級(jí)分包。后續(xù)AE、Lazada的在線人群縮放，精排都能夠基于在線的AnalyticDB算法實(shí)現(xiàn)算法的在線化，幫助國(guó)際化提升人群、商品運(yùn)營(yíng)的整體效率。

AnalyticDB最新關(guān)鍵技術(shù)

過去一年，AnalyticDB完美承載起阿里數(shù)字經(jīng)濟(jì)體業(yè)務(wù)和阿里云公有云+專有云業(yè)務(wù)，其背后，AnalyticDB技術(shù)架構(gòu)全面擁抱云原生，AnalyticDB完成了重大架構(gòu)升級(jí)，在公有云上也同步發(fā)布了新版彈性模式，讓用戶擁有極高性價(jià)比、極致彈性的新一代數(shù)據(jù)倉(cāng)庫(kù)。以下將對(duì)新版彈性模式的關(guān)鍵技術(shù)點(diǎn)一一道來(lái)。

計(jì)算存儲(chǔ)分離

AnalyticDB預(yù)留模式的產(chǎn)品形態(tài)是采用Shared-Nothing架構(gòu)，具備良好的擴(kuò)展性和并發(fā)性。后端采用計(jì)算與存儲(chǔ)耦合的方式，兩者共享相同的資源。存儲(chǔ)容量和計(jì)算能力均與節(jié)點(diǎn)數(shù)有關(guān)。用戶可以通過擴(kuò)容、縮容節(jié)點(diǎn)數(shù)來(lái)調(diào)整自己的資源需求，但是沒法自由搭配計(jì)算與存儲(chǔ)資源配比，來(lái)滿足不同的業(yè)務(wù)負(fù)載需求。此外，節(jié)點(diǎn)數(shù)的調(diào)整往往面臨大量的數(shù)據(jù)遷移，會(huì)花費(fèi)比較長(zhǎng)的時(shí)間，對(duì)當(dāng)前系統(tǒng)的運(yùn)行負(fù)載也有一定的影響。另外，計(jì)算、存儲(chǔ)不能靈活配比，也導(dǎo)致性價(jià)比成為一個(gè)問題。

全面擁抱云平臺(tái)的彈性能力，AnalyticDB主推新彈性模式的產(chǎn)品形態(tài)，后端采用了計(jì)算存儲(chǔ)分離的新架構(gòu)，提供統(tǒng)一的服務(wù)化Serverless存儲(chǔ)層，計(jì)算層可以獨(dú)立彈性擴(kuò)展，同時(shí)兼具了預(yù)留模式的性能。通過計(jì)算與存儲(chǔ)的解耦，用戶可以較為靈活地單獨(dú)對(duì)計(jì)算資源、存儲(chǔ)容量進(jìn)行擴(kuò)縮，更加合理控制總成本。針對(duì)計(jì)算資源的擴(kuò)縮，不再需要數(shù)據(jù)的搬遷，具備更極致的彈性體驗(yàn)。

數(shù)據(jù)冷熱分層

數(shù)據(jù)存儲(chǔ)的高性價(jià)比是云上數(shù)據(jù)倉(cāng)庫(kù)的核心競(jìng)爭(zhēng)力之一，AnalyticDB具備數(shù)據(jù)冷熱分離這一企業(yè)級(jí)特性。AnalyticDB可以按表粒度、表的二級(jí)分區(qū)粒度獨(dú)立選擇冷、熱存儲(chǔ)介質(zhì)，比如指定用戶表數(shù)據(jù)全部存儲(chǔ)在SSD，或指定表數(shù)據(jù)全部存儲(chǔ)在HDD，或指定這個(gè)表的一部分分區(qū)數(shù)據(jù)存儲(chǔ)在SSD，另一部分分區(qū)數(shù)據(jù)存儲(chǔ)在HDD，完全可以按業(yè)務(wù)需求自由指定，并且冷熱策略可以任意轉(zhuǎn)換。同時(shí)，熱數(shù)據(jù)和冷數(shù)據(jù)的空間使用是Serverless按量計(jì)費(fèi)的。未來(lái)AnalyticDB將實(shí)現(xiàn)智能冷熱分區(qū)，即自動(dòng)根據(jù)用戶業(yè)務(wù)訪問模型，提前對(duì)冷數(shù)據(jù)進(jìn)行預(yù)熱。

冷熱存儲(chǔ)定義

冷熱分離的第一步是確定冷熱的粒度和邊界。AnalyticDB冷熱分離技術(shù)延用了現(xiàn)有的二級(jí)分區(qū)機(jī)制，即以分區(qū)為冷熱存儲(chǔ)的基本單位。熱分區(qū)存儲(chǔ)在節(jié)點(diǎn)SSD盤上，獲得最好的性能，冷分區(qū)存儲(chǔ)在OSS上，以達(dá)到最低的存儲(chǔ)成本。

用戶可以定義全熱表（所有分區(qū)在SSD），全冷表（所有分區(qū)在OSS），以及混合表（部分分區(qū)在SSD，部分在OSS）來(lái)靈活使用，達(dá)到性能與成本的平衡。如下是一個(gè)游戲日志表的實(shí)例，采用混合分區(qū)策略，最新7天的數(shù)據(jù)存儲(chǔ)在熱區(qū)，7天前的數(shù)據(jù)存儲(chǔ)在冷區(qū)。

create table event( id bigint auto_increment dt datetime, event varchar, goods varchar, package int ... ) distribute by hash(id) partition by value(date_format(dt, '%Y%m%d')) lifecycle 365 storage_policy = 'MIXED' hot_partition_count = 7;

冷熱數(shù)據(jù)自動(dòng)遷移

AnalyticDB數(shù)據(jù)寫入時(shí)，數(shù)據(jù)會(huì)首先進(jìn)入熱空間SSD上，當(dāng)熱存儲(chǔ)數(shù)據(jù)積累到一定程度或者用戶指定的冷表策略時(shí)會(huì)自動(dòng)調(diào)度后臺(tái)的Build任務(wù)，把數(shù)據(jù)遷移到冷存儲(chǔ)空間。對(duì)于用戶來(lái)說(shuō)，寫入和查詢完全是透明的。

之所以這樣設(shè)計(jì)是借鑒了寫讀優(yōu)化存儲(chǔ)的設(shè)計(jì)理念，為了實(shí)現(xiàn)高效任意維組合分析能力，AnalyticDB默認(rèn)是自適應(yīng)全索引，即每個(gè)列上都有列級(jí)索引，這保證了AnalyticDB的查詢性能做到開箱即用，但這會(huì)對(duì)寫入性能帶來(lái)較大挑戰(zhàn)。因此AnalyticDB采用類LSM架構(gòu)，把存儲(chǔ)分為實(shí)時(shí)和歷史兩部分，實(shí)時(shí)部分采用行存混存的塊級(jí)粗糙索引，歷史部分采用全索引以保證極快的查詢性能，并且通過后臺(tái)數(shù)據(jù)構(gòu)建任務(wù)（Build）實(shí)現(xiàn)實(shí)時(shí)到歷史分區(qū)的轉(zhuǎn)換。冷熱分區(qū)自動(dòng)遷移的機(jī)制是：

• 數(shù)據(jù)積累到一定程度，內(nèi)部自動(dòng)調(diào)度Build任務(wù)，對(duì)實(shí)時(shí)數(shù)據(jù)建立快照，進(jìn)行數(shù)據(jù)整理，構(gòu)造出新的歷史分區(qū)（Partition），并根據(jù)冷熱策略將這些歷史分區(qū)（Partition）分別寫入熱區(qū)和冷區(qū)。
• 在Build調(diào)度的同時(shí)，根據(jù)冷熱策略的滑動(dòng)窗口，自動(dòng)把歷史分區(qū)從熱區(qū)遷移到冷區(qū)。下圖中，定義的熱分區(qū)個(gè)數(shù)為3，在11月4日，熱分區(qū)為11-04、11-03日、11-02日共3個(gè)，在11月5日，寫入了新的11-05的數(shù)據(jù)，根據(jù)滑動(dòng)窗口，最新的熱分區(qū)為11-05、11-04、11-03三個(gè)，因此在Build時(shí)，會(huì)觸發(fā)熱分區(qū)到冷分區(qū)的遷移，11-02分區(qū)自動(dòng)遷移到冷區(qū)。

冷數(shù)據(jù)查詢加速

冷區(qū)降低了存儲(chǔ)成本，但增加了數(shù)據(jù)訪問的開銷。雖然AnalyticDB已經(jīng)做了分區(qū)裁剪、計(jì)算下推等優(yōu)化，仍避免不了需要對(duì)歷史分區(qū)做隨機(jī)和吞吐掃描。為了加速對(duì)冷分區(qū)的查詢性能，AnalyticDB在存儲(chǔ)節(jié)點(diǎn)開辟了一部分SSD空間作為Cache。利用這塊SSD Cache，AnalyticDB做了如下優(yōu)化：

• 不同粒度的SSD Cache Entry，確保可以同時(shí)兼顧索引的隨機(jī)查找和吞吐型數(shù)據(jù)掃描。
• 元信息預(yù)熱，每次Build結(jié)束，會(huì)自動(dòng)生成冷分區(qū)的元信息，加速訪問
• 無(wú)鎖化的冷熱訪問隊(duì)列，避免經(jīng)常訪問的數(shù)據(jù)被頻繁換入換出。

冷熱存儲(chǔ)使用

1、全熱表：適用于整張表全部數(shù)據(jù)都被頻繁訪問，并且對(duì)訪問性能要求比較高。DDL如下：

create table t1(id int,dt datetime ) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'HOT';

2、全冷表：適用于整張表全部數(shù)據(jù)都不頻繁訪問，并且對(duì)性能訪問要求不高。DDL如下：

create table t2(id int,dt datetime ) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'COLD';

3、冷熱混合表：適用于數(shù)據(jù)冷熱有明顯時(shí)間窗口，比如，最近一個(gè)月數(shù)據(jù)是頻繁訪問且對(duì)性能有較高要求，而之前的數(shù)據(jù)是冷數(shù)據(jù)，只是偶爾訪問。針對(duì)這種場(chǎng)景，DDL如下：

create table t3(id int,dt datetime ) distribute by hash(id) partition by value(date_format('%Y%m',dt) lifecycle 12 storage_policy = 'MIXED' hot_partition_count=1;

整張表按照月做二級(jí)分區(qū)，總共保存12個(gè)月，最近一個(gè)月的數(shù)據(jù)保存在SSD上，一個(gè)月以前的數(shù)據(jù)保存在HDD上。通過這樣設(shè)置，性能和成本達(dá)到良好的平衡。

*在離線一體化
*

AnalyticDB使用一套引擎，同時(shí)支持了面向低延遲的在線分析，和面向高吞吐的復(fù)雜ETL。

混合計(jì)算負(fù)載

在存儲(chǔ)計(jì)算分離的架構(gòu)下，AnalyticDB的計(jì)算能力也得到了極大的釋放，可以支持非常豐富和強(qiáng)大的混合計(jì)算負(fù)載能力，在經(jīng)典的在線（online）/交互式（interactive）查詢執(zhí)行模式之外，也支持了離線/批處理(batch)查詢執(zhí)行模式，同時(shí)可以通過集成開源的計(jì)算引擎（比如Spark）來(lái)支持迭代計(jì)算和機(jī)器學(xué)習(xí)等復(fù)雜計(jì)算能力。

在線分析（Online/Interactive）
在線查詢基于MPP架構(gòu)，中間結(jié)果和算子狀態(tài)完全使用內(nèi)存（all-in-memory），計(jì)算過程完全流水線化（pipelined），查詢RT小，適用于低延遲、高并發(fā)的場(chǎng)景 ，比如BI報(bào)表、數(shù)據(jù)分析、在線決策等。

批處理（Batch）
批處理模式基于DAG執(zhí)行模型，整個(gè)DAG可以切分為若干個(gè)stage進(jìn)行，stage-by-stage執(zhí)行，中間結(jié)果和算子狀態(tài)可以落盤，支持大吞吐量的數(shù)據(jù)計(jì)算能力，也可以在較少的計(jì)算資源場(chǎng)景下執(zhí)行，具備更低的計(jì)算成本，適用于數(shù)據(jù)量大或者計(jì)算資源有限的場(chǎng)景，比如ETL、數(shù)據(jù)倉(cāng)庫(kù)等。

復(fù)雜計(jì)算（Iterative/ML等）
AnalyticDB提供了開放和可擴(kuò)展的計(jì)算架構(gòu)，通過集成和兼容開源生態(tài)的計(jì)算引擎（目前為Spark）為用戶提供復(fù)雜計(jì)算能力。用戶可以基于Spark的編程接口（DataFrame/SparkSQL/RDD/DStream）來(lái)編寫更加復(fù)雜的計(jì)算邏輯，滿足業(yè)務(wù)越來(lái)越智能化和實(shí)時(shí)化的數(shù)據(jù)應(yīng)用場(chǎng)景，比如迭代計(jì)算，機(jī)器學(xué)習(xí)等。

資源組（池）多租戶

AnalyticDB新版彈性模式下，支持了資源組功能，即對(duì)計(jì)算資源進(jìn)行彈性劃分，不同資源組之間的計(jì)算資源在物理上完全隔離。通過AnalyticDB賬號(hào)綁定到不同的資源組，SQL查詢根據(jù)綁定關(guān)系自動(dòng)路由至對(duì)應(yīng)的資源組執(zhí)行命令，用戶可以選擇為不同的資源組設(shè)置不同的查詢執(zhí)行模式，從而滿足用戶實(shí)現(xiàn)實(shí)例內(nèi)部多租戶、混合負(fù)載的需求。

資源組相關(guān)命令

-- 創(chuàng)建資源組 CREATE RESOURCE GROUP group_name[QUERY_TYPE = {interactive, batch}] -- 指定資源組查詢執(zhí)行模式[NODE_NUM = N] -- 資源組節(jié)點(diǎn)個(gè)數(shù)-- 綁定資源組 ALTER RESOURCE GROUP BATCH_RG ADD_USER=batch_user-- 調(diào)整資源組大小 ALTER RESOURCE GROUP BATCH_RG NODE_NUM=10-- 刪除資源組 DROP RESOURCE GROUP BATCH_RG

資源組可以支持不同的查詢執(zhí)行模式：

interactive：采用all-in-memory、pipelined的方式執(zhí)行，適用于延遲要求高的在線分析

batch：采用Stage by stage執(zhí)行模型，中間結(jié)果、算子狀態(tài)可以落盤，適用于高吞吐，延遲要求低的查詢，具備更低的計(jì)算成本

分時(shí)彈性

一般情況下，業(yè)務(wù)具備非常明顯的波峰波谷，低峰期資源往往處于閑置階段。AnalyticDB分時(shí)彈性功能可以讓這類用戶定制彈性計(jì)劃（每天定時(shí)、每周定時(shí)），在業(yè)務(wù)高峰期來(lái)臨之前自動(dòng)進(jìn)行擴(kuò)容滿足業(yè)務(wù)流量。定時(shí)的彈性計(jì)劃即滿足了業(yè)務(wù)流量高峰的需求，又降低了AnalyticDB使用成本。結(jié)合資源組功能，用戶甚至可以讓某個(gè)資源組在低峰期時(shí)0節(jié)點(diǎn)，成本極低。

智能優(yōu)化

查詢優(yōu)化是影響數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)性能的關(guān)鍵因素，如何生成更優(yōu)的執(zhí)行計(jì)劃、以何種方式分區(qū)、如何配置索引、何時(shí)更新統(tǒng)計(jì)信息等等問題經(jīng)常對(duì)數(shù)據(jù)開發(fā)人員造成困擾。AnalyticDB一直深耕于智能優(yōu)化技術(shù)，通過實(shí)時(shí)監(jiān)控運(yùn)行的查詢，動(dòng)態(tài)調(diào)整執(zhí)行計(jì)劃和其依賴的統(tǒng)計(jì)信息，自動(dòng)提高查詢性能；內(nèi)置智能算法，可以依據(jù)系統(tǒng)的實(shí)時(shí)運(yùn)行狀態(tài)，動(dòng)態(tài)調(diào)整引擎參數(shù)以適應(yīng)當(dāng)前的查詢負(fù)載。

智能調(diào)整

智能調(diào)整是一個(gè)連續(xù)的監(jiān)控和分析過程，通過不斷的分析當(dāng)前工作負(fù)載的特征，來(lái)識(shí)別潛在的優(yōu)化并加以調(diào)整，并根據(jù)調(diào)整后實(shí)際的性能收益，來(lái)決策是否回滾或進(jìn)一步的分析。

**動(dòng)態(tài)執(zhí)行計(jì)劃調(diào)優(yōu)
**

查詢計(jì)劃經(jīng)常會(huì)由于統(tǒng)計(jì)信息、代價(jià)模型等原因?qū)е滦阅芑赝恕nalyticDB充分利用了運(yùn)行中與運(yùn)行后的執(zhí)行信息，進(jìn)行執(zhí)行計(jì)劃的事中和事后調(diào)整。并通過對(duì)歷史的執(zhí)行計(jì)劃和對(duì)應(yīng)的運(yùn)行指標(biāo)進(jìn)行機(jī)器學(xué)習(xí)，調(diào)整執(zhí)行計(jì)劃的代價(jià)預(yù)估算法，使其更加貼合當(dāng)前的數(shù)據(jù)特征和工作負(fù)載，隨著不斷的學(xué)習(xí)和調(diào)整，達(dá)到自動(dòng)優(yōu)化的目標(biāo)，讓用戶覺得越用越好用。

動(dòng)態(tài)管理物化視圖

物化視圖(Materialized view)是數(shù)倉(cāng)領(lǐng)域核心特性之一，可以幫助用戶加速分析，簡(jiǎn)化數(shù)據(jù)清洗流程(ETL: Extract, Load, Transform)，應(yīng)用場(chǎng)景十分廣泛。比如：大屏類業(yè)務(wù)加速，配合BI工具使用，或者是緩存一些公共中間結(jié)果集用以加速慢查詢。AnalyticDB從3.0版本開始逐步支持物化視圖，可以高效的維護(hù)物化視圖，并提供全自動(dòng)的更新機(jī)制。

結(jié)語(yǔ)

AnalyticDB定位為新一代的云原生數(shù)據(jù)倉(cāng)庫(kù)，在一個(gè)系統(tǒng)中實(shí)現(xiàn)在離線一體化，成功賦能雙十一諸多業(yè)務(wù)，抗住極端業(yè)務(wù)負(fù)載，也進(jìn)一步提升業(yè)務(wù)上數(shù)據(jù)價(jià)值挖掘的實(shí)時(shí)性。隨著平臺(tái)的業(yè)務(wù)演進(jìn)和技術(shù)演進(jìn)，AnalyticDB也在不斷構(gòu)建企業(yè)級(jí)數(shù)倉(cāng)的能力，近期AnalyticDB已釋放新版彈性的核心能力，極致彈性和高性價(jià)比，真正讓用戶所購(gòu)即所得。

原文鏈接：https://developer.aliyun.com/article/778347?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的秘密武器 | 看AnalyticDB如何强力支撑双十一的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。