概要：剛剛結束的2020天貓雙11中，MaxCompute交互式分析（Hologres）+實時計算Flink搭建的雲原生實時數倉首次在核心數據場景落地，為大數據平臺創下一項新紀錄。藉此之際，我們將陸續推出雲原生實時數倉雙11實戰系列內容，本篇將重點介紹Hologres在阿里巴巴AliExpress的最佳實踐，並助力AliExpress實時數倉升級，節約成本近50%，提效300%。

AliExpress中文名是全球速賣通，是阿里巴巴面向國際市場打造的跨境電商平臺，被廣大賣家稱為“國際版淘寶"，在2020年全球疫情肆虐的大背景下迎來了自己的10週年，伴隨業務全球市場的拓展，AliExpress也同樣遇到了大多數電商都會遇到的問題：流量紅利逐步消失、拉新成本飛速上升以及引流效率的逐漸疲軟等。業務發展需要從原始的野蠻生長逐步轉向流量的精細化運營，於是幫助業務看清站內流量的分發及承接效率的流量通道也就應運而生了。
關於電商平臺元素的解析有大家比較熟悉的“人、貨、場”分法，人和貨相對好理解，場可以理解為消費者和商品之間創建特殊鏈接的產品形式，如搜索、推薦、店鋪、猜你喜歡等，流量通道便是以更加結構化的方式描述平臺元素之間的關係，實現更好研究不同場域流量效率的目的。
在僅持續48小時（國際11不同於國內，持續2天）的雙11大促過程中，數據更新的頻率直接決定了業務做決策的頻次，流量通道數據實時化的需求迫在眉睫。文章接下來希望帶你一起還原藉助Hologres卓越性能落地流量通道實時分析體系的過程。

一、流量通道實時化數倉架構調研

流量通道升級前停留在準實時架構，整體數據的時效為H+3（3小時前數據可查），所以接下來的重點工作變成了實時架構的設計及實現，綜合AliExpress內部及其他BU的應用場景，主流實時數倉架構演進主要如下：

1）基於Flink+多數據引擎的Lambda數倉架構

Lambda實時數倉也是業界相對通用的解決方案，數據採集之後根據業務需求分為實時層與離線層，分別進行實時處理和離線處理。處理結果在數據服務層對接數據應用之前會進行數據的合併，從而實現實時數據與離線數據同時服務於在線數據應用和數據產品。

離線層處理：採集數據歸併到離線數倉之後，首先會統一到ODS層。對ODS層的數據進行簡單數據清洗，構建DWD層（明細層）。在數據建模的過程中，為了提高數據分析效率以及進行業務分層，會對DWD層的數據進行進一步的加工和處理，相當於預計算。預計算結果在對接數據服務之前還會轉儲到一些離線存儲系統中。
實時層處理：邏輯與離線層類似，但是更加講究時效性。實時層同樣是對上游數據庫或者系統的數據進行實時數據的訂閱和消費。消費數據之後會將其寫到實時的DWD層或DWS層。實時計算引擎提供的是計算能力，最終處理結果需要寫到一些實時存儲中，例如KV Store等。
很多場景離線層還有一個重要的功能就是對實時層數據問題的修正，其次基於成本和開發效率的考慮，實時層一般保留兩到三天的數據，而月、年的數據等更長的數據存儲在離線數倉中，使用時需要離線數據和實時數據的結合場景，方式是引入了更多產品，如MySQL、ADB等。在流量通道場景，大促相關的分析往往需要對比歷史同比或環比數據，比如需要和去年或者是前年的雙11做對比分析，同樣需要考慮到離線數據回刷或者數據一致性的問題。
AliExpress已有的實時數倉也屬於Lambda架構的範疇，流處理層的幾個關鍵思路如下：

1. Flink承擔絕大部分的解析+聚合計算。
2. 消息隊列TimeTunnel中沉澱抽象明細層和彙總層結果。
3. 按照維度表數據量級，選擇使用Lindorm或者MaxCompute存儲。
4. 根據下游應用場景特點將結果數據導入不同的存儲引擎，例如為了提供高QPS的點查詢引入Lindorm；為了對離線數據進行交互式分析，會引入ADB等。

伴隨業務的高速增長和數據膨脹，數據質量、運維複雜、成本高、業務敏捷性等問題也逐漸突顯，具體如下：

