在大數(shù)據(jù)領(lǐng)域中，流式圖計算（Streaming Graph Processing）作為一種用于處理實(shí)時數(shù)據(jù)流的計算模型和技術(shù)，結(jié)合了圖計算和流式數(shù)據(jù)處理的概念，旨在處理數(shù)據(jù)流中的節(jié)點(diǎn)（vertices）和邊（edges）之間的關(guān)系，以實(shí)時分析、處理和理解不斷涌現(xiàn)的數(shù)據(jù)。螞蟻集團(tuán)對于流式圖計算在實(shí)時數(shù)據(jù)處理與分析領(lǐng)域有較成熟的體系。今天主要介紹螞蟻集團(tuán)實(shí)時數(shù)據(jù)體系和關(guān)鍵技術(shù)、基于流式圖計算的實(shí)時流量歸因場景應(yīng)用，以及基于流式圖計算在支付寶營銷場景實(shí)時 OLAP 和數(shù)金場景實(shí)時用戶行為意圖分析的探索。

一、螞蟻實(shí)時數(shù)據(jù)整體介紹

首先介紹的是螞蟻集團(tuán)實(shí)時大數(shù)據(jù)能力框架圖。

1、螞蟻實(shí)時能力大圖

總體分基礎(chǔ)技術(shù)、實(shí)時核心能力、業(yè)務(wù)三個層次?；A(chǔ)技術(shù)包含計算、存儲、消息隊列等，今天重點(diǎn)分享的流式圖計算引擎就在這里。實(shí)時核心能力自下向上依次是技術(shù)架構(gòu)&研發(fā)范式、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)解決方案。技術(shù)架構(gòu)&研發(fā)范式包括“流批一體”、“湖倉一體”等架構(gòu)，也包括針對不同業(yè)務(wù)情景的研發(fā)范式和架構(gòu)約束。技術(shù)架構(gòu)之上是資產(chǎn)層，類似離線數(shù)倉我們?yōu)閷?shí)時也構(gòu)建了一套資產(chǎn)管理和治理體系。最上面是領(lǐng)域解決方案，面向類似業(yè)務(wù)場景提供一套通用的實(shí)時領(lǐng)域解決方案，比如營銷活動、實(shí)時風(fēng)控等場景?；谶@個能力大圖，逐漸實(shí)現(xiàn)以需求驅(qū)動為主向數(shù)據(jù)驅(qū)動業(yè)務(wù)發(fā)展的整體戰(zhàn)略目標(biāo)轉(zhuǎn)化。

2、螞蟻流批一體架構(gòu)：從“物理”到“邏輯”代碼的數(shù)據(jù)研發(fā)

這里簡要介紹實(shí)時能力大圖中的“流批一體”。流批一體能力的應(yīng)用指的是一種應(yīng)用程序能夠同時處理實(shí)時數(shù)據(jù)流和批量數(shù)據(jù)的能力。換句話說，該應(yīng)用能夠靈活地在實(shí)時情境下處理連續(xù)的數(shù)據(jù)流，也可以在一段時間內(nèi)處理累積的數(shù)據(jù)批次。Apache Flink 和 Apache Spark 是兩個流行的分布式計算框架。這兩個框架都具有處理實(shí)時數(shù)據(jù)流和批處理數(shù)據(jù)的能力。

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

從引擎角度：unified 引擎，它指的是一種引擎，在底層能夠統(tǒng)一處理流式數(shù)據(jù)和批處理數(shù)據(jù)。這意味著開發(fā)人員可以使用同一套引擎來處理不同類型的數(shù)據(jù)處理需求，而不需要切換或使用不同的引擎。

從業(yè)務(wù)研發(fā)角度：開發(fā)人員只需要編寫一套代碼，就能夠處理實(shí)時數(shù)據(jù)流和批處理數(shù)據(jù)，這樣可以減少開發(fā)工作量，提高開發(fā)效率，并且更容易維護(hù)代碼。

