前言
每年雙十一購物狂歡節都是雲原生數據倉庫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也在不斷構建企業級數倉的能力