报告预览

张蛟-小米基于 Flink 的稳定性优化与实践.pdf

编号：101914

PDF 37页 44.57MB 下载积分：VIP专享

下载报告请您先登录！

张蛟-小米基于 Flink 的稳定性优化与实践.pdf

1、张蛟/小米高级软件工程师Apache FlinkApache Flink在小米的在小米的稳定性优化和实践稳定性优化和实践Stability optimization and practice of Apache Flink at Xiaomi发展现状发展现状和规模和规模稳定性优化稳定性优化及实践及实践运维优化运维优化及实践及实践未来规划未来规划与展望与展望#1#2#3#4#1#1发展现状及规模发展现状及规模整体架构业务层广告推荐搜索OneDataXDATA 数据查询与存储Presto/TrinoDorisKuduIcebergElastic SearchKylinHive 计算层Flink J

2、arFlink SQLSparkSparkStreamingYARN消息队列消息队列(Talos/RocketMQ)数据工厂数据采集Web埋点业务日志ServiceLogMySQLTiDBHBaseLCS AgentBinlog/Source发展现状和规模主力版本1.121.14版本已上线30003000+运行作业运行作业峰值处理2亿条每秒日均日均10w10w亿亿+消息消息国内外10+集群4 45 5000000+CPU CoreCPU Core日处理PB级消息量200TB200TB+MemoryMemoryUsedUsed面临的问题与挑战作业内存不可控，易出现YARN OOM Kill导致C

3、ontainer LostOn YARN模式无法自动平滑重启，只能触发failover实时作业对负载敏感，启动和运行时需要保证机器性能Checkpoint使用中遇到的稳定性问题HistoryServer占用磁盘空间大，访问慢，只能手动清理作业异常时难以确定异常原因及节点，排查困难#2 2稳定性优化及实践稳定性优化及实践Container Lost优化Flink JobManagerYARN ResourceManager申请资源返回资源YARN NodeManagerYARN ContainerFlink TaskManagerYARN ContainerFlink TaskManager分配

4、资源启动TaskManager心跳Container Lost问题Container Lost现象(一)Container Lost问题Container Lost现象(二)Container Lost问题YARN OOM KillContainer Lost原因存在的问题1.定时扫描对于进程内存突增情况的隔离性差，可能还没开始扫描就已经被系统kill2.节点资源的超卖导致节点的不稳定3.对于作业临时性内存需求的支持不是很好，即使节点有多余内存仍会触发killYARN NodeManagerContainersMonitor线程YARN ContainerFlink TaskManager启动

5、定期扫描Container Lost优化CgroupJDK升级切换JemallocCgroup内存软限制内存软限制OOM-Listener监听OOM-Event达到节点内存总大小是选取内存超过申请内存，启动时间最短，优先级最低的作业触发OOM KillGlibc分配问题可以解决一部分问题，仍然存在glibc分配问题Container Lost优化1.Cgroup对于rocksdb等造成的内存临时超用问题有效，但无法根本解决内存持续溢出或分配异常2.升级JDK解决Jemalloc导致的线程死锁bug3.切换Jemalloc解决Linux系统下64M anon分配问题Container Lost优

6、化4802.0.1000.2000.3000.4000.5000.月份Unit:1,000,000 US$20222105202106减少作业OOM kill重启 90%以上数量节点平滑重启提前预防可能的隐患云环境下作业的稳定性避免框架内重启影响YARN模式恢复时间问题机器过保机器下线机房迁移恢复时间长作业平滑重启周期处理，避免Node Decommission消息频繁触发批量处理，避免Node Decommission消息造成瞬时负载压力节点去重，避免对同一作业重复触发YARN NodeManagerNode DecommissionFlink R

7、esourceManagerFlink JobManager平台自动检测任务状态并重新拉起Flink作业StopWithSavepointFlink JobMaster快速触发，缩短节点下线周期节点黑名单全局黑名单指标集合/判定节点黑名单JobManager指标监控平滑重启框架内重启内存磁盘I/O CPU指标规则Checkpoint优化CheckpointCoordinatorSourceTalosMapSinkTalosTriggerCheckpointCheckpointBarrierCheckpointBarrierNotifyCheckpointCompleteNotifyCheckp

8、ointCompleteNotifyCheckpointCompleteAckCheckpointAckCheckpointAckCheckpointCheckpointCoordinatorSnapshotStateSnapshotStateSnapshotStateCheckpoint优化磁盘满或其他I/O异常导致Checkpoint长期无法触发，潜在隐患重启时无法从Checkpoint恢复，导致消息丢失或积压Checkpoint小文件过多，引发大量RPC负载压力用户错误配置Checkpoint目录，无法控制，排查困难Checkpoint优化StateSnapshotHDFS磁盘满、磁盘异

9、常、Kerberos文件损坏等怎么办？捕获异常，根据异常栈判断和重试，或者增加checkpoint失败计数，超过一定次数则框架内重试或告警Checkpoint优化重启时默认使用最新的Checkpoint恢复如何确定最新的Checkpoint默认保留数量Metadata文件临时化Finalize时提交为正式文件文件按最新修改时间排序确保文件最后修改时间的正确性任务成功时默认不删除文件Savepoint时默认不Discard文件Checkpoint启动时清理策略Savepoint文件生命周期配置增量Checkpoint按使用情况清理读取Metadata内容确定使用情况Checkpoint优化Che

