流式圖計算在螞蟻大資料場景的應用

　　導讀：在大資料領域中，流式圖計算（Streaming Graph Processing）作為一種用於處理實時資料流的計算模型和技術，結合了圖計算和流式資料處理的概念，旨在處理資料流中的節點（vertices）和邊（edges）之間的關係，以實時分析、處理和理解不斷湧現的資料。螞蟻集團對於流式圖計算在實時資料處理與分析領域有較成熟的體系。

　　今天主要介紹螞蟻集團實時資料體系和關鍵技術、基於流式圖計算的實時流量歸因場景應用，以及基於流式圖計算在支付寶營銷場景實時 OLAP 和數金場景實時使用者行為意圖分析的探索。

　　 01 螞蟻實時資料整體介紹

　　首先介紹的是螞蟻集團實時大資料能力框架圖。

　　1. 螞蟻實時能力大圖　　

　　總體分基礎技術、實時核心能力、業務三個層次。基礎技術包含計算、儲存、訊息佇列等，今天重點分享的流式圖計算引擎就在這裡。實時核心能力自下向上依次是技術架構&研發正規化、資料資產、資料解決方案。技術架構&研發正規化包括“流批一體”、“湖倉一體”等架構，也包括針對不同業務情景的研發正規化和架構約束。技術架構之上是資產層，類似離線數倉我們為實時也構建了一套資產管理和治理體系。最上面是領域解決方案，面向類似業務場景提供一套通用的實時領域解決方案，比如營銷活動、實時風控等場景。基於這個能力大圖，逐漸實現以需求驅動為主向資料驅動業務發展的整體戰略目標轉化。

　　2. 螞蟻流批一體架構：從“物理”到“邏輯”程式碼的資料研發　　

　　這裡簡要介紹實時能力大圖中的“流批一體”。流批一體能力的應用指的是一種應用程式能夠同時處理實時資料流和批次資料的能力。換句話說，該應用能夠靈活地在實時情境下處理連續的資料流，也可以在一段時間內處理累積的資料批次。Apache Flink 和 Apache Spark 是兩個流行的分散式計算框架。這兩個框架都具有處理實時資料流和批處理資料的能力。

　　對於流批一體可以有兩個層面的理解：

　　從引擎角度：unified 引擎，它指的是一種引擎，在底層能夠統一處理流式資料和批處理資料。這意味著開發人員可以使用同一套引擎來處理不同型別的資料處理需求，而不需要切換或使用不同的引擎。

　　從業務研發角度：開發人員只需要編寫一套程式碼，就能夠處理實時資料流和批處理資料，這樣可以減少開發工作量，提高開發效率，並且更容易維護程式碼。

　　螞蟻的解決方案是在資料研發平臺層實現開發一套邏輯程式碼實現流批一體，並在此基礎上做了大量最佳化。比如程式碼裡可以根據“__source_type__“這些系統級別的關鍵詞（值為“bounded”和“unbounded”）進行不同位點和分割槽的流式和批式處理。

　　3. 螞蟻流式圖計算(TuGraph-Analytics)系統架構　　

　　螞蟻流式圖計算系統的整體框架包含了容器資源、流圖引擎與 API、資料應用，及計算控制後臺幾個層面，為實現高效的資料處理和分析提供了完整的架構。在該框架中，底層為強大的容器基礎設施，涵蓋了 Kubernetes（k8s）和Ray，為上層提供了可擴充套件性和資源管理。在此基礎上構建了流圖引擎，為資料流處理和分析提供核心支援，其中包括 GraphView API、Unified Graph Engine 和 Graph State。最上層則是流圖資料應用，涵蓋了轉化歸因、實時 OLAP、行為意圖等多個領域，同時展望未來的發展，計劃在廣告場景中引入鏈路診斷，以進一步提升系統的功能和價值。整個框架在資料處理的各個層面提供了一體化的解決方案，為實時資料處理和分析應用提供了強有力的支援。

　　 02 流式圖計算在實時流量歸因場景的應用

　　1. 流量轉化　　

　　左邊是一個流量轉化漏斗，指在數字營銷和業務運營中，透過不同階段的處理和轉化，將大量的潛在使用者或訪問者逐步引導、篩選，最終實現特定目標的過程。包括了公域到商傢俬域/行業陣地的流量分發、私域交易轉化、流量商業化變現幾個環節。從平臺視角，透過為商家進行流量引導、提升交易轉化，最終實現流量的商業化價值。

　　以使用者在支付寶的訪問為例，可以詳細介紹如何透過流量漏斗實現從公域流量到商傢俬域，再到交易轉化，最終實現商業化：