螞蟻的解決方案是在數(shù)據(jù)研發(fā)平臺層實(shí)現(xiàn)開發(fā)一套邏輯代碼實(shí)現(xiàn)流批一體，并在此基礎(chǔ)上做了大量優(yōu)化。比如代碼里可以根據(jù)“__source_type__“這些系統(tǒng)級別的關(guān)鍵詞（值為“bounded”和“unbounded”）進(jìn)行不同位點(diǎn)和分區(qū)的流式和批式處理。

3、螞蟻流式圖計算(TuGraph-Analytics)系統(tǒng)架構(gòu)

螞蟻流式圖計算系統(tǒng)的整體框架包含了容器資源、流圖引擎與 API、數(shù)據(jù)應(yīng)用，及計算控制后臺幾個層面，為實(shí)現(xiàn)高效的數(shù)據(jù)處理和分析提供了完整的架構(gòu)。在該框架中，底層為強(qiáng)大的容器基礎(chǔ)設(shè)施，涵蓋了 Kubernetes（k8s）和Ray，為上層提供了可擴(kuò)展性和資源管理。在此基礎(chǔ)上構(gòu)建了流圖引擎，為數(shù)據(jù)流處理和分析提供核心支持，其中包括 GraphView API、Unified Graph Engine 和 Graph State。最上層則是流圖數(shù)據(jù)應(yīng)用，涵蓋了轉(zhuǎn)化歸因、實(shí)時 OLAP、行為意圖等多個領(lǐng)域，同時展望未來的發(fā)展，計劃在廣告場景中引入鏈路診斷，以進(jìn)一步提升系統(tǒng)的功能和價值。整個框架在數(shù)據(jù)處理的各個層面提供了一體化的解決方案，為實(shí)時數(shù)據(jù)處理和分析應(yīng)用提供了強(qiáng)有力的支持。

二、流式圖計算在實(shí)時流量歸因場景的應(yīng)用

1、流量轉(zhuǎn)化

左邊是一個流量轉(zhuǎn)化漏斗，指在數(shù)字營銷和業(yè)務(wù)運(yùn)營中，通過不同階段的處理和轉(zhuǎn)化，將大量的潛在用戶或訪問者逐步引導(dǎo)、篩選，最終實(shí)現(xiàn)特定目標(biāo)的過程。包括了公域到商家私域/行業(yè)陣地的流量分發(fā)、私域交易轉(zhuǎn)化、流量商業(yè)化變現(xiàn)幾個環(huán)節(jié)。從平臺視角，通過為商家進(jìn)行流量引導(dǎo)、提升交易轉(zhuǎn)化，最終實(shí)現(xiàn)流量的商業(yè)化價值。

以用戶在支付寶的訪問為例，可以詳細(xì)介紹如何通過流量漏斗實(shí)現(xiàn)從公域流量到商家私域，再到交易轉(zhuǎn)化，最終實(shí)現(xiàn)商業(yè)化：

商家私域/行業(yè)陣地的流量分發(fā)：典型的公域流量如在支付寶首頁空格、腰封的曝光。如何在公域流量場將合適的私域或行業(yè)內(nèi)容分發(fā)推薦給用戶是個非常重要的課題。用戶可以通過點(diǎn)擊入支付寶首頁的曝光內(nèi)容跳轉(zhuǎn)到相應(yīng)的小程序或承接頁面。在這個階段，可以通過精準(zhǔn)的內(nèi)容定位、個性化推送等方式，將用戶進(jìn)一步引導(dǎo)到感興趣的領(lǐng)域，從而提高用戶的黏性和互動性。

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

流量商業(yè)化變現(xiàn)：一旦用戶完成交易轉(zhuǎn)化，平臺就達(dá)到了流量變現(xiàn)的目標(biāo)，即通過用戶的付費(fèi)行為實(shí)現(xiàn)商業(yè)化價值。

