祕密武器 | 看AnalyticDB如何強力支撐雙十一

簡介：第12個雙11已圓滿結束，但對技術的探索永不止步。每年雙11，不僅僅是剁手族的狂歡節，更是資料人的“大考”，是檢驗阿里雲資料庫技術團隊技術水平與技術創新實踐的舞臺。本站已陸續推出雙11護航背後的資料庫技術實踐與經驗分享系列乾貨文章，敬請關注！今天為雲原生資料倉儲AnalyticDB的技術解析。

前言

每年雙十一購物狂歡節都是雲原生資料倉儲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

資源組可以支援不同的查詢執行模式：

1. interactive：採用all-in-memory、pipelined的方式執行，適用於延遲要求高的線上分析
2. batch：採用Stage by stage執行模型，中間結果、運算元狀態可以落盤，適用於高吞吐，延遲要求低的查詢，具備更低的計算成本

分時彈性

一般情況下，業務具備非常明顯的波峰波谷，低峰期資源往往處於閒置階段。AnalyticDB分時彈性功能可以讓這類使用者定製彈性計劃（每天定時、每週定時），在業務高峰期來臨之前自動進行擴容滿足業務流量。定時的彈性計劃即滿足了業務流量高峰的需求，又降低了AnalyticDB使用成本。結合資源組功能，使用者甚至可以讓某個資源組在低峰期時0節點，成本極低。

智慧優化

查詢優化是影響資料倉儲系統效能的關鍵因素，如何生成更優的執行計劃、以何種方式分割槽、如何配置索引、何時更新統計資訊等等問題經常對資料開發人員造成困擾。AnalyticDB一直深耕於智慧優化技術，通過實時監控執行的查詢，動態調整執行計劃和其依賴的統計資訊，自動提高查詢效能；內建智慧演算法，可以依據系統的實時執行狀態，動態調整引擎引數以適應當前的查詢負載。

智慧調整

智慧調整是一個連續的監控和分析過程，通過不斷的分析當前工作負載的特徵，來識別潛在的優化並加以調整，並根據調整後實際的效能收益，來決策是否回滾或進一步的分析。

**動態執行計劃調優
**

查詢計劃經常會由於統計資訊、代價模型等原因導致效能回退。AnalyticDB充分利用了執行中與執行後的執行資訊，進行執行計劃的事中和事後調整。並通過對歷史的執行計劃和對應的執行指標進行機器學習，調整執行計劃的代價預估演算法，使其更加貼合當前的資料特徵和工作負載，隨著不斷的學習和調整，達到自動優化的目標，讓使用者覺得越用越好用。

動態管理物化檢視

物化檢視(Materialized view)是數倉領域核心特性之一，可以幫助使用者加速分析，簡化資料清洗流程(ETL: Extract, Load, Transform)，應用場景十分廣泛。比如：大屏類業務加速，配合BI工具使用，或者是快取一些公共中間結果集用以加速慢查詢。AnalyticDB從3.0版本開始逐步支援物化檢視，可以高效的維護物化檢視，並提供全自動的更新機制。

結語

AnalyticDB定位為新一代的雲原生資料倉儲，在一個系統中實現在離線一體化，成功賦能雙十一諸多業務，抗住極端業務負載，也進一步提升業務上資料價值挖掘的實時性。隨著平臺的業務演進和技術演進，AnalyticDB也在不斷構建企業級數倉的能力，近期AnalyticDB已釋放新版彈性的核心能力，極致彈性和高價效比，真正讓使用者所購即所得。

原文連結：https://developer.aliyun.com/article/778347?

版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。