2019年Flink流批一體的技術架構以及在阿里的實踐.pdf

《2019年Flink流批一體的技術架構以及在阿里的實踐.pdf》由會員分享，可在線閱讀，更多相關《2019年Flink流批一體的技術架構以及在阿里的實踐.pdf（25頁珍藏版）》請在三個皮匠報告上搜索。

1、Flink 流批一體的技術架構以及在阿里的實踐高級技術專家目錄目錄 需求和挑戰 Flink 架構簡介 流批一體的入口 SQL 流批一體的大規模實踐 在線機器學習平臺 總結和展望主流架構對比主流架構對比LambdaKappa 執行引擎同時具備多種能力1.低延遲的流計算2.高吞吐、高穩定性的批處理 用戶角度：編程接口統一。一份代碼，一樣的結果 開發人員角度：架構統一，代碼復用流批一體系統的需求和挑戰流批一體系統的需求和挑戰Flink 架構簡介架構簡介StorageHDFS,HBase,KafkaLocalSingle JVMClusterStandalone,YARN,K8S,DeployDist

2、ributed Streaming DataflowRuntimeDataStream APIAPIDataSet APIWord Countval lines:DataStreamString=env.readFromQueue(address)val words:DataStreamWord=lines.flatmap(line)=split(line)val counts:DataStreamInt=words .keyBy(“word”).sum(“frequency”)counts.addSink(new RollingSink(path)計算模型的核心抽象表達作業邏輯的DAG主要由

3、點和邊構成1.點：算子（operator），包含主要的計算邏輯2.邊：數據流通管道，可以運行在多種介質上（網絡、文件、內存）Streaming Dataflowsource1/2source2/2flatmap1/2flatmap2/21/2aggregate2/2aggregatesink1/1Word Count：批處理是流計算的特例批處理是流計算的特例opopUnbounded StreamUnbounded StreamopopopopopopUnbounded StreamUnbounded StreamPipelinePipelineStream JobStream Jobopop

4、opopopopopopPipeline/PersistPipeline/PersistBounded StreamBounded StreamBounded StreamBounded StreamBatch JobBatch Job流批統一的入口流批統一的入口-SQL-|USER_SCORES|-|User|Score|Time|-|Julie|7|12:01|Frank|3|12:03|Julie|1|12:03|Frank|2|12:06|Julie|4|12:07|-USER_SCORES is a source table/stream.Batch Mode:12:07 SELEC

5、T Name,SUM(Score),MAX(Time)FROM USER_SCORES GROUP BY Name;-|Name|Score|Time|-|Julie|12|12:07|Frank|5|12:06|-Stream Mode:12:01 SELECT Name,SUM(Score),MAX(Time)FROM USER_SCORES GROUP BY Name;-12:04,now)|-|Name|Score|Time|-|Julie|12|12:07|Frank|5|12:06|-|-12:01,12:04)|-|Name|Score|Time|-|Julie|8|12:03|

6、Frank|3|12:03|-|-|-inf,12:01)|-|Name|Score|Time|-|-|-1.流有 Early fire2.最終結果一致流批統一的架構流批統一的架構LocalSingle JVMCloudGCE,EC2ClusterStandalone,YARNRuntimeDistributed Streaming DataflowDataStream APIStream ProcessingDataSet APIBatch ProcessingTable API&SQLRelationalRuntimeDataStream APIStream ProcessingDataS

7、et APIBatch ProcessingTransformationStreamGraphOperator TreeBatch PlanOptimized PlanJob GraphStream Task&OperatorBatch Task&Driver語義難以和 SQL 保持一致開發效率低，添加功能鏈路長執行模式不同，代碼難以復用新架構新架構LocalSingle JVMCloudGCE,EC2ClusterStandalone,YARNRuntimeDistributed Streaming DataflowDataStream APIStream ProcessingDataSet

8、 APIBatch ProcessingTable API&SQLRelationalRuntimeDAG API&Stream OperatorsQuery ProcessorQuery Optimizer&Query ExecutorTable API&SQLRelationalLocalSingle JVMCloudGCE,EC2ClusterStandalone,YARN新架構主要修改點新架構主要修改點RuntimeDAG API&Stream OperatorsQuery ProcessorQuery Optimizer&Query ExecutorTable API&SQLRela

