1. 流批一體架構

2. 天貓雙11實踐

3. 未來規劃

一、流批一體架構

本文主要跟大家分享流批一體化的相關技術在天貓的應用。此前，在較長的時間裡 Lambda 架構基本能滿足業務訴求。但當業務發展到一定階段後，在資料質量、研發效能、穩定性上產生了部分新訴求，需要透過流批一體技術方案來解決。

今年 7 月份，我們開始進行流批一體化的嘗試，然後雙 11 全部應用上線了，當前流批一體架構表現非常穩定。

1.傳統數倉架構（Lambda）

下圖為傳統的 Lambda 架構，包括業務層、儲存層、計算層、服務層和應用層。傳統的架構很靈活，流和批之間沒有相互耦合，但是也會帶來幾個問題。

效率層面。流批底層資料模型不一致，導致應用層需要做大量的拼接邏輯（同比、環比、二次加工等），搭建效率低，且容易出錯。成本層面。流批儲存系統隔離（面向不同寫入場景），提供的資料服務不一致，維護成本高。同時，手工建立資料同步任務，增加了開發成本和儲存成本。質量與資源層面。首先，一個業務邏輯，兩個引擎兩套程式碼，SQL 邏輯不能複用，資料一致性和質量難以保障。其次，不同平臺和引擎間切換，開發體驗割裂，容易出現變更遺漏。並且，批處理&流處理叢集無法做到錯峰，資源利用率較低。

2.流批一體架構（Kappa+Lambda）

基於 Lambda 架構的痛點，我們設計了流批一體的新架構。如下圖所示，流批一體的架構並不是替換原來的 Lambda 架構，它是 Kappa 和 Lambda 結合的架構。批處理和批儲存依然存在，本質上是在流的場景中尋找批場景。

流批邏輯層，這是最重要的部分之一。業務層和儲存層仍然不變，在此之上構建一個流批邏輯層來進行流儲存和批儲存的對映。有了這個邏輯層，就可以基於 Flink 引擎面向統一的邏輯層做業務邏輯表達，並且輸出是統一的。計算層，做流批統一處理。首先，一套程式碼，兩種計算模式，邏輯統一，靈活切換，可以實現研發效率大幅提升。其次，流批計算資源混部，資源利用率提升。服務層，做流批統一儲存，無需手工同步，無重複儲存。應用層，進行產品組裝，流批儲存透明化，查詢邏輯完全一致，應用端接入成本大幅降低，點查 / OLAP 分析統一支援。

3.流批邏輯層示例

這裡面最核心的關鍵在於流批的邏輯層，如下圖所示，是流批邏輯層示例。

在此列舉內部的一張邏輯映象表的例子。左邊是 MaxCompute 表，及其表名和 schema。右邊是 DataHub 的表，也有其表名和 schema。平臺的主要功能在於把兩個表名的欄位進行映象化、對映。比如，左邊有 100 個欄位，右邊有 50 個欄位，他們的交集可能是 30 個欄位，然後將 30 個欄位進行映象化，並將其關聯關係對映到一張邏輯映象表上面去。平臺還提供了智慧對映，當欄位名稱、型別一樣時，可以自動判斷做對映。當然，也可以做一個人工的輔助對映。如此，流批一體的 Flink 任務就可以進行業務表達了。

4.典型流批模式舉例

以下將分享我們內部支援的一個典型的流批模式。比如 Kafka 的流表，同時也有盤古的 MaxCompute 表，透過上面的模式對映到流批邏輯表。中間需要編寫一個 SQL 業務邏輯的表達。業務邏輯的表達與流批是沒有關係的，它只是表達了整個計算的邏輯。在計算邏輯之上，有純流模式的配置，如流模式的並行度、所在的叢集等，這些資訊都是流模式相關的。

同時在上面也可以進行一個批模式的撰寫，批模式更多依賴排程，是純批模式，同時也會進行批的引數最佳化。這樣的話，同一套 SQL 就面向兩套配置了，而且兩套配置可以同時開啟。也就是說，這裡面有三種模式，包括純流模式、純批模式、流批混合的模式。結合業務場景，可以進行靈活的切換。純流模式可以直接寫當天的分割槽，批的模式可以寫歷史分割槽。這種情況下，流和批之間的程式碼和業務邏輯完全可以做到一致。同時在統一的模型彙總表中還可以做統一的儲存，應用層搭建僅需關心報表的表達邏輯即可。

