上海品茶

您的当前位置:上海品茶 > 报告分类 > PDF报告下载

邱从贤-大规模作业的稳定性优化实践.pdf

编号:101811 PDF 32页 3.05MB 下载积分:VIP专享
下载报告请您先登录!

邱从贤-大规模作业的稳定性优化实践.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

友情提示

1、下载报告失败解决办法
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站报告下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。

本文(邱从贤-大规模作业的稳定性优化实践.pdf)为本站 (云闲) 主动上传,三个皮匠报告文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三个皮匠报告文库(点击联系客服),我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。
会员购买
客服

专属顾问

商务合作

机构入驻、侵权投诉、商务合作

服务号

三个皮匠报告官方公众号

回到顶部