9、tionalLocalSingle JVMCloudGCE,EC2ClusterStandalone,YARN1.Table API 和 SQL 變成一級 API2.引入 Query Processor 模塊統一流和批的處理3.使用相同的 DAG 和 Stream Operator 來描述流批作業4.Runtime 統一到流上 push based 實現5.未來可以考慮和 DataStream 共享算子Query Processor 簡介簡介大部分共用部分共用完全一樣SQL&Table APILogical PlanOptimizerPhysical PlanExecutionDAG 執行引擎

10、同時具備多種能力1.低延遲的流計算2.高吞吐、高穩定性的批處理 用戶角度：編程接口統一。一份代碼，一樣的結果 開發人員角度：架構統一，代碼復用回顧需求回顧需求大規模實踐大規模實踐 在線機器學習平臺在線機器學習平臺Event：用戶行為（商品曝光、點擊、購買等）Entity：準靜態特征（商品7天的點擊數量等）Sample：樣本1.Event 和 Entity 的存儲選擇2.時效性：ETL 作業+實時訓練作業3.樣本一致性：規避 Early fire 導致的錯誤樣本4.數據可回溯：任意環節的糾錯能力5.批和流樣本的統一生成6.模型的 Validation 機制問題和挑戰問題和挑戰 需要同時具備低延遲

11、的流式訂閱和高吞吐的歷史數據回溯功能 ETL 作業延遲和數據重復的權衡1.Exactly once 由于 Checkpoint barrier 對齊的問題導致延遲波動2.At least once 不保證數據不重復輸出 解決方案：消息隊列+類 HBase 的 KV 系統1.消息隊列提供低延時的流式訂閱2.ETL 作業使用 At least once，利用 KV 系統的 Update 能力進行去重并提供歷史數據 Scan 功能3.平臺對數據源進行包裝，在不同場景下切換存儲的選擇存儲的選擇 在 CVR（Conversion Rate，轉化率）模型中，我們會根據點擊是否成交而生成相應的樣本：1.假如

12、用戶點擊后進行了購買，則是一個正樣本2.假如用戶點擊后沒有購買，則是一個負樣本3.用戶從點擊到成交的時間不確定，從秒級到小時級不等 解決方案：利用 SQL 的 Retraction 機制1.在延遲容忍程度內，先根據當前數據情況輸出結果2.當結果需要有變化時，先發送一條之前錯誤的結果，標記為 Retraction，然后再發送一條最新的正確結果3.用戶在算法邏輯中對 Retraction 消息進行處理，對錯誤樣本進行修正實時訓練的時效性和一致性實時訓練的時效性和一致性 雖然有了一定的錯誤修正機制，但還是避免不了產生一些負面影響。需要定期進行樣本的批量生成 有些模型還不需要很高的時效性，更關注樣本準

13、確性 解決方案：直接復用實時的樣本生成邏輯，一樣的 SQL，一樣的 UDF1.平臺將 Source 自動替換成 KV 系統的歷史數據進行 Scan2.SQL 作業自動切換成批處理模式執行3.批處理作業使用混部資源運行批流一體的樣本生成機制批流一體的樣本生成機制 優化資源使用1.避免 N*M 級別（上游并發為N，下游并發為M）的內存占用消耗2.Metrics reporter 的內存占用優化 穩定性提升1.JobManager Failover FLINK-49112.Region-based Task Failover FLIP1/FLINK-4256 調度性能優化大規模批處理作業優化大規模批

14、處理作業優化-JobManager Flink 自帶的 Batch Shuffle 會將數據托管給 TM 混部環境中，TM被殺是常態 借助 Yarn Auxiliary Service，將數據托管給可靠性更高的Node Manager 社區也在嘗試更通用的支持方案：FLIP-31-Pluggable Shuffle Manager大規模批處理作業優化大規模批處理作業優化 Shuffle Service 日志 ETL 作業雙十一峰值接近1億條每秒 手淘主搜索和猜你喜歡樣本量每天數百 TB 實時模型直接提升了雙十一效果 最大單一批處理作業處理 400 TB數據，最大單節點并發20000 批處理混部運行拉升了集群資源水位業務效果業務效果 經過改造之后，Flink 已經具備了比較完善流批一體的技術架構 流批一體的技術架構可以簡化業務系統，提升業務效果 從擴展性、性能、穩定性這三個維度看，Flink 的批處理已初步通過大規模上線的考驗總結總結 流批一體還缺少最后一塊拼圖：存儲 流計算 SQL 作業的狀態兼容性和作業熱升級支持 探索介于流批計算之間的其他計算形態 批處理大規模推廣的關鍵：Hive 兼容性 基于新技術架構的機器學習庫未來展望未來展望