AliExpress（簡稱AE）是從集團內wholesale孵化出來面向全球消費者的B2C電商平臺，目前也是全球化電商業務的排頭兵。當前AE為全球220+個國家提供線上購物服務，支援3端（PC、Msite和APP）、18+種語言，有5個獨立分站（印尼、俄羅斯、巴西、西班牙、法國）和2個本地站（西班牙Plaza和俄羅斯Tmall）為當地提供更精細化的服務。
業務挑戰營銷是電商業務的核心場景，本質是解決人貨場的匹配問題。而大資料時代，傳統的小二人工運營的方式越來越力不從心，AE資料智慧中臺賦能小二們在海量使用者和商品裡進行人貨匹配，釋放小二們的壓力，從而更快、更精準的營銷。
去年AE資料智慧中臺在雙十一中小試牛刀，效果得到了業務團隊的普遍認可。然而今年由於疫情等各種複雜的國際形勢，對AE智慧化產生了更多的賦能場景，而這些場景對支撐業務的資料系統也提出了更高的要求和挑戰。
時效性---速度要快
AE的場景基本都是實時營銷，如果給使用者的營銷是基於非實時的資料計算出來的結果，會大幅降低運營的決策效率。以會場調控舉例，需要在雙十一大促期間從修改選品池條件到生效到會場整體時間穩定在10分鐘以內，運營根據實時看板的秒級粒度的大促資料表現，以修改選品規則進行實時調控，解決商品疲勞、會場投放效果差、調整會場貨品結構佈局等問題。
智慧型---效果要準
相對於傳統的小二憑藉自身知識營銷，AE資料智慧平臺需要支援各種分析需求，既有基於規則的簡單分析需求，又有大資料分析需求，越多的資料緯度，越多的成交資料，分析出來的結果就越精確，效果越好。以人群洞察為例，需要使用各種聚類演算法嘗試對使用者進行分組，從而找到相似的客群。傳統的資料庫已經不滿足這種複雜分析需求。
耐操型---使用要狠
在大促期間，既有來自於多使用者高QPS的分析查詢，又有各種複雜離線需求，同時這些離線計算不能影響使用者的即時分析。以使用者洞察為例，既需要秒級響應使用者TGI的計算，又需要支援複雜聚類演算法的計算；而實時會場調控也需要支援高QPS的線上統計和將大資料量結果同時匯出給會場展現引擎，同時還有大資料量的實時寫入，還需要資料實時可見，這樣狠的使用方式，一般的數倉根本滿足不了。
簡易型---使用要省
在滿足以上條件的情況下，往往會使用鏈路很長的複雜大資料方案，同時對於開發者，既要去掌握多平臺的開發能力，又要在使用上區分不同的場景使用不同的系統，這個開發運維成本都非常的大。故AE資料智慧平臺需要一個數倉，使用簡單的sql就可以滿足使用者的所以需求，達到事半功倍的效果。
AnalyticDB--快準狠省的雲原生實時數倉AnalyticDB是阿里雲自研的雲原生數倉，全面相容MySQL語法，為分析而生，擁有出色的分析效能。
資料寫入實時可見
會場實時調控對資料的時效性要求高，AnalyticDB資料寫入後實時可見，可以使運營小二的調控效果實時的反映到會場上，同時AE會場的實時效果資料，從產生到分析到決策應用，從原來的天級別或者小時級別縮短在10分鐘以內。資料寫入實時可見充分滿足了AE對時效性的要求。
高效能高並行度
AnalyticDB不僅資料寫入生效快，計算也快得當仁不讓，AnalyticDB在業界權威效能TPC-DS榜上連續兩年奪得第一名，擁有行列混存、自適應索引，結合向量化的分散式執行引擎實現大部分複雜查詢在毫秒級完成，全面滿足AE智慧營銷各個場景的效能需求：人群洞察場景中人群間的DiffScore計算秒級響應；基於AnalyticDB的進行分析決策，在高峰期平均每小時進行了4800次有效流量調控，平均每分鐘進行80次。
支援各種大資料分析需求
AnalyticDB不僅支援高QPS的即時查詢，同時也支援各種型別的大資料分析能力，使用者洞察業務裡AnalyticDB支援了業務的多種聚類演算法，從而滿足AE的智慧化需求。
在離線一體化數倉
藉助混合負載管理能力，不管使用者的查詢情況多“狠”，AnalyticDB都可以以最高效能完成使用者的所有查詢，同時保證線上查詢不受離線/batch查詢影響。在實時會場調控中，AnalyticDB支撐了平均每分鐘80次的匯出，每次匯出平均100w條記錄，1w/s的實時寫入、10qps的秒級查詢的混合壓力。
MySQL相容
好用是資料庫價值真正的體現，AnalyticDB高度相容MySQL，基本無需修改程式碼即可像使用MySQL一樣使用AnalyticDB，簡單易用。對於AE智慧平臺的使用者--商家和小二來講，會MySQL語法就掌握了全套的大資料分析能力。在AE業務裡使用者圈選，分析一體化，tgi，聚類計算等等都是直接使用SQL全部完成。
業務實踐業務架構
業務概述
資料智慧部使命：致力於全面整合 AliExpress 資料分析體系，以資料服務化的形式，支撐使用者增長、導購營銷、社互動動等業務場景，透過與 AnalyticDB 的深度合作與共建，將原有臃腫的離線資料服務鏈路，打造成快、準、狠、省的實時化鏈路，透過人、貨、場等多維度的標準化資料服務，提升運營小二、商家的運營效率。
架構升級
使用AnalyticDB之前的資料處理鏈路
在計算引擎框中因為多種計算需求的原因，引入了兩種計算引擎：
MaxCompute: 滿足資料批計算需求Pai: 滿足演算法分析需求計算出來的結果會同步到兩個地方：
會場展現引擎：分析的結果對線上生效。HBase：結果儲存在HBase裡供其它業務高QPS查詢。這樣的方案除了鏈路複雜外，更本質的是滿足不了業務實時性需求以及高併發高效能需求。實時會場調控在這條鏈路下時效性日常30分鐘，大促繁忙時2小時以上。
使用AnalyticDB後的資料處理鏈路
AnalyticDB作為一個雲原生實時倉庫，增加 Embedding Algorithm 模組，實現了演算法與分析的一體化能力，極大的縮短了資料處理鏈路。
如上，AnalyticDB解決了所有的計算需求。實時會場調控的時效性縮小到6分鐘。AnalyticDB MySQL作為鏈路核心，支撐了AE業務的快準狠省的智慧營銷。在資料時效性、高併發、低延時以及複雜分析等方面提供了強力的保障。
效果展示
圖示摘自 AE 資料銀行商家版，透過實時標籤、AIPL 趨勢分析、實時人群畫像、秒級人群生成、效果監控等核心能力，豐富了商家自主運營的手段，目前已成為商家店鋪運營的核心產品之一。
店鋪使用者分析
人群顯著性特徵分析
人群畫像分析
投放效果分析
未來展望今年AE智慧中臺在營銷場景中藉助AnalyticDB的能力得到了長足的進步，特別在雙十一大促中，表現絲般順滑。未來將繼續融入AnalyticDB的最新能力進行工程架構上的升級。
全鏈路實時化演進
隨著業界軟硬體技術的發展，全鏈路實時化的路徑變得越來越清晰，資料智慧部在關注資料內容建設之外，也著手於全鏈路實時化的探索與演進。未來，資料智慧部將投入大量的人力，將 AE 的離線鏈路遷移至實時化鏈路，從演算法到工程，從資料到服務，依託於 AnalyticDB 的強大能力，加快小二與商家的運營效率，以應對瞬息萬變的全球化電商市場。
資料服務成本降低研究
業務資源隔離
AE的業務繁多，經常出現多個業務共用一個庫，其中有些是雙十一線上重點保障業務，而有些是測試需求臨時搭建的業務，在大促中出現未經過壓測的複雜測試業務搶佔重保業務的資源，作為AE平臺，要麼增加成本，物理上嚴格分離這兩個業務；要麼進行人工管理這兩個業務的資源。在 AnalyticDB MySQL版新推出的彈性形態下實現了資源組功能，透過新建資源組可以從現有例項劃分出部分計算節點，這些計算節點資源只歸屬該資源組。AE平臺直接將業務繫結到不同的資源組，從而滿足內部多租戶隔離、混合負載的需求。資源組的建立、修改、刪除等操作都可以線上實時生效，並可以透過API與使用者業務系統進行深度融合，實現全自動調配。
儲存計算分離
AE智慧營銷經過這麼多的工作取得了非常不錯的效果，但同時AE智慧平臺仍時刻關注成本的投入，AnalyticDB高效能例項是按儲存能力來計費的，而不同的業務場景計算和儲存的開銷卻不是一致的，甚至相差很大。比如人群洞察業務來講，聚類演算法的計算開銷要求更多的資源，相對於計算，儲存需要的資源是少量的，故後續也需要使用AnalyticDB彈性功能中的儲存計算分離能力進行成本的降低。
彈性擴容
在儲存計算分離的情況下，能夠自動根據負載進行彈性庫容，便於管控。AE業務作為典型的電商場景來講，具有很明顯的峰值和低谷流量時刻。而目前的AnalyticDB高效能模式是資源預分配模式，在絕大部分低谷流量時刻，資源也是在進行計費。而AnalyticDB新推出的彈性形態下自動彈性擴縮功能可以在保證業務服務能力的情況下，同時大幅度降低閒時成本。
資料查詢服務可行性研究
AE智慧業務裡很多資料都會在HBase裡存一份，比如現在的架構裡會場的計算結果仍然會在HBase裡放一份，用來後續業務高QPS點查，這個場景AnalyticDB已經具備高QPS點查能力，目前正在展開前期相關工作，進行KV系統的替換，使用AnalyticDB為AE智慧平臺提供全站資料服務。
智慧化診斷
需要做好監控和邊界問題的發現機制，在出現問題時能夠快速定位。期望能夠充分利用AnalyticDB的監控能力，在出現問題前第一時間預警，規避問題的發生。為此，AnalyticDB將提供全方位、多維度以及準實時的例項執行狀況洞察能力，透過對例項內部的各類執行日誌和時序指標進行演算法建模，提供出問題前準確預測、出問題時及時告警、處理問題時精準定位的能力，確保不影響使用者上層業務。