劉建剛-全球化視野下的多云數據架構.pdf

《劉建剛-全球化視野下的多云數據架構.pdf》由會員分享，可在線閱讀，更多相關《劉建剛-全球化視野下的多云數據架構.pdf（28頁珍藏版）》請在三個皮匠報告上搜索。

1、DataFunConDataFunCon#20242024快手快手Flink on k8sFlink on k8s的遷移的遷移與穩定性保障與穩定性保障演講人：劉建剛-快手-技術專家ContentsContents目錄目錄快手Flink介紹大規模遷移實踐穩定性保障未來規劃logo0101 快手快手FlinkFlink介紹介紹發展歷程 Flink生產可用改造 實時計算平臺建設 公司實時化轉型2018-2020 流批一體探索 易用性、穩定性、功能性深度優化2021-2022 Flink on k8s Runtime adaption 湖倉一體建設 AI場景大規模落地2023-2024整體架構應用規模

2、0202 大規模遷移實踐大規模遷移實踐背景公司需求 統一、高效的資源管理與調度。技術趨勢 Kubernetes已發展為容器編排的事實標準。Flink發展 彈性伸縮 存算分離 Runtime adaption2018-20222018-2022 FlinkFlink onon yarnyarn 初期跟Flink結合的比較好。調度性能好，支持上萬節點?？梢杂行У卣螲adoop生態。2023-20242023-2024 FlinkFlink onon k8sk8s 統一的云生態和豐富的應用。統一的資源管理(資源置換、混部)。更好的隔離性。架構演進核心痛點設計設計組件交互的平滑遷移用戶交互的無感知開

3、發開發功能集成異常診斷測試測試如何達到上線條件。遷移遷移如何快速、批量遷移。設計挑戰：挑戰：1.系統組件眾多，都是圍繞yarn來構建。2.用戶更熟悉yarn，對k8s沒有概念。方案：方案：組件復用與拓展，支持邏輯上的集群、隊列概念。用戶接口不變，保障體驗一致性。開發-組件交互開發-指標觀測背景背景Metric是可觀測性的重要一環，k8s metric存在以下問題：1.Flink on k8s以pod為粒度匯報指標，連接數過多。2.海量metric存在性能問題，比如Prometheus擴展性差。3.如何跟之前的metric處理保持兼容。實現實現1.通過kafkaGateWay來減少與kafka的

4、連接。2.采用clickhouse+grafana的metric處理方式。3.K8s和yarn的metric統一到kafka topic，進行統一的展示。開發-日志查看背景背景問題排查最重要的是查看日志，但是k8s存在以下問題：Pod結束后，日志也會隨之消失，導致無法排查問題。Pod異常時，如何進行pod的問題診斷。實現實現我們開發了日志服務來解決用戶問題排查的痛點：通過hostPath將日志存到本地磁盤，由k8s定期清理。針對常規日志，通過日志服務的web界面查看。針對重要日志，將日志采集到ES，提工具全局分析能力。另外，我們還通過日志服務為用戶展示pod event事件來診斷pod異常。測

5、試確保功能完善、穩定性高、性能不回退。類型類型說明說明集成測試組合各個組件和功能，進行端到端的測試，確保整體流程順暢。故障測試1.Flink自身，包含master、slave節點的failover。2.k8s，比如etcd、kubelet、master切主等的異常。3.集群硬件異常，包含機器假死、磁盤故障、網絡異常等。性能測試1.Flink自身性能。2.K8s apiServer性能。3.K8s調度性能?；貧w測試為后續的新環境提供回歸測試，確?？焖俚?。遷移原則原則 優先選擇低優、拓撲簡單的作業。監控報警，出現問題及時回滾。支持批量自動遷移。選擇一批作業修改作業到k8s集群重啟作業并從快照恢復

6、監控作業健康度一旦出現問題及時回滾收益資源上，資源上，統一了大數據和容器云兩大資源池：資源置換上，從天級降到分鐘級。運維效率上，統一的機器配置能大幅降低人力成本。資源利用上，在離線混部能提高集群利用率。其他：其他：Flink層面，彈性伸縮成為趨勢。用戶層面，資源管理更加便捷。0303 穩定性保障穩定性保障背景易用性性能功能穩定性穩定是重中之重穩定是重中之重穩定是實時計算低延遲最重要的保障。公司核心業務的延遲要求在秒級。穩定可以減少人力損耗和資源成本，助力降本增效。穩定性保障的難點穩定性保障的難點Flink是long-running的在線計算，保障級別高。影響因素繁多，包括用戶代碼、周邊組件、系

7、統環境等。Flink運維成本極高，問題排查錯綜復雜。Flink作為新興技術，延遲要求高、計算拓撲復雜。保障能力FlinkFlink故障故障 Master failover Task failover熱點問題熱點問題 數據，自動打散與rebalance 機器，自動規避和驅逐軟件問題軟件問題 業務邏輯，工具輔助 周邊組件，風險排除硬件故障硬件故障 機器問題，自動拉黑 AZ故障，自動容災本章主要介紹挑戰最大、影響最廣的AZ逃生技術！AZ逃生背景背景1.AZ故障，風險大（近一年兩次斷電風險）、人力緊，影響面廣（所有服務和數據）。2.公司AZ逃生專項，實現國內和海外的AZ容載能力。3.為應對AZ逃生，F

8、link on k8s屏蔽了底層集群概念、只暴露AZ大資源池。自底而上、自左而右，必自底而上、自左而右，必須都具備逃生能力，包含須都具備逃生能力，包含其他鏈路依賴！其他鏈路依賴！AZ逃生FlinkFlink引擎引擎 挑戰一：Flink job配置綁定集群，一旦生成無法修改集群 克隆生成新集群作業步驟復雜，作業冗余 支持修改集群，啟動時動態生成集群配置！挑戰二：Flink快照存在本集群HDFS，AZ故障時會丟失 HDFS支持多AZ副本性能差，實現難。工具拷貝到備集群難維護，難高可用。Flink支持定期跨AZ快照高性能，好使用！AZ逃生實時平臺實時平臺挑戰一：資源不足，引發資源搶占、全局高負載等問

9、題建立分級保障制度，優先保障核心業務的SLA（支持搶占）、以Flink整體利益最大化為目標。挑戰二：10分鐘內完成幾十萬核、上千作業的逃生操作。相比存儲服務，單Flink切換操作重（完全停止、重新啟動）通過壓測，發現HDD盤高負載jar包下載性能減弱10倍，優化如下：云盤解決單機IO瓶頸的問題，存儲上實現水平擴容。通過多線程異步加載jar包，徹底抹去jar包下載時間！雙AZ熱備P0 雙AZ冷備P1 常規作業P2 低優作業，易被強占P3AZ逃生業務方業務方挑戰 保障全鏈路AZ逃生能力 建設定期溝通機制，提供用戶手冊、指導用戶改造。自動巡檢，通過血緣等檢測作業逃生能力。資源管理，協調用戶資源騰挪、提示資源風險等。同時，定期演練，確保整體的逃生能力并無一遺漏。AZ逃生整體架構整體架構AZ逃生結果結果1.整體逃生由小時級別降低到分鐘級別，主要通過IO異步加載、水平擴展及云盤存儲等技術。2.建立起分級保障機制，在AZ逃生、資源優化、穩定性保證等方面意義重大。0404 未來規劃未來規劃未來規劃存算分離分層存儲，支持超大狀態全面提升穩定性和性能Runtime adaption動態擴縮容動態增、刪、改算子湖倉一體建設 支持流批一體的計算引擎支持統一的數據湖存儲感謝觀看感謝觀看