周末去了趟外地，受托给某省移动公司(经确认更正，是中国移动位置基地，不是省公司)做了一下Hadoop集群故障分析和性能调优，把一些问题点记录下来。

该系统用于运营商的信令数据，大约每天1T多数据量，20台Hadoop服务器，赞叹一下运营商乃真土豪，256G内存，32核CPU，却挂了6块2T硬盘。还有10台左右的服务器是64G内存，32核CPU，4~6块硬盘，据用户反馈，跑数据很慢，而且会有失败，重跑一下就好了。

软件环境是RedHat 6.2，CDH Hadoop 4.2.1。

总容量260多TB，已使用200多T。

首先，这硬件配置属于倒挂，内存CPU和硬盘不匹配，因为作为Hadoop来说，注重的是磁盘的高吞吐量，而并发读写磁盘个数决定了吞吐量的大小。对于Hadoop来说，硬盘数量多比单盘容量大更具有优势。举例说明，假设一块硬盘的读写速度是210MB每秒，一块硬盘3TB，那么全部扫描一遍大概需要4小时左右。而1TB的硬盘扫描一遍大概只需要一个多小时。Hadoop最好的硬盘挂载方式是JBOD，也就是直接插主板不做raid。那么如果同时10块硬盘读写，得到的吞吐量是2.1G左右。20块就是4G左右。所以，对于Hadoop来说，30块1TB硬盘的性能要绝对优于10块3TB的硬盘。但是目前来说，性价比最高的还是2TB的硬盘。

还好只有20台服务器，可以挨个手工上去查一下，如果是200台，挨个查我就死在移动了。除了硬件配置不合理外，还查出几个比较重要的问题。

一、20台机器没有做机架感知，而且复制份数是2，因为受集群总存储能力限制，目前只能复制两备份，这个没辙了，以后扩服务器再说吧。

二、配置不合理，且没有为异构硬件搭配不同的Hadoop配置项

1. 因为采用CDH 4，所以实际是在YARN上跑MRv1，256G内存的服务器配置的map槽位数是150个，reduce槽位数是130个，其实是很大程度上超出了32核CPU的计算能力，绝大部分的CPU时间消耗在了MR Java进程之间的切换上。大量的Java进程用strace跟踪看都是在互斥锁上等待(FUTEX_WAIT)。所以，跑任务的时候服务器的System CPU很高，真正用于MR的User CPU很少。

2. 256G跟64G内存的服务器，Hadoop配置文件一样，64G也是150 map slots, 130 reduce slots，mapred.map(reduce).child.java.opt内存也没改，没发生OOM真是奇迹...MR槽位数不是越大越好，要跟CPU和内存数量搭配着算才好，至于2.0，更简单一些，只要配置vcore数量就行了，但是也不是vcore配的越大就越好。而且，据说搭建集群之前有公司给他们培训过Hadoop，居然告诉他们map,reduce槽位数的配置项没用，不用管，这培训也太坑人了吧。

3. 没有做磁盘保留空间，我到了现场以后没多久一台NodeManager就挂了，我以为是我神威所致，服务器害怕了，上去一看是硬盘100%了...

三、Linux系统层面没有做优化。

1. 没有开启TCP回收和TCP复用

2. 没有设置文件打开句柄数

3. 还有三台服务器没有关闭SELinux

4. 没有自动化运维，20台Hadoop服务器都是tar包解压缩手工装的。

5. 没有监控，据说是我去之前几天才装的Ganglia...监控数据采集了MR和HBASE，没有HDFS

6. 没有做数据压缩。

7. 小文件太多，块数量380万，文件数量360万。分块大小设定128M，上去看很多文件都达不到，基本都是40~80兆左右。

四、业务层面太过复杂。

1. 数据清洗依赖Hive进行，而没有采用编写MR的方式，Hive开发速度快，但是执行效率是真低啊。

2. 单个查询Join太多，并开启了Hive的并行查询，引发大量的Stage任务，占用太多MR槽位。

3. 同时并发计算太多，没有做Job分解和规划调度。

4. 清洗后的数据使用snappy压缩，这玩意计算读取的时候不分块的，只能1map读取。

总的来说，基本还是由于硬件配置不合理和对Hadoop底层不熟悉导致的性能较低，这个不是我这个层面能解决的问题了。

当然，这不是我见过的配置最不合理的硬件，记得去年年初中软国际卖某部委的Hadoop服务器，找我给配置，128G内存，64核CPU，4块2T盘。当时我看着这服务器是真不知道该怎么配才合适。当时说给钱，到现在也没给，赖账了这帮孙子...

其实搞hadoop，不仅仅只是搭起来能跑那么简单，传统运营商基本还是拿传统的思维观念在看待这些新生的开源事物，认为单个机器CPU足够多，内存足够大，就不需要很多台机器了。如果只是这样简单的话，就不需要开发Hadoop了，谷歌只要弄个牛逼配置的大型机，继续用Oracle就好了。Hadoop也好，Spark也好，更多的是蚂蚁啃大象的思路，虽然单个机器烂，但是只要足够多，也可以解决大问题。

云服务也好，大数据也罢，真正注重的是运维的能力，运维强则数据强