Hologres助力AliExpress雙11實時數倉更新

概要：剛剛結束的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工具使用，或者是緩存一些公共中間結果集用以加速慢查詢。

作者：

陳功（昀西），阿裡巴巴資料技術及産品部技術專家

李月（志歉），阿裡巴巴資料技術及産品部技術專家