8-3 Flink 作業的穩定性優化實踐.pdf

1、FLINK 作業的穩定性優化實踐邱從賢 騰訊高級開發工程師/Apache Flink Committer|01Flink在騰訊的應用在騰訊的應用02Flink的穩定性介紹的穩定性介紹03穩定性的優化實踐穩定性的優化實踐04總結總結&展望展望目錄目錄CONTENT|Flink 在騰訊的應用01|實時計算的應用|Oceanus 平臺概況JarSQLCanvasConfigurationTextDeploymentMonitoringFlinkMQYarn/K8SHDFSZooKeeperMQOLAPOnlineServiceOceanus實時計算的應用|營銷分析、指標提升運營監控、商業決策產品改進

2、、體驗升級從Business Intelligence走向Continuous Intelligence實時計算的應用|在線服務消息隊列實時用戶行為離線存儲推理服務樣本拼接模型存儲樣本存儲特征存儲離線特征計算實時特征計算oceanustdbankHDFSusDBServiceCache典型應用消息隊列Flink 的穩定性介紹02|穩定性介紹|Flink 作業概況HDFSmasterTask-2Task-3Task-1HA 相關心跳checkpoint數據傳輸穩定性介紹|Flink 作業穩定性可能的影響方面第三方系統YarnContainer 數量Container 的資源使用（CPU，Memo

3、ry，鏈接數等）HDFS存儲量訪問量ZooKeeper連接數Flink控制鏈路Master 和 worker 通信Checkpoint 流程數據鏈路數據熱點反壓Flink Bug用戶邏輯異常穩定性優化實踐03|穩定性優化實踐|穩定性減少故障優化 ZooKeeperHA 協議Checkpoint 小文件合并降低影響空間上單點重啟Master failover時間上作業啟動加速快速發現&恢復自動診斷系統減少故障優化 Zookeeper HA 協議|masterTask-2Task-3Task-1masterTask-2Task-3Task-1優化前優化后減少故障優化 Zookeeper HA 協議

4、|masterTask-2Task-3Task-1masterTask-2Task-3Task-1master減少故障優化 Zookeeper HA 協議|單計算集群中 ZooKeeper 的連接數多個計算集群共用一個 ZooKeeper 集群masterTask-2Task-3Task-1masterTask-2Task-3Task-1masterTask-2Task-3Task-1010000200003000026154583降低影響單點重啟|HDFSmasterYarnTask-2Task-3Task-1Task-2Task-3Task-11 master 監聽 Task 執行狀態2

5、master 發現 task-2 異常后取消所有 Task 的執行3 Master 從 ZK 上讀取最新檢查點地址4 Mater 從 HDFS 上讀取檢查點元數據5 Master 部署Task 并告知所需恢復的狀態Task failover 流程減少故障單點重啟|Flink 對網絡傳輸的大量優化，使得網絡連接的重置變得困難挑戰一：Flink 基于 Buffer 而非Record 進行網絡傳輸，Task 對數據的序列化和反序列化是有狀態的。在 Task 中殘留數據會導致數據序列化/反序列化異常。如何正常清理網絡傳輸中的殘留數據挑戰二：Flink 網絡傳輸中存在反壓機制。如何避免 Task 由于反

6、壓導致無法響應網絡重置請求減少故障單點重啟|Task-1Task-5Task-2Task-4Task-3Task-1Task-5Task-2Task-4Task-3Master1 故障探測上游 Task 發現 Task 故障后，將對應的網絡管道（ResultSubpartition）設置為掛起狀態，下游 Task 發現 Task 故障后，忽略異常2 重置上游網絡連接Master 向故障 Task 的所有上游發送重置命令，重置發往故障 Task 的網絡管道減少故障單點重啟|Task-1Task-5Task-2Task-4Task-3Task-1Task-5Task-2Task-4Task-33

7、調度故障 TaskMaster 完成故障 Task 所有上游的重置后，重啟調度故障 Task 的執行4 重置下游網絡連接Master 收到恢復 Task 的發送的調度請求后，告知下游Task 新 Task 的地址并重置連接減少故障單點重啟|全局恢復-Task 粒度單個 Task 故障導致其他Task 吞吐和延遲受到影響單點恢復-Task 粒度單個 Task 故障幾乎不會影響其他 Task 的吞吐和延遲作業粒度單點重啟保障作業大部分數據仍然得到有效處理050100150138業務感知斷流時間（秒）0快速恢復啟動加速|MasterTaskTaskTaskTask31s20s39s111sYarn主

8、要瓶頸Master 主線程需要處理 Task 啟動階段大量 RPC 請求Container 拉取文件慢Container 需即時申請解決方案 優化分布式協議，去除不必要的 RPC 請求 合并 Jar 包，減少 Container 啟動所需的文件數目 允許額外的備份 Container，避免故障時再去申請部署Task 故障恢復流程（并發度 4691）050100150200250故障恢復時間從201s 減少到 48s快速的感知問題reactive-proactive|問題 日志/指標可能不夠（缺少上下文信息）耗時耗力，流程繁瑣常見作業的異常處理流程告警查看日志/指標人工解決快速的感知問題reac

9、tive-proactive|NodelostOOMKillerTM GCJM GCHeartbeatTimeoutBarrieralignSycnsnapshotAsyncsnapshotCheckpointexpire快速的感知問題reactive-proactive|NodelostOOMKillerTMGCJMGCHeartbeatTimeoutBarriealignSycnsnapshotAsyncsnapshotCheckpointexpire總結&展望04|總結|穩定性減少故障優化 Zookeeper HA 協議Checkpoint 小文件合并降低影響空間上Master failover有損單點重啟時間上作業啟動加速快速發現&恢復自動診斷系統展望|穩定性減少故障優化 Zookeeper HA 協議Checkpoint 小文件合并降低影響空間上無損單點重啟Master failover時間上作業啟動加速大狀態快速恢復快速發現&恢復自動診斷系統&恢復非常感謝您的觀看|