　　商傢俬域/行業陣地的流量分發： 典型的公域流量如在支付寶首頁空格、腰封的曝光。如何在公域流量場將合適的私域或行業內容分發推薦給使用者是個非常重要的課題。使用者可以透過點選入支付寶首頁的曝光內容跳轉到相應的小程式或承接頁面。在這個階段，可以透過精準的內容定位、個性化推送等方式，將使用者進一步引導到感興趣的領域，從而提高使用者的黏性和互動性。

　　私域交易轉化： 在商家的私域內，可以採取多種策略促使使用者進行轉化，例如訂閱、入會等。這些操作可以進一步深化使用者與商家之間的互動，建立使用者畫像，私域中的使用者已經顯示出一定的興趣和親近度，因此更容易進行交易轉化。

　　流量商業化變現： 一旦使用者完成交易轉化，平臺就達到了流量變現的目標，即透過使用者的付費行為實現商業化價值。

　　右邊是一個對應的廣告商業化的漏斗。從曝光到點選再到轉化，可以透過廣告中不同的 CPM（千次曝光）、CPC（點選）、CPA（動作）計費模式來實現流量的實時跟蹤與變現。

　　2. 流量轉化歸因模型　　

　　流量轉化歸因模型在數字營銷等場景中具有關鍵作用，它可以幫助分析和理解使用者在不同階段的行為對最終轉化（例如購買、註冊等）的貢獻，從而最佳化營銷策略和資源分配。這有助於瞭解使用者決策路徑、最佳化轉化率，以及對不同營銷渠道和策略進行評估和最佳化。

　　使用者路徑建模：客戶端上報的埋點資料將被用於構建使用者路徑模型，即使用者在整個流程中的行為路徑。這可以透過分析使用者在頁面之間的轉換關係來實現，整個過程會形成一個動態的路徑圖。

　　該模型包含以下節點：

　　路徑起點：轉化事件發生前最後一次進入支付寶首頁

　　裁剪點：從相同的頁面跳出又跳入，兩次跳入之間沒有發現轉化事件，中間日誌對轉化達成無效，可以剪裁

　　有效轉化節點：轉化主鏈路上的有效轉化日誌

　　無效轉化節點：轉化鏈路上的無效轉化日誌

　　路徑終點：轉化事件前的最後一條日誌

　　經過裁剪的最終轉化鏈路：A(1)->B(6)->F(7)->G(8)->H(9)

　　3. 實時流量轉化歸因整體技術架構　　

　　這是實時流量轉化歸因的整體技術架構，其中資料部分比較核心的是基於業務中間層的轉化事件定義（如交易支付、權益核銷等）和轉化資料模型的 Schema 歸一化。透過對不同轉化事件型別的 Schema 歸一化可以遮蔽不同業務的差異，便於下游消費使用。在此基礎上，透過邏輯檢視可以實現對不同業務場景分類消費的支援，大大提升了資料消費的效率。最後是基於流圖的轉化歸因計算，輸入是流量和轉化事件，輸出是轉化的歸因結果。

　　4. 基於流式圖計算的的實時流量轉化歸因　　

　　目前，使用者行為日誌主要以“訪問”和“點選”為主，“曝光”由於資料量大、上傳延遲高暫沒有使用。根據實時的使用者訪問行為日誌和使用者點選行為日誌透過流式圖計算引擎進行實時構圖，當轉化事件到達時進行歸因路徑計算，即根據流量轉化歸因模型從橙色節點（路徑起點）到綠色節點（路徑終點）的鏈路計算，最後將其結果輸出到下游的 MQ 和 OLAP。

　　該系統從使用者端到後端的資料採集時效已經達到五分鐘90%以上，十分鐘接近100%，已可以滿足絕大多數業務需求。

　　5. 實時流量轉化歸因資料鏈路　　

　　以上是實時生產過程中的實時轉化鏈路，上游主要有兩種資料來源，一種是客戶端埋點採集，一種是服務端資料採集（如服務端日誌、資料庫 binlog）。一般而言服務端資料採集實效性比較快，除了中介軟體的抖動，其上報速度在秒級。整個鏈路的主要延遲集中在流量上報環節和流圖計算環節，其中流量上報環節由於客戶端、網路等多種因素變數較大，而流圖計算環節則是可控的人為設定的等待時間視窗，因為實際的流量、轉化事件上傳不是嚴格有序及時上傳的，這個等待視窗大小的設定也要結合歸因的時效性和準確性綜合考慮權衡。最終這些資料會加工處理成 DWD 中間層供下游營銷等應用場景使用。

　　 03 流式圖計算在實時 OLAP 場景的探索

