基于Apache Flink實時計算數據流業務引擎在京東零售的實踐和落地 _flink

01
京東零售實時計算的現狀
1.1 現狀
1.2 動力
1.3 目標
02
實時計算框架
2.1 為什么做數據流框架
數據流框架上層各業務場景基于數據流組件化，實現業務數據的加工，包括樣本中心、京享值、搜索等一些業務。
2.2 怎么做實時計算框架？
實時計算框架分成四層：
1.層：實現比如 Json 解析、RPC 調用、以及數據流的鏈接；
2.層：對 Flink 引擎、Data 、Data Set、SQL 等 API 進行封裝；
3.和組合生成，對具體的處理邏輯進行封裝，比如實現、Sink、、Join 等常用的算子；
【基于Apache Flink實時計算數據流業務引擎在京東零售的實踐和落地】4. 一個或者多個構成不同的場景，比如多流拼接導數的 Top N、動線分析，這些構成了 JSON 的配置文件，然后再通過通用的引擎解析配置文件提交任務。
2.3 實時框架：公用 Ops 和
數據接入和 Sink 層：實現了實時離線、近線常用的數據源；
數據解析：是為了將公用的計算邏輯進一步細化，在算子里封裝多個，進行靈活實現業務的邏輯；
算子：如多流拼接、TopN、Count Time ，業務自己實現會比較復雜，因此框架提供了這些算子的，業務只需要在的基礎上增加業務代碼即可，不需要再對這些通用的算子進行學習、開發、調試等工作；
業務算子：可以基于已有的業務算子sql server數據庫操作工具，重寫得到新的業務算子，也可以自定義組合，形成業務算子。
優點如下：
1. 開發標準化：基于框架提供的公用算子，組合完成業務標準化的開發；
2. 易用性提升：框架提供一些常用且難以實現的算子，使業務的開發變得簡單；
3. 開發迭代效率提升：業務只需要業務邏輯，從而提高開發迭代效率質量的提升；
4. 質量提升：框架提供的公共算子都是經過嚴格的測試，并經過長期的業務驗證，從而提高開發質量。
03
場景優化：TopN
3.1 復用算子
首先不僅僅是 TopN ，包括所有業務場景，數據接入和數據寫出都是可以共用的，比如針對流計算，像 Kafka 或 JMQ 的接入和寫出，都是可以復用的。
然后是數據解析的算子，包括 JSON 解析、CSV 解析都是可以復用的，但是如果每一個 JSON 解析和 CSV 解析都抽象成一個，會需要很多的，因此抽象了概念，然后可以組合成公用的算子。
【案例】以榜單計算為例，首先用訂單榜單的一個元素值作為一個計算，然后 KeyBy 時用榜單 ID 加元素，接下來再進行一次訂單榜單元素值的計算，把榜單 ID 和元素值進行一次 KeyBy，產生的 TopN 的排序。
在這里需要 KeyBy 兩次，因為在京東的固有的場景下，有業務上的數據傾斜，只能采用多次聚合，或者是多次排序的方式來解決問題。
3.2 任務優化
HDFS 小文件的問題：因為數據量非常大，因此在寫 HDFS 時，如果策略設置不合理，會導致 HDFS 產生很多的小文件，可能會把 HDFS Name Node 的 RPC 請求隊列打滿。通過源碼及其任務機制發現，HDFS 的文件的策略與的時間以及 Sink 的并行度相關，因此合理設置的時間和 Sink 的并行度，可以有效解決 Sink HDFS 的小文件的問題。
優化：通過查看官方文檔可以發現，針對相關的優化有很多，但是如何有效優化的設置，核心就在于合理地設置和的大小，還可以添加sql server數據庫操作工具，相應調整這些參數，具體采用哪些配置都可以。
優化：主要是超時時間、間隔時間、最小停頓時間。比如超時時間是半個小時，這個任務產生了 Fail 了，假如它是在 29 分鐘的時候，進行的時候，需要從上個開始恢復，需要很快消費前 29 分鐘的數據。這種情況下如果數據量非常大，對任務是一個不小的沖擊。但是如果把的時間設置為更合適的 5 分鐘或者 10 分鐘，這個沖擊量會少很多。
數據傾斜：造成數據的傾斜的情況有很多種，比較難解決的是數據源中引發的數據傾斜問題，因此可以采用多次聚合或者多次排序模式解決；另外一個是機器問題，是由于某臺機器問題造成的數據傾斜，通常的表現是這臺機器上所有的或者 TM 都會產生問題。
04
場景優化：動線分析
4.1 什么是動線
用戶點擊以及頁面展現的瀏覽路徑稱之為是動線；以搜索詞舉例，在京東平臺首先搜索臺燈，然后又搜索臺燈學習，最后搜索兒童學習護眼臺燈，從臺燈到臺燈學習，到兒童學習護眼臺燈，這樣搜索詞的線稱為搜索詞動線。

文章插圖

