最近好多朋友问我在CentOS 8.1上搭Hadoop、MapReduce和HBase的事干脆把这个项目的搭建全过程整理出来。标题上的“hdoop”其实就是Hadoop手一快就打错了。这个项目说白了就是三件事用Hadoop做分布式存储和资源调度用MapReduce做离线计算再用HBase承接需要实时读写的列式存储数据。整套环境跑起来之后既可以练习经典的大数据离线数仓流程也能给后续做实时类应用打个底。我会按照真实的动手顺序往下写从系统初始化到HBase Shell里跑出数据全部覆盖。如果你有一两台机器想练手这个流程基本可以直接照抄如果你准备把它放到生产环境配置参数方面我也把原理讲清楚方便你按实际资源调整。写这篇文的路子是我自己踩坑踩出来的。事前最需要想清楚的不是某个命令而是架构、版本和目录规划这三样没定好后面会到处补洞。1. 项目思维拆解与方案选型1.1 项目需求与技术选型这个项目的出发点往往是一个很朴素的需求有一批结构化和半结构化的数据既要跑批量统计又想让后续应用能按行键快速查询。传统关系型数据库在数据量大到一定量级后单表查询和批量计算都会出现瓶颈所以需要一个分布式的解决方案。Hadoop负责把文件打散存储在多个节点上MapReduce负责把这些数据切片并行算HBase则在HDFS之上建立一张面向海量数据的列式存储表。选型的时候我明确了两条原则第一能用同一种生态体系解决的问题不要引入太多陌生的框架。Hadoop、MapReduce、HBase本身都是Hadoop生态里的东西学习路径和问题排查方式都比较成熟。第二版本必须互相兼容这是这个项目里最容易翻车的一环。如果选一个太新的Hadoop版本配一个很老的HBase版本或者反过来启动时经常会出现一些非常抽象的类加载错误。我在这个实验项目里选定的组合是Hadoop 3.2.1、HBase 2.2.4、JDK 1.8。这个组合是很多离线数据实验环境的经典配置社区讨论多踩坑记录也容易搜到。JDK没有选更新的版本因为Hadoop和HBase官方对JDK版本的要求都偏保守JDK 8在兼容性和稳定性上最稳妥。1.2 架构设计与资源规划接下来要考虑的是拓扑。单机伪分布式模式只有一个节点NameNode、DataNode、ResourceManager、NodeManager都挤在同一台机器上适合做功能演示。完全分布式模式至少需要三个节点通常一个主节点跑NameNode和ResourceManager两个从节点跑DataNode和NodeManagerHBase的两个核心角色HMaster和RegionServer也可以按同样的思路分布上去。这个项目我选了三节点完全分布式主机名分别叫node01、node02、node03对应的内网地址是192.168.10.1、192.168.10.2、192.168.10.3。node01作为主节点负责跑NameNode、ResourceManager、HMasternode02和node03作为从节点跑DataNode、NodeManager、RegionServer。ZooKeeper我选择让HBase自己托管HBASE_MANAGES_ZKtrue省掉一个额外部署组件的复杂度等后续需要给其他框架做协调服务时再单独拆出来。资源方面三台机器每台分配2核CPU、4G内存足够了硬盘给到50G以上。这里有个教训如果每台机器内存只有2GHadoop和HBase的多个JVM进程会争抢内存启动的时候表面看着一切正常跑任务时经常卡死在GC上。2. 环境准备CentOS 8.1基础配置与JDK安装2.1 系统初始化与主机名映射拿到CentOS 8.1系统后我做的第一步不是安装Hadoop而是把操作系统层面的信息理顺。首要是修改主机名主节点叫node01从节点叫node02、node03然后统一写入三台机器的/etc/hosts文件。hostnamectl set-hostname node01 cat /etc/hosts EOF 192.168.10.1 node01 192.168.10.2 node02 192.168.10.3 node03 EOF这一步很关键因为Hadoop和HBase内部大量使用主机名来互相通信。如果主机名解析不了NameNode能启动但DataNode进程起不去日志里会看到一堆UnknownHostException。我见过不少人的问题其实根本不是Hadoop配置错了而是hosts文件里忘了写映射。同时建议关闭防火墙或者放行相关端口。实验环境下最简单的做法是直接停掉firewalldsystemctl stop firewalld systemctl disable firewalld sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/configSELinux如果保持enforcing经常导致HBase创建文件时权限异常而且错误提示很隐蔽所以实验环境我直接关掉。生产环境当然不建议这么干应该通过SELinux策略或者放行特定端口来解决这点要区分开。2.2 JDK安装与环境变量配置Hadoop和HBase都跑在JVM上JDK是基础。我使用的是OpenJDK 1.8CentOS 8.1可以直接通过包管理器安装yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel安装完之后要确认Java路径因为后面要写进hadoop-env.sh和hbase-env.sh。可以这样查update-alternatives --config java或者用readlink -f $(which java)看一下完整路径常见的路径是/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.x.x。我习惯把JAVA_HOME单独写进一个/etc/profile.d/java.sh文件里避免污染主profilecat /etc/profile.d/java.sh EOF export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export PATH\$PATH:\$JAVA_HOME/bin EOF source /etc/profile.d/java.sh java -version这里说明一下为什么要单独建文件Hadoop的start-dfs.sh脚本查找Java时依赖JAVA_HOME环境变量如果用普通用户执行脚本用户没有加载到系统全局变量启动时就会提示找不到JAVA_HOME。把变量放到/etc/profile.d下面是最省心的方式。若还是报错就把JAVA_HOME直接写死在hadoop-env.sh里这是唯一能保证被加载到的位置。2.3 创建专用用户与SSH免密登录大数据组件不建议用root直接跑一方面HDFS的一些操作对权限敏感另一方面安全上也是隐患。我单独创建了一个hadoop用户useradd hadoop echo hadoop123 | passwd --stdin hadoop chown -R hadoop:hadoop /opt所有组件的安装包、解压目录都放在/opt下面并将/opt授权给hadoop用户。文件目录归属问题在启动HBase时经常让人抓狂一次配好后面省事。SSH免密登录是集群之间通信的基础。主节点node01需要能免密登录到所有节点包括自己这样start-dfs.sh才能远程拉起其他节点的进程。生成密钥后分发即可su - hadoop ssh-keygen -t rsa -P ssh-copy-id node01 ssh-copy-id node02 ssh-copy-id node03一定要逐节点验证一下ssh nodeXX能不能免密进去。如果分发的时机不对例如某个节点还没配好hosts文件免密登录会一直要求输入密码start-dfs.sh执行到一半就卡住。另外不要忘记本机也要拷贝一份否则很多脚本启动时会在本机卡住。3. Hadoop与MapReduce集群搭建3.1 安装目录规划与下载部署Hadoop的运行机制可以用一句话先概括NameNode管元数据DataNode管数据块NodeManager管计算资源。它的所有模块都由配置文件驱动所以部署的核心不是安装而是把配置文件改对。目录规划我参考的是统一目录结构原则。下载好的hadoop-3.2.1.tar.gz放到/opt/apps目录解压后建立软链方便以后切换版本mkdir -p /opt/apps mkdir -p /opt/data/hdfs/nn mkdir -p /opt/data/hdfs/dn tar -zxvf hadoop-3.2.1.tar.gz -C /opt/apps ln -s /opt/apps/hadoop-3.2.1 /opt/apps/hadoop chown -R hadoop:hadoop /opt/apps /opt/data这里我把NameNode的元数据目录指定到/opt/data/hdfs/nnDataNode的数据块目录指定到/opt/data/hdfs/dn。很多默认配置会把元数据放到/tmp目录下而/tmp在系统重启时可能被清理一旦清理NameNode会因找不到元数据而拒绝启动这是运维里一个非常经典的坑。3.2 核心配置文件逐项分析Hadoop的配置集中在$HADOOP_HOME/etc/hadoop目录下对一次集群初始化来说必改的文件是core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml、workers、hadoop-env.sh。core-site.xml主要告诉客户端和DataNodeNameNode在哪个地址configuration property namefs.defaultFS/name valuehdfs://node01:8020/value /property property namehadoop.tmp.dir/name value/opt/data/hdfs/tmp/value /property /configurationfs.defaultFS里的8020是NameNode RPC通信端口之前的老教程写的多是9000新版Hadoop里默认配置是8020你完全可以自定义但必须保证node01的9000或8020端口没有被占用。hadoop.tmp.dir则是为了把临时文件和元数据从/tmp挪出来。hdfs-site.xml里最主要的是副本数和元数据目录configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/opt/data/hdfs/nn/value /property property namedfs.datanode.data.dir/name value/opt/data/hdfs/dn/value /property property namedfs.permissions.enabled/name valuefalse/value /property /configuration三个节点的集群把副本数设为2表示一份数据会存两份。如果只有一个节点这里要改回1。dfs.permissions.enabled设成false在实验环境里可以减少很多权限报错生产环境绝对不能这样配。yarn-site.xml负责资源调度。重中之重是aux-services和resourcemanager地址configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuenode01/value /property property nameyarn.nodemanager.resource.memory-mb/name value2048/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value1/value /property /configurationmapred-site.xml要指定MapReduce跑在YARN上同时需要把application classpath配好否则提交作业时会报找不到Hadoop相关类的错误configuration property namemapreduce.framework.name/name valueyarn/value /property property namemapreduce.application.classpath/name value/opt/apps/hadoop/etc/hadoop:/opt/apps/hadoop/share/hadoop/common/*:/opt/apps/hadoop/share/hadoop/common/lib/*:/opt/apps/hadoop/share/hadoop/hdfs/*:/opt/apps/hadoop/share/hadoop/hdfs/lib/*:/opt/apps/hadoop/share/hadoop/mapreduce/*:/opt/apps/hadoop/share/hadoop/mapreduce/lib/*:/opt/apps/hadoop/share/hadoop/yarn/*:/opt/apps/hadoop/share/hadoop/yarn/lib/*/value /property /configuration这份配置是从Hadoop 3.0开始才特别需要的。如果不写YARN运行MapReduce作业时AppMaster经常会抛ClassNotFoundException起初很多人以为是自己代码问题实际上只差这么一段路径。workers文件则列出所有DataNode和NodeManager节点Hadoop 3.x里这个文件名从slaves改成了workerscat /opt/apps/hadoop/etc/hadoop/workers EOF node02 node03 EOF最后补上hadoop-env.sh里的JAVA_HOMEecho export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk /opt/apps/hadoop/etc/hadoop/hadoop-env.sh3.3 HDFS与YARN的启动和验证配置文件修改完成后要把整个etc/hadoop目录同步到node02和node03然后回到node01第一次启动前必须格式化NameNode。格式化的本质是创建NameNode的元数据目录并生成一个空的文件系统镜像。如果集群版本或核心配置在格式化之后有大的变化通常需要重新格式化但要注意直接重复格式化会把之前写入HDFS的数据全部清空所以生产环境格式化的时机要非常谨慎。su - hadoop hdfs namenode -format start-dfs.sh start-yarn.sh启动后每个节点用jps看一眼进程node01上应该有NameNode、ResourceManager、SecondaryNameNodenode02和node03上应该有DataNode和NodeManager。这里有个容易混淆的点SecondaryNameNode和NameNode是两回事它不会成为NameNode的备份只是负责定期合并编辑日志和镜像文件没有它集群也能跑但元数据恢复会变慢很多。浏览器访问node01的9870端口可以看到HDFS的Web UI访问8088端口能看到YARN的资源调度界面。这是两个非常直观的集群健康指标。如果9870访问不了多半是hosts解析问题或防火墙问题如果8088访问不了多半是ResourceManager进程没起来。3.4 跑通第一个MapReduce作业集群跑起来之后我习惯先用自带的WordCount例子验证整个计算链路。先在HDFS上创建一个测试目录上传几个文本文件hdfs dfs -mkdir -p /input echo hadoop mapreduce hbase test1.txt echo centos hdoop bigdata test2.txt hdfs dfs -put test1.txt test2.txt /input然后提交经典示例作业hadoop jar /opt/apps/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.1.jar wordcount /input /output hdfs dfs -cat /output/part-r-00000在YARN的Web界面里可以看到这个作业从Submitted到Succeeded的完整流转过程。第一次等待的时间可能偏长因为每个容器启动时要加载大量类库。如果作业失败不要急着改代码先把日志找出来看。YARN日志在node01的/opt/apps/hadoop/logs/userlogs下按job id分目录map或reduce的每个任务都有单独的日志文件这种定位效率远高于看着Web UI猜。跑通WordCount意味着HDFS的分布式存储是通的YARN的资源调度是通的MapReduce的整个执行框架也是通的HBase就可以放心接上来了。4. HBase列式存储的集成与实操4.1 HBase版本兼容性与部署位置HBase的定位可以简单理解成运行在HDFS之上的分布式列存数据库。它会把自己的数据文件写到HDFS里但表结构、Region的状态这类运行期元数据由ZooKeeper管理。因此部署HBase前必须先确认HDFS是健康的这是几乎所有HBase启动异常的总根源。版本搭配上HBase 2.2.4官方支持的Hadoop版本范围覆盖了Hadoop 2.x和3.x和Hadoop 3.2.1配起来没有问题。要下载hbase-2.2.4-bin.tar.gz解压之后同样做软链tar -zxvf hbase-2.2.4-bin.tar.gz -C /opt/apps ln -s /opt/apps/hbase-2.2.4 /opt/apps/hbase chown -R hadoop:hadoop /opt/apps/hbaseHBase的目录结构里/opt/apps/hbase/conf存放配置文件/opt/apps/hbase/regionserver存放RegionServer的进程文件。如果多次启动失败常见原因是regionserver目录里残留了一些临时状态把它删掉再重启通常会恢复正常。4.2 hbase-site.xml关键参数分析HBase的配置同样集中在conf目录核心是hbase-site.xml。以下几项必须有而且必须和Hadoop、ZooKeeper的实际情况对齐configuration property namehbase.rootdir/name valuehdfs://node01:8020/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuenode01,node02,node03/value /property property namehbase.zookeeper.property.dataDir/name value/opt/data/zookeeper/value /property property namehbase.master.info.port/name value16010/value /property /configurationhbase.rootdir必须和core-site.xml里的fs.defaultFS保持一致端口都要用8020否则HBase会把数据写到本地文件系统而不是HDFS报错的样式非常奇葩。hbase.zookeeper.quorum里填的必须和hosts映射完全一致不能写IP和主机名混用。hbase.zookeeper.property.dataDir是让HBase自带的ZooKeeper持久化数据这个目录也要从/tmp挪走否则系统重启后ZooKeeper状态全丢HBase表就找不回来了。conf目录下还需要一个regionservers文件写法跟Hadoop的workers完全类似cat /opt/apps/hbase/conf/regionservers EOF node02 node03 EOF另外别忘了hbase-env.sh至少要设置JAVA_HOME。如果集群的内存比较紧张可以像下面这样调整HBase的堆大小export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HBASE_HEAPSIZE1GHBASE_HEAPSIZE这个参数是HMaster和RegionServer各自的最大堆内存。机器总共只有4G的情况下我建议给到1G左右给Hadoop的NodeManager留一点余地否则两个框架一起抢内存系统会频繁触发GC。4.3 HBase启动、验证与Shell操作启动HBase之前先确认HDFS没有处于安全模式然后使用start-hbase.sh启动。观察启动顺序会发现HBase自带ZooKeeper启动在先然后才是HMaster和RegionServer。启动完成后用jps在node01上应能看到HMaster进程node02和node03上应能看到HRegionServer进程。访问16010端口可以登录HBase的Web UI看到表数量、Region分布和RegionServer状态。接下来进入Shell验证读写hbase shell创建一张测试表列族定义为cf然后写入几行数据create user_info, cf put user_info, row1, cf:name, zhangsan put user_info, row2, cf:age, 25 scan user_info get user_info, row1看到能scan出整表数据后说明一级链路通客户端 → HMaster → ZooKeeper → RegionServer → HDFS。如果scan卡住十有八九是RegionServer没有正常注册先去日志目录看HRegionServer启动日志而不是反复重启集群。Shell里几个高频命令也可以顺手记一下disable和drop用来下线并删除一张表alter用来修改列族属性describe用来查看表结构。删除表前必须先disable否则会报错这是HBase和老朋友关系型数据库在操作习惯上一个很明显的差异。4.4 MapReduce读写HBase的典型用法HBase本来就可以和MapReduce配合使用。官方自带的例子能让你快速确认这一层联通性。比如统计HBase表行数hbase org.apache.hadoop.hbase.mapreduce.RowCounter user_info这个命令内部会启动一个MapReduce作业通过TableInputFormat读取表数据统计完成后输出总行数。如果你能正常跑出统计结果说明MapReduce框架已经从HDFS阶段扩展到了HBase阶段。实际项目中更常见的是自己写一个Mapper或Reducer读取HBase表做ETL清洗再写回另一张表。总体思路是用TableInputFormat把表里的数据逐行喂给Mapper输出给Reducer或直接写回HBase。这里只提醒一点自定义HBase MapReduce作业的jar包路径要配置到HADOOP_CLASSPATH里因为HBase客户端类需要在YARN容器里被加载export HBASE_HOME/opt/apps/hbase export HADOOP_CLASSPATH$HBASE_HOME/lib/*:$HADOOP_CLASSPATH很多人在这一步会卡在ClassNotFoundException原因就是没有把HBASE_HOME/lib加载到HADOOP_CLASSPATH。配置完环境变量后要重新提交作业才会生效。5. 常见问题与排查技巧实录5.1 HDFS安全模式一直退不出怎么办NameNode刚启动时会进入安全模式这个模式可以理解成文件系统的只读保护状态用来确认DataNode上报的数据块情况。如果集群的DataNode注册数量不够或者上报的数据块数和元数据里记录的数量差异太大安全模式就会迟迟不退出。排查时先看有几个DataNode在线。合理的情况是node02和node03都正常注册了。有一个隐蔽原因经常被忽略DataNode进程是起来了但由于hostname和hosts不匹配它注册到NameNode时显示的地址是一个奇怪的随机主机名NameNode一直等不到它。解决办法就是把/etc/hosts统一改好删除DataNode运行目录下的dfs.dn.uid残留文件然后重启DataNode。如果只是想强制离开安全模式可以用hdfs dfsadmin -safemode leave这只能解决一时的问题。如果每次启动都卡在安全模式还是要从副本数、健康节点数去排查强制退出只是饮鸩止渴。这里补充一下HDFS刚格式化后第一次启动也会短暂停留在安全模式等一小段时间会自动退出这是正常现象。5.2 DataNode或RegionServer进程起不来这个现象我也反复遇到过。进程起不来最直接的排查路径是看日志而不是反复执行启动脚本。Hadoop在挂掉之后日志会记录异常线程栈HBase同理也会在启动日志里写明失败原因。实际案例中有两个高频原因。第一个是磁盘目录权限不对DataNode在/opt/data/hdfs/dn目录下创建块文件失败错误信息里会出现Permission denied。解决方法是确定这个目录归属于hadoop用户并保证从节点目录路径和配置完全一致。第二个是端口被占用NameNode的8020端口如果已经被某些进程占用DataNode连接不上真正的NameNode表现为DataNode起来了又马上退出。排查端口占用可以这样ss -lntup | grep 8020一旦发现可疑进程不要武断地杀掉先确认是不是其他服务占用。集群服务器上常见的错误就是有人把自己跑的Java服务占了8020端口结果Hadoop怎么起都不对。5.3 内存溢出与资源争抢的调优三台4G内存的机器Hadoop和HBase同时跑内存压力是比较大的。我的经验是先给系统留1G剩下的再分配给各进程。YARN的NodeManager如果分配了过多的container内存同时HMaster和RegionServer又把堆撑满机器整体就会卡成PPT。几个可以落地的调优点适当降低HBase的HBASE_HEAPSIZE从默认的几个G调成1G或2G。修改yarn-site.xml里的yarn.nodemanager.resource.memory-mb不要让NodeManager把内存全部承诺给container。检查mapred-site.xml里的mapreduce.map.memory.mb和mapreduce.reduce.memory.mb默认值通常是1G左右如果不够需要调大如果集群资源紧张就要调小。另外补充一个很多人容易忽略的点swap分区的使用。在大数据集群节点上内存不够时会大量使用swapJVM挂起和GC停顿现象会非常明显。如果实验环境允许建议关掉swap或者在调优时优先保证关键进程的堆内内存。5.4 ZooKeeper与系统层面的坑HBase自带的ZooKeeper虽然方便但也引入了几个易踩的坑。最典型的是数据目录写在/tmp下重启后丢失。我把hbase.zookeeper.property.dataDir改到/opt/data/zookeeper后这类问题基本绝迹。另外时间同步问题也很关键。NameNode、DataNode和RegionServer之间对时间偏差的容忍度有限。如果三台机器各差几十秒HBase的ZooKeeper会话会频繁超时用着用着RegionServer就掉线。安排一个简单的NTP时间同步服务或者至少启动前手动date -s校准一下能省下很多排查时间。从整体来看搭建这套环境的成功率不高很多时候不是因为你不会配置而是因为某个基础项没有打牢。我自己的习惯是先做最小化验证再叠加服务。先把单机伪分布式跑通再扩成多节点最后接HBase每增加一层组件都先确认上一层是健康的。这套思路在后面排查问题时帮了不少忙。最后再分享一个小技巧。整套环境搭好后把启动顺序固定下来先启动HDFS再启动YARN确认HDFS健康后启动HBase。关机或维护时反过来先停HBase再停YARN最后停HDFS。别小看这个顺序HBase如果先于HDFS退出下一次启动时在HDFS上留下的临时文件很可能让RegionServer恢复异常。按照这套顺序操作我整个实验期间几乎没有再遇到环境级故障。