右邊是一個對應(yīng)的廣告商業(yè)化的漏斗。從曝光到點(diǎn)擊再到轉(zhuǎn)化，可以通過廣告中不同的 CPM（千次曝光）、CPC（點(diǎn)擊）、CPA（動作）計費(fèi)模式來實(shí)現(xiàn)流量的實(shí)時跟蹤與變現(xiàn)。

2、流量轉(zhuǎn)化歸因模型

流量轉(zhuǎn)化歸因模型在數(shù)字營銷等場景中具有關(guān)鍵作用，它可以幫助分析和理解用戶在不同階段的行為對最終轉(zhuǎn)化（例如購買、注冊等）的貢獻(xiàn)，從而優(yōu)化營銷策略和資源分配。這有助于了解用戶決策路徑、優(yōu)化轉(zhuǎn)化率，以及對不同營銷渠道和策略進(jìn)行評估和優(yōu)化。

用戶路徑建模：客戶端上報的埋點(diǎn)數(shù)據(jù)將被用于構(gòu)建用戶路徑模型，即用戶在整個流程中的行為路徑。這可以通過分析用戶在頁面之間的轉(zhuǎn)換關(guān)系來實(shí)現(xiàn)，整個過程會形成一個動態(tài)的路徑圖。

該模型包含以下節(jié)點(diǎn)：

路徑起點(diǎn)：轉(zhuǎn)化事件發(fā)生前最后一次進(jìn)入支付寶首頁

裁剪點(diǎn)：從相同的頁面跳出又跳入，兩次跳入之間沒有發(fā)現(xiàn)轉(zhuǎn)化事件，中間日志對轉(zhuǎn)化達(dá)成無效，可以剪裁

有效轉(zhuǎn)化節(jié)點(diǎn)：轉(zhuǎn)化主鏈路上的有效轉(zhuǎn)化日志

無效轉(zhuǎn)化節(jié)點(diǎn)：轉(zhuǎn)化鏈路上的無效轉(zhuǎn)化日志

路徑終點(diǎn)：轉(zhuǎn)化事件前的最后一條日志

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

3、實(shí)時流量轉(zhuǎn)化歸因整體技術(shù)架構(gòu)

這是實(shí)時流量轉(zhuǎn)化歸因的整體技術(shù)架構(gòu)，其中數(shù)據(jù)部分比較核心的是基于業(yè)務(wù)中間層的轉(zhuǎn)化事件定義（如交易支付、權(quán)益核銷等）和轉(zhuǎn)化數(shù)據(jù)模型的 Schema 歸一化。通過對不同轉(zhuǎn)化事件類型的 Schema 歸一化可以屏蔽不同業(yè)務(wù)的差異，便于下游消費(fèi)使用。在此基礎(chǔ)上，通過邏輯視圖可以實(shí)現(xiàn)對不同業(yè)務(wù)場景分類消費(fèi)的支持，大大提升了數(shù)據(jù)消費(fèi)的效率。最后是基于流圖的轉(zhuǎn)化歸因計算，輸入是流量和轉(zhuǎn)化事件，輸出是轉(zhuǎn)化的歸因結(jié)果。

4、基于流式圖計算的的實(shí)時流量轉(zhuǎn)化歸因

目前，用戶行為日志主要以“訪問”和“點(diǎn)擊”為主，“曝光”由于數(shù)據(jù)量大、上傳延遲高暫沒有使用。根據(jù)實(shí)時的用戶訪問行為日志和用戶點(diǎn)擊行為日志通過流式圖計算引擎進(jìn)行實(shí)時構(gòu)圖，當(dāng)轉(zhuǎn)化事件到達(dá)時進(jìn)行歸因路徑計算，即根據(jù)流量轉(zhuǎn)化歸因模型從橙色節(jié)點(diǎn)（路徑起點(diǎn)）到綠色節(jié)點(diǎn)（路徑終點(diǎn)）的鏈路計算，最后將其結(jié)果輸出到下游的 MQ 和 OLAP。

該系統(tǒng)從用戶端到后端的數(shù)據(jù)采集時效已經(jīng)達(dá)到五分鐘90%以上，十分鐘接近100%，已可以滿足絕大多數(shù)業(yè)務(wù)需求。

