基於 Apache Flink 的實時計算資料流業務引擎在京東零售的實踐和落地

來源：Apache Flink

摘要：本文整理自京東零售-技術研發與資料中心張穎&閆莉剛在 ApacheCon Asia 2022 的分享。內容主要包括五個方面：

1. 京東零售實時計算的現狀

2. 實時計算框架

3. 場景最佳化：TopN

4. 場景最佳化：動線分析

5. 場景最佳化：FLINK 一站式機器學習

01

京東零售實時計算的現狀

1.1 現狀

• 技術門檻高、學習成本大、開發週期長。行業內實時開發能力只有少數人能夠掌握的現狀；
• 資料開發迭代效率比較低，重複邏輯反覆的開發缺少複用；

  
  
• 測試運維難，複雜業務邏輯難以區域性測試。

  
  

    

1.2 動力

• 降本增效、節省人力，助力高效開發；
• 多角色資料開發，不同角色對應不同的開發方式，非資料人員也能做資料開發的工作。

1.3 目標

• 降低資料開發門檻，透過標準化積木式的開發，實現低程式碼配置化資料加工，進一步實現圖形化清晰表達資料流轉；
• 透過運算元庫元件的沉澱，提升開發效率，提高複用性，一站式加工；
• 透過單元測試以及沉澱用例，提高開發質量。

02

實時計算框架

2.1 為什麼做資料流框架

• 資料流框架：9N-Tamias/9N-Combustor，資料流框架基於計算引擎之上，提供一種易用高效的資料開發方式，包括：tamias，是基於 Flink 的引擎的開發框架；combustor：基於 Spark 引擎的開發框架。基於 9N-Tamias 和 9N-Combustor 提供資料流開發工具；
• 支援實時離線統一的表達；
• 多種使用方式：圖形化、配置化、SDK 等；
• 運算元、元件複用：資料流運算元、轉換運算元、自定義運算元、目標源運算元，靈活的組合，沉澱常用的運算元組合，元件化包括資料流元件和自定義元件，透過資料流開發沉澱資料流元件，同時也開放自主開發自定義元件方式，透過運算元、元件的複用，提高開發效率。

  
  

資料流框架上層各業務場景基於資料流元件化，實現業務資料的加工，包括樣本中心、京享值、搜尋等一些業務。

2.2 怎麼做實時計算框架？

實時計算框架分成四層：

1. Function 層：實現比如 Json 解析、RPC 呼叫、以及資料流的連結；

2. Process 層：對 Flink 引擎、Data Stream、Data Set、SQL 等 API 進行封裝；

3. Function 和 Process 組合生成 Operator，對具體的處理邏輯進行封裝，比如實現 Source、Sink、Filter、Join 等常用的運算元；

4. 一個或者多個 Operator 構成不同的場景，比如多流拼接導數的 Top N、動線分析，這些構成了 JSON 的配置檔案，然後再透過通用的引擎解析配置檔案提交任務。

2.3 實時框架：公用 Ops 和 Function

資料接入 Source 和 Sink 層：實現了實時離線、近線常用的資料來源；

資料解析 Function：是為了將公用的計算邏輯進一步細化，在運算元裡封裝多個 Function，進行靈活實現業務的邏輯；

運算元 Template：如多流拼接、TopN、Count Time Window，業務自己實現會比較複雜，因此框架提供了這些運算元的 Template，業務只需要在 Template 的基礎上增加業務程式碼即可，不需要再對這些通用的運算元進行學習、開發、除錯等工作；

業務運算元：可以基於 Template 已有的業務運算元，重寫得到新的業務運算元，也可以自定義組合 Function，形成業務運算元。

優點如下：

1. 開發標準化：基於框架提供的公用運算元，組合完成業務標準化的開發；

2. 易用性提升：框架提供一些常用且難以實現的運算元，使業務的開發變得簡單；

3. 開發迭代效率提升：業務只需要關注業務邏輯，從而提高開發迭代效率質量的提升；

4. 質量提升：框架提供的公共運算元都是經過嚴格的測試，並經過長期的業務驗證，從而提高開發質量。

03

場景最佳化：TopN

3.1 複用運算元

首先不僅僅是 TopN，包括所有業務場景，資料接入和資料寫出都是可以共用的，比如針對流計算，像 Kafka 或 JMQ 的接入和寫出，都是可以複用的。

然後是資料解析的運算元，包括 JSON 解析、CSV 解析都是可以複用的，但是如果每一個 JSON 解析和 CSV 解析都抽象成一個 Operator，會需要很多的 Operator，因此抽象了 Function 概念，然後 Function 可以組合成公用的運算元。

