上雲節省 35%計算資源，420 個運維人天：運滿滿實時計算實踐和思考

摘要：本文整理自滿幫實時資料團隊 TL 歐銳，在 FFA 2022 行業案例專場的分享。本篇內容主要分為四個部分：
滿幫業務及平臺架構介紹
實時資料
實時產品
未來計劃

一、滿幫業務及平臺架構介紹

滿幫集團全心全意幫助司機和貨主，助力物流降本增效，利用移動網際網路、大資料、人工智慧等新技術，打造智慧物流生態平臺，提升“車找貨、貨找車”的智慧化和標準化，改變傳統物流行業“小、亂、散、弱”的狀況。旗下運滿滿貨運平臺一站式解決貨運全鏈路問題，百萬司機一秒響應。

滿幫實時資料矩陣圖

滿幫的實時資料矩陣圖主要採用了雲原生和 OLAP 平臺的架構，主要採用了阿里雲 Flink+Hologres 的應用架構。在實時數倉層面，建設了使用者、貨源、流量、支付、交易、營銷以及 CRM 基礎層，同時還建設了我們特有的數倉分層，叫實時供需層，相當於傳統公司的 ADM 層。在這一層我們建設了線路司機分佈情況、沿途貨源分佈情況、二級貨類分佈情況、實時離線供需融合情況以及每個出發城市或者線路沿途的疫情和天氣情況。

在數倉上我們還往前更近了一層，做了實時特徵。基於分鐘級或者秒級的實時數倉去做資料，快速高效的賦能給演算法和運營業務。包括司機和貨主的行為特徵、司機行為機率分佈、貨源行為狀態分佈、路線貨源價格分佈。同時，我們團隊在實時策略上也做了相應開發，比如說司機有拼單的意願，或者說司機有漫遊行為、人群流量實時預測、Push 流量實時預測和分配。

關於為了滿足實時業務的實時資料產品，它和離線數倉有一個本質區別，就是實時資料需要更多直接觸達業務。那麼我們怎麼去定義實時資料產品呢？我們想把它變成一個實時的決策平臺，包含如下幾個環節：

第一步是資料洞察;

第二步是智慧歸因;

第三步是實時預警，指標歸因出來後把資料告警給相關的業務方;

第四步是人群畫像，指在告警時，需要把相關人群的畫像主動勾勒出來;

第五步透過高效的 OLAP 和 Flink 計算開發一條簡單的策略;

然後匯入到規則引擎，讓演算法和運營來調取;

最後透過 A/B 效果完成整個決策平臺的產品構建。

線上實時決策平臺和底層數倉，主要的服務物件包含頁面排序、搜尋排序、智慧召回、Push 收歸、司機會員、委託定價等權益或價格的策略，實時決策基本上都用到了實時特徵和實時資料。

在做實時資料的時候，我們思考了三個維度。第一是價值。我們需要去理解和洞察業務，然後透過實時決策平臺賦能業務。第二是閉環，我們不僅只是把資料做到位，還需要考慮整個業務的閉環效果。第三是成本，主要是基於價值去衡量 ROI，如果投入與產出不成正比，我們就需要在成本上相對收斂一些。

滿幫實時計算平臺架構

接下來分享一下滿幫實時計算平臺的架構。滿幫的資料分佈在不同的機房，當然也分佈在不同的雲廠商。從下圖可以看到 A 機房主要是生產系統和實時計算，B 機房主要是離線機房，即離線叢集。

在這種資料架構下做實時資料的全鏈路能力，我們做了如下幾件事：

我們做了全鏈路穩定性建設。資料來源到最上游的資料消費做到分鐘級，即一分鐘、十幾秒甚至幾秒鐘，業務系統就要消費到底層傳來的資料。

我們在實時計算資料來源上進行了穩定性治理。在前端埋點採用了業內比較領先的架構，後端埋點在一些關鍵的業務點上進行了一些打點，讓資料可以做到秒級到達實時資料倉儲。

