前言
每年雙十一購物狂歡節都是雲原生資料倉庫AnalyticDB MySQL版（原分析型資料庫MySQL版）的一塊試金石。今年AnalyticDB除了在阿裡數字經濟體内進入更多核心交易鍊路，全力支撐雙十一以外，AnalyticDB全面擁抱雲原生，建構極緻彈性，大幅降低成本，釋放技術紅利，重磅釋出了諸多全新企業級特性，讓使用者及時擁有極高成本效益的雲原生資料倉庫。
雲原生資料倉庫AnalyticDB
雲原生資料倉庫AnalyticDB是一種支援高并發低延時查詢的新一代雲原生資料倉庫，高度相容MySQL協定以及SQL:2003 文法标準，可以對海量資料進行即時的多元分析透視和業務探索，快速建構企業雲上資料倉庫，實作資料價值的線上化。
AnalyticDB全面覆寫資料倉庫場景，包括報表查詢、線上分析、實時數倉、ETL等，應用範圍廣。AnalyticDB相容MySQL和傳統資料倉庫生态，使用門檻低。
AnalyticDB全力支撐雙十一
2020年雙十一，AnalyticDB支援了阿裡數字經濟體内幾乎所有BU的業務，承載了集團的菜鳥、新零售供應鍊、DT資料系列産品、資料銀行、生意參謀、人群寶、達摩院店小蜜、AE資料、盒馬、天貓營銷平台等130多個主要業務。從核心交易鍊路的高并發線上檢索到複雜實時分析應用場景，表現非常穩定。當天各項名額再創新高，AnalyticDB當天的寫入TPS峰值到達2.14億，通過離線上一體化架構，支援線上ETL及實時查詢Job數達到174571個/秒，離線ETL導入導出任務570267個，處理的實時資料量達到7.7萬億行。
在本次雙十一中，在公有雲上支援聚水潭、遞四方、EMS等諸多核心業務，在專有雲上支援了中國郵政集團的各類業務。AnalyticDB資料庫為這些業務方提供了資料處理ETL、實時線上分析、核心報表、大屏和監控能力，為數十萬商家和千萬消費者提供穩定的離線上資料服務。
AnalyticDB面臨的挑戰
雙十一的一連串亮眼資料背後，AnalyticDB也面臨極大的挑戰，主要展現在：
1、進入集團核心交易鍊路
AnalyticDB開始正式接入集團内的核心交易鍊路，進入集團核心交易業務買家分析庫業務，這對AnalyticDB的實時高并發寫入、線上檢索的能力提出了極高的要求。雙十一總共超過600億條訂單記錄，其中雙十一1号0點和0點30分預付尾款的多波峰值達到500萬TPS，是日常的100倍。Query 95分位RT在10ms以内。
AnalyticDB全新研發的行存引擎首次表現亮眼，可支援千萬級QPS線上高并發檢索和分析，關鍵技術點包括高并發查詢鍊路、全新的行存存儲、任意列TopN下推、聯合索引、智能索引選擇等，實作了單節點10000+QPS并可線性擴充。在相同資源下，單表點查、聚合及TopN是開源ElasticSearch的2-5倍，存儲空間節省50%，寫入性能是其5-10倍，并且保證資料的實時可見和資料高可靠。
2、進入更多生産作業環節
這一年來，AnalyticDB深入到菜鳥倉儲的核心作業環節。倉庫操作人員的資料看闆、資料核對、發貨操作等都依賴AnalyticDB的高并發實時寫入、實時查詢和相關的資料分析能力，每秒峰值6000訂單。ADB作為菜鳥數倉引擎，實時監控億級包裹在倉、攬、幹、運、配每個作業節點的狀态，確定每一筆訂單都能按時履約，極大提升了使用者體驗。在11月1日的第一波流量峰值中，菜鳥倉儲單執行個體的TPS 40萬+，QPS 200；供應鍊履約單執行個體TPS峰值160萬，1200 QPS。
菜鳥數倉資料架構圖：
3、接入更多的導入任務
一些依賴資料洞察（類似DeepInsight）的業務，他們本身也是平台方，上面每天都大量的導入任務，且這些任務需要在規定的時間内導入完成，有些甚至配置了基線要求，不僅要求所有任務在規定的時間點導入完成，還要求每個任務在規定的時間點内完成。這在原來AnalyticDB 2.0上（依靠跑MapReduce任務）是不可想象的，然而在AnalyticDB 3.0上可以輕松地跑完。AnalyticDB 3.0的任務導入做到更加輕量和實時。以11月8日的導入任務為例，9074個任務最長的隻需要921秒，最短的3秒完成，平均時長39秒完成。
4、接入更多高吞吐的寫入業務
類似資料銀行之類的業務，每天會有大量的資料導入，導入的資料量巨大，對AnalyticDB的寫入吞吐量要求極高，雙十一前後資料銀行的AnalyticDB TPS峰值寫到近1000萬，寫入流量達到1.3GB/s。資料銀行利用AnalyticDB實作人群畫像、自定義分析、觸發式計算、實時引擎和離線加速。單庫存儲了6PB+的資料，中間使用了大量的複雜SQL的交并差、group by、count、distinct、多張萬億級别的大表的join操作。
5、線上離線混合負載
基于線上分析和離線ETL混合負載的能力，AnalyticDB支援了AE中台的多個雙十一業務：商家端業務實作100 QPS的基于明細事件的商家端人群預估，将複雜的畫像從平均10秒鐘降低到平均3秒内。相比于傳統将商家的事件加工為物化的标簽，通過明細事件的分表過濾能力大幅度降低了基于事件的新人群的上線時間，從原先需要資料開發一周的工作量，降低到半天的資料配置。基于AnalyticsDB實作了AE使用者洞察人群的實時聚類，從原先離線的20分鐘離線聚類提升為分鐘級别的線上聚類，并實作了權益分包算法的準實時化，從原先離線的20分鐘分包，提升為線上的分鐘級分包。後續AE、Lazada的線上人群縮放，精排都能夠基于線上的AnalyticDB算法實作算法的線上化，幫助國際化提升人群、商品營運的整體效率。
AnalyticDB最新關鍵技術
過去一年，AnalyticDB完美承載起阿裡數字經濟體業務和阿裡雲公有雲+專有雲業務，其背後，AnalyticDB技術架構全面擁抱雲原生，AnalyticDB完成了重大架構更新，在公有雲上也同步釋出了新版彈性模式，讓使用者擁有極高成本效益、極緻彈性的新一代資料倉庫。以下将對新版彈性模式的關鍵技術點一一道來。
計算存儲分離
AnalyticDB預留模式的産品形态是采用Shared-Nothing架構，具備良好的擴充性和并發性。後端采用計算與存儲耦合的方式，兩者共享相同的資源。存儲容量和計算能力均與節點數有關。使用者可以通過擴容、縮容節點數來調整自己的資源需求，但是沒法自由搭配計算與存儲資源配比，來滿足不同的業務負載需求。此外，節點數的調整往往面臨大量的資料遷移，會花費比較長的時間，對目前系統的運作負載也有一定的影響。另外，計算、存儲不能靈活配比，也導緻成本效益成為一個問題。
全面擁抱雲平台的彈性能力，AnalyticDB主推新彈性模式的産品形态，後端采用了計算存儲分離的新架構，提供統一的服務化Serverless存儲層，計算層可以獨立彈性擴充，同時兼具了預留模式的性能。通過計算與存儲的解耦，使用者可以較為靈活地單獨對計算資源、存儲容量進行擴縮，更加合理控制總成本。針對計算資源的擴縮，不再需要資料的搬遷，具備更極緻的彈性體驗。
資料冷熱分層
資料存儲的高成本效益是雲上資料倉庫的核心競争力之一，AnalyticDB具備資料冷熱分離這一企業級特性。AnalyticDB可以按表粒度、表的二級分區粒度獨立選擇冷、熱存儲媒體，比如指定使用者表資料全部存儲在SSD，或指定表資料全部存儲在HDD，或指定這個表的一部分分區資料存儲在SSD，另一部分分區資料存儲在HDD，完全可以按業務需求自由指定，并且冷熱政策可以任意轉換。同時，熱資料和冷資料的空間使用是Serverless按量計費的。未來AnalyticDB将實作智能冷熱分區，即自動根據使用者業務通路模型，提前對冷資料進行預熱。
冷熱存儲定義
冷熱分離的第一步是确定冷熱的粒度和邊界。AnalyticDB冷熱分離技術延用了現有的二級分區機制，即以分區為冷熱存儲的基本機關。熱分區存儲在節點SSD盤上，獲得最好的性能，冷分區存儲在OSS上，以達到最低的存儲成本。
使用者可以定義全熱表（所有分區在SSD），全冷表（所有分區在OSS），以及混合表（部分分區在SSD，部分在OSS）來靈活使用，達到性能與成本的平衡。如下是一個遊戲日志表的執行個體，采用混合分區政策，最新7天的資料存儲在熱區，7天前的資料存儲在冷區。
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; 冷熱資料自動遷移
AnalyticDB資料寫入時，資料會首先進入熱空間SSD上，當熱存儲資料積累到一定程度或者使用者指定的冷表政策時會自動排程背景的Build任務，把資料遷移到冷存儲空間。對于使用者來說，寫入和查詢完全是透明的。
之是以這樣設計是借鑒了寫讀優化存儲的設計理念，為了實作高效任意維組合分析能力，AnalyticDB預設是自适應全索引，即每個列上都有列級索引，這保證了AnalyticDB的查詢性能做到開箱即用，但這會對寫入性能帶來較大挑戰。是以AnalyticDB采用類LSM架構，把存儲分為實時和曆史兩部分，實時部分采用行存混存的塊級粗糙索引，曆史部分采用全索引以保證極快的查詢性能，并且通過背景資料建構任務（Build）實作實時到曆史分區的轉換。冷熱分區自動遷移的機制是：
- 資料積累到一定程度，内部自動排程Build任務，對實時資料建立快照，進行資料整理，構造出新的曆史分區（Partition），并根據冷熱政策将這些曆史分區（Partition）分别寫入熱區和冷區。
- 在Build排程的同時，根據冷熱政策的滑動視窗，自動把曆史分區從熱區遷移到冷區。下圖中，定義的熱分區個數為3，在11月4日，熱分區為11-04、11-03日、11-02日共3個，在11月5日，寫入了新的11-05的資料，根據滑動視窗，最新的熱分區為11-05、11-04、11-03三個，是以在Build時，會觸發熱分區到冷分區的遷移，11-02分區自動遷移到冷區。
冷資料查詢加速
冷區降低了存儲成本，但增加了資料通路的開銷。雖然AnalyticDB已經做了分區裁剪、計算下推等優化，仍避免不了需要對曆史分區做随機和吞吐掃描。為了加速對冷分區的查詢性能，AnalyticDB在存儲節點開辟了一部分SSD空間作為Cache。利用這塊SSD Cache，AnalyticDB做了如下優化：
- 不同粒度的SSD Cache Entry，確定可以同時兼顧索引的随機查找和吞吐型資料掃描。
- 元資訊預熱，每次Build結束，會自動生成冷分區的元資訊，加速通路
- 無鎖化的冷熱通路隊列，避免經常通路的資料被頻繁換入換出。
冷熱存儲使用
1、全熱表：适用于整張表全部資料都被頻繁通路，并且對通路性能要求比較高。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、全冷表：适用于整張表全部資料都不頻繁通路，并且對性能通路要求不高。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、冷熱混合表：适用于資料冷熱有明顯時間視窗，比如，最近一個月資料是頻繁通路且對性能有較高要求，而之前的資料是冷資料，隻是偶爾通路。針對這種場景，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; 整張表按照月做二級分區，總共儲存12個月，最近一個月的資料儲存在SSD上，一個月以前的資料儲存在HDD上。通過這樣設定，性能和成本達到良好的平衡。
*在離線一體化
*
AnalyticDB使用一套引擎，同時支援了面向低延遲的線上分析，和面向高吞吐的複雜ETL。
混合計算負載
在存儲計算分離的架構下，AnalyticDB的計算能力也得到了極大的釋放，可以支援非常豐富和強大的混合計算負載能力，在經典的線上（online）/互動式（interactive）查詢執行模式之外，也支援了離線/批處理(batch)查詢執行模式，同時可以通過內建開源的計算引擎（比如Spark）來支援疊代計算和機器學習等複雜計算能力。
線上分析（Online/Interactive）
線上查詢基于MPP架構，中間結果和算子狀态完全使用記憶體（all-in-memory），計算過程完全流水線化（pipelined），查詢RT小，适用于低延遲、高并發的場景 ，比如BI報表、資料分析、線上決策等。
批處理（Batch）
批處理模式基于DAG執行模型，整個DAG可以切分為若幹個stage進行，stage-by-stage執行，中間結果和算子狀态可以落盤，支援大吞吐量的資料計算能力，也可以在較少的計算資源場景下執行，具備更低的計算成本，适用于資料量大或者計算資源有限的場景，比如ETL、資料倉庫等。
複雜計算（Iterative/ML等）
AnalyticDB提供了開放和可擴充的計算架構，通過內建和相容開源生态的計算引擎（目前為Spark）為使用者提供複雜計算能力。使用者可以基于Spark的程式設計接口（DataFrame/SparkSQL/RDD/DStream）來編寫更加複雜的計算邏輯，滿足業務越來越智能化和實時化的資料應用場景，比如疊代計算，機器學習等。
資源組（池）多租戶
AnalyticDB新版彈性模式下，支援了資源組功能，即對計算資源進行彈性劃分，不同資源組之間的計算資源在實體上完全隔離。通過AnalyticDB賬号綁定到不同的資源組，SQL查詢根據綁定關系自動路由至對應的資源組執行指令，使用者可以選擇為不同的資源組設定不同的查詢執行模式，進而滿足使用者實作執行個體内部多租戶、混合負載的需求。
資源組相關指令
-- 建立資源組
CREATE RESOURCE GROUP group_name
[QUERY_TYPE = {interactive, batch}] -- 指定資源組查詢執行模式
[NODE_NUM = N] -- 資源組節點個數
-- 綁定資源組
ALTER RESOURCE GROUP BATCH_RG ADD_USER=batch_user
-- 調整資源組大小
ALTER RESOURCE GROUP BATCH_RG NODE_NUM=10
-- 删除資源組
DROP RESOURCE GROUP BATCH_RG 資源組可以支援不同的查詢執行模式：
- interactive：采用all-in-memory、pipelined的方式執行，适用于延遲要求高的線上分析
- batch：采用Stage by stage執行模型，中間結果、算子狀态可以落盤，适用于高吞吐，延遲要求低的查詢，具備更低的計算成本
分時彈性
一般情況下，業務具備非常明顯的波峰波谷，低峰期資源往往處于閑置階段。AnalyticDB分時彈性功能可以讓這類使用者定制彈性計劃（每天定時、每周定時），在業務高峰期來臨之前自動進行擴容滿足業務流量。定時的彈性計劃即滿足了業務流量高峰的需求，又降低了AnalyticDB使用成本。結合資源組功能，使用者甚至可以讓某個資源組在低峰期時0節點，成本極低。
智能優化
查詢優化是影響資料倉庫系統性能的關鍵因素，如何生成更優的執行計劃、以何種方式分區、如何配置索引、何時更新統計資訊等等問題經常對資料開發人員造成困擾。AnalyticDB一直深耕于智能優化技術，通過實時監控運作的查詢，動态調整執行計劃和其依賴的統計資訊，自動提高查詢性能；内置智能算法，可以依據系統的實時運作狀态，動态調整引擎參數以适應目前的查詢負載。
智能調整
智能調整是一個連續的監控和分析過程，通過不斷的分析目前工作負載的特征，來識别潛在的優化并加以調整，并根據調整後實際的性能收益，來決策是否復原或進一步的分析。
**動态執行計劃調優
**
查詢計劃經常會由于統計資訊、代價模型等原因導緻性能回退。AnalyticDB充分利用了運作中與運作後的執行資訊，進行執行計劃的事中和事後調整。并通過對曆史的執行計劃和對應的運作名額進行機器學習，調整執行計劃的代價預估算法，使其更加貼合目前的資料特征和工作負載，随着不斷的學習和調整，達到自動優化的目标，讓使用者覺得越用越好用。
動态管理物化視圖
物化視圖(Materialized view)是數倉領域核心特性之一，可以幫助使用者加速分析，簡化資料清洗流程(ETL: Extract, Load, Transform)，應用場景十分廣泛。比如：大屏類業務加速，配合BI工具使用，或者是緩存一些公共中間結果集用以加速慢查詢。AnalyticDB從3.0版本開始逐漸支援物化視圖，可以高效的維護物化視圖，并提供全自動的更新機制。
結語
AnalyticDB定位為新一代的雲原生資料倉庫，在一個系統中實作在離線一體化，成功賦能雙十一諸多業務，抗住極端業務負載，也進一步提升業務上資料價值挖掘的實時性。随着平台的業務演進和技術演進，AnalyticDB也在不斷建構企業級數倉的能力，近期AnalyticDB已釋放新版彈性的核心能力，極緻彈性和高成本效益，真正讓使用者所購即所得。