2017年携程大数据平台实践.pdf

《2017年携程大数据平台实践.pdf》由会员分享，可在线阅读，更多相关《2017年携程大数据平台实践.pdf（46页珍藏版）》请在三个皮匠报告上搜索。

1、携程大数据平台实践OPS/IT/CC提纲大数据平台现状大数据平台现状“成长的烦恼”“成长的烦恼”再谈稳定性再谈稳定性系统“走马观花”系统“走马观花”挑战和未来挑战和未来大数据平台现状OPS/IT/CC平台规模主集群规模180 1100+台 X6数据增量（每天）250T 数据表数量正式表60000+调度任务数（每天）50000+运行实例120000+底层任务数（每天）310000+实时集群规模100+实时作业数290+Jstorm 40+Spark-streaming20152017OPS/IT/CC平台架构OPS/IT/CC团队规模小而精干REN SHAO SHI DUO底层数据架构：9+1开

2、发和查询平台：6+1运维数据分析：4+1*日常维护支持新技术调研落地“成长的烦恼”OPS/IT/CC“成长的烦恼”有什么？运维：系统规模不断扩大系统繁多，复杂性高开源系统开源是把“双刃剑”快速构建起相应的系统随着系统规模的增大，开源系统的问题不断地暴露出来服务和支持用户不断增长的“物质文化需求”与“短小精悍”团队之间的矛盾临时的支持，问题排查工作变多OPS/IT/CC运维-应对策略总体策略：“自动化”：节省运维成本，保证环境和配置一致运维自动化初始安装/变更覆盖范围尽可能全（特别是客户端）覆盖范围尽可能全（特别是客户端）监控+失败的自动回复确定的，风险不大的失败点（进程监控/Thrift Se

3、rver的可用性监控）多次自动回复失败需要升级我们的惨痛教训：2015-09 Kerberos升级OPS/IT/CC开源系统-应对策略总体策略：建立“代码级”维护能力招聘时就要选择对技术有浓厚兴趣，能够沉的下心来的同学在底层团队通过各种层次的分享建立学习，研究的氛围代码学习小组全员学习，模糊职位的边界培养方向：一专多能模糊开发和运维的边界思想上做好长期斗争的准备“深挖洞（加深对现有系统的理解）”，“广积粮（基础知识/新系统调研）”！OPS/IT/CC实例：Hadoop调优Hadoop调优是一项长期工程从2016年10月开始（CDH4.6-CDH 5.7.1升级完成,79个commits）我们几

4、乎每1-2个月会遇到1个影响集群的稳定性/效率的问题，而且每次问题的Root Cause往往并不相同实例一：RM调优在业务高峰的4点-10点，集群的使用率偏低通过YARN的主页面我们发现，集群的Used的Vcores只占Vcores Total的70%-80%通过一段时间的分析，我们发现瓶颈在YARN的Fair Scheduler的效率上OPS/IT/CC实例：Hadoop调优实例二：NN优化2017-01底到2017-02初，我们发现在早上6-10点，集群的利用效率有多次较大的下跌我们分析发现，NN的RPC平均处理时间（RpcProcessingTimeAvgTime）较高解决方法：给NN减

5、负，增效HDFS-9198 HDFS-7964 HADOOP-12483主节点优化的总结1.发现发现问题问题：关注集群总体的利用率；关注NN和RM的关键指标（RPC ProcessTime/Call Queue Length）和GC指标2.分析分析问题问题：分析NN和RM更加细致的指标（GC问题的话分析GC Log）；通过线索在去搜索相应的Jira，筛选Jira，通过Jira查看和分析相关的Code3.在保证稳定性的前提下进行尝试尝试OPS/IT/CC服务和支持-应对策略总体策略：从使用者的角度去设计产品，关注用户的易用性控制推广的节奏Early Adopter-1个BU-全面铺开完善文档，常

6、见问题FAQ“授人以渔”：增强BU数据开发的工程技术能力全员客服 短期再谈稳定性OPS/IT/CC平台的稳定性是项系统工程流程合理的流程能够降低人为事故发生的概率，及时发现问题流程无法一簇而就，从失败中学习，举一反三很重要能做“灰度”的一定要做“灰度”提升团队成员的责任心技术设计尽量简单，复杂的设计修改容易出错合适的重试机制帮助很大木桶效应：关注所有有影响的系统的短板OPS/IT/CC实例：数据开发平台的稳定性提升2015年下半年，数据开发平台几乎每个月都会发生1次全局性延迟的大故障第1阶段：快速止损：通过发布后轮