大数据 张翼-携程大数据平台实践_大数据and人工智能专场.pptx

携程大数据平台实践Pus我介绍6龍 OPS/IT/CC张翼超过10年的互联网从业经验，超过7年的数据系统相 关的经验浙江大学：本科研究生Ebay：软件开发工程师大众点评：资深软件开发工程师-〉技术经理携程：大数据平台技术总监提纲6龍 OPS/IT/CC、挑战和未来大数据平台现状Pus平台规模6龍 OPS/IT/CC主集群规模 180 -1100+台X6数据增量（每天）250T数据表数量正式表60000+调度任务数（每天）50000+运行实例120000+底层任务数（每天）310000+2017z\实时集群规模100+实时作业数 290+ Jstorm ~40+ Spark-streaming2015平台架构6龍 OPS/IT/CC开发平台Zeus查询平台ART机器学习 算法平台调度 主数据传输 数据质量报表■/OLAP 命析即时查询基于Spark图 形化AI平台实］吋数据平台GPU云平台分布式存储和计算框架实时框架______Spark.-St r earn i n gHiveSparkPrestoBBMHHermes (Kafka)Hadoop资源部鄙运雜监控自动运维系统大数据监控系统团队规模6龍 OPS/IT/CCREN SHAO SHI DUO而精干小底层数据架构：9 + 1开发和查询平台：6 + 1运维数据分析：4+1*日常 维护 支持.调研落成长的烦恼〃成长的烦恼有什么?6龍 OPS/IT/CC运维：?系统规模不断扩大-系统繁多，复杂性高开源系统-开源是把“双刃剑”?快速构建起相应的系统-随着系统规模的增大，开源系统的问题不断地暴露出来服务和支持-用户不断增长的“物质文化需求”与“短小精悍”团队之间的矛盾 ?临时的支持，问题排查工作变多运维-应对策略6龍 OPS/IT/CC总体策略：-“自动化”：节省运维成本，保证环境和配置一致?运维自动化?初始安装/变更-覆盖范围尽可能全（特别是客户端）?监控+失败的自动回复?确定的，风险不大的失败点（进程监控/Thrift Server的可用性监控）-多次自动回复失败需要升级?我们的惨痛教训：2015-09 Kerberos升级开源系统-应对策略6龍 OPS/IT/CC思想上做好长期斗争的准备“深挖洞（加深对现有系统的理解），“广积粮（基础知识/新系统调研）总体策略：-建立“代码级”维护能力-招聘时就要选择对技术有浓厚兴趣，能够沉的下心来的同学-在底层团队通过各种层次的分享建立学习，研究的氛围-代码学习小组?全员学习，模糊职位的边界-培养方向：一专多能?模糊开发和运维的边界实例：Hodoop调优6龍 OPS/IT/CCHadoop调优是一项长期工程从2016年 10月开始（CDH4.6 - CDH 5.7.1 升级完成,79个commits）我们几乎每1-2个月会遇至U1个影响集群的稳定性/效率的问题，而且每次问题的Root Cause往往并不相同实例一：RM调优在业务高峰的4点-10点，集群的使用率偏低 通过YARN的主页面我们发现，集群的Used的Vcores只占Vcores Total的70%-80%通过一段时间的分析，我们发现瓶颈在YARN的Fair Scheduler的效率上/jira/browse/YARN-5188httDS/jira/browse/YARN-5188：/jira/browse/YARN-5188〃/jira/browse/YARN-5188issues.aD/iira/browse/YARN-5188DOOM』npasNodesNOW54 3DMin5430Avg54 3DMax543.CPUSNOW15BkMi n15BkAvg15BkMax15.F rocsNOW24kMi n1IkAvg116kMax20.实例：Hodoop调优6龍 OPS/IT/CC实例二：NN优化2017-01底到2017-02初，我们发现在早上6-10点, 集群的利用效率有多次较大的下跌我们分析发现，NN的RPC平均处理时间(RpcProcessingTimeAvgTime)较高解决方法：给NN减负，增效/jira/browse/HDFS-9198HDFS-9198/jira/browse/HDFS-7964 HDFS-7964/jira/browse/HADOOP-12483 HADOOP-12483主节点优化的总结1. 发现问题：关注集群总体的利用率；关注NN和RM的关键指标(RPC Process Time / Call Queue Length)和GC指标2. 分轿问题：分析NN和RM更加细致的指标(GC问题的话分析GCLog)；通过线 索在去搜索相应的Jira,筛选Jira,通过Jira查看和分析相关的Code3. 在保证稳定性的前提下