简介一套完整的Hadoop集群搭建与MapReduce开发实战指南面向大数据入门者以及需要在虚拟环境中亲手复现集群的开发者。文档以任务驱动方式讲解在VM虚拟机中安装Ubuntu Kylin 16.04.4以及后续SSH无密码登录、apt更新、Java环境配置、Hadoop安装、集群网络与分布式环境配置并给出执行分布式实例的具体方法。MapReduce部分则从Eclipse安装、Hadoop-Eclipse-Plugin配置开始延伸到HDFS文件操作、MapReduce项目创建与运行全程配有可直接使用的代码和逐步解释新手按步骤操作即可完成环境部署与程序开发。资源为单个doc文档压缩包大小12.37MB目录结构清晰按任务1、任务2、任务3组织便于检索。目前已有1047人学习文档末尾还集中总结了常见问题如启动集群时的No route to host、Too many fetch-failures、内存溢出、DataNode未启动等给出针对性解决思路可以有效帮助读者规避部署陷阱提升搭建效率。 这几年代人做面试我几乎每轮都会问一句“你亲手从零到一搭过Hadoop集群吗”大多数人简历上写着熟悉Hadoop一追到NameNode格式化、DataNode起不来、MapReduce跑不出结果就含糊其辞了。说实话搭一套三节点分布式集群、把MapReduce程序按业务需求改成自己能掌控的样子并没有想象中那么玄乎但坑确实不少尤其是“看着教程走却死在不该死的地方”那种真的很磨人。这篇内容我就从头到尾拆一遍集群怎么规划、配置哪些核心文件、格式化为什么只能做一次、MapReduce开发有哪些关键点、个性化定制该往哪个方向动。文章适合两类人——刚入门大数据、想验证自己对Hadoop理解的同学以及准备把单机伪分布式迁到多机真分布式的开发。看完能少走至少三天的弯路。1. 整体设计思路与集群方案选型1.1 集群形态与角色规划动手之前先把拓扑想清楚。最常见的起步配置是3台机器1台作为Master节点跑NameNode和ResourceManager另外2台作为Worker节点跑DataNode和NodeManager。有条件的话再加一台作为备用的NameNode但那属于高可用范畴后面我会单独说。这里有一个重要经验DataNode和NodeManager尽量部署在同一批机器上因为MapReduce计算要走数据本地性计算进程离数据越近IO开销越小。如果NodeManager和DataNode分离Reduce阶段去拉数据时网络开销会直线上升。机器配置方面我建议每台至少8核16G内存、500G以上磁盘并且系统盘和数据盘分开。HDFS特别吃磁盘系统盘一旦被日志或block数据占满整个集群基本瘫痪。数据盘建议单独挂载路径规划要提前想好不要什么都丢在根目录下。1.2 版本选型与配套组件版本选型这块很多新手上来就搜“最新版Hadoop”其实稳才是第一位的。我自己的选择是Apache Hadoop 3.3.x配合JDK 8原因很简单Hadoop 3.x是当前主流3.2.0以上版本要求JDK 8以上而JDK 8在各大发行版里兼容性最稳、排错资料最多。至于Cloudera的CDH或HDP这类发行版他们确实把组件整合得方便但这些年授权模式变了商用限制越来越明显。如果是个人学习或企业内部非核心场景直接装Apache社区版更省心。网上还有用Docker镜像快速拉一个Hadoop环境的方案说实话拿来体验可以真要跑业务还是在物理机或云主机上老老实实部署比较实在。配置选型时要提醒一句不要一上来就追求高可用。没有HA需求时ZooKeeper可以不装等集群跑稳定了再考虑HA改造。一上来就堆组件出了问题你根本分不清是Hadoop的问题还是ZooKeeper的问题。1.3 从单Namenode到HA的演进预留哪怕现在只搭单NameNode我也建议在做目录规划和端口规划时提前预留HA的空间。比如NameNode的元数据目录、DataNode的数据目录、JournalNode需要的目录这些最好独立出来为以后引入ZooKeeper做自动故障切换做好准备。很多团队就是前期图省事把所有数据都堆在默认目录里后面想做HA时发现目录结构一塌糊涂迁移成本极高。目录规划这件事一开始多花十分钟后面能省一整天。2. 集群搭建部署实操详解2.1 部署前的环境准备这一步看着简单但80%的坑都出在这里。先明确三台机器的主机名和IP映射关系比如我用master、slave1、slave2三个主机名在每台机器的/etc/hosts里写清楚192.168.1.10 master 192.168.1.11 slave1 192.168.1.12 slave2主机名必须能互相解析否则后面启动时会报UnknownHostException。接着配置SSH免密登录Master要能免密登录自己和其他所有节点ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id master ssh-copy-id slave1 ssh-copy-id slave2JDK安装没什么好讲的装完记得配好JAVA_HOME。然后把Hadoop二进制包解压到统一目录比如/opt/hadoop-3.3.6并创建软链/opt/hadoop指向它。目录归属建议创建一个hadoop用户所有组件进程都用这个用户跑避免权限混乱。2.2 四个核心配置文件逐个拆解Hadoop的配置集中在etc/hadoop目录下的几个XML文件里。新手最容易犯的错就是照着网上的配置一顿复制完全不知道每个参数是干什么的。我把最关键的参数列出来逐个说明为什么这样配。先看core-site.xmlproperty namefs.defaultFS/name valuehdfs://master:9820/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /propertyfs.defaultFS定义了整个集群的入口所有客户端都是通过这个地址访问HDFS。hadoop.tmp.dir非常关键如果不管它默认落在/tmp目录下而Linux系统会周期性清理/tmp里的文件。元数据一旦被清走整个集群就废了。所以这个目录一定要挪到数据盘上的独立路径。再看hdfs-site.xmlproperty namedfs.namenode.name.dir/name value/data/hadoop/name/value /property property namedfs.datanode.data.dir/name value/data/hadoop/data/value /property property namedfs.replication/name value2/value /propertydfs.replication表示副本数三节点集群如果只有2个DataNode副本数设为2才保险设成3反而会让写入一直报副本不足。生产环境副本数一般等于DataNode数量减1但不要超过DataNode总数。接着是yarn-site.xml重点调资源参数property nameyarn.resourcemanager.hostname/name valuemaster/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value4/value /property property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property最后这个虚拟内存检查的开关是所有新手都会踩的雷。默认情况下YARN会校验Container的虚拟内存使用量稍微跑大一点的数据就报“Virtual memory exceeded”任务莫名其妙被杀死。学会业务优化之前先把这个开关关掉能让集群少死一大半任务。当然生产环境还是要结合实际情况决定是否关闭。最后配置mapred-site.xmlproperty namemapreduce.framework.name/name valueyarn/value /property这个配置的意思是把MapReduce任务提交到YARN上运行。MapReduce本身只是计算框架资源调度交给YARN统一管理。2.3 我的建议配置参数速查表以下这个表格是我在3节点集群上实测比较稳的一套组合硬件条件不同时按比例调整即可配置文件核心参数推荐值说明core-site.xmlfs.defaultFShdfs://master:9820集群统一入口core-site.xmlhadoop.tmp.dir/data/hadoop/tmp别用/tmphdfs-site.xmldfs.namenode.name.dir/data/hadoop/nameNameNode元数据目录hdfs-site.xmldfs.datanode.data.dir/data/hadoop/dataDataNode数据块目录hdfs-site.xmldfs.replication2不超过DataNode数yarn-site.xmlyarn.nodemanager.resource.memory-mb8192约物理内存的60%-80%yarn-site.xmlyarn.nodemanager.vmem-check-enabledfalse避开虚拟内存误杀mapred-site.xmlmapreduce.framework.nameyarn任务提交到YARN2.4 启动顺序与初始化验证集群初次启动前必须先执行NameNode格式化hdfs namenode -format格式化成功时会打印“successfully formatted”字样。这里要严肃提醒格式化千万不能随意执行。它的作用是初始化元数据目录在name目录下生成一个包含clusterID的VERSION文件。之后DataNode启动时会拿自己data目录里的clusterID去和NameNode比对对不上就直接拒绝连接。格式化之后才是启动流程start-dfs.sh start-yarn.sh等几秒后在Master上执行jps应该能看到NameNode、ResourceManager、SecondaryNameNode。在slave1和slave2上执行jps应该能看到DataNode和NodeManager。缺哪个进程就去logs目录下看对应日志日志文件名通常是hadoop-用户名-进程名-主机名.log。启动完成后再进一步验证浏览器打开NameNode的Web界面地址是http://master:98703.x版本端口是9870不是2.x时代的50070。页面里应该能看到活着的DataNode数量。然后用命令行上传一个测试文件echo hello hadoop test.txt hdfs dfs -mkdir /test hdfs dfs -put test.txt /test/ hdfs dfs -cat /test/test.txt能正常读写集群才算真正立住了。3. MapReduce关键点拆解与个性化开发实践3.1 三段式开发模型与编程骨架集群跑通之后真刀真枪的MapReduce开发就要上场了。很多人第一次看MapReduce代码会觉得绕其实核心就是三段式Driver负责组装任务、Mapper负责逐条处理输入数据、Reducer负责聚合相同Key的结果。以最经典的WordCount为例Mapper把每一行按空格切分输出单词, 1Reducer把相同单词的值累加输出单词, 总次数。理解这个模型的关键在于Map阶段是对数据逐条处理Reduce阶段是按Key分组处理中间那个宽宽的Shuffle过程也就是分组、排序、分发是框架自动完成的不需要写代码但你要理解它的存在。3.2 个性化开发第一步自定义Writable序列化类Hadoop没有直接用Java自带的Serializable而是定义了Writable接口。因为Java序列化会把类的完整类名、继承结构都写进去非常臃肿而Writable只保留必要字段精简高效适合在大量节点之间传输数据。业务字段一多就得自己写序列化类。比如要做访问日志分析字段包括用户ID、访问时间、访问URL、流量大小可以这样写import org.apache.hadoop.io.Writable; import java.io.DataInput; import java.io.DataOutput; import java.io.IOException; public class AccessLogWritable implements Writable { private String userId; private long timestamp; private long traffic; // 无参构造必须提供MapReduce反射时会调用 public AccessLogWritable() {} public AccessLogWritable(String userId, long timestamp, long traffic) { this.userId userId; this.timestamp timestamp; this.traffic traffic; } Override public void write(DataOutput out) throws IOException { out.writeUTF(userId); out.writeLong(timestamp); out.writeLong(traffic); } Override public void readFields(DataInput in) throws IOException { this.userId in.readUTF(); this.timestamp in.readLong(); this.traffic in.readLong(); } // 针对性补充getter/setter }这里有两个要点一是自定义类必须提供无参构造因为框架要用反射创建对象二是write和readFields里字段的读写顺序必须完全一致否则反序列化时数据全部错位。这类问题报错往往不直接而是体现在数值诡异上排查起来特别费劲。3.3 个性化开发第二步自定义Partitioner与Combiner默认情况下Map输出会按Key的哈希值分区Reduce从每个Map里拉取属于自己分区的数据。但业务上经常需要控制数据去向比如按某个字段分组而不是按Key哈希。这时就要重写Partitionerpublic class TimePartitioner extends PartitionerText, AccessLogWritable { Override public int getPartition(Text key, AccessLogWritable value, int numPartitions) { // 假设key是日期字符串按日期哈希 return (key.toString().hashCode() Integer.MAX_VALUE) % numPartitions; } }然后在Driver里设置job.setPartitionerClass(TimePartitioner.class); job.setNumReduceTasks(3);这样的好处是可以做局部聚合。再来是Combiner它的作用是在Map端先做一次“预Reduce”减少shuffle阶段要传输的数据量。但要注意Combiner必须能用“可交换和可结合”的逻辑比如求和、求最大值可以求平均值不行。如果硬把求平均值的Reducer逻辑当成Combiner用结果一定会出错。所以既想要平均值又想用Combiner一般做法是先求总和和计数Reduce阶段再做除法。3.4 数据倾斜与性能优化的实战调整主要跑到真实数据上第三个要面对的就是数据倾斜。最常见的表现是所有Reduce都跑完了就剩一两个卡在那里磁盘IO和CPU被打满其他节点闲置。倾斜的本质是某几个Key的数据量远超其他Key。业务上比如某个热门用户产生的日志量非常大所有这条日志都分到同一个Reduce机器不死才怪。我比较推荐的做法是两阶段聚合第一个阶段给Key加上随机前缀让原本扎堆的数据均匀散到多个Reduce上各自做局部聚合。第二个阶段去掉前缀再按原始Key做一次聚合。这样能把热点数据的压力摊开效果立竿见影。另外处理小文件过多的问题也有技巧。大量小文件会让Map任务数暴增每个Map启动销毁都有开销。通过CombineTextInputFormat把多个小文件合并成一个大切片job.setInputFormatClass(CombineTextInputFormat.class); CombineTextInputFormat.setMaxInputSplitSize(job, 1024 * 1024 * 32);这个配置实质上是把几十个小文件合并成一个32MB的切片Map数量立刻降下来。3.5 个性化的衡量标准代码要能应对真实业务变化现在有些人一提个性化开发以为是不用现成框架自己从零手写一套。真没必要。个性化开发的核心是“在了解框架机制的前提下针对业务特征做定制化的参数和逻辑调整”。比如日志分析类的作业就要重写Writable和Partitioner计算类作业要重点调Combiner和内存参数报表类作业要多关注Reduce数量和输出格式。我自己的经验是写完一个MapReduce作业先跑少量数据验证逻辑再跑全量数据验证性能。逻辑有bug顶多出结果不对性能有问题却会让集群整个拖垮。4. 常见问题与排查技巧实录4.1 NameNode格式化与DataNode启动不上的问题这是我这些年遇到最多的问题症状非常典型格式化NameNode之后启动集群NameNode正常DataNode起不来日志里报Incompatible clusterIDs。原因就是前面说的NameNode格式化时生成了新的clusterID但DataNode的数据目录里保存的是旧clusterID。两边对不上DataNode自然拒绝工作。解决办法是把DataNode的数据目录清空再重启rm -rf /data/hadoop/data/*这里要提醒清空DataNode数据目录意味着所有已经存在的数据块都丢失了。如果集群里已经有重要数据这个操作不能做正确的做法是先把有数据的DataNode的clusterID修改成和NameNode一致。所以说格式化NameNode这事一定想清楚再动手。4.2 YARN资源不足导致任务被杀YARN任务的报错千奇百怪但大部分根因都是两个。一个是物理内存用超了报“Physical memory usage exceeds physical memory limits”另一个是虚拟内存超限报“Virtual memory exceeded”。物理内存超限要检查yarn-site.xml里的内存配置是否合理。比如机器16G内存给YARN分配8G到10G比较合适留一部分给操作系统和HDFS自身进程用。虚拟内存超限最常见直接关掉虚拟内存检查也就是前面提到的把yarn.nodemanager.vmem-check-enabled设为false简单有效。4.3 日志定位与排查的基本路径集群出了问题第一反应不要猜去看日志。Hadoop的日志在$HADOOP_HOME/logs目录下文件名格式是hadoop-用户名-进程名-主机名.log。比如hadoop-hadoop-datanode-slave1.log就是slave1上DataNode的日志。排查顺序我一般建议先jps看进程在不在再df -h看磁盘满没满然后看对应节点日志里的ERROR和Exception最后才去翻Web界面。很多新手上来就百度报错信息其实80%的错误日志里已经写清楚了原因。还有一个特别容易忽视的地方是Web界面里的Application日志。YARN的8088端口能看到所有作业的运行状态点进某个失败任务可以发现是Map阶段挂了还是Reduce阶段挂了甚至能看到是哪一台机器挂的。这个信息很多时候比Slave上的日志更精准。4.4 实用排查关键词速查表症状常见关键词排查方向DataNode启动失败Incompatible clusterIDs检查clusterID一致性连接NameNode失败UnknownHostException检查/etc/hosts解析任务被异常杀死Container killed by ApplicationMaster检查YARN内存配置虚拟内存超限Virtual memory exceeded关vmem-check或调大比例任务运行极慢Data skew / OOM检查倾斜与Map数量5. 从单集群到高可用与运维提升集群稳定运行一阵子之后我的建议是逐步做这些提升。第一件就是把NameNode的高可用安排上核心是引入ZooKeeper协调Active/Standby两个NameNode之间的状态同步。这套机制的逻辑是Active NameNode往JournalNode写编辑日志Standby NameNode同步拉取ZooKeeper负责自动FailoverNameNode挂掉后能在几秒内切换。你会发现ZooKeeper不是一定要装的但一旦要上HA它就成了组件中不可缺失的一环。第二件事是建立监控体系。Hadoop自带的Web界面只能被动查看数据量大了以后必须上监控工具做告警比如磁盘占用超过85%、DataNode失联、作业失败率飙升这些都应该第一时间被感知。第三件事是探索Spark、Flink等计算引擎。MapReduce适合离线批处理吞吐量大但延迟高。有实时计算需求时把数据链路迁移到其他引擎上做计算HDFS仍然可以作为一个稳定的存储底座。根据我个人的运维经验一台刚搭好的集群最忌讳的就是马上把核心业务压上去。先用几周时间跑边缘任务观察磁盘、内存、网络层面的趋势宁可前期慢一点也要把集群脾气摸清楚后面再上核心业务就踏实很多。顺着这个方向持续演进一套集群能陪你走很远。本文还有配套的精品资源点击获取