來源：Apache Flink
摘要：本文整理自京東零售-技術研發與資料中心張穎&閆莉剛在 ApacheCon Asia 2022 的分享。內容主要包括五個方面：京東零售實時計算的現狀
實時計算框架
場景最佳化：TopN
場景最佳化：動線分析
場景最佳化：FLINK 一站式機器學習
1.1 現狀
- 技術門檻高、學習成本大、開發週期長。行業內實時開發能力只有少數人能夠掌握的現狀；
- 資料開發迭代效率比較低，重複邏輯反覆的開發缺少複用；
- 多角色資料開發，不同角色對應不同的開發方式，非資料人員也能做資料開發的工作。
1.3 目標
- 降低資料開發門檻，透過標準化積木式的開發，實現低程式碼配置化資料加工，進一步實現圖形化清晰表達資料流轉；
- 透過運算元庫元件的沉澱，提升開發效率，提高複用性，一站式加工；
2.1 為什麼做資料流框架
- 資料流框架：9N-Tamias/9N-Combustor，資料流框架基於計算引擎之上，提供一種易用高效的資料開發方式，包括：tamias，是基於 Flink 的引擎的開發框架；combustor：基於 Spark 引擎的開發框架。基於 9N-Tamias 和 9N-Combustor 提供資料流開發工具；
- 運算元、元件複用：資料流運算元、轉換運算元、自定義運算元、目標源運算元，靈活的組合，沉澱常用的運算元組合，元件化包括資料流元件和自定義元件，透過資料流開發沉澱資料流元件，同時也開放自主開發自定義元件方式，透過運算元、元件的複用，提高開發效率。
資料流框架上層各業務場景基於資料流元件化，實現業務資料的加工，包括樣本中心、京享值、搜尋等一些業務。
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. 質量提升：框架提供的公共運算元都是經過嚴格的測試，並經過長期的業務驗證，從而提高開發質量。
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 都會產生問題。
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。
機器學習可以從四個方面來描述：特徵、樣本、訓練、預估，而每個方面都有相應的問題（如上圖）。
5.1 特徵
從生成的角度，特徵分為實時特徵和離線特徵；從特徵的特性分為靜態特徵和動態特徵。1. 靜態特徵是相對變化不太大的特徵，比如使用者的年齡、店鋪評分、商品金額，可以把靜態特徵和離線特徵相對應；2. 動態特徵比如近一個小時內的點贊量，或者近一個小時內的點選量，動態特徵和實時特徵相對應。1. 特徵一般是放到 Hive 裡，會涉及到一些特徵的解析以及計算，最終生成一個特徵的大寬表，然後把這些特徵放到 Redis 裡，如果是實時特徵，涉及到資料接入以及資料解析行為。2. 特徵生成可以認為是業務化的過程，特徵寫入可以直接寫入 Redis 裡。3. FeatureOPS 主要是專注於特徵生成，如果特徵解析涉及到業務運算元，也可以用 FeatureOPS 來做。
樣本分為實時樣本拼接和離線樣本拼接兩個鏈路；針對樣本的特性，有離線的樣本和實時的樣本兩個鏈路。離線的樣本拼接：透過 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 預估
方案 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，從資源的角度減少了網路開銷，節省了資源。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70027827/viewspace-2940254/，如需轉載，請註明出處，否則將追究法律責任。