邱從賢-大規模作業的穩定性優化實踐.pdf

1、邱從賢Apache Flink Committer/騰訊高級開發工程師大規模作業的穩定性優化實踐平臺介紹穩定性建設總結與展望#1#2#3#1平臺介紹實時計算的應用從Business Intelligence走向Continuous Intelligence營銷分析、指標提升運營監控、商業決策產品改進、體驗升級以財付通為例，實時計算在微加卡實時營銷、實時智能推薦、基金實時營銷分析、實時自助分析等項目中扮演重要的作用，理財通實時活動和信用卡營銷效果取得了巨大的提升實時計算的應用Yarn/K8SHDFSZooKeeperMQFlinkConfigurationOceanusTextDeploymen

2、tMonitoringMQOLAPOnlineServicesCanvasSQLJarOceanus 平臺概況#2穩定性建設穩定性衡量要素減少故障空間上降低影響時間上降低影響功能測試穩定性保障方案測試演練故障演練混沌測試部署監控故障恢復SLA 評估資源隔離鏈路雙活可用性監控延遲監控亂序監控實時對賬負載均衡集群擴容鏈路切換災備降級壓力測試開發故障預防體驗優化測試驗證作業開發流程Jar 開發流程測試上線Jar 代碼 開發作業開發流程SQL 開發流程調試上線SQL 代碼 開發作業開發流程Canvas 開發流程調試上線Canvas 開發作業開發流程開發方式可能的問題解決方案JarJava 代碼開發調試

3、困難API 太底層沖突較多使用 SQL/Canvas 模式 提前檢測class 的沖突SQLSQL 代碼表結構不明顯（字段信息不明顯）報錯信息定位不方便優化報錯信息提示提供 Debug 驗證模式使用 Canvas 模式Canvas圖形化語義不對齊完善語義故障演練故障類型故障影響如何恢復serverserver 故障/db 故障影響作業啟停不影響作業運行重啟 server 或者 dbYarnRM 故障無法啟動等待 RM 恢復NM 故障NM 所在機器所有 container 作業重啟Flink 自動恢復資源不足無法啟動作業擴容HDFS服務不可用無法啟動作業，運行中作業可能重啟等待 HDFS 恢復D

4、N/NN 慢作業無法啟動，運行中作業可能重啟等待 HDFS 恢復容量滿無法啟動作業，無法完成checkpoint 無法自動 failover擴容Zookeeper服務不可用服務不穩定導致 leader 切換無法啟動作業，運行中作業可能failover 無法正?；謴偷却?Zookeeper 恢復或者切換zookeeper 集群Flink 運行異常Flink/用戶邏輯異常作業 failoverFlink 自動恢復壓力測試通過不斷增加壓力了解各系統的能力邊界測試項測試項優化優化釋義釋義server不同 QPS 請求下，server 的請求成功率以及操作時延水平擴容掌握 server 的整體 SLA

5、以及擴容時機Yarn不同 application/container 規模下，集群的響應速度資源隔離降低硬件故障的影響掌握不同規模集群能支撐的作業數HDFS給定集群規模下，能支持的 checkpoint 大小以及頻率小文件合并掌握集群能支撐的 checkpoint 大小以及頻率Zookeeper給定集群能支撐的作業數/TaskManager 數 降低 TM 對 Zookeeper 的連接依賴（TaskExecutor 啟動或者 HeartbeatTimeout 后重新連接 zookeeper）掌握集群能支撐的作業數/TaskManager 數部署階段評估作業的接入，將可能的影響降到最低評估指標

6、評估指標處理措施處理措施server接入后能否滿足 SLA 要求水平擴容Yarn接入后集群能否支撐 application/container 的需求 集群擴容接入新集群HDFS接入后集群能否支撐 checkpoint 的讀寫集群擴容接入新集群Zookeeper接入后集群能否支撐連接數/znode 數Zookeeper 擴容/隔離作業運行情況masteryarnzookeeperHDFSTask-1Task-2Task-3Task-4心跳心跳心跳心跳barrierwatermarkmaster/worker 的穩定性masterzookeeperworker-2worker-1可能的問題 與Z

7、ookeeper 斷開鏈接導致 lost leadership 作業 failover 資源超用被 kill 其他 container 使用資源過多影響 GC 頻繁導致優化方案 容忍 Zookeeper suspended 事件 資源超用預警 資源隔離 GC 告警控制鏈路的穩定性Sender1 requestHeartBeatReporter2 receive request3 retrieve payload4 report heartbeat5 received heartbeat6 reset timeout timerreport payload TimeTime心跳模型可能的影響因素