5.新老研發模式比對

下面是對新老研發模式的一個比對。

第一個場景，批任務週期排程，流批任務因為輸入源集合不一致會導致差異，需要批任務週期排程訂正流輸出結果。老模式的批處理任務需要在 MaxCompute、Hive、Spark 等處理系統編寫一套程式碼，而流是在 Flink 上編寫，導致兩套程式碼。在新的模式上面，完全可以做到一套程式碼。Flink Batch 任務每天週期排程訂正流產生的歷史資料。優勢是處理邏輯一致，一套程式碼實現流和批的排程，研發效率提升一倍。第二個場景，批任務按需排程（回刷場景），流批任務計算結果完全一致，不需要批任務週期排程訂正。老的模式還是不變，在新的模式下，Flink Batch 任務每天空跑排程，當出現口徑變更時再啟動手工任務。優點是處理邏輯一致、研發效率提升一倍、批空跑排程，計算資源節省 50%。

6.Dataphin“流批一體”：新一代資料處理框架

Dataphin 是一個智慧資料構建和管理的平臺，今天主要分享平臺中跟流批一體相關的功能。

首先，提供全面的資料來源管理，把資料來源的資訊接到 Dataphin 中做統一的資料來源管理。同時，也提供常規的資料整合的方式，離線實時都支援，然後把線上的資料匯入數倉的資料系統裡面去。

基於這兩個點，我們在 Dataphin 研發和運維上面做了一些功能的迭代。這一套功能在以前都是基於 Flink Stream 去構建的，現在有了流批的統一邏輯層，所有的功能可以複用到批的場景上。平臺提供的非常完整的一套資料中臺的基礎功能，都可以被流批一體架構使用。如圖所示，左邊會翻譯成流計算，進行實時寫入。右邊會翻譯成批計算，進行離線週期的排程，然後將二者放到統一的儲存層。有了統一的儲存層，就可以面向不同的場景了。

二、天貓雙 11 實踐

1.雙 11：“營銷活動分析” 核心挑戰

下面講一下天貓雙 11 的實踐，首先跟大家介紹一下營銷活動分析核心的挑戰。

第一，高時效性。多維度資料分析體系，業務訴求全面實時化。第二，高準確度。大量同比和環比場景，實時和離線資料口徑需要完全一致。第三，高穩定性。洪峰和海量資料挑戰，高 SLA 要求，雙鏈路保障。第四，高靈活度。活動週期跨天累計，實時多維度排行拆解。

2.業務流批架構

下面的資料採集還是以前的 Lambda 架構。流的模式有相應的分層，批的模式也有相應的分層，這一套模式是我們以前常規用的模式。在這套模式之上，有大量的明細資料，我們會在明細資料上面構建流批的邏輯層。有了這個邏輯層可以進行統一維度的抽象。比如說，天貓這邊有很多大盤，再從大盤上面拆解到行業上面。還有很多業務上面的一些維度，就不展開去講了。

我們再往下去看具體的一些維度的統一邏輯層的設計。

如下圖所示，這裡舉了幾個資料，有流量、交易、加購、預售等，是對前面流批一體的架構的細化。比如說，從流量的角度，有兩張表，一張是整體的商品 pv 表，一張是整體商品的引導 pv 表。每一個數據都會有本身資料的最明細資料，還有本身資料的引導資料。在這個基礎上，我們做了一個映象表的對映，流的流量表也會跟批的流量表進行一個欄位的對映，做成統一的模型層。有了模型層之後，可以進行很多面向業務場景的嘗試。我們需要看每一個行業上的實時資料，還需要跟歷史資料進行對比。整套體系就是天貓常規的大促裡面的一些分析體系了。

在雙 11 來臨之前，大家可以看到預售的資料，預售的過程中，還有預熱的資料，比如加購、收藏。再到正式期的支付、紅包、券等。面向整個營銷活動分析體系進行資料的建設，這裡面所有流批一體的資料都會放到 Hologres。Hologres 提供兩個能力，一個是點查能力，另一個是 OLAP 的分析能力。最上層是透過 Quick BI 的資料展示層。因為有了統一的 Hologres 儲存，Quick BI 就可以做很多東西。我們經常有一些同比、趨勢圖、柱狀圖等，我們在 Quick BI 上面可以構建面向 BI 場景的一些元件。

