简介这是为Ambari 2.7.5编译环境准备的大数据组件离线包之一面向手动搭建HDP 3.1.4平台、或经常编译Ambari相关项目的开发与运维人员。由于官方源下载极慢提前将HBase 2.0.2.3.1.4.0-315二进制压缩包打包分享可大幅缩短编译前的依赖准备时间。整个压缩包共412个文件大小约211.57MB内部以jar库文件、rb脚本、sh启动与配置脚本为主同时包含少量xml配置、cmd命令文件及前端样式资源覆盖HBase运行所需的可执行程序、类库与配置文件。目前已有2191人学习使用适合在离线或弱网环境中部署HBase时直接引用。作者还同步整理了Hadoop、Grafana、Phoenix等配套大包便于一次性备齐Ambari编译所需依赖减少因网络中断导致的重复下载。 拿到这个安装包的时候大多数人第一反应是“这不就是个HBase的tar包嘛”。但如果你仔细看文件名里的2.0.2.3.1.4.0-315会发现事情没那么简单——这个版本号其实是HDP发行版的命名规则而不是Apache社区版的纯版本号。也就是说你拿到的不是原生Apache HBase 2.0.2而是hortonworks打包、基于HBase 2.0.2内核、附带一堆平台适配和bugfix的企业发行版二进制包。这篇文章我就从安装配置、端口清单、核心原理到面试高频考点把hbase-2.0.2.3.1.4.0-315-bin.tar.gz这个包一次讲透。无论你是刚入行的大数据工程师还是准备面试的候选人这篇都能帮你在实际部署和原理理解上少走弯路。1. 拿到这个tar包先搞明白它到底是什么1.1 版本号里的秘密2.0.2.3.1.4.0-315怎么读这个版本号可以拆成两段看。第一段2.0.2是Apache HBase社区版本号表示内核基于HBase 2.0.2。第二段3.1.4.0-315是HDPHortonworks Data Platform的版本号其中3.1.4是HDP的大版本0-315是build号。这种双版本号命名在CDH和HDP这类发行版里非常常见。对于直接使用Apache社区版的团队来说版本就是2.0.2简单干净但如果你所在的公司用的是HDP全家桶那安装包就必须要和HDP的元数据服务、Ambari管理平台兼容不能随便拿个社区版就往上怼。1.2 部署前必须确认的三件事第一确认JDK版本。HBase 2.0.2官方要求JDK 8实际部署中我建议用JDK 8u161以上版本。之前踩过坑用JDK 8u121跑HBase 2.0.2会偶发java.lang.IllegalArgumentException: Invalid character之类的异常查了半天最后发现是JDK老版本对TLS握手协议支持不完整导致的升级JDK小版本后问题消失。第二确认Hadoop版本兼容性。HBase 2.x对Hadoop 3.x的兼容做了大量适配但这个HDP 3.1.4.0发行包默认适配的是Hadoop 3.1.1。如果你硬要用它跑在Hadoop 2.7上大概率启动时会报UnsupportedClassVersionError或者客户端协议不匹配。最稳妥的做法是去看安装包里的hbase-shaded-client依赖确认里面打包的Hadoop client版本。第三确认ZooKeeper版本。HBase 2.0.2对ZooKeeper 3.4.x兼容性最好HDP 3.1.4.0自带的是ZooKeeper 3.4.14。这里有个细节HBase 2.x以后的版本内置了HBaseZK但默认还是使用外部ZK。如果你用ZK 3.5.x需要额外处理admin server端口冲突的问题因为ZK 3.5默认会在8080端口起一个管理服务和HBase的Master端口容易撞车。2. 安装配置实操从解压到集群跑起来2.1 解压与目录规划拿到tar包后第一步是解压到规范目录。我习惯把大数据组件统一放在/opt下而不是用户的home目录这样多个用户都能访问也方便统一管理权限。tar -zxvf hbase-2.0.2.3.1.4.0-315-bin.tar.gz -C /opt/ ln -s /opt/hbase-2.0.2.3.1.4.0-315 /opt/hbase之所以做个软链是为了后续升级版本时不需要改一堆配置文件里的路径。很多老手推荐的HBASE_HOME环境变量也直接指向软链的路径就行。cat /etc/profile EOF export HBASE_HOME/opt/hbase export PATH$PATH:$HBASE_HOME/bin EOF source /etc/profile然后编辑conf/hbase-env.sh这里有两个关键配置必须改export JAVA_HOME/usr/local/jdk1.8.0_161 export HBASE_MANAGES_ZKfalseHBASE_MANAGES_ZKfalse的意思是让HBase使用外部ZooKeeper而不是自己启动内置ZK实例。生产环境强烈建议用外部ZK否则RegionServer宕机恢复时内置ZK的状态一致性很难保证。2.2 hbase-site.xml核心参数逐一拆解hbase-site.xml是整个HBase部署的关键我直接给你一份生产可用配置再逐个解释为什么这么设configuration property namehbase.rootdir/name valuehdfs://hadoop-cluster/user/hbase/value /property property namehbase.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.master.port/name value16000/value /property property namehbase.regionserver.port/name value16020/value /property /configurationhbase.rootdir指定了HBase数据在HDFS上的存储路径。注意这个路径如果已经存在且非空HBase启动时会尝试读取里面的元数据。我见过有同学图省事直接配成/hbase结果和HDFS根目录下的其他目录混在一起权限和垃圾文件问题一堆。建议单独建一个用户目录。hbase.zookeeper.quorum填ZK集群地址生产环境至少3个节点。这里有个细节不需要填所有ZK节点HBase客户端会通过ZK的hbase:meta节点定位元数据填3个就足够了但如果你只有2个ZKHBase也能工作只是可用性差一些。关于hbase.master.port的默认值HBase 2.x是16000和160201.x是60000和60020很多网上老教程还在写60000照着配会把端口搞混。我建议第一次部署的同学在Master和RegionServer节点上分别执行netstat -anp | grep 160确认监听端口是否正确。2.3 regionservers与备份Master配置conf/regionservers文件里填写所有RegionServer节点的主机名每行一个node02 node03 node04HBase启动时会通过这个文件启动对应的RegionServer进程。注意这里填的是主机名不是IP。主机名解析依赖/etc/hosts如果你在云环境里跑还要确保所有节点的hostname都是唯一的避免因为hostname重复导致RegionServer进程在同一台物理机上重复启动。如果你想启用备份Master在conf/backup-masters文件里填上备用节点node05HBase的Active Master宕机后backup-masters里的节点会自动接管。这个机制和HDFS的NameNode HA类似都是通过ZK做选主。有一点要说明backup-masters文件并不是官方文档里明确描述的机制而是HDP发行版在hbase-daemon.sh脚本里做的扩展。如果是纯Apache社区版需要用hbase master backup命令手动启动备份Master或者通过ZK选主机制自行管理。3. 端口清单与连通性自查3.1 一张表理清HBase各项服务端口端口清单是面试和排障的高频考点我整理了一张实际部署中必须掌握的端口表服务组件默认端口说明HMaster RPC端口16000Master对外提供元数据管理、DDL操作的RPC端口HMaster Web UI16010查看Master状态、Region分布、表列表的HTTP端口RegionServer RPC端口16020RegionServer对外提供数据读写RPC的端口RegionServer Web UI16030查看RegionServer负载、Region分布的HTTP端口ZooKeeper Client端口2181HBase通过ZK协调Master选举和Region分配HDFS NameNode RPC端口8020 / 9000HBase底层数据存储依赖HDFS不同发行版端口不同HDFS DataNode RPC端口9866RegionServer实际写入数据时与DataNode通信的端口真实排障中最容易被忽略的是HDFS端口。HBase读写慢、写入超时有时候不是HBase本身的问题而是HDFS DataNode节点掉线、副本数不足导致的。所以排查时要先把HDFS的hdfs dfsadmin -report跑一遍确认所有DataNode节点都是Live状态。3.2 端口起不来怎么排查端口起不来的原因按发生率从高到低排列第一端口被占用。尤其是测试环境之前跑过别的HBase实例进程没杀干净。在启动新实例前用jps确认没有遗留的HMaster和HRegionServer进程再用netstat -anp | grep 16000看看端口是否被其他程序占用。第二ZK集群状态异常。HBase Master启动时需要连接ZK如果ZK的过半节点不可用Master会一直卡在Waiting for the ZooKeeper cluster to become available这个状态。遇到这种情况先去zkCli.sh里执行ls /hbase如果命令卡住说明ZK本身有问题如果rs目录下出现了临时节点但很快消失说明RegionServer和Master之间的心跳有问题。第三Hostname解析不对。HBase集群节点之间通过hostname通信如果/etc/hosts里没配置对应映射Master启动时会报java.net.UnknownHostException。我见过一个诡异的情况所有节点的hostname都配了但Master节点上的/etc/hostname写的是localhost导致HMaster把自己的地址注册成localhost:16000其他节点根本连不上。这个问题很隐蔽启动日志里可能看不到报错但客户端连接时就是超时。4. 弄懂读写链路配参不再靠猜4.1 四大组件各管什么HBase依赖四个核心组件的协作才能正常工作理解它们的职责是看懂读写链路的基础。HMaster负责Table的DDL操作创建表、删除表、修改列族以及Region的分配和迁移。它不参与具体的数据读写请求所以HBase的高可用瓶颈不在Master上。很多同学面试时会说“Master是单点”严谨来说Master有备份机制但数据读写不经过Master所以Master宕机只影响DDL操作不影响已有数据的读写。RegionServer是真正干活的人负责管理若干个Region的数据读写处理客户端的读写请求并定期将内存中的数据刷写到HDFS。一台RegionServer常驻一个进程内部维护多个Region实例。ZooKeeper承担协调者的角色维护HBase的元数据位置。客户端在发起任何请求前第一件事是连接ZK从ZK里找到hbase:meta表所在RegionServer的位置然后才能继续后续操作。HDFS是底层的存储底座HBase的HFile和WAL日志最终都落在HDFS上。HBase不自己管理磁盘就是因为它把一致性、副本和容错全交给了HDFS处理。4.2 写路径与读路径的关键环节写一条数据时客户端先通过ZK找到meta表所在RegionServer再从meta表中查到目标region所在的RegionServer然后直接向该RegionServer发起写请求。RegionServer收到写请求后会做两件事先写入WAL日志在HDFS上再写入MemStore内存中。当MemStore达到阈值默认128MB时RegionServer会将其刷写成HFile并最终合并Compact。这里要记住一个关键点WAL是写路径的性能瓶颈。如果集群的写入延迟高先看HDFS的DataNode是否有节点异常再看WAL刷写策略是否合理。HBase 2.0.2支持异步WAL通过hbase.regionserver.hlog.async.batcher.impl参数开启可以显著降低高并发下的写入延迟但代价是同步内存延迟和数据安全性有一定折中生产环境要评估风险再开启。读路径的关键在于BlockCache。HBase读数据时会优先查BlockCache再查MemStore最后才查HFile。如果业务是点查为主的场景可以适当调大hfile.block.cache.size默认0.4即堆内存的40%如果是写多读少的场景把这个值调低反而能减少GC压力。5. 高频问题与面试考点整理5.1 老生常谈的Region分裂与热点问题Region分裂是HBase运营中绕不开的话题。当Region的单个HFile大小超过hbase.hregion.max.filesize默认10GB时Region会自动分裂成两个。听起来很简单但实际生产环境里频繁分裂会导致集群不稳定。原因在于Region分裂瞬间需要更新meta表同时父Region的引用文件要在所有RS节点上清理干净这个过程中如果恰好有大量写入请求很容易造成短暂的数据不一致。我建议在数据量可预估的情况下预建Region分区通过hbase shell的create命令指定SPLITS[a,b,c]把数据分散到多个Region里避免单点写入过热。热点问题最常见的原因是RowKey设计不合理。比如用时间戳当RowKey会因为前缀相同导致大量写入落在同一个Region上。典型解法是加盐、哈希、反转RowKey等策略。有一条经验规律RowKey的前缀必须足够离散否则怎么调参都没用。5.2 运维现场最常见的几个坑坑一HBase版本和Hadoop版本不匹配导致客户端报No FileSystem for scheme hdfs。这是因为HBase发行包的HDFS客户端依赖和你的Hadoop集群不完全一致。解决办法是检查hbase classpath中是否包含匹配的hadoop-client jar或者把Hadoop的share/hadoop/common、share/hadoop/hdfs下的jar包软链到HBase的lib目录下。坑二RegionServer频繁Full GC导致ZooKeeper会话超时被踢出集群。RegionServer同时管理多个RegionMemStore和BlockCache都在JVM堆里如果堆大小设得不合理很容易OOM或Full GC频繁。经验值是把HBASE_HEAPSIZE设置为16GB到32GB之间同时开启hbase.regionserver.global.memstore.size限制默认0.4避免MemStore无限增长。坑三删除数据后磁盘空间没有回收。HBase删除数据不是直接删除文件而是打一个Delete标记等到Major Compaction时才会物理删除。所以你会发现删了很多数据但HDFS使用率没有下降。解决方法是手动触发Major Compactionhbase shell执行major_compact table_name但要注意执行时机尽量在业务低峰期做因为Compaction会消耗大量CPU和磁盘IO。5.3 面试官爱问的几个问题结合“hbase面试题”这个热词我整理了几个出现频率极高的考点为什么HBase的写性能比读性能好因为写入是顺序追加到WAL和MemStore的MemStore是内存操作所以写入本质上接近内存速度而读取需要先在BlockCache中查找miss后要落盘扫描HFile涉及随机IO所以性能相对较低。HBase的Region分裂和合并有什么区别分裂是Region变大后自动拆成两个子Region是HBase自动触发、自动完成的合并是用户或运维手动触发的主要目的是回收大量空Region或解决Region数量过多的问题。HBase的RowKey设计原则有哪些核心原则是长度要短、前缀要离散、业务上唯一。还需要注意如果RowKey是按时间顺序递归递增的可以通过反向RowKey将时间戳取反来平衡热点。HBase 2.x和1.x的区别是什么HBase 2.x引入了基于Procedure V2的分布式事务框架、支持Master和RegionServer的独立RPC group、指派RPC和io进程的分离、以及更智能的Compaction策略。这些改进都是为了应对更大规模集群的稳定性需求。6. 最后再分享一个部署上的小技巧如果你要在一套集群上同时跑HDFS和HBase启动顺序非常重要。HBase的RegionServer启动时会在HDFS上创建hbase.rootdir指定的目录如果此时HDFS的NameNode还没进入SafeMode退出状态会导致初始化失败。所以一个稳妥的启动流程是先启动ZooKeeper再启动HDFS等hdfs dfsadmin -safemode get显示Safe mode是OFF最后再启动HBase。反向操作也一样关闭时先停HBase再停HDFS。这个顺序在Ambari里已经被自动处理了但如果你手动部署这个顺序踩过的坑不少。另外每次改完hbase-site.xml后最好在conf/目录下执行一次hbase-config.sh验证配置格式是否正确避免因为XML语法错误导致进程起不来时还要去翻日志。本文还有配套的精品资源点击获取
HBase HDP发行版安装配置与核心原理详解
简介这是为Ambari 2.7.5编译环境准备的大数据组件离线包之一面向手动搭建HDP 3.1.4平台、或经常编译Ambari相关项目的开发与运维人员。由于官方源下载极慢提前将HBase 2.0.2.3.1.4.0-315二进制压缩包打包分享可大幅缩短编译前的依赖准备时间。整个压缩包共412个文件大小约211.57MB内部以jar库文件、rb脚本、sh启动与配置脚本为主同时包含少量xml配置、cmd命令文件及前端样式资源覆盖HBase运行所需的可执行程序、类库与配置文件。目前已有2191人学习使用适合在离线或弱网环境中部署HBase时直接引用。作者还同步整理了Hadoop、Grafana、Phoenix等配套大包便于一次性备齐Ambari编译所需依赖减少因网络中断导致的重复下载。 拿到这个安装包的时候大多数人第一反应是“这不就是个HBase的tar包嘛”。但如果你仔细看文件名里的2.0.2.3.1.4.0-315会发现事情没那么简单——这个版本号其实是HDP发行版的命名规则而不是Apache社区版的纯版本号。也就是说你拿到的不是原生Apache HBase 2.0.2而是hortonworks打包、基于HBase 2.0.2内核、附带一堆平台适配和bugfix的企业发行版二进制包。这篇文章我就从安装配置、端口清单、核心原理到面试高频考点把hbase-2.0.2.3.1.4.0-315-bin.tar.gz这个包一次讲透。无论你是刚入行的大数据工程师还是准备面试的候选人这篇都能帮你在实际部署和原理理解上少走弯路。1. 拿到这个tar包先搞明白它到底是什么1.1 版本号里的秘密2.0.2.3.1.4.0-315怎么读这个版本号可以拆成两段看。第一段2.0.2是Apache HBase社区版本号表示内核基于HBase 2.0.2。第二段3.1.4.0-315是HDPHortonworks Data Platform的版本号其中3.1.4是HDP的大版本0-315是build号。这种双版本号命名在CDH和HDP这类发行版里非常常见。对于直接使用Apache社区版的团队来说版本就是2.0.2简单干净但如果你所在的公司用的是HDP全家桶那安装包就必须要和HDP的元数据服务、Ambari管理平台兼容不能随便拿个社区版就往上怼。1.2 部署前必须确认的三件事第一确认JDK版本。HBase 2.0.2官方要求JDK 8实际部署中我建议用JDK 8u161以上版本。之前踩过坑用JDK 8u121跑HBase 2.0.2会偶发java.lang.IllegalArgumentException: Invalid character之类的异常查了半天最后发现是JDK老版本对TLS握手协议支持不完整导致的升级JDK小版本后问题消失。第二确认Hadoop版本兼容性。HBase 2.x对Hadoop 3.x的兼容做了大量适配但这个HDP 3.1.4.0发行包默认适配的是Hadoop 3.1.1。如果你硬要用它跑在Hadoop 2.7上大概率启动时会报UnsupportedClassVersionError或者客户端协议不匹配。最稳妥的做法是去看安装包里的hbase-shaded-client依赖确认里面打包的Hadoop client版本。第三确认ZooKeeper版本。HBase 2.0.2对ZooKeeper 3.4.x兼容性最好HDP 3.1.4.0自带的是ZooKeeper 3.4.14。这里有个细节HBase 2.x以后的版本内置了HBaseZK但默认还是使用外部ZK。如果你用ZK 3.5.x需要额外处理admin server端口冲突的问题因为ZK 3.5默认会在8080端口起一个管理服务和HBase的Master端口容易撞车。2. 安装配置实操从解压到集群跑起来2.1 解压与目录规划拿到tar包后第一步是解压到规范目录。我习惯把大数据组件统一放在/opt下而不是用户的home目录这样多个用户都能访问也方便统一管理权限。tar -zxvf hbase-2.0.2.3.1.4.0-315-bin.tar.gz -C /opt/ ln -s /opt/hbase-2.0.2.3.1.4.0-315 /opt/hbase之所以做个软链是为了后续升级版本时不需要改一堆配置文件里的路径。很多老手推荐的HBASE_HOME环境变量也直接指向软链的路径就行。cat /etc/profile EOF export HBASE_HOME/opt/hbase export PATH$PATH:$HBASE_HOME/bin EOF source /etc/profile然后编辑conf/hbase-env.sh这里有两个关键配置必须改export JAVA_HOME/usr/local/jdk1.8.0_161 export HBASE_MANAGES_ZKfalseHBASE_MANAGES_ZKfalse的意思是让HBase使用外部ZooKeeper而不是自己启动内置ZK实例。生产环境强烈建议用外部ZK否则RegionServer宕机恢复时内置ZK的状态一致性很难保证。2.2 hbase-site.xml核心参数逐一拆解hbase-site.xml是整个HBase部署的关键我直接给你一份生产可用配置再逐个解释为什么这么设configuration property namehbase.rootdir/name valuehdfs://hadoop-cluster/user/hbase/value /property property namehbase.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.master.port/name value16000/value /property property namehbase.regionserver.port/name value16020/value /property /configurationhbase.rootdir指定了HBase数据在HDFS上的存储路径。注意这个路径如果已经存在且非空HBase启动时会尝试读取里面的元数据。我见过有同学图省事直接配成/hbase结果和HDFS根目录下的其他目录混在一起权限和垃圾文件问题一堆。建议单独建一个用户目录。hbase.zookeeper.quorum填ZK集群地址生产环境至少3个节点。这里有个细节不需要填所有ZK节点HBase客户端会通过ZK的hbase:meta节点定位元数据填3个就足够了但如果你只有2个ZKHBase也能工作只是可用性差一些。关于hbase.master.port的默认值HBase 2.x是16000和160201.x是60000和60020很多网上老教程还在写60000照着配会把端口搞混。我建议第一次部署的同学在Master和RegionServer节点上分别执行netstat -anp | grep 160确认监听端口是否正确。2.3 regionservers与备份Master配置conf/regionservers文件里填写所有RegionServer节点的主机名每行一个node02 node03 node04HBase启动时会通过这个文件启动对应的RegionServer进程。注意这里填的是主机名不是IP。主机名解析依赖/etc/hosts如果你在云环境里跑还要确保所有节点的hostname都是唯一的避免因为hostname重复导致RegionServer进程在同一台物理机上重复启动。如果你想启用备份Master在conf/backup-masters文件里填上备用节点node05HBase的Active Master宕机后backup-masters里的节点会自动接管。这个机制和HDFS的NameNode HA类似都是通过ZK做选主。有一点要说明backup-masters文件并不是官方文档里明确描述的机制而是HDP发行版在hbase-daemon.sh脚本里做的扩展。如果是纯Apache社区版需要用hbase master backup命令手动启动备份Master或者通过ZK选主机制自行管理。3. 端口清单与连通性自查3.1 一张表理清HBase各项服务端口端口清单是面试和排障的高频考点我整理了一张实际部署中必须掌握的端口表服务组件默认端口说明HMaster RPC端口16000Master对外提供元数据管理、DDL操作的RPC端口HMaster Web UI16010查看Master状态、Region分布、表列表的HTTP端口RegionServer RPC端口16020RegionServer对外提供数据读写RPC的端口RegionServer Web UI16030查看RegionServer负载、Region分布的HTTP端口ZooKeeper Client端口2181HBase通过ZK协调Master选举和Region分配HDFS NameNode RPC端口8020 / 9000HBase底层数据存储依赖HDFS不同发行版端口不同HDFS DataNode RPC端口9866RegionServer实际写入数据时与DataNode通信的端口真实排障中最容易被忽略的是HDFS端口。HBase读写慢、写入超时有时候不是HBase本身的问题而是HDFS DataNode节点掉线、副本数不足导致的。所以排查时要先把HDFS的hdfs dfsadmin -report跑一遍确认所有DataNode节点都是Live状态。3.2 端口起不来怎么排查端口起不来的原因按发生率从高到低排列第一端口被占用。尤其是测试环境之前跑过别的HBase实例进程没杀干净。在启动新实例前用jps确认没有遗留的HMaster和HRegionServer进程再用netstat -anp | grep 16000看看端口是否被其他程序占用。第二ZK集群状态异常。HBase Master启动时需要连接ZK如果ZK的过半节点不可用Master会一直卡在Waiting for the ZooKeeper cluster to become available这个状态。遇到这种情况先去zkCli.sh里执行ls /hbase如果命令卡住说明ZK本身有问题如果rs目录下出现了临时节点但很快消失说明RegionServer和Master之间的心跳有问题。第三Hostname解析不对。HBase集群节点之间通过hostname通信如果/etc/hosts里没配置对应映射Master启动时会报java.net.UnknownHostException。我见过一个诡异的情况所有节点的hostname都配了但Master节点上的/etc/hostname写的是localhost导致HMaster把自己的地址注册成localhost:16000其他节点根本连不上。这个问题很隐蔽启动日志里可能看不到报错但客户端连接时就是超时。4. 弄懂读写链路配参不再靠猜4.1 四大组件各管什么HBase依赖四个核心组件的协作才能正常工作理解它们的职责是看懂读写链路的基础。HMaster负责Table的DDL操作创建表、删除表、修改列族以及Region的分配和迁移。它不参与具体的数据读写请求所以HBase的高可用瓶颈不在Master上。很多同学面试时会说“Master是单点”严谨来说Master有备份机制但数据读写不经过Master所以Master宕机只影响DDL操作不影响已有数据的读写。RegionServer是真正干活的人负责管理若干个Region的数据读写处理客户端的读写请求并定期将内存中的数据刷写到HDFS。一台RegionServer常驻一个进程内部维护多个Region实例。ZooKeeper承担协调者的角色维护HBase的元数据位置。客户端在发起任何请求前第一件事是连接ZK从ZK里找到hbase:meta表所在RegionServer的位置然后才能继续后续操作。HDFS是底层的存储底座HBase的HFile和WAL日志最终都落在HDFS上。HBase不自己管理磁盘就是因为它把一致性、副本和容错全交给了HDFS处理。4.2 写路径与读路径的关键环节写一条数据时客户端先通过ZK找到meta表所在RegionServer再从meta表中查到目标region所在的RegionServer然后直接向该RegionServer发起写请求。RegionServer收到写请求后会做两件事先写入WAL日志在HDFS上再写入MemStore内存中。当MemStore达到阈值默认128MB时RegionServer会将其刷写成HFile并最终合并Compact。这里要记住一个关键点WAL是写路径的性能瓶颈。如果集群的写入延迟高先看HDFS的DataNode是否有节点异常再看WAL刷写策略是否合理。HBase 2.0.2支持异步WAL通过hbase.regionserver.hlog.async.batcher.impl参数开启可以显著降低高并发下的写入延迟但代价是同步内存延迟和数据安全性有一定折中生产环境要评估风险再开启。读路径的关键在于BlockCache。HBase读数据时会优先查BlockCache再查MemStore最后才查HFile。如果业务是点查为主的场景可以适当调大hfile.block.cache.size默认0.4即堆内存的40%如果是写多读少的场景把这个值调低反而能减少GC压力。5. 高频问题与面试考点整理5.1 老生常谈的Region分裂与热点问题Region分裂是HBase运营中绕不开的话题。当Region的单个HFile大小超过hbase.hregion.max.filesize默认10GB时Region会自动分裂成两个。听起来很简单但实际生产环境里频繁分裂会导致集群不稳定。原因在于Region分裂瞬间需要更新meta表同时父Region的引用文件要在所有RS节点上清理干净这个过程中如果恰好有大量写入请求很容易造成短暂的数据不一致。我建议在数据量可预估的情况下预建Region分区通过hbase shell的create命令指定SPLITS[a,b,c]把数据分散到多个Region里避免单点写入过热。热点问题最常见的原因是RowKey设计不合理。比如用时间戳当RowKey会因为前缀相同导致大量写入落在同一个Region上。典型解法是加盐、哈希、反转RowKey等策略。有一条经验规律RowKey的前缀必须足够离散否则怎么调参都没用。5.2 运维现场最常见的几个坑坑一HBase版本和Hadoop版本不匹配导致客户端报No FileSystem for scheme hdfs。这是因为HBase发行包的HDFS客户端依赖和你的Hadoop集群不完全一致。解决办法是检查hbase classpath中是否包含匹配的hadoop-client jar或者把Hadoop的share/hadoop/common、share/hadoop/hdfs下的jar包软链到HBase的lib目录下。坑二RegionServer频繁Full GC导致ZooKeeper会话超时被踢出集群。RegionServer同时管理多个RegionMemStore和BlockCache都在JVM堆里如果堆大小设得不合理很容易OOM或Full GC频繁。经验值是把HBASE_HEAPSIZE设置为16GB到32GB之间同时开启hbase.regionserver.global.memstore.size限制默认0.4避免MemStore无限增长。坑三删除数据后磁盘空间没有回收。HBase删除数据不是直接删除文件而是打一个Delete标记等到Major Compaction时才会物理删除。所以你会发现删了很多数据但HDFS使用率没有下降。解决方法是手动触发Major Compactionhbase shell执行major_compact table_name但要注意执行时机尽量在业务低峰期做因为Compaction会消耗大量CPU和磁盘IO。5.3 面试官爱问的几个问题结合“hbase面试题”这个热词我整理了几个出现频率极高的考点为什么HBase的写性能比读性能好因为写入是顺序追加到WAL和MemStore的MemStore是内存操作所以写入本质上接近内存速度而读取需要先在BlockCache中查找miss后要落盘扫描HFile涉及随机IO所以性能相对较低。HBase的Region分裂和合并有什么区别分裂是Region变大后自动拆成两个子Region是HBase自动触发、自动完成的合并是用户或运维手动触发的主要目的是回收大量空Region或解决Region数量过多的问题。HBase的RowKey设计原则有哪些核心原则是长度要短、前缀要离散、业务上唯一。还需要注意如果RowKey是按时间顺序递归递增的可以通过反向RowKey将时间戳取反来平衡热点。HBase 2.x和1.x的区别是什么HBase 2.x引入了基于Procedure V2的分布式事务框架、支持Master和RegionServer的独立RPC group、指派RPC和io进程的分离、以及更智能的Compaction策略。这些改进都是为了应对更大规模集群的稳定性需求。6. 最后再分享一个部署上的小技巧如果你要在一套集群上同时跑HDFS和HBase启动顺序非常重要。HBase的RegionServer启动时会在HDFS上创建hbase.rootdir指定的目录如果此时HDFS的NameNode还没进入SafeMode退出状态会导致初始化失败。所以一个稳妥的启动流程是先启动ZooKeeper再启动HDFS等hdfs dfsadmin -safemode get显示Safe mode是OFF最后再启动HBase。反向操作也一样关闭时先停HBase再停HDFS。这个顺序在Ambari里已经被自动处理了但如果你手动部署这个顺序踩过的坑不少。另外每次改完hbase-site.xml后最好在conf/目录下执行一次hbase-config.sh验证配置格式是否正确避免因为XML语法错误导致进程起不来时还要去翻日志。本文还有配套的精品资源点击获取