#今年雙十一快遞有多快#、#雙十一快遞比外賣還快# 這些話題在今年雙十一期間頻繁出現在熱搜榜上，“凌晨付款起床收貨”成了今年雙十一快遞時效的新標籤。作為天貓官方物流服務提供方，今年菜鳥聯合14家快遞公司為消費者提供瞭如任意門般的天貓雙十一物流體驗。而在這背後，正是阿里云云原生數據倉庫 AnalyticDB MySQL 為菜鳥運配的運營決策提供了強有力的數據支撐，使包裹能夠通過更優更快的線路到達消費者手中。

菜鳥運配雙十一面臨的挑戰

智能運營平臺作為菜鳥運配域的數據中臺，一直承載著整個運配事業部幾乎全部的數據洞察、分析類需求；作為運配事業部運營的眼睛，智能運營平臺有將近1000個實時指標、上百張報表和幾十種簡報及協同場景，這些指標數據來自菜鳥6個業務域。整體業務挑戰包括包裹鏈路長、數據源各異、實操集中發車、數據實時性要求高等。去年雙十一和今年618，相繼出現過慢SQL、數據導出量過大、SOP遵守率參差不齊等問題，並且大促期間會有大量的臨時運營需求需要快速響應和支持，這些對數據鏈路的存儲、抽取、計算都會是非常大的挑戰，今年雙十一必須要完美達成。目標如下：

1）運配數據洞察要求高併發低延遲

需要支持上百張報表和幾十種簡報等複雜分析場景，QPS不低於300，支持百億毫秒級的實時分析性能。

快速支持大促期間各類數據拉取、分析、報表搭建等臨時需求。

2）運配數據的時效性要求

搭建包含1000指標的秒級實時鏈路，和業務系統數據一致性達到99.99%，數據全鏈路1分鐘可見。

問題5分鐘發現，10分鐘定位，30分鐘解決，重大問題2小時內解決。

3）高吞吐的實時數據寫入

支持在每秒幾十萬條數據高吞吐實時寫入，高峰時間3倍的流量峰值。

支持各類報表的數據導出，單次可導出30萬行。

4）大促穩定性保障

系統保障100%可用，0故障，0資損。

指標查詢5s內響應，簡報在時效內發送。

普通工單低於5個，無雙高工單。

同時需要對所有指標進行TPS、QPS、RT的監控。

可進行指標或應用維度的上下線、主備切換、主備負載均衡、彈性擴縮容等操作。

為什麼選擇 AnalyticDB

AnalyticDB MySQL是阿里雲自研的PB級雲原生數據倉庫，有著百億毫秒級的分析性能、千萬級的高吞吐實時寫入，是阿里內部性能最好、最成熟穩定的在線數據倉庫。

如下幾個關鍵特性是我們選擇AnalyticDB MySQL的主要原因：

數據更新完全實時可見

菜鳥當前數據倉庫模型中，AnalyticDB MySQL需要應對每秒十幾萬行的更新量，業務對時效性要求非常高，寫入後完全實時可見，業務上即時進行彙總報表輸出。AnalyticDB MySQL基於Raft協議構建了一套分佈式強一致高可靠的輕量級存儲架構，可實現高吞吐實時寫入+立即可見，很好的滿足了業務上的時效性，對智能運營的報表彙總提供了有力保障。

高併發低延遲的複雜查詢

在每秒10萬行數據更新場景的基礎上，智能運營平臺不僅關聯分析查詢延時敏感（要求高性能），還要求高併發。而AnalyticDB MySQL通過優化器層面的RBO+CBO，以及分區裁剪和計算下推，計算引擎的向量執行+Codegen、存儲引擎的行列存儲、自適應索引能力提供了出色的查詢性能，大部分查詢可以在毫秒級完成；同時通過在線化的調度和雲原生的彈性擴展能力，支持幾百個併發的複雜查詢，也符合要求。

在線查詢和批處理混合負載

除了高吞吐實時寫入、高併發複雜分析性能，智能運營平臺還同時不定期的執行大量的數據ETL導入導出任務。在存儲計算分離的架構下，AnalyticDB 同時支持在線查詢和批處理。在線查詢基於MPP架構，中間結果和算子狀態完全使用內存（all-in-memory），計算過程完全流水線化（pipelined），查詢RT小，適用於低延遲、高併發的場景 ，比如BI報表、數據分析、在線決策等。批處理模式基於DAG執行模型，stage-by-stage執行，中間結果和算子狀態可以落盤，支持大吞吐量的數據計算能力，適用於數據量大或者計算資源有限的場景，比如ETL、數據倉庫等。