3.挑戰

這裡主要講三個挑戰。

第一個既是機會也是挑戰，錯峰。同一個引擎上，流和批天然是在同一個叢集或同一批叢集中執行。如下圖所示，天貓的業務在流處理上，流資料來自於線上系統，0~8 點是非常低的。批處理部分，叢集水位由週期排程決定，0~8 點屬於高峰期。這剛好是錯峰的場景。我們內部提高叢集資源利用率的途徑有兩個：

線上離線混布。比如說 Flink 和 MaxCompute，流和批的系統進行混布，透過統一排程方式，可以達到比較高的資源利用率。透過同一個引擎，流批引擎統一。

同時，也會帶來一個問題，雖然資源利用率高，但在資源隔離上面會有比較多的挑戰。所以我們還做了叢集 CPU 物理水位的控制，避免單叢集 CPU 的水位達到 70% 以上。當 CPU 的水位 70% 以上時，對線上的實時計算的業務會產生比較大的影響。另外，我們還做了叢集的優先順序劃分，按優先順序做叢集負載均衡。透過以上兩點，可以避免離線影響線上。

第二個挑戰是批例項的資料寫入方式。

方案一，直接寫正式表對應分割槽。它帶來兩個弊端，一是寫過程對線上不透明，造成秒級或分鐘級影響。二是流批主鍵值個數不一樣，存在髒資料。方案二，寫臨時表，Sink 結束後， Rename 成正式分割槽表。Rename 過程的示意程式碼如下圖所示。這種方案的優點是，寫過程不影響線上，Rename 過程毫秒級。

舉例說明，在天貓營銷活動分析中，BI 產品很多是看分鐘的趨勢圖和小時的趨勢圖。以前我們在流裡面的實現的方式，對累計指標取分鐘快照，存在三個弊端：

第一，相同邏輯，批模式只輸出1條資料，流批結果不一致。第二，追歷史資料情況下，分鐘趨勢圖不完整。第三，嚴格意義上，趨勢圖不準確，資料歸屬分鐘錯誤。

引入了流批一體技術之後，因為流批要一致，我們需要採用另外一種方式，計算分成4步：

第一步，首次購買時間。第二步，分鐘增量買家數。第三步，分鐘累計買家數。第四步，分鐘資料展開。

這種方式有三個優點：

第一，流批兩種執行，結果完全一致。第二，追歷史資料情況下，結果完全一致。第三，趨勢圖和業務表現完全一致。

我們看一下最終在天貓的業務效果，與最初流批一體架構想達到的目的是完全一致的。

在時效性上，面對 583000 筆/秒的交易峰值，上億/秒的無線流量洪流，所有任務秒級延時，峰值 TPS 達 40 億條/秒。批任務錯峰執行，機器資源利用率大幅提升，單任務處理資料量超千億，重要基線提前 4 小時產出。在準確性上，流批任務的業務口徑完全一致，0 資料質量問題，成為大促期間重要的業務雷達。流批模型完全統一，產品搭建效率提升 400%，豐富了資料展示形式。在靈活性上，只需要一套程式碼，需求迭代效率提升 2 倍，大促當天緊急需求承接效率提升 5 倍。實時數倉與 OLAP 場景結合，變更成本大幅下降，滿足分析師按需取數的場景。三、未來規劃

最後講一下未來的一個規劃。現階段，從資料架構上來看，我們完成了計算層面的流批統一。透過邏輯表、映象表做異構儲存之間的 schema 的統一。下一個階段，應該是計算和儲存相加的統一，才是真正的流批一體。

所以在整個平臺建設上，我們會尋找可以做到流批統一的儲存系統，進行整個解決方案的構建。同時，流批一體在大規模使用後，產生了部分新的需求，批計算穩定性已達標，周圍的工具仍需要花精力構建和投入，如此才可以達到真正更好的生產效果。我們也會投入精力與計算平臺技術團隊一起合作，也藉助社群的力量，共建流批一體架構。

出處：

https://mp.weixin.qq.com/s/O5otEqfBVYDOcordFovMhQ