我們統一了資料標準。在資料來源治理完後，把所有的實時資料放到一個資料匯流排裡，保證實時資料的消費是統一資料標準。

我們曾經採用過傳統的 Doris 和自建的一些架構，但發現運維成本都相對比較高，所以最終採用了阿里的 Hologres 叢集。

我們要做一個完整的資料服務生態圈。在把資料賦能到業務方和呼叫方的時候，我們需要提供一些 API 和訊息佇列。這裡我們吸收了阿里雲 OneService 的建設思路，構建了一個統一資料服務。

我們和演算法平臺一起做了實時樣本歸因平臺，同時配合他們做了一個實時訓練的框架，保證演算法和運營的實時決策。

從自建 Flink 到遷移雲原生的阿里雲實時計算 Flink 版平臺降本增效

以上是實時計算平臺架構的分享，接下來分享一下，我們從自建的 Flink 遷移到雲原生的阿里雲實時計算 Flink 版平臺的原因。原有自建叢集上執行實時作業穩定性差，嚴重影響業務，自建整體運維成本較高，需要將重心從平臺建設向業務最佳化傾斜，技術發展路線從開源自建向託管雲服務遷移。具體如下：

第一點，阿里雲實時計算 Flink 版平臺採用了雲原生全託管架構，部署、資源隔離在上面都具有天然的架構先進性，CU 級別智慧彈性擴縮容有效提升價效比。

第二點，我們在自己搭建 Flink on Yarn 的時候，發現底層的資源隔離和資源之間的影響有很大的波動性，阿里雲實時計算 Flink 版平臺的雲原生資源隔離能力可以實現作業級和程式碼級的隔離，減少互相影響，技術領先性創造平臺穩定性。

第三點，阿里雲實時計算 Flink 版開發平臺，它的 metrics 採集系統、SQL 開發、資源調優明顯改善開發效率，運維工作量和成本顯著降低。

下面我們來看一下，下半年把運滿滿的整個實時計算 Flink 任務全部遷移到阿里雲，收益是怎麼樣的？

我們遷移的 Flink 任務有 560 個，遷移時間僅需 1.5 個月。遷移過後，經過一段時間的觀察，我們發現 SLA 的指標從 95%提升到了 99%。另外在運維人效方面，從原來的三個人到現在的一個人，全年節約了 420 人天。

在開發的效率方面，每個任務的開發、調優、上線可以提前兩天。如果按照每年 300 個任務，就是節省了 600 人天。最後基於阿里雲對 Flink SQL 和底層 state 狀態的深度最佳化，我們發現平均一個 Flink SQL 任務消耗 6.67CU 的資源，而上了阿里雲過後，可以節省 40%的資源。這樣算下來，整體可以達到 35%的資源節省。

二、實時資料

目前我們使用阿里雲 Flink+Hologres 這套架構來基於分鐘級或者秒級的實時數倉去做資料，快速高效的賦能給演算法和運營業務。包括司機和貨主的行為特徵、司機行為機率分佈、貨源行為狀態分佈、路線貨源價格分佈等。應用場景主要分成兩個部分。第一部分是特徵計算，第二部分是樣本歸因。樣本歸因即把使用者的行為資料、特徵資料、迴流資料關聯起來。

我們採用這套架構的原因是，Hologres 支援讀寫分離和實時數倉，其中讀寫分離的效能給我們帶來很大的收益。另外我們在做特徵的二次計算時，也採用了阿里雲 Flink+Hologres 的最佳實踐，實時計算 Flink 版在實時作業的穩定性上給了我們很大的驚喜，同時定時調優的策略使得資源效率顯著提高，很好的為實時決策提供了資料支撐。

從實時資料到實時決策

實時決策包含兩部分，分別是在演算法場景的實時決策、在運營場景的實時決策。下面先分享一些我們怎麼用實時資料決策演算法場景。

