相信每个集群管理员在长期管理多个不同规模、不同应用场景的集群后，都会有感慨。其实在我看来，这是一个很微妙的事情，就是大家开始人性化的对待每一个集群。既然是人性化的管理集群，我总会思考几个问题：集群有什么特别之处？集群常患什么病？集群引发的突发疾病如何精准定位？应急响应故障排除后如何避免去旧加新？在大规模集群治理的长期实践中，我们也形成了自己的西医（排错）、中医（回诊分析）、健身预防（定期优化）手段和产品。下面我通过三魂自虐分享一下自己大规模集群治理的经验总结。灵魂拷问1有大量的集群。有什么特点？集群多、规模大：管理近20个集群，最大的xxx集群和xx集群达到1000+节点规模。拷问2中，哪些疾病容易丛生，有哪些隐患？集群在整体功能、稳定性和资源使用方面会有一些痛点。集群治理中常见的问题包括文件过多、小文件过多、RPC队列深度过高、各组件版本bug、使用组件时生产严重失败、资源浪费等。拷问3集群突发疾病如何准确解决故障？对于集群的突发故障，平台要有全面、及时的监控和告警，做到分钟级发现告警故障，推送告警通知。这是快速解决故障的前提。对于集群的慢性病，??从底层收集可用的详细数据，分析并报告，通过长效治理有效保障集群的深层次健康（详见《运维老司机都想要掌握的大数据平台监控技巧》）),发展形成即可实施。企业数据资产管理和数据治理产品。下面将一一解答如何解决以上九种集群问题或故障。1、底层计算引擎老旧，业务处理占用资源多，速度极慢。集群底层使用MR计算引擎，大量任务没有得到很好的优化。大部分任务占用上千核、上百TB内存，对集群造成很大的IO读写压力。解决方案：通过监控“大头”，找出消耗资源较多的任务，通过业务、计算引擎、调参优化集群资源的使用，提升集群计算能力。业务优化：从业务角度理清源数据，减少加载数据量。计算引擎优化：MR到Spark。参数调优：小文件合并优化、内存内核调优、并发调优、数据倾斜预防。2.xx集群RPC失败问题。现象概述：XX产线集群提交作业，执行缓慢；业务数据处理逻辑是从HDFS读取新文件>>>到HBase；遍历列表文件的周期为5s。根本原因分析：解决方法：阅读RPC源码：动态代理机制+NIO通信模型。调整NNRPC的关键参数，做对比实验。1）优化系统参数配置：ipc.server.handler.queue.size；dfs.namenode.service.handler.count2）HDFS千万级目录扫描周期从5s调整为5分钟3）按时间增加集群RPC请求业务模型深度监控3.自xx集群托管外部多租户，各个租户对集群生产环境提出的要求不一致，导致集群环境复杂。运营和维护成本。解决方案：集群环境多版本异构管理：配置多版本Python环境，搭建私有第三方库。配置多版本Spark和Kafka环境。实时监控yarn队列资源使用情况，监控yarn应用任务，重点优化。配置详细的接口机监控，优化接口机负载。接口机对CPU内存消耗过大的进程进行基础指标监控、置顶分析、多维度监控，及时合理调整优化接口机调度任务，降低接口机负载。4、由于xxx集群文件较多，导致集群运行缓慢，NameNode进程下线。集群的文件对象达到9000万以上。而集群的读写IO是写多读少。NameNode启动需要加载大量区块信息，启动时间过长。解决方案：计算引擎优化：尽量使用Spark，高效利用内存资源，减少磁盘IO读写。定期清理：定期协调业务人员根据HDFS业务目录存储增量清理相关无用业务数据。块大小管理：合并小文件，将块大小增加到1GB，减少小文件块的数量。深度清洗：收集并监控auit日志，对HDFS文件系统进行多维画像。深度清理无用数据表、空文件、废文件。5、HDFS数据目录权限管理混乱，经常导致数据被误删或丢失。因为委托的权限没有及时收回，或者一些误操作导致数据被误删、丢失。解决方案：业务划分：明确梳理各业务对应的权限用户，整顿当前HDFS数据目录结构，分离生产库和测试库的控制权。数据生命周期管理：6.YarnJOB导致节点负载过大，影响其他作业的运行。部分节点CPU负载过高，影响作业任务的运行。发现部分节点的负载从9:30到现在一直偏高，导致job任务执行了7个小时左右。解决方法：找到执行耗时任务的节点，确实发现负载高，找到这个任务对应的进程。查看这个进程的堆栈信息，发现有多次FullGC，持续时间大约6小时。频繁的FullGC会导致CPU使用率过高。查看job进程详情，发现java堆内存只有820M，任务处理的记录数超过7400万条，导致堆内存不足导致频繁FullGC。建议下次执行任务时设置如下参数大小：hive>setmapreduce.map.memory.mb=4096;hive>setmapreduce.map.java.opts=-Xmx3686m;7、部分Hive表切换NameNode后无法查询。切换小集群的NameNode，无法使用某Hive数据库下的表及其关联表，报错如下：截图报错，说明当前NameNode节点是standby节点。经过排查，发现Hive的Metadata中部分分区列的属性仍然保留了之前配置的NameNode位置。解决方法：备份Hive所在的MySQL元数据库#mysqldump-uRoot-pPasswordhive>hivedump.sql;进入Hive所在的MySQL数据库执行，修改Hive数据库下SDS表下的位置信息，涉及9739行。将指定IP的位置替换为名称服务；UPDATESDSSETLOCATION=REPLACE(LOCATION,'hdfs://ip:8020','hdfs://nameservice1')whereLOCATIONlike'hdfs://ip%';切换NameNode验证受影响的Hive表是否可用；验证业务的各个方面；变更影响范围：本次变更可线上实施，避开业务繁忙期，对业务无影响；回退计划：从备份mysqldump文件数据库恢复mysqlhive元素mysql-uUsername-pPasswordhive