1. 一致性問題：離線/實時2套代碼、2套語義、2份數據。流和批執行的代碼數據處理邏輯的不同，導致同一份源數據處理結果可能不一致，同時離線數據和實時數據合併過程需要不斷地進行數據結構的重新定義，數據的轉儲、變化、合併，都可能引入數據一致性問題。常聽到“流批一體”技術核心就是解決一致性問題。
2. 多套系統環環相扣，架構複雜，延遲風險大：數據計算鏈路長，穿插在若干Flink任務中間的TT sink節點降低了系統了魯棒性，當某一個下游任務發現了數據異常，其向上溯源及排查成本被放大。而流式計算任務由於其實時的特性，往往給到開發定位和止血問題的時間都在小時級別，有時涉及線上系統甚至會要求分鐘級別。
3. 開發週期長，業務不敏捷：複雜架構帶來還有較高的開發、變更成本，任何一套數據或業務方案上線之前都需要進行數據校對、數據驗證。數據校對過程中一旦出現問題，其定位和診斷將十分複雜，在極端情況下，實現一個實時任務的代碼邏輯只佔開發時間的20%不到，剩下80%時間都用於漫長的比對任務開發，數據校驗調試，任務調優運維等，這對研發效能提升是非常大挑戰。
4. 元數據管理困難、存儲成本高：數據服務部分，針對不同的業務場景選擇不同的數據庫引擎，一方面存儲成本成本增加，同時管理這些系統也變得異常麻煩，當底層存儲引擎多樣的時候，尤其是包含了很多KV引擎時，由於schema free的特點，我們很難有一種簡潔友好的方式管理表及字段。

2）基於Flink+Lindorm實時數倉架構

鑑於以上痛點，是否可以用Flink+Lindorm簡化實時部分呢？Lindorm 是一個分佈式的 No-SQL 數據庫，數據以鍵值對形式存儲，支持高併發、毫秒級響應的點查詢，同時Flink作為當前業界最先進的流計算引擎，其動態表狀態管理及回撤機制能滿足大部分指標計算需求。

從架構圖可以看出，所有指標的計算，包括表關聯、指標聚合、維表查詢，都在Flink 引擎中完成。具體地講，Flink 引擎實時處理消息，在引擎內存中保存指標的結果，當指標有更新時，會將結果通過回撤機制（指標結果的新舊值）通知下游算子，將指標結果的最新值更新到 Lindorm 中。
這種方案最大的特點是指標的計算都是通過Flnk流引擎實現，然後將預計算好的多維 Cube 導入到 Lindorm 這個低延遲的分佈式數據庫中，從而可以實現亞秒級的查詢響應。然而，這種架構存儲明顯的弊端：

1. 計算邏輯，資源消耗大：指標按不同維度組合都需要保存在 Flink 內存中，當指標粒度越細或指標時間跨度越大時，資源消耗越大。
2. 查詢靈活性不足：計算邏輯需預先定義，無法靈活調整 Query。在流量通道的場景中，會有行業/產品/商品/商家等類似多維靈活交叉分析的場景。

3）基於Flink+Druid實時數倉架構

Flink+Druid如何呢？Druid 是一個分佈式、支持實時多維 OLAP 分析的數據處理系統。它的關鍵特性在於支持根據時間戳對數據進行預聚合攝入和聚合分析，支持亞妙極高併發查詢。此方案Flink只需要負責簡單的ETL工作，指標的計算由 Druid 完成。Druid 按預先定義的指標計算模板進行預聚合計算存儲，並對外提高查詢服務。

但是該方案的侷限性也非常明顯：

• 查詢靈活度不夠：指標計算邏輯需預先按模板定義，同時數據預聚合存儲，複用性明細降低了。
• 表關聯能力性能差：Druid在表關聯場景支持比較弱，在流量通道的場景中，轉化率相關指標的計算邏輯複雜，同時需要大量實時表的關聯聚合。

以上兩種方案，在某些特定場景下均有較好的應用價值，比如 Flink+Lindorm 方案很適合實時大屏等時效性要求非常高的場景；Flink+Druid 方案則較適合超大數據量（萬億級）單表的實時多維分析場景。而對於流量分析場景，這兩種方案都存在明顯的侷限性，無法滿足我們的需求。

二、基於Flink+Hologres實時數倉的實現

偶然的機會，在公司內部看到淘系搜索推薦、客服體驗事業部等在嘗試Flink+Hologres的方式實現實時數倉，詳細瞭解後，給了我們很大的信心，其中最吸引我們的能力有三點：