5、實(shí)時流量轉(zhuǎn)化歸因數(shù)據(jù)鏈路

以上是實(shí)時生產(chǎn)過程中的實(shí)時轉(zhuǎn)化鏈路，上游主要有兩種數(shù)據(jù)源，一種是客戶端埋點(diǎn)采集，一種是服務(wù)端數(shù)據(jù)采集（如服務(wù)端日志、數(shù)據(jù)庫 binlog）。一般而言服務(wù)端數(shù)據(jù)采集實(shí)效性比較快，除了中間件的抖動，其上報速度在秒級。整個鏈路的主要延遲集中在流量上報環(huán)節(jié)和流圖計算環(huán)節(jié)，其中流量上報環(huán)節(jié)由于客戶端、網(wǎng)絡(luò)等多種因素變量較大，而流圖計算環(huán)節(jié)則是可控的人為設(shè)定的等待時間窗口，因為實(shí)際的流量、轉(zhuǎn)化事件上傳不是嚴(yán)格有序及時上傳的，這個等待窗口大小的設(shè)定也要結(jié)合歸因的時效性和準(zhǔn)確性綜合考慮權(quán)衡。最終這些數(shù)據(jù)會加工處理成 DWD 中間層供下游營銷等應(yīng)用場景使用。

三、流式圖計算在實(shí)時 OLAP 場景的探索

1、后置計算

后置計算是流計算的一種研發(fā)模式。當(dāng)前螞蟻實(shí)時計算以“前置計算”為主，正逐步發(fā)展成為包括“后置計算”在內(nèi)的支持不同業(yè)務(wù)場景的“多模式計算”研發(fā)模式。

前置預(yù)計算模式：在數(shù)據(jù)進(jìn)入 OLAP 系統(tǒng)之前，提前對部分計算進(jìn)行處理，從而減輕后續(xù)計算的負(fù)擔(dān)，加速數(shù)據(jù)處理和分析過程。廣泛應(yīng)用于大數(shù)據(jù)量，數(shù)據(jù)時效和查詢性能要求高的場景，如實(shí)時大屏。其優(yōu)點(diǎn)為數(shù)據(jù)時效快，查詢性能高。其缺點(diǎn)為數(shù)據(jù)容錯性差，靈活性低。

前置打?qū)捄笾镁酆希?/strong>從 TP 到 AP 階段進(jìn)行數(shù)據(jù)打?qū)?，?AP 階段進(jìn)行聚合。其優(yōu)點(diǎn)為靈活性適中，數(shù)據(jù)容錯高。缺點(diǎn)為查詢性能一般。因而適用于業(yè)務(wù)確定性比較高的場景，例如直播分析看板。

后置聚合：從 TP 到 AP 階段進(jìn)行實(shí)時同步，保存原始數(shù)據(jù)，其優(yōu)點(diǎn)為靈活性較高，且數(shù)據(jù)容錯率高，但是查詢性能低。適用于業(yè)務(wù)不確定性比較高的場景，例如自助分析。

以實(shí)時特征研發(fā)為例，基于后置計算模式后，新增特征只需要在特征平臺進(jìn)行特征視圖配置，無需為不同特征加工建設(shè)不同的 Flink 實(shí)時任務(wù)，實(shí)時特征研發(fā)效率得到極大提升。

2、后置計算：基于流式圖計算在營銷實(shí)時 OLAP 場景的探索

接下來介紹支付寶營銷場景后置計算的一個案例，即流式圖計算在實(shí)時 OLAP 場景的探索。采用流圖進(jìn)行后置計算后，在數(shù)據(jù)模型和研發(fā)模式上都發(fā)生了比較大的變化。

數(shù)據(jù)模型方面，過去在我們完成基礎(chǔ)的 ODS、DWD 建設(shè)后，隨著時間和復(fù)雜度的增加，ADM 應(yīng)用層的數(shù)量會急劇上升（各種維度的指標(biāo)報表），這給開發(fā)和運(yùn)維工作都帶來了極大壓力。采用流圖后，基于用戶去做圖建模，將權(quán)益和玩法等業(yè)務(wù)層面與用戶本身建立關(guān)系，形成一個圖關(guān)系網(wǎng)，再進(jìn)行后置分析。

