1. 为什么是伪分布式单机学习HBase的最优解1.1 伪分布式到底是什么它能解决什么问题很多人第一次接触HBase上来就被“分布式”三个字吓住了——是不是必须搞三台、五台服务器才能玩其实不是。HBase运行在HDFS之上而HDFS本身支持伪分布式模式也就是说NameNode、DataNode、SecondaryNameNode这些角色可以全部跑在同一台机器上。HBase也一样HMaster、HRegionServer、ZooKeeper可以全部作为独立进程部署在同一台Linux机器上从进程角度看它该有的都有了只是物理上共处一机。这个模式的价值非常实在它能让你用一台普通电脑完整体验HBase的完整架构、配置方式、启动流程和日常运维操作同时还能跑真实的读写测试、预分区测试甚至Sqoop导入。换句话说伪分布式就是“单人版”的集群用来学习和做功能验证刚刚好。我自己带过不少刚入门的朋友发现至少有七成的人能在伪分布式环境里踩完所有生产环境会踩的坑——端口占用、WAL路径异常、Region分裂问题、ZooKeeper超时——这些和真实集群基本一模一样。当然伪分布式也有明显的边界。它无法验证多节点负载均衡、网络分区容错、跨机架感知这些东西性能数据也没有参考意义。但如果你目标是“先把HBase跑起来、把Shell调明白、把数据模型搞透”伪分布式绝对是最快路径。这篇文章就是围绕这条路径来写的包含我从零搭建到完成各种测试的完整记录。1.2 版本选型为什么我用的是Hadoop 3.x HBase 2.x版本选型往往是新手第一个栽跟头的地方。HBase和Hadoop有严格的版本兼容关系乱配版本最常见的后果就是HBase启动时HDFS客户端报Protocol版本不匹配或者RegionServer起来几秒后就自动退出。我实测下来比较稳的一套组合是JDK 8 Hadoop 3.3.4 HBase 2.4.17。为什么选这套原因有三点第一HBase 2.4.x是2.x系列里比较成熟的维护分支和Hadoop 3.x的兼容性做得很好第二JDK 8是这两者共同支持最稳妥的版本HBase 2.x用JDK 11也能跑但会有不少细碎警告没必要给自己添堵第三这套组合的资料多、踩坑记录多遇到问题容易搜到解决方案。一个额外的建议去Apache官网下载时认准hbase-2.4.17-bin.tar.gz这种带bin字样的包不要去下源码包。源码包需要自己编译那个过程能消耗掉你一下午。如果你要在Windows上用WSL或虚拟机也一样用这个包没有区别。2. 环境准备Hadoop伪分布式搭建的坑与经验2.1 用户、JDK与SSH免密配置我在搭建时习惯单独创建一个hadoop用户而不是直接用root跑集群。原因很朴素用root跑HDFS和HBase一旦脚本里有什么路径权限判断很容易出现“明明有权限却报Permission denied”的诡异问题而普通用户配合正确授权行为更可预测。创建用户的命令很简单useradd -m hadoop passwd hadoop然后登录hadoop用户配置JDK。JDK安装路径建议统一放在/usr/local/java这样后续配置JAVA_HOME时路径清爽。配好之后一定要验证java -version接着做SSH免密登录。伪分布式模式下Hadoop脚本会通过SSH登录本机来启动守护进程如果每次都要输密码启动脚本会卡住。配置方式ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost这里有一个容易被忽略的点Hadoop脚本解析主机名走的是hostname命令如果主机名里有下划线之类的特殊字符SSH解析会出问题。建议提前把/etc/hostname改成一个简洁名字比如node1并在/etc/hosts里加上一行127.0.0.1 node1同时把Hadoop配置里的fs.defaultFS、dfs.namenode.http-address等地址统一写成这个主机名不要混用localhost和node1否则启动时各种莫名其妙的连接拒绝会让你怀疑人生。2.2 Hadoop核心配置详解Hadoop的配置集中在$HADOOP_HOME/etc/hadoop/目录下伪分布式搭建真正要改的就三个文件core-site.xml、hdfs-site.xml、mapred-site.xml跑Sqoop或MR任务时需要。yarn-site.xml在纯HBase场景下可以跳过但如果你后续想跑Sqoop导入HBase的MR任务YARN也得配好。core-site.xml里最关键的是fs.defaultFSconfiguration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/home/hadoop/data/tmp/value /property /configurationhadoop.tmp.dir是我强烈建议你修改的参数默认值指向/tmp系统重启可能清空届时NameNode会报“目录不存在”或者元数据丢失整个集群直接废掉。hdfs-site.xml需要设置副本数和NameNode地址configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/home/hadoop/data/datanode/value /property /configuration伪分布式只有一台DataNodedfs.replication必须设为1否则所有块都会处于“副本不足”状态HBase写入时会一直报NotEnoughReplicasException。mapred-site.xml如果是跑Sqoop或HBase批量导入需要指定框架为YARNconfiguration property namemapreduce.framework.name/name valueyarn/value /property /configuration2.3 格式化NameNode与启动验证配置完成后第一次启动HDFS前必须格式化NameNode。这一步有讲究格式化会清空原有元数据所以只在首次搭建或确需重置时执行。之后重启集群千万不要再格式化否则NameNode和DataNode的clusterID不一致DataNode起不来。hdfs namenode -format启动HDFSstart-dfs.sh然后用jps命令验证进程一个标准伪分布式HDFS应该看到NameNode DataNode SecondaryNameNode再验证HDFS Web UI浏览器打开http://node1:9870能看到文件系统概览就算成功。我还建议顺手做一次文件上传测试hdfs dfs -mkdir -p /test hdfs dfs -put /etc/hostname /test/ hdfs dfs -cat /test/hostname这一步的意义在于确认HDFS读写功能正常避免后面HBase启动失败时你还要回过头来排查HDFS的问题。3. HBase安装与配置核心细节3.1 解压与目录规划HBase的安装本身没有太多技巧解压即可但目录规划值得说两句。我把所有大数据组件统一放在/home/hadoop/app/下这样环境变量和配置路径都非常好管理。下载解压之后顺手建一个软链接tar -xzf hbase-2.4.17-bin.tar.gz -C /home/hadoop/app/ ln -s /home/hadoop/app/hbase-2.4.17 /home/hadoop/app/hbase这样做的目的是让HBASE_HOME指向稳定的路径以后升级版本只需要替换软链接指向配置文件不用动。环境变量方面在~/.bashrc里追加export HBASE_HOME/home/hadoop/app/hbase export PATH$PATH:$HBASE_HOME/bin然后source ~/.bashrc。记得确认JAVA_HOME也在这个文件里导出了因为HBase启动脚本会用到它。3.2 hbase-site.xml配置文件逐个参数说hbase-site.xml是整个HBase配置的核心伪分布式模式下真正需要改的参数其实不多但每一个都很关键。第一个是hbase.rootdir告诉HBase把数据写到HDFS的哪个目录property namehbase.rootdir/name valuehdfs://node1:9000/hbase/value /property这个目录不需要手动创建HBase首次启动会自己建。但如果路径写错HBase启动时会报目录无法访问排查时需要先确认HDFS上有没有这个目录。第二个是hbase.cluster.distributed伪分布式要设成trueproperty namehbase.cluster.distributed/name valuetrue/value /property这个参数很多教程没讲清楚。它控制的是HBase以单机模式运行还是分布式模式运行。单机模式下HBase使用本地文件系统数据不落到HDFS伪分布式和完全分布式都必须设为trueHBase才会去HDFS上读写数据。如果你漏了这行HBase虽然能启动但数据会写到本地磁盘后续重启数据就“消失”了。第三个是hbase.zookeeper.quorum。HBase自带ZooKeeper伪分布式模式下直接用自带的即可这个参数保持默认的localhost就能跑。但如果你把主机名改成了node1建议显式写出来property namehbase.zookeeper.quorum/name valuenode1/value /property第四个是hbase.master.info.port默认是16010这是HMaster Web UI的端口。新手容易和HDFS的9870端口搞混记住9870是HDFS的管理界面16010是HBase的管理界面。还有一个值得关注的参数hbase.wal.provider默认值是filesystem表示WAL写到HDFS上。伪分布式环境下默认配置就能正常工作但如果遇到WAL写入异常可以先查看这个配置是否被改过。hbase-env.sh里需要改的是JAVA_HOMEexport JAVA_HOME/usr/local/java如果不设HBase脚本会去PATH里找java有时候找到的版本不对启动直接失败。3.3 启动HBase并核对端口清单启动之前先确认HDFS正常然后直接start-hbase.sh启动完成后用jps看进程一个健康的伪分布式HBase应该有HMaster HRegionServer HQuorumPeer另外hbase shell也可以用于验证hbase shell status能返回1 active master, 0 backup masters, 1 servers之类的信息就说明集群状态正常。端口清单方面我整理了一张表方便自查端口服务说明9870NameNode Web UIHDFS管理界面9000HDFS RPCHBase写入数据走这个端口2181ZooKeeperHBase元数据协调16010HMaster Web UIHBase管理界面16020HRegionServer RPCRegion读写请求16030HRegionServer Web UI单个RegionServer监控我用ss -tlnp验证过这些端口的监听情况一个常见问题是16020端口没起来多半是RegionServer启动失败这时要去$HBASE_HOME/logs/下看hbase-hadoop-regionserver-node1.log里面通常写明了具体原因。4. Shell操作测试建表、读写与预分区4.1 基础CRUD测试从建表到Scan全流程进入HBase Shell的方式是hbase shell注意Shell的回显会比较慢尤其是第一次执行时ZooKeeper要建立连接大概有几秒钟延迟这是正常的不要以为卡住了。下面是伪分布式环境里我认为必须完整走一遍的基础CRUD流程# 创建命名空间 create_namespace test_ns # 建表指定列族 create test_ns:user, info, address # 查看表详情 describe test_ns:user # 插入数据rowkey是1001 put test_ns:user, 1001, info:name, zhangsan put test_ns:user, 1001, info:age, 25 put test_ns:user, 1001, address:city, beijing # 查询单行 get test_ns:user, 1001 # 查询指定列 get test_ns:user, 1001, {COLUMN info:name} # 全表扫描 scan test_ns:user # 删除列和表 deleteall test_ns:user, 1001 disable test_ns:user drop test_ns:user这里有几个经验想分享。第一建表时列族一定不要贪多。HBase的每个列族对应一个独立的存储文件多个列族意味着一次写入要写多个文件性能会下降。生产环境通常1到3个列族就够用。日常测试一个列族完全够。第二put命令的语法很多人会记错完整的写法是put 表名, rowkey, 列族:列标识符, 值。注意列标识符前面的冒号不能丢。如果列族名或者列名写错HBase不会报错而是会静默地在表里创建一个新的列标识符等数据越积越多才发现表里全是垃圾列。这个机制比较坑我在教学时专门强调过。第三get和scan的区别要理解清楚。get严格按rowkey查一行走的是索引速度快scan是范围扫描可以指定起始rowkey和结束rowkey但不指定条件时会全表扫描数据量大时很慢测试时无所谓生产环境用scan要非常克制。4.2 预分区与自动拆分测试搞懂Region分裂机制关于Region拆分我的建议是先测预分区再测自动拆分。这两件事看起来都是“怎么让Region变多”但背后的触发机制完全不同。预分区是在建表时手动指定rowkey的分布范围HBase按照这些范围一次性创建多个Region避免后续写入时热Region不断Split。测试命令create test_ns:pre_split, cf1, SPLITS [1000, 2000, 3000]执行后可以用hbase shell里的status detailed查看Region分布或者直接看HMaster Web UI能清楚看到表被分成了4个Region一个空Region三个预定义边界切分的Region。为什么这么做HBase的rowkey在物理上是按字典序排列的如果建表时不预分区数据全部涌入单一Region达到阈值后触发Split这个过程中该Region的写入会短暂阻塞而且Split产生的文件需要Compaction来合并对性能影响很明显。预分区的核心价值是让数据从一开始就均匀分摊到多个Region上。自动拆分则是让HBase自己根据Region大小触发分裂。hbase.hregion.max.filesize参数默认是10GB测自动拆分时等10GB太慢了可以临时调小比如设置为128MBproperty namehbase.hregion.max.filesize/name value134217728/value /property改完配置后重启HBase然后往表里不停地put数据写一段时间后观察Region数量变化。需要注意的是伪分布式只有一个RegionServerRegion越多碎片化越严重如果只是为了理解机制测试完就删表别留着影响后续实验。4.3 数据导入测试Sqoop操作HBase的完整链路Sqoop操作HBase是面试和实际工作中都常被问到的点。我建议在伪分布式环境里把这条链路完整跑一遍因为Mysql到HBase的数据导入涉及Sqoop、YARN、HBase三个组件的协同任何一个环节配置不对都跑不起来。先准备MySQL测试数据CREATE DATABASE test_db; USE test_db; CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(20), amount DECIMAL(10,2), create_time DATETIME ); INSERT INTO orders (user_id, amount, create_time) VALUES (U001, 99.50, NOW()); INSERT INTO orders (user_id, amount, create_time) VALUES (U002, 150.00, NOW());Sqoop导入HBase时最常用的方式是sqoop import \ --connect jdbc:mysql://localhost:3306/test_db \ --username root \ --password your_password \ --table orders \ --hbase-table test_ns:orders \ --column-family cf1 \ --hbase-row-key id \ --hbase-create-table \ --m 1参数含义逐个说--hbase-table指定HBase目标表名--column-family指定列族--hbase-row-key指定将MySQL的哪一列作为rowkey--hbase-create-table让Sqoop自动建表--m 1表示只用1个Mapper伪分布式环境用多Mapper没有意义反而会因为资源调度变慢。导入完成后回HBase Shell验证scan test_ns:orders然后试一下带条件的查询get test_ns:orders, 1Sqoop导入时有一个默认行为值得一提它会将MySQL表的每一行非主键列都放到--column-family指定的列族下列名就是MySQL里的字段名值全部转为字符串。这意味着HBase里的数据结构和你MySQL里的原表结构差不多只是物理存储方式变了。这条链路里最常遇到的问题有两个一是Sqoop任务提交到YARN但YARN没配好任务直接失败二是MySQL驱动mysql-connector-java.jar没放到Sqoop的lib目录报ClassNotFoundException。前者在上文配yarn-site.xml时就能避免后者提前把驱动下载放进去就行。5. WAL日志异常与常见故障排查实录5.1 WAL机制简述与伪分布式常见异常WAL是HBase里最核心的可靠性机制全称Write-Ahead Log预写日志。HBase写入数据时不会直接改内存中的数据而是先把写入操作追加到WAL日志文件中然后再更新内存中的MemStore。这样一旦RegionServer宕机重启后可以回放WAL日志来恢复尚未落盘的数据。这个机制本身不复杂但伪分布式环境下因为角色集中在一台机器上资源争抢更容易触发WAL异常。以下是我实测中遇到过的几种典型情况。WAL日志写入慢或阻塞伪分布式只有一块磁盘HDFS的DataNode写入和HBase的WAL写入共用同一块磁盘I/O当RegionServer执行Flush或Compaction时磁盘I/O被打满WAL写入就会变慢极端情况下会报Blocking WAL这是RegionServer自我保护机制触发的——它发现WAL写入速度跟不上CPU处理速度就强制阻塞写入请求让数据能先落盘。遇到这个情况本质原因是磁盘性能不够短期内你可以尝试调大hbase.regionserver.hlog.blocksize和hbase.regionserver.logroll.period参数来缓解但长期来看换一块SSD比什么都管用。WAL文件路径异常HBase的WAL默认存放在hbase.rootdir下的WALs目录中。如果你改了hbase.rootdir但没有重启HDFS或者HDFS本身状态异常RegionServer启动时会报Failed to create WAL directory。排查这个问题的第一步是上HDFS确认目录状态hdfs dfs -ls /hbase/WALs如果目录存在但RegionServer还是起不来看看hbase.regionserver.hlog.dir这个参数有没有被改过正常不用改默认跟随hbase.rootdir。还有一次我在测试时手动删了/hbase/WALs下的子目录结果RegionServer直接拒绝服务后来花了很长时间才意识到HBase对这个目录的权限要求非常严格不要在运行时手动改动HDFS上的HBase数据目录。WAL回放时损坏伪分布式环境如果直接kill -9掉RegionServer进程WAL里可能残留未完成的事务记录重启时HBase会尝试回放这些WAL。如果WAL文件本身也损坏了重启会卡在恢复日志阶段。此时最直接的办法是把损坏的WAL文件转移或删除然后重启。注意这个操作会丢失该WAL里尚未落盘的数据但在测试环境里这个代价可以接受。定位损坏文件的方式是看RegionServer日志里面会明确告诉你哪个WAL文件回放失败。5.2 常见问题速查表我整理了一张伪分布式HBase日常使用中最常见的问题表配合日志文件路径直接查能省掉大量排查时间。HBase的日志统一在$HBASE_HOME/logs/下HMaster日志是hbase-hadoop-master-node1.logRegionServer是hbase-hadoop-regionserver-node1.log。现象可能原因排查方式解决方案HMaster启动后自动退出ZooKeeper数据目录异常看master日志中ZK相关报错备份后清除/home/hadoop/data/tmp下的ZK数据目录RegionServer起不来HDFS副本数不足检查dfs.replication是否设置为1将副本数改为1后重启HDFSShell执行status无响应ZooKeeper连接超时ping node1检查2181端口检查hbase.zookeeper.quorum主机名是否可解析写入时报NotEnoughReplicasExceptionHDFS块副本数为3但只有1个DataNode查看HDFS Web UI修改dfs.replication为1重启HDFSWAL目录创建失败HDFS空间不足或目录权限异常hdfs dfs -du -h /hbase清理HDFS空间确认目录属主HBase Shell操作超时单机资源紧张看系统负载top命令调大hbase.client.operation.timeout或改善机器配置这张表里的每一项都是我在实际搭建过程中真实遇到并解决过的。把这些问题的原因和表现记熟不光能应付环境搭建面试的时候被问到HBase运维问题你也能从容答出排查思路。5.3 杀手锏级排查技巧日志文件里找答案排查HBase问题我的个人习惯是先看日志再做操作绝不猜。很多初学者遇到RegionServer挂掉第一反应是重启结果重启了一百次还是挂因为根因根本不在重启这个动作能解决的范围内。具体做法是启动失败后立刻打开tail -100看最近日志重点搜索ERROR、FATAL、Exception这几个关键字。如果是Java堆栈异常往上翻十几行找到Caused by那一行那才是真正的根因。比如HMaster启动失败日志里如果出现了FileSystemManipulationException或者NoSuchFileException基本可以断定是和HDFS通信有问题和HBase自身的配置无关。还有一个调试技巧在启动HBase时加上-D参数开启调试日志${HBASE_HOME}/bin/hbase-daemon.sh start master -Dorg.apache.hadoop.hbase.master.log4j.loggerDEBUG但调试日志量非常大伪分布式环境下可能刷屏严重我更推荐的做法是定位到具体模块再开启对应的Logger。日常环境里保持INFO级别就够了等真出问题时再按需调高。6. 测试完成之后的收尾与进阶建议测试做完了环境确认没问题之后还有两个收尾的小建议。第一个建议是学会正确停止HBase。直接kill进程是新手最容易犯的错正确的关闭顺序是先停HBase Shell然后执行stop-hbase.sh等HMaster和RegionServer都退出后再执行stop-dfs.sh。如果顺序反了HDFS先停了HBase的RegionServer会在日志里刷一堆连接异常。还有反复启动时不要忘了清空/tmp下的临时文件HBase在启动过程中会产生不少临时锁文件残留锁文件会导致端口被占用现象就是“明明没启动但端口起不来”。第二个建议是在伪分布式环境里顺手把HBase的数据备份练一遍。HBase的snapshot命令非常实用测试环境里可以轻松演练snapshot test_ns:user, snapshot_user_001 clone_snapshot snapshot_user_001, test_ns:user_restore这个操作在生产环境的价值极高——很多公司做HBase数据迁移或者表结构变更时就是先打快照再克隆。在伪分布式环境里提前练熟比真到了生产环境临阵磨枪要强得多。最后说说这个环境还能怎么扩展。伪分布式环境跑通后你可以非常自然地往三个方向深入第一试试HBase的Region分裂参数调优观察不同阈值下Region数量和写入性能的变化第二把Sqoop的导入做成定时增量导入研究如何用--incremental append模式同步MySQL数据到HBase第三进阶到真实的完全分布式部署把HMaster、RegionServer、ZooKeeper分别拆到3台机器上感受伪分布和真分布在配置上的差别和关联。我个人当初就是靠一台4核8G的机器把这套环境跑通然后一步步扩展到真实集群的。虽然伪分布式环境跑不出什么惊人的性能数据但它把HBase的工作原理和故障排查思路完完整整地教给了我。我之后在生产环境处理过的绝大多数HBase问题在伪分布式阶段基本都见过相似的原型。这套环境值得你花一个周末把它跑通。
HBase伪分布式搭建全攻略：从Hadoop到WAL故障排查
1. 为什么是伪分布式单机学习HBase的最优解1.1 伪分布式到底是什么它能解决什么问题很多人第一次接触HBase上来就被“分布式”三个字吓住了——是不是必须搞三台、五台服务器才能玩其实不是。HBase运行在HDFS之上而HDFS本身支持伪分布式模式也就是说NameNode、DataNode、SecondaryNameNode这些角色可以全部跑在同一台机器上。HBase也一样HMaster、HRegionServer、ZooKeeper可以全部作为独立进程部署在同一台Linux机器上从进程角度看它该有的都有了只是物理上共处一机。这个模式的价值非常实在它能让你用一台普通电脑完整体验HBase的完整架构、配置方式、启动流程和日常运维操作同时还能跑真实的读写测试、预分区测试甚至Sqoop导入。换句话说伪分布式就是“单人版”的集群用来学习和做功能验证刚刚好。我自己带过不少刚入门的朋友发现至少有七成的人能在伪分布式环境里踩完所有生产环境会踩的坑——端口占用、WAL路径异常、Region分裂问题、ZooKeeper超时——这些和真实集群基本一模一样。当然伪分布式也有明显的边界。它无法验证多节点负载均衡、网络分区容错、跨机架感知这些东西性能数据也没有参考意义。但如果你目标是“先把HBase跑起来、把Shell调明白、把数据模型搞透”伪分布式绝对是最快路径。这篇文章就是围绕这条路径来写的包含我从零搭建到完成各种测试的完整记录。1.2 版本选型为什么我用的是Hadoop 3.x HBase 2.x版本选型往往是新手第一个栽跟头的地方。HBase和Hadoop有严格的版本兼容关系乱配版本最常见的后果就是HBase启动时HDFS客户端报Protocol版本不匹配或者RegionServer起来几秒后就自动退出。我实测下来比较稳的一套组合是JDK 8 Hadoop 3.3.4 HBase 2.4.17。为什么选这套原因有三点第一HBase 2.4.x是2.x系列里比较成熟的维护分支和Hadoop 3.x的兼容性做得很好第二JDK 8是这两者共同支持最稳妥的版本HBase 2.x用JDK 11也能跑但会有不少细碎警告没必要给自己添堵第三这套组合的资料多、踩坑记录多遇到问题容易搜到解决方案。一个额外的建议去Apache官网下载时认准hbase-2.4.17-bin.tar.gz这种带bin字样的包不要去下源码包。源码包需要自己编译那个过程能消耗掉你一下午。如果你要在Windows上用WSL或虚拟机也一样用这个包没有区别。2. 环境准备Hadoop伪分布式搭建的坑与经验2.1 用户、JDK与SSH免密配置我在搭建时习惯单独创建一个hadoop用户而不是直接用root跑集群。原因很朴素用root跑HDFS和HBase一旦脚本里有什么路径权限判断很容易出现“明明有权限却报Permission denied”的诡异问题而普通用户配合正确授权行为更可预测。创建用户的命令很简单useradd -m hadoop passwd hadoop然后登录hadoop用户配置JDK。JDK安装路径建议统一放在/usr/local/java这样后续配置JAVA_HOME时路径清爽。配好之后一定要验证java -version接着做SSH免密登录。伪分布式模式下Hadoop脚本会通过SSH登录本机来启动守护进程如果每次都要输密码启动脚本会卡住。配置方式ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost这里有一个容易被忽略的点Hadoop脚本解析主机名走的是hostname命令如果主机名里有下划线之类的特殊字符SSH解析会出问题。建议提前把/etc/hostname改成一个简洁名字比如node1并在/etc/hosts里加上一行127.0.0.1 node1同时把Hadoop配置里的fs.defaultFS、dfs.namenode.http-address等地址统一写成这个主机名不要混用localhost和node1否则启动时各种莫名其妙的连接拒绝会让你怀疑人生。2.2 Hadoop核心配置详解Hadoop的配置集中在$HADOOP_HOME/etc/hadoop/目录下伪分布式搭建真正要改的就三个文件core-site.xml、hdfs-site.xml、mapred-site.xml跑Sqoop或MR任务时需要。yarn-site.xml在纯HBase场景下可以跳过但如果你后续想跑Sqoop导入HBase的MR任务YARN也得配好。core-site.xml里最关键的是fs.defaultFSconfiguration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/home/hadoop/data/tmp/value /property /configurationhadoop.tmp.dir是我强烈建议你修改的参数默认值指向/tmp系统重启可能清空届时NameNode会报“目录不存在”或者元数据丢失整个集群直接废掉。hdfs-site.xml需要设置副本数和NameNode地址configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/home/hadoop/data/datanode/value /property /configuration伪分布式只有一台DataNodedfs.replication必须设为1否则所有块都会处于“副本不足”状态HBase写入时会一直报NotEnoughReplicasException。mapred-site.xml如果是跑Sqoop或HBase批量导入需要指定框架为YARNconfiguration property namemapreduce.framework.name/name valueyarn/value /property /configuration2.3 格式化NameNode与启动验证配置完成后第一次启动HDFS前必须格式化NameNode。这一步有讲究格式化会清空原有元数据所以只在首次搭建或确需重置时执行。之后重启集群千万不要再格式化否则NameNode和DataNode的clusterID不一致DataNode起不来。hdfs namenode -format启动HDFSstart-dfs.sh然后用jps命令验证进程一个标准伪分布式HDFS应该看到NameNode DataNode SecondaryNameNode再验证HDFS Web UI浏览器打开http://node1:9870能看到文件系统概览就算成功。我还建议顺手做一次文件上传测试hdfs dfs -mkdir -p /test hdfs dfs -put /etc/hostname /test/ hdfs dfs -cat /test/hostname这一步的意义在于确认HDFS读写功能正常避免后面HBase启动失败时你还要回过头来排查HDFS的问题。3. HBase安装与配置核心细节3.1 解压与目录规划HBase的安装本身没有太多技巧解压即可但目录规划值得说两句。我把所有大数据组件统一放在/home/hadoop/app/下这样环境变量和配置路径都非常好管理。下载解压之后顺手建一个软链接tar -xzf hbase-2.4.17-bin.tar.gz -C /home/hadoop/app/ ln -s /home/hadoop/app/hbase-2.4.17 /home/hadoop/app/hbase这样做的目的是让HBASE_HOME指向稳定的路径以后升级版本只需要替换软链接指向配置文件不用动。环境变量方面在~/.bashrc里追加export HBASE_HOME/home/hadoop/app/hbase export PATH$PATH:$HBASE_HOME/bin然后source ~/.bashrc。记得确认JAVA_HOME也在这个文件里导出了因为HBase启动脚本会用到它。3.2 hbase-site.xml配置文件逐个参数说hbase-site.xml是整个HBase配置的核心伪分布式模式下真正需要改的参数其实不多但每一个都很关键。第一个是hbase.rootdir告诉HBase把数据写到HDFS的哪个目录property namehbase.rootdir/name valuehdfs://node1:9000/hbase/value /property这个目录不需要手动创建HBase首次启动会自己建。但如果路径写错HBase启动时会报目录无法访问排查时需要先确认HDFS上有没有这个目录。第二个是hbase.cluster.distributed伪分布式要设成trueproperty namehbase.cluster.distributed/name valuetrue/value /property这个参数很多教程没讲清楚。它控制的是HBase以单机模式运行还是分布式模式运行。单机模式下HBase使用本地文件系统数据不落到HDFS伪分布式和完全分布式都必须设为trueHBase才会去HDFS上读写数据。如果你漏了这行HBase虽然能启动但数据会写到本地磁盘后续重启数据就“消失”了。第三个是hbase.zookeeper.quorum。HBase自带ZooKeeper伪分布式模式下直接用自带的即可这个参数保持默认的localhost就能跑。但如果你把主机名改成了node1建议显式写出来property namehbase.zookeeper.quorum/name valuenode1/value /property第四个是hbase.master.info.port默认是16010这是HMaster Web UI的端口。新手容易和HDFS的9870端口搞混记住9870是HDFS的管理界面16010是HBase的管理界面。还有一个值得关注的参数hbase.wal.provider默认值是filesystem表示WAL写到HDFS上。伪分布式环境下默认配置就能正常工作但如果遇到WAL写入异常可以先查看这个配置是否被改过。hbase-env.sh里需要改的是JAVA_HOMEexport JAVA_HOME/usr/local/java如果不设HBase脚本会去PATH里找java有时候找到的版本不对启动直接失败。3.3 启动HBase并核对端口清单启动之前先确认HDFS正常然后直接start-hbase.sh启动完成后用jps看进程一个健康的伪分布式HBase应该有HMaster HRegionServer HQuorumPeer另外hbase shell也可以用于验证hbase shell status能返回1 active master, 0 backup masters, 1 servers之类的信息就说明集群状态正常。端口清单方面我整理了一张表方便自查端口服务说明9870NameNode Web UIHDFS管理界面9000HDFS RPCHBase写入数据走这个端口2181ZooKeeperHBase元数据协调16010HMaster Web UIHBase管理界面16020HRegionServer RPCRegion读写请求16030HRegionServer Web UI单个RegionServer监控我用ss -tlnp验证过这些端口的监听情况一个常见问题是16020端口没起来多半是RegionServer启动失败这时要去$HBASE_HOME/logs/下看hbase-hadoop-regionserver-node1.log里面通常写明了具体原因。4. Shell操作测试建表、读写与预分区4.1 基础CRUD测试从建表到Scan全流程进入HBase Shell的方式是hbase shell注意Shell的回显会比较慢尤其是第一次执行时ZooKeeper要建立连接大概有几秒钟延迟这是正常的不要以为卡住了。下面是伪分布式环境里我认为必须完整走一遍的基础CRUD流程# 创建命名空间 create_namespace test_ns # 建表指定列族 create test_ns:user, info, address # 查看表详情 describe test_ns:user # 插入数据rowkey是1001 put test_ns:user, 1001, info:name, zhangsan put test_ns:user, 1001, info:age, 25 put test_ns:user, 1001, address:city, beijing # 查询单行 get test_ns:user, 1001 # 查询指定列 get test_ns:user, 1001, {COLUMN info:name} # 全表扫描 scan test_ns:user # 删除列和表 deleteall test_ns:user, 1001 disable test_ns:user drop test_ns:user这里有几个经验想分享。第一建表时列族一定不要贪多。HBase的每个列族对应一个独立的存储文件多个列族意味着一次写入要写多个文件性能会下降。生产环境通常1到3个列族就够用。日常测试一个列族完全够。第二put命令的语法很多人会记错完整的写法是put 表名, rowkey, 列族:列标识符, 值。注意列标识符前面的冒号不能丢。如果列族名或者列名写错HBase不会报错而是会静默地在表里创建一个新的列标识符等数据越积越多才发现表里全是垃圾列。这个机制比较坑我在教学时专门强调过。第三get和scan的区别要理解清楚。get严格按rowkey查一行走的是索引速度快scan是范围扫描可以指定起始rowkey和结束rowkey但不指定条件时会全表扫描数据量大时很慢测试时无所谓生产环境用scan要非常克制。4.2 预分区与自动拆分测试搞懂Region分裂机制关于Region拆分我的建议是先测预分区再测自动拆分。这两件事看起来都是“怎么让Region变多”但背后的触发机制完全不同。预分区是在建表时手动指定rowkey的分布范围HBase按照这些范围一次性创建多个Region避免后续写入时热Region不断Split。测试命令create test_ns:pre_split, cf1, SPLITS [1000, 2000, 3000]执行后可以用hbase shell里的status detailed查看Region分布或者直接看HMaster Web UI能清楚看到表被分成了4个Region一个空Region三个预定义边界切分的Region。为什么这么做HBase的rowkey在物理上是按字典序排列的如果建表时不预分区数据全部涌入单一Region达到阈值后触发Split这个过程中该Region的写入会短暂阻塞而且Split产生的文件需要Compaction来合并对性能影响很明显。预分区的核心价值是让数据从一开始就均匀分摊到多个Region上。自动拆分则是让HBase自己根据Region大小触发分裂。hbase.hregion.max.filesize参数默认是10GB测自动拆分时等10GB太慢了可以临时调小比如设置为128MBproperty namehbase.hregion.max.filesize/name value134217728/value /property改完配置后重启HBase然后往表里不停地put数据写一段时间后观察Region数量变化。需要注意的是伪分布式只有一个RegionServerRegion越多碎片化越严重如果只是为了理解机制测试完就删表别留着影响后续实验。4.3 数据导入测试Sqoop操作HBase的完整链路Sqoop操作HBase是面试和实际工作中都常被问到的点。我建议在伪分布式环境里把这条链路完整跑一遍因为Mysql到HBase的数据导入涉及Sqoop、YARN、HBase三个组件的协同任何一个环节配置不对都跑不起来。先准备MySQL测试数据CREATE DATABASE test_db; USE test_db; CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(20), amount DECIMAL(10,2), create_time DATETIME ); INSERT INTO orders (user_id, amount, create_time) VALUES (U001, 99.50, NOW()); INSERT INTO orders (user_id, amount, create_time) VALUES (U002, 150.00, NOW());Sqoop导入HBase时最常用的方式是sqoop import \ --connect jdbc:mysql://localhost:3306/test_db \ --username root \ --password your_password \ --table orders \ --hbase-table test_ns:orders \ --column-family cf1 \ --hbase-row-key id \ --hbase-create-table \ --m 1参数含义逐个说--hbase-table指定HBase目标表名--column-family指定列族--hbase-row-key指定将MySQL的哪一列作为rowkey--hbase-create-table让Sqoop自动建表--m 1表示只用1个Mapper伪分布式环境用多Mapper没有意义反而会因为资源调度变慢。导入完成后回HBase Shell验证scan test_ns:orders然后试一下带条件的查询get test_ns:orders, 1Sqoop导入时有一个默认行为值得一提它会将MySQL表的每一行非主键列都放到--column-family指定的列族下列名就是MySQL里的字段名值全部转为字符串。这意味着HBase里的数据结构和你MySQL里的原表结构差不多只是物理存储方式变了。这条链路里最常遇到的问题有两个一是Sqoop任务提交到YARN但YARN没配好任务直接失败二是MySQL驱动mysql-connector-java.jar没放到Sqoop的lib目录报ClassNotFoundException。前者在上文配yarn-site.xml时就能避免后者提前把驱动下载放进去就行。5. WAL日志异常与常见故障排查实录5.1 WAL机制简述与伪分布式常见异常WAL是HBase里最核心的可靠性机制全称Write-Ahead Log预写日志。HBase写入数据时不会直接改内存中的数据而是先把写入操作追加到WAL日志文件中然后再更新内存中的MemStore。这样一旦RegionServer宕机重启后可以回放WAL日志来恢复尚未落盘的数据。这个机制本身不复杂但伪分布式环境下因为角色集中在一台机器上资源争抢更容易触发WAL异常。以下是我实测中遇到过的几种典型情况。WAL日志写入慢或阻塞伪分布式只有一块磁盘HDFS的DataNode写入和HBase的WAL写入共用同一块磁盘I/O当RegionServer执行Flush或Compaction时磁盘I/O被打满WAL写入就会变慢极端情况下会报Blocking WAL这是RegionServer自我保护机制触发的——它发现WAL写入速度跟不上CPU处理速度就强制阻塞写入请求让数据能先落盘。遇到这个情况本质原因是磁盘性能不够短期内你可以尝试调大hbase.regionserver.hlog.blocksize和hbase.regionserver.logroll.period参数来缓解但长期来看换一块SSD比什么都管用。WAL文件路径异常HBase的WAL默认存放在hbase.rootdir下的WALs目录中。如果你改了hbase.rootdir但没有重启HDFS或者HDFS本身状态异常RegionServer启动时会报Failed to create WAL directory。排查这个问题的第一步是上HDFS确认目录状态hdfs dfs -ls /hbase/WALs如果目录存在但RegionServer还是起不来看看hbase.regionserver.hlog.dir这个参数有没有被改过正常不用改默认跟随hbase.rootdir。还有一次我在测试时手动删了/hbase/WALs下的子目录结果RegionServer直接拒绝服务后来花了很长时间才意识到HBase对这个目录的权限要求非常严格不要在运行时手动改动HDFS上的HBase数据目录。WAL回放时损坏伪分布式环境如果直接kill -9掉RegionServer进程WAL里可能残留未完成的事务记录重启时HBase会尝试回放这些WAL。如果WAL文件本身也损坏了重启会卡在恢复日志阶段。此时最直接的办法是把损坏的WAL文件转移或删除然后重启。注意这个操作会丢失该WAL里尚未落盘的数据但在测试环境里这个代价可以接受。定位损坏文件的方式是看RegionServer日志里面会明确告诉你哪个WAL文件回放失败。5.2 常见问题速查表我整理了一张伪分布式HBase日常使用中最常见的问题表配合日志文件路径直接查能省掉大量排查时间。HBase的日志统一在$HBASE_HOME/logs/下HMaster日志是hbase-hadoop-master-node1.logRegionServer是hbase-hadoop-regionserver-node1.log。现象可能原因排查方式解决方案HMaster启动后自动退出ZooKeeper数据目录异常看master日志中ZK相关报错备份后清除/home/hadoop/data/tmp下的ZK数据目录RegionServer起不来HDFS副本数不足检查dfs.replication是否设置为1将副本数改为1后重启HDFSShell执行status无响应ZooKeeper连接超时ping node1检查2181端口检查hbase.zookeeper.quorum主机名是否可解析写入时报NotEnoughReplicasExceptionHDFS块副本数为3但只有1个DataNode查看HDFS Web UI修改dfs.replication为1重启HDFSWAL目录创建失败HDFS空间不足或目录权限异常hdfs dfs -du -h /hbase清理HDFS空间确认目录属主HBase Shell操作超时单机资源紧张看系统负载top命令调大hbase.client.operation.timeout或改善机器配置这张表里的每一项都是我在实际搭建过程中真实遇到并解决过的。把这些问题的原因和表现记熟不光能应付环境搭建面试的时候被问到HBase运维问题你也能从容答出排查思路。5.3 杀手锏级排查技巧日志文件里找答案排查HBase问题我的个人习惯是先看日志再做操作绝不猜。很多初学者遇到RegionServer挂掉第一反应是重启结果重启了一百次还是挂因为根因根本不在重启这个动作能解决的范围内。具体做法是启动失败后立刻打开tail -100看最近日志重点搜索ERROR、FATAL、Exception这几个关键字。如果是Java堆栈异常往上翻十几行找到Caused by那一行那才是真正的根因。比如HMaster启动失败日志里如果出现了FileSystemManipulationException或者NoSuchFileException基本可以断定是和HDFS通信有问题和HBase自身的配置无关。还有一个调试技巧在启动HBase时加上-D参数开启调试日志${HBASE_HOME}/bin/hbase-daemon.sh start master -Dorg.apache.hadoop.hbase.master.log4j.loggerDEBUG但调试日志量非常大伪分布式环境下可能刷屏严重我更推荐的做法是定位到具体模块再开启对应的Logger。日常环境里保持INFO级别就够了等真出问题时再按需调高。6. 测试完成之后的收尾与进阶建议测试做完了环境确认没问题之后还有两个收尾的小建议。第一个建议是学会正确停止HBase。直接kill进程是新手最容易犯的错正确的关闭顺序是先停HBase Shell然后执行stop-hbase.sh等HMaster和RegionServer都退出后再执行stop-dfs.sh。如果顺序反了HDFS先停了HBase的RegionServer会在日志里刷一堆连接异常。还有反复启动时不要忘了清空/tmp下的临时文件HBase在启动过程中会产生不少临时锁文件残留锁文件会导致端口被占用现象就是“明明没启动但端口起不来”。第二个建议是在伪分布式环境里顺手把HBase的数据备份练一遍。HBase的snapshot命令非常实用测试环境里可以轻松演练snapshot test_ns:user, snapshot_user_001 clone_snapshot snapshot_user_001, test_ns:user_restore这个操作在生产环境的价值极高——很多公司做HBase数据迁移或者表结构变更时就是先打快照再克隆。在伪分布式环境里提前练熟比真到了生产环境临阵磨枪要强得多。最后说说这个环境还能怎么扩展。伪分布式环境跑通后你可以非常自然地往三个方向深入第一试试HBase的Region分裂参数调优观察不同阈值下Region数量和写入性能的变化第二把Sqoop的导入做成定时增量导入研究如何用--incremental append模式同步MySQL数据到HBase第三进阶到真实的完全分布式部署把HMaster、RegionServer、ZooKeeper分别拆到3台机器上感受伪分布和真分布在配置上的差别和关联。我个人当初就是靠一台4核8G的机器把这套环境跑通然后一步步扩展到真实集群的。虽然伪分布式环境跑不出什么惊人的性能数据但它把HBase的工作原理和故障排查思路完完整整地教给了我。我之后在生产环境处理过的绝大多数HBase问题在伪分布式阶段基本都见过相似的原型。这套环境值得你花一个周末把它跑通。
