摘要：本文整理自網易互娛技術中心計費實時平台與 SDK 技術負責人林佳在 Flink Forward Asia 2021 行業實踐專場的演講。本篇内容主要分為三個部分：
- 從一次 APP 内購買支付聊起
- 實時 SDK 與平台化的雙線發展
- 走向實時全關聯
點選檢視直播回放 & 演講PDF
說到網易互娛，大家首先想到的肯定是遊戲。作為網易的核心業務線之一，讓遊戲業務可以穩定可靠地運作自然是重中之重，而遊戲業務中最重要就是 APP 内購買服務的可靠性。本文的分享，就從一次 APP 内購買聊起。
一、從一次 APP 内購買支付聊起
玩家在遊戲内購買道具的操作，首先會觸發用戶端行為與管道商、計費中心進行通訊，完成下單與支付。計費中心也會與管道商進行互動，驗證用戶端訂單的合法性以及支付狀态。隻有訂單合法，遊戲服務才會被通知發貨。而這一整套流程下來，每一個參與者産生的日志、資料監控點等等，它們的來源、資料結構、時間步調可能是千差萬别的。此外，這個過程中還有通訊網絡、資料庫、監控系統等的參與，使得整個過程非常複雜。
資料持續而大量地産生，資料之間會話的關聯、資料源之間的異構、資料結構的異構還有時間步調的不一緻等等，都是我們選擇用實時方式去處理的原因。
2017 年之前我們的處理方式相對落後，其中還有一些比較陳舊的處理方式，比如網盤、rsync、T+1 處理離線任務等。
元件繁多、技術棧的割裂、時效性低、資源使用情況粗糙等，都會使資源無法被均勻地利用，而這正是帶來時效性低的原因之一，也使代碼能效、資料能效和資源能效都相對較低。
上圖是我們之前的離線計算業務運作時的資源情況示意，在淩晨的時候去計算前一天的資料報表。在流式計算普及之前，這是一種非常大規模使用的模式，在淩晨的時候用一大批機器執行 Spark 離線任務去計算前一天的結果。為了使報表可以按時傳遞，整個離線叢集需要大算力，堆疊大量的機器資源，而這些機器資源在許多時間段卻是空閑的，這便造成了資源能效低下。
如果這類計算任務可以被實時化，那麼它所需要的算力即可被分攤到每一個時間片上，避免在淩晨的時候資源使用嚴重傾斜。這些機器算力可以被托管在資源管理的平台上，是以它們也可以被其他業務所使用，進而提升能效。
那麼如何選擇實時化的架構？經過深刻的調研和嘗試之後，我們最終選擇了 Flink，它所提供的特性，可以說是完全适配了我們的場景，下圖列舉了我們關于技術架構選型的一些考慮。
二、實時 SDK 與平台化的雙線發展
網易互娛從 2018 年開始便制定了雙線發展計劃，全面推進資料中心 JFlink 的實時化程序。
經過多次疊代，目前我們已經形成了一個一站式的運維平台 + 一個支援配置化開發的 SDK，且已經完成了從可用到實用的進階，下一步就是讓使用者愛用。
如何提高人力以及代碼的效能，是我們從一開始設計 JFlink 的時候就極其注重的。我們希望可以用有限的人力最大化地發揮出能效，是以 SDK 的配置化、子產品化變得尤為重要，要實作每一個實時作業都可以用一套配置語義來描述。
SDK 中封裝了 JFlink SDK 常用的連接配接器處理函數以及資料的流轉對象，使得可以以配置化的形式來組裝和使用它們。SDK 還提供了統一的配置文法，能夠将作業以配置的形式描述後，動态地去組織構造 Flink DAG，以實作一個 SDK 程式包覆寫各類資料業務的特性，提高代碼的複用和能效。
在 SDK 上，可以通過編寫或生成 Kafka source、TiDB sink 以及中間聚合視窗的 UDF，即可拉起一個實時業務，不需要任何額外的開發。
為了配合 SDK 作業的統一文法，我們也建構了一個一站式的處理平台，資料運維人員可以一站式、便捷、可視化地構造自己的資料業務。
即便 DAG 如此錯綜複雜，也依然可以用解析文法來生成。
SDK 化戰略實作了功能子產品化、作業配置化、資料視圖化以及流批一體化，讓子產品複用成為日常，讓每個人都能互相了解彼此的作業，讓異構的資料能為每一種寫好的 UDF 子產品進行處理，更重要的是讓曆史作業可以過渡到 Flink 上。
SDK 化還為我們提供了快速跟随社群更新 Flink 版本的能力。SDK 隔離了業務邏輯和 Stream API，且絕大多數擴充功能都是在 SDK 側對 Flink 原生類的拓展。這在跟随 Flink 進行大版本更新時，一方面業務側可以做到近乎零改動更新，另一方面也解決了内部關于 Flink 的拓展功能需要不斷從各個版本的内部分支向新版分支上做合并的巨大代價。
而雙線發展計劃中的另一側則是網易互娛的一站式平台，它完全基于 K8s 實作了作業的獨立叢集化運作。
上圖是平台的技術架構圖，它配套的 Nexus、HDFS 等大資料元件來作為基礎設施，維護了版本化的軟體倉庫，裡面托管了包括 SDK 以及其他業務 jar 包。運作層面，Flink 使用了 k8s 獨立叢集的理念，即每一個作業都運作在自己獨立的 k8s 命名空間下，擁有自己的資源配套以及依賴集合，實作了業務作業的完全隔離運作以及資源的精細化調配。
為跟蹤業務的疊代、作業的運作以及日志集分析等等的平台化功能，JFlink 平台還封裝好了各種運維接口，通過無狀态的 rest 服務節點對外提供。平台還為運維人員提供了可視化建立實時作業的功能，這也正是我們把平台與 SDK 互相配合而産生的優秀成果。
在一站式平台上，使用者可以監視自己的作業實時狀态，查閱運作日志，復原曆史版本，甚至可以查閱曆史的異常、記錄與統計、風險控制、生命周期的詳細管理。
除了上述提到的能力，我們的一站式平台上還有相當多其他功能，所有的功能與 SDK 互相配合共同組成了我們的實時計算體系。
三、走向實時全關聯
接下來，從資料業務的角度出發，分析闡述網易互娛在計費這一關鍵領域上開展實時業務的經驗與實踐。
我們最早的實踐是對計費節點上産生的資料日志進行統計分析。不同來源的日志往往形式各異、千奇百怪，尤其是外部管道商的回調，更是難以規範其日志格式，應該如何處理這些雜亂的格式，将它們變成一種可以統一處理的資料？這是我們第一個探索目标。
為此， SDK 封裝了可以通過定義抽象文法樹來處理半結構化資料的 UDF Message Unified Parse，也制定了一些可以處理 Group By 以及聚合函數的 UDF。這樣的需求，以配置文法的形式實作了這個統計業務，并通過封裝的 Sink，寫入自研的 TSDB 中。
日志分析監控是從點的角度對計費業務接口、子產品的通路量、法規情況和時延等來進行監控，以此實作對業務的無侵入式實時監視，降低了原先通過微批處理的時延以及業務伺服器上監控腳本導緻的 CPU 開銷，也提高了監控發現率，使業務更可靠。
緊接着，我們把目光投向了做通用的 ETL 架構。
異構資料通過 Parser 可以轉化為統一的視圖和統一的流轉對象，随後可以被内置的符合協定的 UDF 進行處理轉換，我們還實作了一個 JavaScript UDF，通過靈活地 JS 腳本的嵌入，實作了輕松便捷地處理資料的轉換工作。
通過 Flink 處理的資料流入我們自研的異構資料倉庫中，可以讓業務方很友善地使用。還可以直接使用 SQL 來對實時産生的日志進行查詢，甚至對這些日志進行聚合。而這些業務是以點的角度，将支付環境上的接口子產品産生的資料實時地利用起來，每日處理的資料量大約在 30 Billion 級别，它為後續展開更深一步的資料業務實時化提供了有力的保障。
在 2019 年左右，我們開始考慮如何把這些點關聯成有機的線？即将在支付環境上發生的支付，會從頭到尾進行一個全鍊路的關聯分析，這其中的服務是否會發生問題？
這些服務的日志來源千差百怪，可能是來自于用戶端的日志，可能是計費的日志，也可能是網關的日志。而針對這些與上下文分析有關的鍊路式的日志，其實 Flink 已經為我們提供了非常友善的 API，就是 keyed stream + session window。
上圖是全鍊路監控的架構圖。鍊路分析的知識被封裝成了模型，并加載到 Flink 實時分析的程式中。它會把一條支付鍊路上的資料進行實時串聯，然後寫入到我們自研的圖資料庫中，供下遊繼續使用。此外，它還提供了 Daily Spark Job 來處理異常鍊路，以完成一些鍊路補全的需求，這也是對于 Lambda 架構的一種實踐。
上圖展示了全鍊路串聯的效果。一筆支付訂單可以被串聯和展示，這種方式非常有利于 DBA 和産品去定位支付問題。
2020 年左右，網易互娛開始了對實時數倉的探索，其中一個很重要的應用就是使用者畫像系統。
此前 T+1 的形式展示資料報表，時效性比較低。将報表更新改造和實時化之後，現在已經可以通過接口的形式做到即時查詢。而這種時效性的提升使得産品可以去做精細化的營運，更及時地響應營銷需求，進而提升收益。
這些千差萬别的計算，也是通過配置 +SDK 的形式來實作的。
尤其是流式的資料打寬，利用 Flink 提供的 Async IO 去外表進行 Lookup Join，都是實時處理資料的得力助手。
實時使用者數倉和實時數倉名額為産品提供了玩家級的微觀查詢和報表級的宏觀查詢。這些使用者資料可以對接到可視化工具，通過資料可視化直覺地進行展示，讓産品營運可以發現從數字中無法發現的規律，進一步挖掘出其中的資料價值。
有了上述實踐之後，我們開始思考，在一筆鍊路、一個使用者的層次上，能否能将整個支付環境上的各種資料都關聯起來，實作支付環境的宏觀監控。
我們将支付環境會話上各種異構術語，比如支付資料庫 TiDB、支付中間件産生的各種日志資料，都通過 Flink 的 Interval Join 特性來進行關聯分析。
比如在 TiDB 中，存儲有下單與付款的資料庫 40 行，日志中有使用者從用戶端下單到管道回調等支付過程的記錄，對它們分别關聯即可分析出對應服務子產品的情況。
進一步可以把各個子產品情況産生的鍊路再進行關聯合并，最終得到整個支付環境上的關聯分析結果。
例如，存在一種可能的異常，資料日志發貨完畢後，數量驟減或錯誤碼的情況很多，那麼運維人員可以很快發現發貨服務存在異常。如上圖展示這類關聯分析的情況，在生成環境的一些複雜場景中，這套全關聯分析架構處理了近十種異構源的資料、關聯分析出幾十種情況的業務場景會話。基于關聯分析的能力做出的許多支付環境上的實時報表，以協助營運修複問題，指導産品制定政策，最終提升收益。
資料業務實時化之後帶來的資源能效和資料能效的提升有目共睹，而高時效性帶來了全新的資料使用靈感的迸發，這也正是 Flink 帶來的全新的大資料未來。