10、ckpoint目录可由用户任意配置，造成冲突和负载压力Meta文件增加作业名、时间戳校验，不通过时告警合并小文件、联邦集群多NameNode均衡RPC负载、统一Checkpoint目录，并通过HDFS挂载表读旧写新，自动迁移案例、数据采集小米统计SDKBI SDK自打点第三方采集消息队列(类Kafka)FlinkFlink消息队列Doris用户行为看板实时应用看板750+海内外业务接入日均1.6K亿+数据RPC延迟降低40%小文件减少Exactly Once案例、数据采集#3 3运运维优化实践维优化实践Flink HistoryServer 优化存在的问题2.作业历史日志文件系统可能不支持过期

11、，导致缓存的作业长期存在3.历史日志最大值不好确定，可能基础服务的异常导致同时出现大量失败，冲走有效日志4.没有记录TaskManager上的相关日志，不利于异常排查1.服务重启造成缓存的作业ID丢失，形成悬浮缓存作业获取已被缓存的作业ID获取作业的历史日志历史日志未超配置的最大值执行清理否是缓存的作业在历史日志中不存在是HistoryServer 优化HistoryServer优化对比逻辑优化本地缓存对比历史日志记录清理支持历史日志最长保留时间TaskManager日志优化TaskManager和Container数据支持archive和清理作业全链路心跳监控SourceTalosMapOP

12、_SOURCE_0_OP_1_0,time_used_1OP_SOURCE_1_OP_1_0,time_used_2SinkTalosSourceMapSinkOP_SOURCE_0_OP_1_0_OP_2_0,time_used_1OP_SOURCE_1_OP_1_0_OP_2_0,time_used_2OP_SOURCE_0_OP_1_1_OP_2_0,time_used_3OP_SOURCE_1_OP_1_1_OP_2_0,time_used_4MetricsReporterOP_SOURCE_0_OP_1_1,time_used_1OP_SOURCE_1_OP_1_1,time_use

13、d_2OP_SOURCE_0,timeOP_SOURCE_0,timeOP_SOURCE_1,timeOP_SOURCE_1,timeOP_SOURCE_0_OP_1_0,timeOP_SOURCE_1_OP_1_0,timeOP_SOURCE_0_OP_1_1,timeOP_SOURCE_1_OP_1_1,timeOP_SOURCE_0_OP_1_1,timeOP_SOURCE_1_OP_1_1,timeOP_SOURCE_0_OP_1_0,timeOP_SOURCE_1_OP_1_0,timeOP_SOURCE_0_OP_1_0_OP_2_1,time_used_1OP_SOURCE_1_

14、OP_1_0_OP_2_1,time_used_2OP_SOURCE_0_OP_1_1_OP_2_1,time_used_3OP_SOURCE_1_OP_1_1_OP_2_1,time_used_4MetricsReporter作业全链路心跳监控全链路心跳监控触发越频繁，对各节点监控的采样越准确全链路心跳监控触发越频繁，监控信息越多，影响正常消息的传递提升处理性能Chain operator metrics合并上报Restful接口动态启停配置增加对数据量的预估和监控配置动态调整ClientRest请求Flink JobMasterHandlerGatewaySchedulerAPICheck

15、pointCoordinator调整CheckpointConfigAPITaskManagerGatewayAPITaskAPI其他调整接口API调整全链路心跳监控/日志级别等配置动态调整配置动态调整#1动态日志级别调整或其他场景动态日志级别调整或其他场景其它配置的调整，Restful接口的调整暂时没有持久化，调整完成后的配置会因为框架重启原因等失效心跳信息过多心跳信息过多作业出现性能问题或Checkpoint超时等问题时通过Restful接口动态开启，确定问题后停止CheckpointCheckpoint超时超时负载突增、短时数据倾斜导致Checkpoint超时，动态增大超时时间，超时时间确定#2#3#4 4未来规划未来规划提高资源利用率和作业稳定性自动弹性伸缩容145632降低运维压力，紧跟社区版本收敛提升大状态作业速度，优化性能State读写性能优化减少GC停顿，提升作业稳定性Heartbeat Timeout问题减少作业因各种原因造成的断流时间启动和恢复性能优化继续完善对Batch模式和数据湖的支持批流融合能力20212021-1212-0505THANKS

友情提示

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

本文（张蛟-小米基于 Flink 的稳定性优化与实践.pdf）为本站（云闲）主动上传，三个皮匠报告文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若此文所含内容侵犯了您的版权或隐私，请立即通知三个皮匠报告文库（点击联系客服），我们立即给予删除！

温馨提示：如果因为网速或其他原因下载失败请重新下载，重复下载不扣分。

上海品茶

张蛟-小米基于 Flink 的稳定性优化与实践.pdf

张蛟-小米基于 Flink 的稳定性优化与实践.pdf