成熟和穩定

AnalyticDB MySQL在阿里集團具有大規模的業務驗證，覆蓋阿里內部幾乎所有BU，成熟穩定。同時AnalyticDB MySQL全面兼容MySQL協議，和現有的數據庫體驗一致，簡單易用；此外，AnalyticDB提供了眾多的運維監控指標、慢SQL日誌診斷等能力，對大促的穩定性提供了有效支撐。

菜鳥運配的場景實踐

菜鳥運配採用雲原生數據倉庫 AnalyticDB MySQL版、Lindorm、Blink等構建了包含上千指標的實時數據鏈路後置彙總業務技術架構，將鏈路上各個數據源的海量數據實時多流join形成寬表，最後通過 AnalyticDB 將千餘指標開放複用，整體鏈路如下圖所示。有力保證了菜鳥運配智穩雙全的雙十一運營體驗。

1）將各個業務系統的消息和日誌鏡像到多模數據庫 Lindorm（HBase）中

2）通過 Lindorm 落庫後發出的 export 消息作為觸發源，去 Lindorm 中取出這個主鍵（運單號）相關的所有數據，在 Blink 中加工成寬表後寫入 AnalyticDB MySQL 中進行實時存儲和分析，並提供主備切換能力

3）智能運營平臺在 AnalyticDB MySQL 版中通過SQL關聯查詢分析，將各類指標在服務中心維護並開放出來

智穩雙全的運配體驗

相比去年雙十一單量上漲2.5倍，TPS峰值上漲4倍以及業務指標增長一倍的情況下，智能運營平臺體系面臨著對數據的高實時性、高完整性、高準確性的三“高”挑戰，在系統穩定性方面打了一場漂亮的勝仗，系統100%可用無延遲，數據覆蓋運配全鏈路，真實反饋實操現狀，強有力的保障了業務運營，受到運配域業務團隊好評。

AnalyticDB MySQL作為鏈路核心，支撐了菜鳥運配平臺十幾萬TPS高吞吐寫入並且完全實時可見，複雜查詢達到300 QPS，毫秒級響應，同時還兼顧不同表定期/不定期的數據導出。在數據時效性、高併發、低延時的複雜查詢體驗等方面提供了強力的保障，助力菜鳥實現了智穩雙全的雙十一運配運營體驗。

未來展望

未來我們希望在現有基礎上根據不同業務維度劃分數據模型層，構建所有指標和數據鏈路，將平穩保障整個大盤，為快速迭代各項指標和快速響應業務需求打下基礎。為此，菜鳥運配會持續與 AnalyticDB 保持共建，以實現更好的業務體驗：

業務資源隔離

在 AnalyticDB MySQL版新推出的彈性形態下實現了資源組功能，通過新建資源組可以從現有實例劃分出部分計算節點，這些計算節點資源只歸屬該資源組。用戶可將數據庫賬號綁定到不同的資源組，SQL查詢時根據綁定關係自動路由至對應的資源組執行，滿足用戶實現內部多租戶隔離、混合負載的需求。資源組的創建、修改、刪除等操作都可以在線實時生效，並可以通過API與用戶業務系統進行深度融合，實現全自動調配。

一寫多讀（災備實例）

目前業務測需要主備實例做業務分離和災備，前端還是通過Blink雙寫兩個AnalyticDB實例，這帶來了寫入的複雜性和數據一致性風險。而AnalyticDB將提供了一寫多讀的主備實例能力，業務側只需寫入主實例，其數據會自動實時複製到備實例，這大大簡化了業務的部署和複雜性。

智能化診斷

需要做好監控和邊界問題的發現機制，在出現問題時能夠快速定位。期望能夠充分利用AnalyticDB的監控能力，在出現問題前第一時間預警，規避問題的發生。為此，AnalyticDB將提供全方位、多維度以及準實時的實例運行狀況洞察能力，通過對實例內部的各類運行日誌和時序指標進行算法建模，提供出問題前準確預測、出問題時及時告警、處理問題時精準定位的能力，確保不影響用戶上層業務。

隨時歡迎技術圈的小夥伴們過來交流^_^：

AnalyticDB詳情見：產品詳情

AnalyticDB知乎公眾號：雲原生數據倉庫

AnalyticDB開發者社區公眾號：雲原生數據倉庫

AnalyticDB開發者釘釘群：23128105