摘要：本文整理自聚水潭資料專家張成玉，聚水潭高階資料工程師應聖楚，在 FFA 2022 行業案例專場的分享。本篇內容主要分為四個部分：
- 實時數倉的建設和發展
- 資料中臺的產品體系及架構
- 實時計算的實踐和最佳化
- 對實時計算的未來展望
聚水潭是一家做電商 ERP 的公司，ERP 主要由四個模組組成，OMS、WMS、SCM、DRM，其中 OMS 是訂單管理系統。從 2014 年發展至今，聚水潭已經對接了 300+線上平臺渠道，客戶透過我們的 ERP 產品可以統一做訂單的管理，避免了需要去各個線上平臺單獨處理，全渠道也是由此而來。基於 ERP 的底座，我們的資料團隊打造了為商家服務的實時資料中臺，目前已經有兩萬+商家付費訂閱。
一、實時數倉的建設和發展
聚水潭發展至今大概經歷了四個階段。
第一階段，為了滿足商家報表的看數需求，提供了 SqlServer 的線上查詢。但它有一些弊端：
- 無法提供豐富統計指標；
- 業務庫耦合，RT 不穩定，商家體驗差。
- 分庫分表很難全域性聚合統計，影響運營分析。
第二階段，透過 AnalyticDB、多叢集 ETL 做 T+1 的離線分析，補足 SqlServer AP 能力的不足。
第三階段，透過 Flink+MC 實現實時/離線 Lambda 架構的雙鏈路，MC 補齊了模型、排程、跨叢集統計的短板。計算引擎實現了秒級更新，支援業務高時效的統計需求。
第四階段，實時數倉 1.0 落地，透過 Flink 實時模型規範、數倉分層落地，包括自建 DB 提供實時維表和外接狀態儲存，用 Hologres/PolarDB 作為 ADS 層儲存，提供不同場景高效查詢。
上圖是我們實時數倉的架構。我們大多數的資料都在 SqlServer 的業務庫，然後透過我們自研的同步中介軟體，同步資料到 Kafka 或者 SLS 裡，作為 Flink 的 ODS 層。接著透過 Flink 清洗到 DWD 層，DWD 層和我們自建 DB 做了很多維表關聯，包括外接狀態互動。接著透過 Flink 做 ADS 層的聚合運算，ADS 的結果根據不同的業務場景落到不同的儲存引擎裡。
目前在聚水潭主要分為兩個模組。第一個是線上服務，它目前支撐我們的實時資料門戶、實時大屏的業務場景，主要由 PolarDB 和 Redis 承接。第二個是 AD-HOC 分析，它目前支撐實時物流場景，主要由 Hologres 和 AnalyticDB 承接。
二、資料中臺的產品體系及架構
聚水潭的資料中臺主要為商家服務，基於商家的看數場景，我們抽象了三個核心要素，分別是角色、資料、場景。簡而言之，就是什麼樣的人，在什麼樣的場景，看什麼樣的資料。
下面透過兩個場景，帶大家感受一下，為什麼我們要透過實時計算的方式來滿足商家高時效的看數需求。
場景 1：線上交易實時多維分析。商家運營人員經常要面對線上交易實時多維分析的場景。最開始我們透過線上庫提供簡單的支援，但線上庫有大商家 RT 響應慢，多表關聯效能差，AP 查詢效能差的問題。所以我們基於實時計算，在中間層做多表關聯，在應用層實時聚合，將資料量級降低。透過 KV 做快速查詢，來滿足商家高時效的快速場景。
場景 2：倉管發貨實時跟蹤。我們的商家很多都有自己的倉庫或者三方倉庫，對於倉庫內的倉管，他們需要對每天的發貨情況做實時跟蹤。最開始我們透過離線計算的方式產出 T+1 的資料，但這就會導致今日發貨進度無法感知，發貨不及時產生資損，所以商家有很強烈的實時看數需求。我們透過實時計算保證資料的秒擊產出，且我們提供了多個倉庫發貨進度的實時統計，倉管可以基於我們的實時分析資料來做實時驅動，調配發貨。
上圖是我們實時資料中臺的完整架構圖。目前最底層的資料來源已經對接了 300+平臺，100+物流公司，透過實時計算的分層來支撐多業務場景、多主題的資料分析。目前我們的實時場景可以分為兩部分，實時場景分析和實時風控監控。
實時場景分析可以分全渠道今日銷量統計、多平臺多店鋪彙總統計、重點商品多維統計、多平臺直播分析、售後型別實時分析、發貨進度實時跟蹤。
實時風控監控目前做的比較多的是物流實時預警，未來將要做的庫存實時監控、價格實時預警。
商家的業務同學可以大致分為運營同學、售後同學、直播同學、倉庫同學。他們在我們的實時門戶裡都能找到自己對應的業務場景，滿足他們實時看數的需求。大致我們分為了以下六個板塊。
- 多平臺多店鋪彙總指標，實時趨勢歷史對比。
- 重點店鋪核心渠道置頂，新店鋪新渠道孵化。
- 主推款式重點商品關注，新款新品銷售跟蹤。
- 發貨進度及未發貨情況，關鍵節點超時風險。
- 主播帶貨支援跨天統計，頭部主播直播爆品。
- 售後訂單退貨金額統計，售後單據原因跟蹤。
以上板塊可以滿足不同的業務同學，其中“多平臺多店鋪彙總指標、重點店鋪核心渠道置頂、主推款式重點商品關注”可以幫助運營同學快速響應。“發貨進度即及發貨情況”可以幫助倉庫同學做發貨的實時跟蹤。“主播帶貨支援跨天統計”可以幫助主播做跨店統計。“售後訂單退貨金額統計”可以幫助售後同學做售後訂單的實時跟蹤。
我們的全渠道實時資料大屏主要滿足商家平時或者大促階段的投放訴求。不但涵蓋了實時資料中臺的大部分模組，又做了銷量熱力地圖，讓分佈一目瞭然。
三、實時計算的實踐和最佳化
我們把 Flink 的一些難題歸納為以下三類。
- 第一類，多流關聯。這裡特指多事實流狀態關聯，關聯週期長。
- 第二類，大狀態管理。它可能會有 TB 級的狀態，甚至更大，且它的 TTL 可能會超過一個月。
- 第三類，高時效體驗。包括穩定性、任務延遲的概念。
舉個例子，商品分攤、拆分是 Flink 的一個任務，它屬於數倉的公共層。這個任務背景是客戶想要看到商品粒度金額、件數、成本價等等資訊。對於這樣的需求，我們把整個流程拆成三步。
- 第一步，三流關聯。三流分別是訂單流、訂單明細流、操作日誌流。訂單流裡是支付時間等基本的訂單資訊；明細流裡是商品粒度的成本價等資訊；操作日誌流會記錄一些刪除的資訊、update、更改其他欄位的資訊。關聯之後的資料，我們再根據業務邏輯做商品分攤。
- 第二步，商品分攤。這一步我們會把訂單上的金額，分攤到具體的每個商品上。這樣我們就可以得到商品的金額和件數了。
- 第三步，組合裝拆分。它有個特殊的業務場景，商家會把不同的商品打包成另外的商品來賣。比如 a 和 b 商品，會打包成 c。如果發生 c 的訂單，需要拆分成 a 和 b 做統計，具體去看它的成本價和銷售金額。
在上面的場景中，有一個多事實流關聯的問題。最初我們是用 Join 來解決的，也就是把三條流分為兩次 Join 去解決，但任務效率不太理想，狀態也較大。之後我們參考了一些行業案例，並瞭解到 UNION ALL+KEY BY 是關聯鍵一致的，所以後來我們用 UNION ALL+KEY BY 替代了多次 Join。這個方案的原理是我們可以複用它的狀態，即 UNION ALL+KEY BY 每條流的狀態只保留一份，而 Join 保留多份。
另外，多事實流關聯還有一個關聯週期長的問題。在某些場景下，比如訂單今日發貨了，而明細表卻是一個月前的，這時它的狀態保留時間不確定，甚至可能超過了一個月。對此，我們會引入額外的狀態管理機制。
在分享狀態管理機制前，先來闡述一下 Flink 對一些大狀態的痛點。
第一，效率。效率問題在小狀態的時候是沒有問題的，效率很快，但當狀態達到 TB 級別，甚至幾十 TB，它的讀寫效率就會顯著下降，且狀態恢復任務的時間也比較長，通常需要幾十分鐘的時間。
第二，穩定性。Flink 的狀態越大，Checkpoint 的時間越長，這就會導致一些延遲的波動，也就會不滿足我們對於高時效的要求。
第三，靈活性。目前社群版 Flink 和商業版 Flink 都只提供了 TTL 這個清理策略，所以我們無法根據業務的一些特性，定製刪除這個狀態。
基於以上痛點，我們提出了狀態外接+冷熱分離的方案。對於大狀態的業務場景，我們會把狀態完全外接到 KV 資料庫裡，然後把 StateBackend 作為外接資料庫的快取。在快取裡 Flink 運算元與資料互動，優先讀取 StateBackend 的資料，當流式讀取讀不到的時候，才會走到外接的冷資料層，也就是外接的 KV 資料庫。這樣我們就可以儘量減少的訪問外部的資料庫了。
寫入的過程也是 StateBackend 流式寫入，但寫入冷資料層是 Batch 寫入。它雖然不能保證 StateBackend 和 KV 資料庫的狀態一致性，但我們的業務場景是 AtleastOnce 語義，可以在程式碼裡判斷它的業務邏輯，透過業務邏輯規避資料重複。
透過這個框架我們可以實現以下優勢。
- 可以支援更大 TB 級的大狀態。大狀態的大小取決於外接資料庫的儲存大小。
- 月週期級別的 TTL。這個 TTL 可以非常長，可能超過一個月，但它的效率比較高，因為 80%的資料都走到了快取層。
- 狀態可以查詢。比如你可以清晰的定位狀態的流轉變化，透過 SQL 語句查詢當前的狀態。另外，我們也可以容忍狀態丟失風險，比如 StateBackend 由於版本升級或者其他原因，它的狀態消失了，我們可以從 KV 資料庫無狀態重啟。
在實時訂閱場景中，我們需要對商家保證比較穩定，且延遲非常低的實時性體驗，這就要求我們需要保障任務的穩定性和延遲。在這個任務裡，我們的服務包括：
- 第一，按需計算，即只有開通或者訂購的商家才會做計算，這樣可以節省成本。
- 第二，商家開通功能後，需要實時看到資料，這就要求我們的訂閱邏輯也需要是實時的。
- 第三，我們需要保障今日新訂閱商家今日指標的完整性，不能從第二天才開始算。
所以，我們做了實時訂閱任務，保證任務的穩定性。
熱點商家業內俗稱資料傾斜。資料傾斜問題我們有兩種解法。
第一個最佳化是訂閱流的。我們把本來按照商家粒度聚合的資料打散成商家+訂單粒度來聚合。之前視為商家粒度，如果某個商家的資料非常大，它會分發到 TaskManager 下面的某一個 slot，導致 TaskManager 的 CPU 一直拉滿。這樣它就跑不下去了，延遲也會相應變高。做了打散最佳化後，可以讓所有的 TaskManager 同時觸發訂閱邏輯，任務的穩定性相對就提高了。
第二個最佳化，針對分攤任務中有主表和明細表關聯的時候，明細表可能出現了幾十萬條甚至上百萬條，主表和明細表關聯時的 Key 就會非常大。這時我們把時間視窗劃分為 3 秒一個視窗註冊定時器，透過定時器觸發分攤動作，限制單條訂單下最多 3 秒觸發一次分攤，有效緩解反壓問題。
四、對實時計算的未來展望
對於實時計算未來的展望，我們將圍繞流批一體、資料探勘、風控能力這幾個關鍵詞展開。
對於流批一體，我們希望找到能夠具體應用 Kappa 架構的場景，提高我們的資料複用性。對於標籤體系，當前還沒建設比較完整的標籤體系，未來會考慮在商家標籤或者商品標籤方面逐步建設，提高我們內部的運營能力。對於風控能力，我們當前已經有物流預警的風控產品，未來我們將擴充套件其他的業務場景，比如庫存預警、分銷價格預警等等，幫助商家解決資損問題。
更多內容
活動推薦
阿里雲基於 Apache Flink 構建的企業級產品-實時計算Flink版現開啟活動：
99 元試用 實時計算Flink版（包年包月、10CU）即有機會獲得 Flink 獨家定製衛衣；另包 3 個月及以上還有 85 折優惠！
瞭解活動詳情：https://www.aliyun.com/product/bigdata/sc