在一個傳統的推薦演算法鏈路上，它的鏈條是相對比較長的。司機從 APP 進行搜尋，然後經過 AB 流、子場景、召回、粗排、截斷、精排，最後到實時策略。其中召回的環節，可能會帶來千條的資料，所以要透過後邊的環節逐步減少資料量。

從下圖可以看到，AB 分流到實時策略的過程需要實時指標把它們串聯起來，實時指標的資料在 AB 分流、召回、粗排、截斷、精排等環節都會被用到。另外在精排的時候，用分鐘級模型也要用到實時指標的資料。所以要理解實時資料的決策，首先要理解實時資料對每一個演算法子模組的作用。

接下來我們思考一個問題，要怎麼去推導實時資料問題定義、目標、策略和價值呢？

首先，如果我們在演算法場景用實時資料賦能業務，需要考慮以下三個方面：

系統實時性，需要實時獲取最新的模型和資料。

特徵實時性，需要實時獲取資料的分佈。

模型實時性，需要保證實時擬合資料的分佈。

然後我們需要確定子目標，確保特徵的更實時、模型的更實時、樣本的更實時。我們給自己定義的目標是，第一計算延遲全鏈路小於 3 分鐘，關鍵點鏈路要做到 10 秒甚至 20 秒；第二整體資料延遲小於 5 分鐘；第三樣本準確率大於 97%。

接下來制定策略。在計算延遲方面，我們採用阿里雲 Flink+OLAP。在資料低延方面，需要考慮樣本延遲、特徵延遲、全鏈路延遲監控、資料治理、鏈路最佳化。在樣本準確率方面，除了使用傳統的一些樣本技術，我們還需要注意樣本資料質量監控和模型效果線上監控。我們採用了阿里雲 Flink+Hologres 這套架構。

最後明確價值。在業務價值方面，基於搜尋天模型基礎，有 3%業務的提升。技術價值方面，積累沉澱實時特徵模型，提升演算法模型更新時效性，賦能演算法業務，服務不同特色演算法場景；打通增量學習全鏈路，為增量學習平臺打下技術基礎。

具備實時特徵計算的實時數倉建設

下面分享基於阿里雲 Flink+Hologres 實現的實時數倉的建設。我們的數倉是以位置關係、運力、供需三個維度為核心，進行雙向推導和抽象。和一般的物流公司差不多，我們的實時基礎資料也都包含使用者、貨源、車輛、流量、交易、車油、金融、風控。但我們更關注的其實是司機和貨主的位置狀態，因為這決定了我們的匹配效率，所以我們的實時數倉和傳統的離線數倉有很大不一樣。

我們基於位置構建了一套實時數倉，由於業務決策的實時必要性，產生了對資料的實時性要求，因此我們在構建數倉時，資料一部分透過 Flink CDC 同步到 Hologres，實時入倉，一部分經過實時計算後落到數倉中，形成一體化分析服務。透過位置把貨源、車輛、使用者、交易、流量、營銷等資料關聯起來。另外我們還需要深入業務，在車貨匹配、定價決策、排程決策、供需監控、客服決策等方面，實時做決策。

但在這一過程中，業務使用還是會和數倉之間有一層 Gap。

實時數倉對業務的抽象度不夠，要怎麼辦？

實時數倉到底能給業務帶來什麼價值？怎麼度量？

實時資料怎麼挖掘特有業務的指標和特徵？所以我們抽象了一個實時供需引擎。

換句話來說就是在業務和實時數倉上，抽象了一個虛擬的產品層供業務使用。我們在數倉建設的時候進行了兩次抽象。第一次抽象是自下而上，抽象出一個實時數倉。第二次抽象是也是自下而上，抽象出一個供需引擎。

建設實時數倉過後，我們還在進行了實時特徵和實時指標的開發。在這一過程中我們發現，對接業務的時候，我們往往很被動。客戶提出一個需求，我們就逐步去開發，這樣往往會花費大量的時間。