【案例】以榜單計算為例，首先用訂單榜單的一個元素值作為一個計算，然後 KeyBy 時用榜單 ID 加元素，接下來再進行一次訂單榜單元素值的計算，把榜單 ID 和元素值進行一次 KeyBy，產生的 TopN 的排序。

在這裡需要 KeyBy 兩次，因為在京東的固有的場景下，有業務上的資料傾斜，只能採用多次聚合，或者是多次排序的方式來解決問題。

3.2 任務最佳化

HDFS 小檔案的問題：因為資料量非常大，因此在寫 HDFS 時，如果 Rolling 策略設定不合理，會導致 HDFS 產生很多的小檔案，可能會把 HDFS Name Node 的 RPC 請求佇列打滿。透過原始碼及其任務機制發現，HDFS 的檔案 Rolling 的策略與 Checkpoint 的時間以及 Sink 的並行度相關，因此合理設定 Checkpoint 的時間和 Sink 的並行度，可以有效解決 Sink HDFS 的小檔案的問題。

RocksDB 最佳化：透過檢視官方文件可以發現，針對 RocksDB 相關的最佳化有很多，但是如何有效最佳化 RocksDB 的設定，核心就在於合理地設定 BlockCache 和 WriteBuffer 的大小，還可以新增 BloomFilter，相應調整這些引數，具體採用哪些配置都可以。

Checkpoint 最佳化：主要是超時時間、間隔時間、最小停頓時間。比如超時時間是半個小時，這個任務產生了 Fail 了，假如它是在 29 分鐘的時候，進行 Failover 的時候，需要從上個 Checkpoint 開始恢復，需要很快消費前 29 分鐘的資料。這種情況下如果資料量非常大，對任務是一個不小的衝擊。但是如果把 Checkpoint 的時間設定為更合適的 5 分鐘或者 10 分鐘，這個衝擊量會少很多。

資料傾斜：造成資料的傾斜的情況有很多種，比較難解決的是資料來源中引發的資料傾斜問題，因此可以採用多次聚合或者多次排序模式解決；另外一個是機器問題，是由於某臺機器問題造成的資料傾斜，通常的表現是這臺機器上所有的 Subtask 或者 TM 都會產生問題。

04

場景最佳化：動線分析

4.1 什麼是動線

使用者點選以及頁面展現的瀏覽路徑稱之為是動線；以搜尋詞舉例，在京東平臺首先搜尋檯燈，然後又搜尋檯燈學習，最後搜尋兒童學習護眼檯燈，從檯燈到檯燈學習，到兒童學習護眼檯燈，這樣搜尋詞的線稱為搜尋詞動線。

動線分析的作用：尋找決定轉化的關鍵路徑點以理解使用者決策習慣；經常相鄰查詢的搜尋詞透過導流工具串聯，發現趨勢動線；同一個使用者對不同排序策略的接受程度，最終從細分的使用者型別，提出個性化的導購佈局和策略建議；

4.2 資料建模

涉及到串聯相鄰的搜尋詞問題，需要從宏觀的角度進行資料建模。

首先在京東每天 PB 資料量的動線資料分析下，現有的圖結構是沒有辦法解決這個問題。目前最常用的一個分析方法，是把大批次的這種資料全部同時灌到資料庫裡，然後等離線資料執行一段時間，拿到分析的結果從結果上去分析。

當前業界線上圖資料庫進行這種大資料量的圖分析，會嚴重地影響資料庫的執行和對外提供服務，因此引入 Flink Gelly 技術棧，透過類似 MySQL 與 Hive 的模式，解決這種大規模圖分析問題。

解決方案：首先是把圖的源資料透過 Flink SQL 從 Hive 裡取出資料，透過 Left Join 把每個 Session ID 下面的 Query 鏈連起來，然後匯入到 HDFS 裡；從 HDFS 裡讀動線的資料，並且把動線的資料生成一個 Graph，根據資料科學家提出的分析條件，將圖的分析的結果，直接灌到 OLAP 裡進行多維的分析；資料流實時計算的框架，從 Hive 或者 HDFS 裡讀資料，然後透過資料的 Join，包括寫 HDFS、Graph Generate、Graph Analyse 等以可配置化的形式，生成公用運算元放到運算元庫裡，對於搜尋、推薦或者是廣告等所有涉及到動線分析的部門，都可以用到。

4.3 模型建模

如果要對使用者進行細分和個性化的分析，就涉及到模型建模。

首先是樣本生產的過程，需要把資料從 Hive 裡拿到，針對搜尋詞動線分析需要拿到使用者搜尋詞的表，然後和相應的訂單表裡決定下單的 Query 進行左連線，生成樣本放到 HDFS 裡。

