Hadoop几乎成了大数据处理的代名词那个。但是 你是否也曾遇到过这样的情况：明明硬件配置不差，集群跑起来却像老牛拉破车，Job卡在99%迟迟不动，或者NameNode内存溢出搞得你焦头烂额？说实话，很多时候这并不是Hadoop不行，而是我们太“粗暴”了。默认配置往往是为了“能跑”而设计的，而不是为了“跑得快”。今天 我们就抛开那些枯燥的教科书式定义，像老朋友聊天一样，深入探讨如何通过精细化的配置优化，把你的Hadoop集群从“拖拉机”改装成“法拉利”，火候不够。。

一、 硬件与操作系统：打好地基是关键

在谈论Hadoop配置之前，我们必须先看看脚下的路平不平。硬件和操作系统是Hadoop集群的土壤， 希望大家... 土壤贫瘠，再好的种子也长不出参天大树。

1. 硬件资源的合理分配

行吧... 很多新手容易陷入一个误区：所有机器配置必须一模一样。其实不然。Hadoop集群的角色分工明确，硬件配置也应该有所侧重。

Master节点是大脑，它不负责繁重的计算，但负责调度和元数据管理。所以呢，它需要大量的内存来存放目录结构，但对CPU和磁盘IO的要求相对较低。如果你吝啬内存，NameNode频繁Full GC，整个集群都会跟着“抽风”。相反， Slave节点是苦力，它们需要大量的磁盘空间存储数据，需要多核CPU来处理计算任务，内存适中即可。

这里有一个简单的配置建议表， 供大家参考：

角色	CPU	内存	硬盘	网卡
NameNode	8-16核	64GB - 128GB	RAID 10	万兆
DataNode	16-32核	48GB - 64GB	4-6块 4TB SATA	千兆/万兆

2. 操作系统内核参数调优

Linux默认的参数是为了通用场景设计的，对于高并发、大吞吐量的Hadoop这些参数往往显得过于保守。如果不调整，你会发现大量的连接请求被丢弃，或者网络传输慢得像蜗牛。

你需要编辑/etc/sysctl.conf文件，把下面这些参数加上去。别嫌麻烦，这真的是血泪经验：，我倾向于...

• net.core.somaxconn=65535增加socket监听队列的长度。默认只有128，这在Hadoop高并发场景下简直就是瓶颈，必须调大。
• net.ipv4.tcp_max_syn_backlog=65535SYN队列长度，防止在大规模并发连接时被丢包。
• net.ipv4.tcp_rmem=4096 87380 16777216TCP接收缓冲区。调大这个值，可以显著提升网络数据吞吐量，特别是对于数据传输密集的Shuffle阶段。
• net.ipv4.tcp_wmem=4096 65536 16777216TCP发送缓冲区， 同理，让数据发得更快。

引起舒适。 修改完记得施行sysctl -p让配置生效。再说一个，强烈建议关闭Swap分区！swappiness设置为0或者10。主要原因是JVM的垃圾回收机制和操作系统的Swap机制简直是天敌， 一旦系统开始Swap，你的Hadoop任务性能就会呈断崖式下跌。

二、 环境搭建：别让低级错误拖后腿

尊嘟假嘟？ 环境搭建看似简单，但很多坑都在这里。有时候一个环境变量没配对，或者权限没开好，排查起来能让你怀疑人生。

1. Java环境与用户权限

试试水。 主要原因是Hadoop是基于Java开发的，所以JDK是必须的。这里有个小细节，请务必保证Hadoop能找到Java的路径。通常我们会修改hadoop-env.sh或者~/.bashrc设置JAVA_HOME。

深得我心。 关于用户权限， 虽然用root用户安装配置最省事，权限最高，能保证配置顺利进行，但这简直是“裸奔”。为了平安起见，我们通常会创建一个专门的hadoop用户。这里我安装的JDK版本是 jdk-6u38-linux-i586.bin， 可用其他版本，但需要修改环境变量以及后面的配置路径。

每个主机的登陆用户名也最好都一样， 比如都是hadoop不然到再说说启动Hadoop时会出现不管你密码是否输入正确，都会提示权限不够的错误。 卷不动了。 如果你之前装系统时没注意到这个问题， 可以之后在每个主机上都新建一个用户hadoop并赋予sudo权限。

2. SSH免密登录的配置艺术

Hadoop集群内部节点之间的通信依赖SSH。如果每次都要输密码， 那自动化脚本就没法跑了而且NameNode去连DataNode时总不能让人在旁边守着输密码吧？

配置SSH免密登录是基本功。在主节点上生成SSH密钥对，然后把公钥分发到所有从节点。命令行大概是这样的：，复盘一下。