比如業務提出了一個需求，資料的同學就需要大概 8 天的時間去做架構設計和資料開發。等把特徵開發完後，演算法同學還要進行資料的迴流和模型訓練及驗證，這個過程又需要大概 10 天左右。整個過程需要 20 天甚至一個月才能全鏈路上線。

那麼怎樣才能提高整個鏈路的開發和迭代效率呢？

我們做了一個批次實時特徵計算框架。舉個例子，在我們的環境中，有一個點選資料需要根據演算法不同的時間時間維度去看。有的演算法要求 5 分鐘，有的演算法要求 1 個小時，有的演算法要求 10 秒，這個時間是無法預估的，在演算法上線之前我們無法知道哪一個時間緯度對它最有效。

除此之外，還需要看每次點選次數的分位數、近 5 分鐘的分佈、排名、近 5 分鐘排名 log、group by 的狀態、daytime 分桶特徵等等。在前面基礎上我們還會做一些交叉特徵，比如減去常有的平均次數，當天天氣情況和當前疫情情況等。所以使用者提出一個資料的背後其實隱含了很多特徵。

我們採用了一套阿里雲實時計算Flink 版架構，來確保使用者提出資料後，能盡最大可能滿足業務需求。用 Window 的滑動視窗、滾動視窗保證可以做到時間上的切片和滑動。sum 代表計算，我們可以做 5 分鐘、10 分鐘、30 分鐘的開發計算。然後透過 function 呼叫計算函式，自動計算出實時特徵。function 定義的函式包括 log、ration、cnt、dayCategory 等。

在做了這套計算框架後，我們在研發效率上有明顯提升，支撐特徵批次開發，開發週期從 3 天降低到 2 天，目前還在大規模的推廣，我們目標是從 3 天降低到 0.5 天。資源利用方面，我們把 120 個任務合併成 16 個，資源消耗減少 200 Core 資源。在效能和穩定性方面，我們每分鐘計算出 1000+特徵，且任務保持穩定執行。值得一提的是，如此龐大的計算得益於阿里雲實時計算Flink版雲上能力的不斷更新，比如將類似 Window table-valued 函式增強、CAST 和型別系統增強、雙流 Join 運算元支援自動推導開啟 KV 分離最佳化等，能力完善的同時作業執行效能顯著提高，對業務決策進行了有力的支撐。

三、實時產品

解決了實時資料的問題，我們在實時數倉的基礎之上，構建了以實時線上決策系統為核心定位的產品，以實時預警作為出發點開始，目前我們做了以下這些事。

第一個是實時指標告警平臺烽火臺，它的作用是解決實時指標的展示和告警。從下圖中右邊的視窗可以看到，我們可以透過實時指標烽火臺把使用者關心的指標展示出來；從右邊的視窗可以看到，還可以對指標進行配置告警，主動觸達業務告警。

第二個是實時資料服務平臺，它的作用是解決實時資料服務能力。當業務方需要呼叫資料時，我們不能直接吐到它的訊息佇列裡，所以希望有一套 API 介面或者一套服務來解決它呼叫我們資料的問題。因此我們和離線數倉共用一套 OneService，然後把我們提供的資料服務展示在一個資料超市裡。業務方只需要透過一些簡單的配置，就能生成 API，供使用者直接呼叫，最後進行計費。

四、未來計劃

2006 年我們上了 Hadoop；2018-2019 主要以 Spark Streaming 為主；2020 年上了 Flink DataStream；2021 年上了實時數倉和 Flink SQL；2022 年，我們搭建了實時特徵、實時服務、烽火臺；2022 年 Q4 我們將 Flink 遷移到了阿里雲上，升級了特徵平臺，還對實時決策平臺進行了初步構造。

2023 年，我們將把實時資料和業務進行更深度的融合，做實時決策平臺 2.0；探索 Flink on AI 並大規模使用。除此之外，我們還會基於阿里雲 Hologres 和別的雲廠商產品，去構建我們自己的跨雲 OLAP 引擎平臺。

點選檢視直播回放 & 演講PPT