秘密武器 | 看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，確?？梢酝瑫r兼顧索引的隨機查找和吞吐型數據掃描。
- 元信息預熱，每次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資源組可以支持不同的查詢執行模式：
分時彈性
一般情況下，業務具備非常明顯的波峰波谷，低峰期資源往往處于閑置階段。AnalyticDB分時彈性功能可以讓這類用戶定制彈性計劃（每天定時、每周定時），在業務高峰期來臨之前自動進行擴容滿足業務流量。定時的彈性計劃即滿足了業務流量高峰的需求，又降低了AnalyticDB使用成本。結合資源組功能，用戶甚至可以讓某個資源組在低峰期時0節點，成本極低。
智能優化
查詢優化是影響數據倉庫系統性能的關鍵因素，如何生成更優的執行計劃、以何種方式分區、如何配置索引、何時更新統計信息等等問題經常對數據開發人員造成困擾。AnalyticDB一直深耕于智能優化技術，通過實時監控運行的查詢，動態調整執行計劃和其依賴的統計信息，自動提高查詢性能；內置智能算法，可以依據系統的實時運行狀態，動態調整引擎參數以適應當前的查詢負載。
智能調整
智能調整是一個連續的監控和分析過程，通過不斷的分析當前工作負載的特征，來識別潛在的優化并加以調整，并根據調整后實際的性能收益，來決策是否回滾或進一步的分析。
**動態執行計劃調優
**
查詢計劃經常會由于統計信息、代價模型等原因導致性能回退。AnalyticDB充分利用了運行中與運行后的執行信息，進行執行計劃的事中和事后調整。并通過對歷史的執行計劃和對應的運行指標進行機器學習，調整執行計劃的代價預估算法，使其更加貼合當前的數據特征和工作負載，隨著不斷的學習和調整，達到自動優化的目標，讓用戶覺得越用越好用。
動態管理物化視圖
物化視圖(Materialized view)是數倉領域核心特性之一，可以幫助用戶加速分析，簡化數據清洗流程(ETL: Extract, Load, Transform)，應用場景十分廣泛。比如：大屏類業務加速，配合BI工具使用，或者是緩存一些公共中間結果集用以加速慢查詢。AnalyticDB從3.0版本開始逐步支持物化視圖，可以高效的維護物化視圖，并提供全自動的更新機制。
結語
AnalyticDB定位為新一代的云原生數據倉庫，在一個系統中實現在離線一體化，成功賦能雙十一諸多業務，抗住極端業務負載，也進一步提升業務上數據價值挖掘的實時性。隨著平臺的業務演進和技術演進，AnalyticDB也在不斷構建企業級數倉的能力，近期AnalyticDB已釋放新版彈性的核心能力，極致彈性和高性價比，真正讓用戶所購即所得。
原文鏈接：https://developer.aliyun.com/article/778347?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的秘密武器 | 看AnalyticDB如何强力支撑双十一的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 首次公开！阿里巴巴云原生实时数仓核心技术
- 下一篇： 开放下载！《阿里云实时数仓Hologre