百感交集。 ssh-copy-id hd@hadoop02 ssh-copy-id hd@hadoop03

我破防了。 配置完记得测试一下直接ssh hadoop02看能不能直接进去。如果不行， 检查一下~/.ssh/authorized_keys的权限是不是600，或者sshd_config里的配置是不是允许公钥认证。这些小细节往往决定了你今晚能不能按时下班。

三、 HDFS存储优化：让数据流动更顺畅

HDFS是Hadoop的基石，它的配置直接决定了数据的读写效率，出岔子。。

1. 块大小的抉择

默认的HDFS块大小是128MB。这个值不是一成不变的。如果你的文件都是几百MB甚至GB级别的大文件，那么把块大小调大到256MB甚至512MB是个明智的选择。

为什么？主要原因是块越大， NameNode管理的元数据就越少，而且客户端读取数据时与DataNode建立的连接次数也越少，减少了寻址时间。但是 如果你的文件都是些小日志文件， 薅羊毛。 只有几KB，那调大块大小就是灾难，会产生大量的小文件问题，把NameNode撑爆。所以 dfs.block.size的设置，一定要来定。

2. 副本策略与存储策略

默认的3副本策略是为了容错。但 或者你有其他更底层的RAID保护机制， 何不... 可以考虑降低副本数到2，这能直接节省一半的存储空间和写入时间。

还有啊， 利用Hadoop的存储策略，你可以把热数据放在SSD上，把温数据放在SAS盘上， 踩个点。 冷数据归档到大容量SATA盘上。这种分层存储能极大提升性价比和IO效率。

四、 MapReduce与YARN计算优化：榨干CPU性能

这才是重头戏。大部分性能瓶颈都出在计算阶段。MapReduce和YARN的参数多如牛毛，但抓住核心的几个，就能解决80%的问题，改进一下。。

1. 内存与CPU资源的分配

稳了！ 在yarn-site.xml和mapred-site.xml中， 你需要精细规划mapreduce.map.memory.mbmapreduce.reduce.memory.mb以及yarn.scheduler.minimum-allocation-mb。

最后说一句。 原则是：不要让容器内存太小，否则OOM会让你崩溃；也不要太大，导致集群并发度上不去。通常 Map任务的内存设置在2GB-4GB，Reduce任务主要原因是需要做Shuffle，内存消耗大一些，设置在4GB-8GB比较常见。一边，记得开启JVM重用功能，避免一个任务启动一个JVM带来的巨大开销。

2. 开启压缩：用CPU换IO

也是醉了... 网络带宽和磁盘IO往往比CPU更宝贵。开启压缩是提升性能最直接的手段之一。你可以在Map的输出端开启压缩，减少Shuffle过程中的数据传输量。

推荐使用Snappy或者LZ4这种压缩/解压速度极快的算法。虽然它们的压缩率不如Gzip，但速度优势太明显了，那必须的！。

配置示例：

简单来说... mapreduce.output.fileoutputformat.compress=true mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.SnappyCodec

Snappy压缩速度快，非常适合大数据场景。相信我，开启这个选项后你会发现网络流量下来了Job跑得更快了，这就说得通了。。

五、 监控与持续调优：永无止境的修行

配置优化不是一劳永逸的。因为业务量的增长和数据特征的变化，今天的优化可能就是明天的瓶颈。

你需要建立完善的监控体系。除了Hadoop自带的Web UI，强烈建议集成Promeus + Grafana或者Cloudera Manager。 我好了。 重点关注以下几个指标：

• GC时间NameNode和ResourceManager的GC时间如果过长，说明内存配置不合理。
• Container失败率如果频繁出现Container被Kill，通常是内存超限或代码逻辑问题。
• 磁盘IO Util如果IO Util长期100%， 说明磁盘成了瓶颈，要么加盘，要么优化数据 locality。

持续监控集群状态，及时发现性能瓶颈并进行调整。比如 当你发现Shuffle阶段特别慢时可能需要调整mapreduce.task.io.sort.mb或者增加Reduce的数量。

从Linux内核参数的的选择，每一个环节都藏着提升性能的契机。不要迷信所谓的“万能配置模板”， 只有深入理解这些参数背后的原理，结合自己的业务场景进行不断的尝试和调整，才能真正实现高效的大数据处理，极度舒适。。

再说说 送大家一句话：Hadoop优化是一场与细节的博弈，耐心点，你的数据会给你回报的。希望这篇文章能给你的集群优化带来一些新的思路，祝你的Job不再卡顿，早日跑出高分，好吧...！

---