文章插圖
動線分析的作用：尋找決定轉化的關鍵路徑點以理解用戶決策習慣；經常相鄰查詢的搜索詞通過導流工具串聯，發現趨勢動線；同一個用戶對不同排序策略的接受程度，最終從細分的用戶類型，提出個性化的導購布局和策略建議；
4.2 數據建模
涉及到串聯相鄰的搜索詞問題，需要從宏觀的角度進行數據建模。
首先在京東每天 PB 數據量的動線數據分析下，現有的圖結構是沒有辦法解決這個問題。目前最常用的一個分析方法，是把大批量的這種數據全部同時灌到數據庫里，然后等離線數據運行一段時間，拿到分析的結果從結果上去分析。
當前業界在線圖數據庫進行這種大數據量的圖分析，會嚴重地影響數據庫的運行和對外提供服務，因此引入 Flink Gelly 技術棧，通過類似 MySQL 與 Hive 的模式，解決這種大規模圖分析問題。
解決方案：首先是把圖的源數據通過 Flink SQL 從 Hive 里取出數據，通過 Left Join 把每個ID 下面的 Query 鏈連起來，然后導入到 HDFS 里；從 HDFS 里讀動線的數據，并且把動線的數據生成一個 Graph，根據數據科學家提出的分析條件，將圖的分析的結果，直接灌到 OLAP 里進行多維的分析；數據流實時計算的框架，從 Hive 或者 HDFS 里讀數據，然后通過數據的 Join ，包括寫 HDFS、Graph 、Graph等以可配置化的形式，生成公用算子放到算子庫里，對于搜索、推薦或者是廣告等所有涉及到動線分析的部門，都可以用到。
4.3 模型建模
如果要對用戶進行細分和個性化的分析，就涉及到模型建模。
首先是樣本生產的過程，需要把數據從 Hive 里拿到，針對搜索詞動線分析需要拿到用戶搜索詞的表，然后和相應的訂單表里決定下單的 Query 進行左連接，生成樣本放到 HDFS 里。
訓練任務是從 HDFS 里把這些數據灌到 Alink 里進行Value 建模，最終的 Query 重要度寫到 Hive 里。
全鏈路是以公用算子的方式提供，目前京東采用這種離線訓練的方式，相當于是天級，之后希望天級訓練的模式實時化，做成分鐘級的或者流式的 Join 。
05
場景優化：FLINK 一站式機器學習
機器學習可以從四個方面來描述：特征、樣本、訓練、預估，而每個方面都有相應的問題（如上圖）。
5.1 特征
從生成的角度，特征分為實時特征和離線特征；從特征的特性分為靜態特征和動態特征。
1. 靜態特征是相對變化不太大的特征，比如用戶的年齡、店鋪評分、商品金額，可以把靜態特征和離線特征相對應；
2. 動態特征比如近一個小時內的量，或者近一個小時內的點擊量，動態特征和實時特征相對應。
離線特征可以分為特征的整體生成過程。
1. 特征一般是放到 Hive 里，會涉及到一些特征的解析以及計算，最終生成一個特征的大寬表，然后把這些特征放到 Redis 里，如果是實時特征，涉及到數據接入以及數據解析行為。
2. 特征生成可以認為是業務化的過程，特征寫入可以直接寫入 Redis 里。
3.主要是專注于特征生成，如果特征解析涉及到業務算子，也可以用來做。
5.2 樣本
樣本分為實時樣本拼接和離線樣本拼接兩個鏈路；針對樣本的特性，有離線的樣本和實時的樣本兩個鏈路。
離線的樣本拼接：通過 Join 存到數倉里，從數倉里拿取用戶的曝光以及行為日志后，通過一系列的 Join 操作，形成樣本的寬表，每個業務可以從樣本寬表拿到屬于自己的樣本進行模型的訓練。
實時的鏈路拼接也是相同的，區別是樣本拼接為實時的。Flink 樣本基本上都是雙流的，采用 Unit 和 Timer 模式，適配多流的樣本拼接，會涉及到大狀態的優化，大狀態目前用的 State是 Roll SDB 。更新機制是采用最慢的時間作為更新的機制，如果某一個行為流的數據量比較少，則會導致不更新的問題。
實時樣本拼接針相對離線的樣本拼接更加困難，包括一個窗口的選擇、一些業務上的樣本拼接等。
OPS 做樣本質量的校驗：首先在樣本生成的階段，需要做樣本的分布，如正負樣本的分布；其次在做實時樣本或者是離線樣本拼接時，需要對拼接率做監測；觀察任務的延時率，即每一條樣本的延時情況。
模型升級定義為只有模型進行模型校正時，才會認為它升級了，而增量訓練不是模型升級。
5.3 模型
模型是指數據科學方向，并非大模型的方向。按照特征和樣本實時離線的，把模型分為實時和離線兩種。
實時訓練涉及到模型實時參數的更新，但并非每一條數據訓練一次，由超時時間解決這個問題，比如 Count 達到 1 萬條或者超時時間 5 分鐘，來解決 Mini Batch 的問題。
針對，目前沒有辦法離線地做 AB，因此當一批數據進來時，可以先訓練出一個模型，同樣用這一批數據做 AB，以達到訓練和 AB 的一體化。同時用離線的大數據量訓練出來的模型，去及時校正實時訓練出來的模型，防止模型訓偏了；然后任務內部采用 Keyby 方式實現數據并行，解決模型分布式的問題。
舉例，如模型，是采用報警維度指標來設置，同時在模型產出時將模型推到模型庫，然后會不停地在模型庫里面把當前的模型的參數快照打到模型庫里。
5.4 預估
Flink 做預估目前有兩種方案：
方案 A 是將模型如或者模型，通過 RPC 的方式或者 HTTP 的方式部署，由 Flink Task 去遠程RPC 或者 HTTP，會有網絡的開銷。因為 Flink Task 可能是實時的，也有可能是離線的，所以在RPC 時，不可能讓它隨著 Flink 任務的啟動而啟動，或者隨著 Flink 任務的停止而停止，需要有人來運維該。
方案 B 是將模型 Load 到 Flink TM 內部，即在 Flink TM 內部該模型，其優點是不用去維護 RPC 或者 HTTP 的，從資源的角度減少了網絡開銷，節省了資源。
本文到此結束，希望對大家有所幫助。

继夫的玩弄H辣文的小说|女人与拘性猛交视频|精品欧美高清不卡高清|一起做亏亏的事情的视频|啦啦啦在线视频观看|望月直播下载ios版本|国产日韩欧美一区二区三区

基于Apache Flink實時計算數據流業務引擎在京東零售的實踐和落地