1. Hologres高性能的寫入：可以支持上百W+ RPS，同時支持數據實時寫入即可查。
2. Hologres高性能的查詢：基於 MPP 架構的分佈式 ROLAP （Relational OLAP）分析引擎，各節點職責對等，各自負責一部分數據的處理（Shared Nothing），開發了向量化執行引擎，利用日誌合併樹、bitmap索引與 CPU 的 SIMD（單指令多數據 ，Single Instruction Multiple Data）等特性，充分發揮硬件優勢，即使面對大數據量計算的場景，通常也能達到 CPU 性能的極限，達到高效計算的目的。具備同時支持PointQuery，Ad-hoc，OLAP，實時離線聯邦分析等多業務場景的能力，讓對外服務統一引擎成為可能。
3. Hologres豐富可擴展的存儲：Hologres豐富可擴展的存儲：Hologres支持行存和列存兩種存儲格式，採用計算與存儲分離架構，便於水平彈性伸縮，可以支持海量 （TB到PB）的數據存儲。
   

基於此，我們設計了流量通道實時架構：

• 交互式計算：Flink只做簡單明細層數據的產出，指標彙總在Hologres實時交互式觸發。
• 流批一體：歷史明細數據提前導入Hologres內表，基於Hologres引擎同當天分區數據實時彙總比對。
• 聯邦查詢：部分小維表直接作為Hologres外部表，做離線加速方式查詢關聯。

圖5-流量通道具體Flink+Hologres實時數倉實現
那Flink+Hologres升級版實時數倉架構是如何解決Lindorm/Druid架構存在的問題呢？

• 資源消耗大：Flink+Lindorm方案最大的侷限性在於，所有維度的計算都通過Flink完成，Flink是純內存有狀態的流式計算，每到一條消息都需要對內存狀態進行讀取更新。維度組合複雜、聚合週期跨度較大時，內存往往會成為瓶頸，使得無法應對細粒度的分析需求。在流量通道場景場景中，查詢均為人工觸發，所以QPS相對較低，同時運營查詢維度相對固定，實時CUBE存在大量的計算浪費，預期利用Hologres 強大的交互式查詢能力，可以大大降低計算資源的消耗。
• 靈活性不足：上述提及的兩種方案，由於物理存儲的是指標數據，都存在靈活性不足的缺點。當需新增不同維度的指標時，這兩種方案都需要重新創建任務計算新指標，而新指標歷史數據的回刷成本極高。基於Hologres的方案可以直接存儲明細數據，具備滿足各種查詢維度的能力。
• 表關聯能力弱：流量通道分析遵循漏斗分析模型，從用戶瀏覽->收藏加購->下單支付各階段看流量轉化的表現，所以存在大量大表關聯操作。藉助Hologres的特性，對主要分析鏈路的明細數據表進行精心設計，以滿足流量分析場景中的大表關聯需求。從整個分析鏈路來看，最終可以細化到每個設備在網站的行為表現，所以我們選取了設備id 作為表的分佈鍵，充分利用 Hologres 的 Local Join 能力，使得大表的關聯操作得以在秒級以內完成返回。
• 運維成本高：大促往往具有數據量成倍增長的特點，因此需要在大促前進行資源預估以及擴容，而當大促結束後，為了不讓資源浪費，會進行相應的縮容操作。對比Flink+Lindorm方案，由於計算負載都在Flink任務中，所以擴縮容主要集中在Flink任務上。而對Flink任務進行擴縮容的成本非常高，需要對每個任務獨立執行停止-擴容/縮容-啟動操作。Hologres的計算節點是雲原生的，具有良好的彈性伸縮能力，因此，本方案在運維成本上基本可以忽略不計，大大降低了開發人員的工作量。

三、業務價值

從開始接觸Hologres，到Hologres真正落地具體場景，Hologres帶來諸多顯著業務價值，主要體現在決策實時化，研發提效，降成本三方面。

1）成本節約50%

• 更簡單的Flink計算邏輯，對比Flink+Lindorm方案，流量通道場景至少節省 6000 Cores。
• 更簡單的數據模型，無DWS實際存儲，觸發式計算代替了DWS預計算。

2）決策效率提升300%

• 實時準確的業務決策：雙11有限48小時內，實時帶來最大的價值便是根據流量實時的表現作出當前最直接的應對，保障應對方案的準確性和時效性，今年大促整體的有效的數據覆盤從過去的1次提升為3次，時效價值提升300%，讓我們對未來有了更大的想象空間。
  如圖，2-3點這個區間運營發現會場通道瀏覽轉化持續走低，及時調整後，實時數據驗證提升效果符合預期。