研發(fā)模式方面，經(jīng)典的研發(fā)模式是指標(biāo)需求驅(qū)動研發(fā)，先采集上游數(shù)據(jù)，形成維度等中間表，再根據(jù)不同的場景去計算對應(yīng)需求的指標(biāo)。這個模型的缺點(diǎn)是對于內(nèi)部運(yùn)營非常態(tài)化需求的指標(biāo)數(shù)據(jù)而言，浪費(fèi)了前置計算量?；诹鲌D的后置計算可以有效的避免這個浪費(fèi)，只有業(yè)務(wù)有需求需要查看數(shù)據(jù)時，才進(jìn)行計算，即保證了數(shù)據(jù)時效性也避免了計算浪費(fèi)。除此之外，模型的靈活性比較高，對于臨時增加計算節(jié)點(diǎn)和指標(biāo)等行為的代價比較小。總而言之，后置流圖計算更符合如今高復(fù)雜度，高靈活性需求的應(yīng)用場景。

流式計算引擎與傳統(tǒng)基于 OLAP 的引擎內(nèi)測對比發(fā)現(xiàn)，對于單表場景，流式計算引擎性能稍顯遜色，但是多表關(guān)聯(lián)場景，其性能明顯優(yōu)于基于 OLAP 的引擎。

四、流式圖計算在實(shí)時用戶行為意圖分析場景的探索

另一個我們基于流式圖計算的探索是在數(shù)字金融領(lǐng)域，在財富場景進(jìn)行的用戶行為意圖分析。以前，我們對用戶行為意圖的分析主要是使用一維的用戶行為特征或者二維的用戶行為序列。類似上面提到的流量轉(zhuǎn)化歸因的例子，用戶實(shí)際的行為是復(fù)雜多變的、噪音較多，傳統(tǒng)的數(shù)據(jù)模型在意圖識別準(zhǔn)確度，尤其是大規(guī)模數(shù)據(jù)的精準(zhǔn)意圖識別上還存在比較大的挑戰(zhàn)。

上圖通過對用戶行為意圖的實(shí)時構(gòu)圖及對不同節(jié)點(diǎn)意圖分的計算，得到用戶最有可能感興趣的產(chǎn)品。比如用戶在進(jìn)入支付寶理財 tab 頁，可能在不同的頁面（如引導(dǎo)、承接、交易）訪問了不同的基金產(chǎn)品，這其中結(jié)合基金產(chǎn)品的 spm 和訪問次數(shù)會計算一個意圖分，并綜合整個路徑中不同意圖分的情況得到一個用戶最可能交易的意圖節(jié)點(diǎn)。另一方面，基于這些用戶偏好的產(chǎn)品節(jié)點(diǎn)，可以進(jìn)一步推演出用戶感興趣的產(chǎn)品類目，基于這些數(shù)據(jù)可以實(shí)現(xiàn)更豐富的推廣營銷。

基于流圖可以實(shí)現(xiàn)更加快速精準(zhǔn)識別用戶行為意圖，與傳統(tǒng)的推薦算法不同，作為一個實(shí)時數(shù)據(jù)方案，它具備高時效性、過程白盒化、可人工干預(yù)擴(kuò)展節(jié)點(diǎn)、消除噪音意圖識別更精準(zhǔn)、后置計算效率更高等特點(diǎn)。

五、未來展望

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

基于流圖的實(shí)時 OLAP 在營銷場景的推廣應(yīng)用

基于流圖的實(shí)時用戶行為意圖分析在數(shù)金、內(nèi)容等場景的推廣應(yīng)用

基于流圖的實(shí)時歸因能力在廣告鏈路診斷場景的應(yīng)用探索

流圖開源項目的貢獻(xiàn)參與