8、-網絡-RPC 響應耗時（等待處理&實際處理耗時）-外部影響（GC 等）相關指標-物理機的網絡情況-RPC 的響應耗時-container 的 gc 情況控制鏈路的穩定性可能的問題1.上游反壓導致 barrier 無法對齊（outPoolUsage 100%）2.snapshot 同步A.無法搶到鎖B.Task 主線程太忙3.異步階段的問題1.磁盤 IO 高2.HDFS 不穩定解決方案1.采集 task 相關指標進行告警2.snapshot 同步A.增加 snapshot 同步等待時間指標，并提供相關線程棧信息展示B.Task 主線程太忙 增加 CPU 使用率相關告警（container CP

9、U 超用告警）3.異步階段的問題1.使用 SSD 提高 IO 性能2.優化 Flink 使用 HDFS 的方式barrier 對齊同步階段異步階段HDFS本地磁盤snapshot 流程數據鏈路的通暢數量鏈路的通暢：是否反壓；是否數據傾斜影響反壓數據不能及時處理數據傾斜數據可能無法及時處理指標outqueue 100%不同算子間處理數據量差異作業監控關注指標關注指標相關監控相關監控container 穩定性-master failover 次數-GC 情況-FD 數目-磁盤占用情況-master fail 次數-作業 fail 次數-container 資源使用情況監控（CPU，Memory，F

10、D 等）master/worker 控制鏈路穩定性-心跳相關指標（GC，RPC 等）-snapshot 相關指標（barrier 對齊，同步和異步耗時）-RPC 耗時-snapshot 各階段耗時worker 間數據鏈路穩定性-反壓（outqueue）-數據傾斜(inputqueue/input reocrds)-inqueue/outqueue 使用率-不同并發間數據的處理情況故障恢復切換條件切換條件實施動作實施動作依賴依賴負載均衡負載均衡集群間的壓力不均衡，部分作業出現故障作業遷移checkpoint 跨集群遷移鏈路切換鏈路切換雙跑鏈路其中一條鏈路出現故障 能自動切換集群擴容集群擴容集群資

11、源不夠導致作業故障擴容集群災備降級災備降級集群資源不夠，且暫時無法擴容 按優先級進行作業降級作業故障作業故障作業 fail自動 failover（無法自動failover 的收到告警后人工干預）作業故障恢復Flink 作業的故障恢復1.Flink 檢測到 fail2.按照 global/region failover 的策略重新調度taskTask-1Task-2Task-3Task-4Task-1Task-2Task-3Task-4failover優化1.從空間上降低影響-無需全局重啟的 master failover-無需全局重啟的 Task 故障恢復單點重啟2.從時間上降低影響-優化 f

12、ailover 速度MasterMasterTask-1Task-3無需全局重啟的 master failoverTask-2MasterTask-1Task-3Task-2MasterTask-1Task-3Task-2MasterJobManager fail無需全局重啟（默認開啟 HA）藍色：原來 task紅色：failed master橙色：新 Task/masterTask-4Task-4Task-4Task-1Task-3Task-4無需全局重啟的 Task 故障恢復（有損）Task-2Task-1Task-3Task-4Task-2task failTask-1Task-3Tas

13、k-4Task-2無需全局重啟的優化藍色：原來 task紅色：failed task橙色：新 Task故障 task全局恢復-Task粒度單個Task故障導致其他Task吞吐和延遲受到影響單點恢復-Task粒度單個Task故障幾乎不會影響其他Task的吞吐和延遲作業粒度單點重啟保障作業大部分數據仍然得到有效處理當Task發生故障時，僅重啟發生故障的Task，而不需要重啟所有Task，降低數據整體的平均延遲或計算整體的可用性目前已在騰訊廣告太卜算法中臺上線，支持作業規模超過66萬核廣告模型業務，相對于數據完整性，更關心數據的實時性無需全局重啟的 Task 故障恢復（有損）Task 故障恢復速度優

14、化主要瓶頸master 主線程需要處理 Task 啟動階段大量 RPC 請求Container 拉取文件慢Container 需即時申請解決方案優化分布式協議，去除不必要的 RPC 請求合并 Jar 包，減少 Container 啟動所需的文件數目允許額外的備份 Container，避免故障時再去申請部署故障恢復時間從201s減少到48s故障恢復時間(s)并發度 4761MasterTaskTaskTaskTask1 取消 Task31sYARN2 申請資源20s3 部署 container39s111s作業 Task 故障恢復流程（Container 故障，重新申請資源）#3總結與展望總結開發部署演練測試功能測試部署SLA 評估監控SQL 體驗優化Canvas 語義對齊Jar 沖突檢測故障恢復有損單點重啟資源隔離鏈路雙活壓力測試故障演練可用性延遲監控亂序監控優化恢復速度master failoverlocalKeyBy/Backpressure-aware-Selector展望開發部署演練測試混沌測試部署在資源隔離的情況下提高使用率監控智能 IDE智能配置故障恢復大狀態的快速恢復智能診斷和優化無損單點重啟2021-12-05THANKS