• 靈活的多維數據分析：實時數據產出後，分析師，業務運營等角色可以根據需求進行實時數據的篩選，過濾和分析展示，雙11前烽火臺（內部使用的數據產品）快速沉澱了行業、產品、商家、商品、海外倉等多視角通道效率分析的能力，其中商品、海外倉部分完成由運營同學自助完成。

3）研發效率提升30%

基於Flink+Hologres架構帶給DA同學最大的驚喜便是研發效率的明顯提升，項目初期評估整體需要40人日，伴隨中間層數據側產出，指標生產、數據驗證、分析報表搭建等工作並行展開，實際人日減少11天，提效近30%，使得我們在大促前有更多的精力來做Hologres SQL調優及性能壓測的工作。

4）更簡單的數據加工鏈路

• 事實明細層：直接開放公共層明細數據給到運營/BA/BI小二，需求交互方式SQL化，指標口徑實時驗證，開發效率由天級縮減至小時級，海外倉需求4合1，效率提升400%。
• 事實彙總層：DWS視圖化雖然增加了諸多性能方面的挑戰，但更短的問題排除路徑、更靈活的指標變更（無需數據回刷）帶來的好處是顯而易見的。
• 數據展示：BI/BA可通過FBI/Vshow+Hologres方式自助搭建實時大屏，提升了業務自助數據分析的體驗，解決了每年大促遇到的業務訴求和數據開發資源的Gap。

5）讓業務打仗隨時上膛-俄羅斯topBrand臨時圈選

今年俄羅斯受盧布貶值的影響(相對美元貶值，AE商品價格以美元計價，相對消費者來說價格變高)，雙11最後的4小時標類行業用戶下單意願疲軟，運營臨時新增topBrand圈選需求，按照行業維度篩選出高於行業平均IPVUV價值但IPVUV低於行業平均值的商品，針對這部分商品做流量的加持，從而促進整體GMV目標的達成。

四、對於Hologres的期望

期待Hologres未來可以繼續在流批一體、HSAP上做更深入的探索，也希望與Hologres保持更加深入的合作，期待的Hologres架構與能力如下：

• 資源隔離：長期看批流統一計算後，大Query/小Query難以避免資源的搶佔，資源組隔離即對計算資源進行彈性劃分，不同資源組之間的計算資源在物理上完全隔離。通過賬號綁定到不同的資源組，SQL查詢根據綁定關係自動路由至對應的資源組執行命令，用戶可以選擇為不同的資源組設置不同的查詢執行模式，從而滿足用戶實現實例內部多租戶、混合負載的需求，當然如果Hologres調度可以自動優化資源搶佔問題就更加完美了。

• 流批一體：批和流一套引擎，運行在一套資源底座上，天然削峰填谷，自然混布，不僅節省了開發成本，同時也大幅節省了運維成本和資源成本。

  • 存儲統一（方向一）：MaxCompute可以直接訪問Hologres數據，準實時鏈路逐步升級實時，Hologres數據支持歸檔MaxCompute，逐步去除離線ODS，實現離線&實時數據的統一。
  • 計算統一（方向二）：基於Hologres一體的流批一體數據業務，MPP模式錯峰執行流批任務。
• 分時彈性：數倉系統的負載存在明細的時段波動，低峰期資源往往處於閒置階段。分時彈性功能允許用戶靈活定製彈性計劃（每天定時），在業務高峰期來臨之前自動進行擴容滿足業務流量，即滿足了業務流量高峰的需求，又降低了使用成本，同時結合資源組功能，甚至可以讓某個資源組在低峰期時0節點，成本極低。
• 數據分層：按表粒度、表的二級分區粒度獨立選擇冷、熱存儲介質，比如指定用戶維表數據全部存儲在本地SSD，或指定交易表的一部分分區數據存儲在本地SSD，冷分區存儲在OSS上，以達到最低的存儲成本。
• 行列混存：維度表訂閱TT流實現維表實時更新，行列混存方式幫助維度表同時具備行存表的更新，列關聯聚合的理想性能。
• 行列自動轉化：Flink/業務數據實時寫入時，選擇行存表，單記錄全字段更新刪除操作更友好，行存表如果可以自動轉換為列存表，同時進行組合排序或多維排序，讓列存表提供貼合業務場景的最佳查詢性能。
• 物化視圖：簡化數據清洗流程(ETL: Extract, Load, Transform)，幫助用戶加速分析，如：大屏類業務加速，配合BI工具使用，或者是緩存一些公共中間結果集用以加速慢查詢。

作者：
陳功（昀西），阿里巴巴數據技術及產品部技術專家
李月（志歉），阿里巴巴數據技術及產品部技術專家