　　1. 後置計算　　

　　後置計算是流計算的一種研發模式。當前螞蟻實時計算以“前置計算”為主，正逐步發展成為包括“後置計算”在內的支援不同業務場景的“多模式計算”研發模式。

　　前置預計算模式：在資料進入 OLAP 系統之前，提前對部分計算進行處理，從而減輕後續計算的負擔，加速資料處理和分析過程。廣泛應用於大資料量，資料時效和查詢效能要求高的場景，如實時大屏。其優點為資料時效快，查詢效能高。其缺點為資料容錯性差，靈活性低。

　　前置打寬後置聚合：從 TP 到 AP 階段進行資料打寬，在 AP 階段進行聚合。其優點為靈活性適中，資料容錯高。缺點為查詢效能一般。因而適用於業務確定性比較高的場景，例如直播分析看板。

　　後置聚合：從 TP 到 AP 階段進行實時同步，儲存原始資料，其優點為靈活性較高，且資料容錯率高，但是查詢效能低。適用於業務不確定性比較高的場景，例如自助分析。

　　以實時特徵研發為例，基於後置計算模式後，新增特徵只需要在特徵平臺進行特徵檢視配置，無需為不同特徵加工建設不同的 Flink 實時任務，實時特徵研發效率得到極大提升。

　　2. 後置計算：基於流式圖計算在營銷實時 OLAP 場景的探索　　

　　接下來介紹支付寶營銷場景後置計算的一個案例，即流式圖計算在實時 OLAP 場景的探索。採用流圖進行後置計算後，在資料模型和研發模式上都發生了比較大的變化。

　　資料模型方面，過去在我們完成基礎的 ODS、DWD 建設後，隨著時間和複雜度的增加，ADM 應用層的數量會急劇上升（各種維度的指標報表），這給開發和運維工作都帶來了極大壓力。採用流圖後，基於使用者去做圖建模，將權益和玩法等業務層面與使用者本身建立關係，形成一個圖關係網，再進行後置分析。

　　研發模式方面，經典的研發模式是指標需求驅動研發，先採集上游資料，形成維度等中間表，再根據不同的場景去計算對應需求的指標。這個模型的缺點是對於內部運營非常態化需求的指標資料而言，浪費了前置計算量。基於流圖的後置計算可以有效的避免這個浪費，只有業務有需求需要檢視資料時，才進行計算，即保證了資料時效性也避免了計算浪費。除此之外，模型的靈活性比較高，對於臨時增加計算節點和指標等行為的代價比較小。總而言之，後置流圖計算更符合如今高複雜度，高靈活性需求的應用場景。

　　流式計算引擎與傳統基於 OLAP 的引擎內測對比發現，對於單表場景，流式計算引擎效能稍顯遜色，但是多表關聯場景，其效能明顯優於基於 OLAP 的引擎。

　　 04 流式圖計算在實時使用者行為意圖分析場景的探索　　

　　另一個我們基於流式圖計算的探索是在數字金融領域，在財富場景進行的使用者行為意圖分析。以前，我們對使用者行為意圖的分析主要是使用一維的使用者行為特徵或者二維的使用者行為序列。類似上面提到的流量轉化歸因的例子，使用者實際的行為是複雜多變的、噪音較多，傳統的資料模型在意圖識別準確度，尤其是大規模資料的精準意圖識別上還存在比較大的挑戰。

　　上圖透過對使用者行為意圖的實時構圖及對不同節點意圖分的計算，得到使用者最有可能感興趣的產品。比如使用者在進入支付寶理財 tab 頁，可能在不同的頁面（如引導、承接、交易）訪問了不同的基金產品，這其中結合基金產品的 spm 和訪問次數會計算一個意圖分，並綜合整個路徑中不同意圖分的情況得到一個使用者最可能交易的意圖節點。另一方面，基於這些使用者偏好的產品節點，可以進一步推演出使用者感興趣的產品類目，基於這些資料可以實現更豐富的推廣營銷。

　　基於流圖可以實現更加快速精準識別使用者行為意圖，與傳統的推薦演算法不同，作為一個實時資料方案，它具備高時效性、過程白盒化、可人工干預擴充套件節點、消除噪音意圖識別更精準、後置計算效率更高等特點。

　　 05 未來展望

　　展望未來主要包括以下這些：

　　基於流圖的實時 OLAP 在營銷場景的推廣應用

　　基於流圖的實時使用者行為意圖分析在數金、內容等場景的推廣應用

　　基於流圖的實時歸因能力在廣告鏈路診斷場景的應用探索

　　流圖開源專案的貢獻參與