訓練任務是從 HDFS 裡把這些資料灌到 Alink 裡進行 Shaply Value 建模，最終的 Query 重要度寫到 Hive 裡。

全鏈路是以公用運算元的方式提供，目前京東採用這種離線訓練的方式，相當於是天級，之後希望天級訓練的模式實時化，做成分鐘級的或者流式的 Join。

05

場景最佳化：FLINK 一站式機器學習

機器學習可以從四個方面來描述：特徵、樣本、訓練、預估，而每個方面都有相應的問題（如上圖）。

5.1 特徵

從生成的角度，特徵分為實時特徵和離線特徵；從特徵的特性分為靜態特徵和動態特徵。

1. 靜態特徵是相對變化不太大的特徵，比如使用者的年齡、店鋪評分、商品金額，可以把靜態特徵和離線特徵相對應；

2. 動態特徵比如近一個小時內的點贊量，或者近一個小時內的點選量，動態特徵和實時特徵相對應。

離線特徵可以分為特徵的整體生成過程。

1. 特徵一般是放到 Hive 裡，會涉及到一些特徵的解析以及計算，最終生成一個特徵的大寬表，然後把這些特徵放到 Redis 裡，如果是實時特徵，涉及到資料接入以及資料解析行為。

2. 特徵生成可以認為是業務化的過程，特徵寫入可以直接寫入 Redis 裡。

3. FeatureOPS 主要是專注於特徵生成，如果特徵解析涉及到業務運算元，也可以用 FeatureOPS 來做。

5.2 樣本

樣本分為實時樣本拼接和離線樣本拼接兩個鏈路；針對樣本的特性，有離線的樣本和實時的樣本兩個鏈路。

離線的樣本拼接：透過 Join 存到數倉裡，從數倉裡拿取使用者的曝光以及行為日誌後，透過一系列的 Join 操作，形成樣本的寬表，每個業務可以從樣本寬表拿到屬於自己的樣本進行模型的訓練。

實時的鏈路拼接也是相同的，區別是樣本拼接為實時的。Flink 樣本基本上都是雙流的，採用 Unit 和 Timer 模式，適配多流的樣本拼接，會涉及到大狀態的最佳化，大狀態目前用的 State Backend 是 Roll SDB。Watermark 更新機制是採用最慢的時間作為更新的機制，如果某一個行為流的資料量比較少，則會導致 Watermark 不更新的問題。

實時樣本拼接針相對離線的樣本拼接更加困難，包括一個視窗的選擇、一些業務上的樣本拼接等。

Sample OPS 做樣本質量的校驗：首先在樣本生成的階段，需要做樣本的分佈，如正負樣本的分佈；其次在做實時樣本或者是離線樣本拼接時，需要對拼接率做監測；觀察任務的延時率，即每一條樣本的延時情況。

模型升級定義為只有模型進行模型校正時，才會認為它升級了，而增量訓練不是模型升級。

5.3 模型 online learning

模型 online learning 是指資料科學方向，並非大模型的方向。按照特徵和樣本實時離線的 Template，把模型分為實時和離線兩種。

實時訓練涉及到模型實時引數的更新，但並非每一條資料訓練一次，由超時時間 CountWindow 解決這個問題，比如 Count 達到 1 萬條或者超時時間 5 分鐘，來解決 Mini Batch 的問題。

針對 Online Learning，目前沒有辦法離線地做 AB，因此當一批資料進來時，可以先訓練出一個模型，同樣用這一批資料做 AB，以達到訓練和 AB 的一體化。同時用離線的大資料量訓練出來的模型，去及時校正實時訓練出來的模型，防止模型訓偏了；然後任務內部採用 Keyby 方式實現資料並行，解決模型分散式的問題。

舉例，如 Profit 模型，是採用報警維度指標來設定，同時在模型產出時將模型推到模型庫，然後 Parameter Server 會不停地在模型庫裡面把當前的模型的引數快照打到模型庫裡。

5.4 預估

Flink 做預估目前有兩種方案：

方案 A 是將模型如 Tensorflow 或者 PyTorch 模型，透過 RPC 的方式或者 HTTP 的方式部署 Server，由 Flink Task 去遠端 Invoke RPC 或者 HTTP，會有網路的開銷。因為 Flink Task 可能是實時的，也有可能是離線的，所以在 invoke RPC 時，不可能讓它隨著 Flink 任務的啟動而啟動，或者隨著 Flink 任務的停止而停止，需要有人來運維該 Server。

方案 B 是將模型 Load 到 Flink TM 內部，即在 Flink TM 內部 Inference 該模型，其優點是不用去維護 RPC 或者 HTTP 的 Server，從資源的角度減少了網路開銷，節省了資源。