简介这款 HBase 离线组件包专为 Ambari 2.7.5 编译过程准备面向需要搭建 HDP 3.1.4.0 集群或对 HBase 进行二次开发的大数据工程师。压缩包内共包含 412 个文件整体大小约 211.57 兆字节其中以 jar 类文件为主数量达到 194 个这些是 HBase 运行所需的核心依赖另有 158 个 rb 脚本和 17 个 sh 脚本承担服务启动、停止与日常维护操作6 个 xml 文件与若干 properties 文件提供关键配置项同时还有少量 css、html、js 等静态资源用于辅助界面展示。全部文件按较为完整的目录结构组织便于在编译时直接引用或整理到本地仓库。提前下载该压缩包可显著缓解 Ambari 编译期间因外部源下载缓慢造成的卡顿和超时问题为集群部署节省大量时间。这一资源已有 2195 人学习下载适合离线安装、依赖预置以及基于 HDP 的组件定制场景使用者可以按需提取其中的库文件、脚本与配置模板快速融入自己的大数据平台。1. 这个hbase-2.0.2.3.1.4.0-315-bin.tar.gz是什么先看懂版本号再决定你的部署路径第一次拿到这个压缩包的人多半会被它的名字绕晕为什么一个HBase会有四段版本号其实它拆开只有三个关键信息——HBase是2.0.2它绑定的底层发行版是3.1.4.0最后面的-315是构建号表示这是由发行版团队重新编译、打包、做过兼容性验证的二进制产物。和Apache官网原版tar包相比这个包最大的区别是lib目录里已经带上了和HDFS客户端匹配的依赖你不需要自己解决一堆类库冲突也不需要从源码编译。它解决的是发行版生态里HBase安装与配置最常见的痛点版本匹配。适合的读者是准备在发行版HDFS集群上跑HBase的数据平台工程师或者刚接手这类集群、想搞明白这套包和原生包差异的人。我用这个包的次数不少可以负责任地说直接拿原生文档配这个包是最容易翻车的路线因为参数体系和启动逻辑都有差别。2. hbase安装与配置前先做三件事环境匹配、安装包校验与目录规划2.1 先过一遍运行环境JDK版本、操作系统与底层文件系统连通性安装配置HBase 2.0.2之前我不建议先解压而是先把运行环境确认到位。这个bin.tar.gz里携带的本地库是按Linux x86_64编译的JDK版本如果不对后面启动时会冒出各式各样看不懂的报错比如原生库加载失败、类字节码版本不兼容。先跑一遍下面这条命令组合能省掉后面大半的排查时间# 1) 确认操作系统内核架构x86_64 最好避免原生库加载问题 uname -a # 2) 确认JDK版本HBase 2.0.2的二进制包是按JDK 1.8编译的 java -version 21 # 3) 确认底层HDFS客户端可用HBase的rootdir要写到HDFS上 hdfs dfs -ls / 2/dev/null || echo HDFS客户端不可用先解决上层环境第一行命令里重点关注输出中的x86_64字样。如果机器是多架构环境比如ARM后面bin目录里的so文件大概率加载不了这不是配置能解决的得换对应架构的包。第二行命令要看的不是「有没有Java」而是版本号必须是1.8.x因为源码包以JDK 8为目标编译用JDK 11或17跑类加载阶段大概率会报UnsupportedClassVersionError。第三行更关键这套发行版HBase和原版最大的差异就是它默认深度依赖hbase-site.xml里的rootdir而这个目录在分布式模式下必须落在底层HDFS上。如果HDFS客户端当前用户没有权限或者版本不匹配Master启动时会直接卡在文件系统初始化阶段日志里全是连接超时和配置本身完全无关。还有一点容易忽略不要只看JAVA_HOME环境变量。登录shell里可能注入了某个JDK路径但执行java -version命中的却是系统级的另一个JDK。最稳的做法是先用which java看清楚实际路径再把它填进hbase-env.sh。我见过一个集群就是这种双JDK环境配置文件里写的JDK 8实际跑起来的JDK 11RegionServer启动后几十秒就退出查了一下午才定位到问题。环境这关没过后面所有配置都是空谈。2.2 校验和解压不要跳过sha256校验也不要直接解压在root家目录发行版发布的这种大体积tar.gz下载过程中出现损坏的概率比想象中高。我通常在解压前先做一次完整性校验和发行版站点公布的校验值比对这一步不复杂但能避免解压后发现HMaster起不来、怎么查都查不出原因的尴尬。# 计算下载产物的sha256校验值与官方站点的校验值逐位比对 sha256sum hbase-2.0.2.3.1.4.0-315-bin.tar.gz # 解压到统一安装根目录建议放在 /opt 下而不是用户家目录 tar -xzf 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校验值比对是笨功夫但值得做。我之前跳过这一步解压出来的包在启动时提示缺少某个类文件重下才解决浪费的时间远比校验那十几秒多。解压目录也有讲究我见过有人解压到/root/hbase下然后用hbase用户去启动权限直接报错更常见的是解压到/home下的某个子目录路径里带用户名后面写配置时容易把路径写错。统一放/opt用软链把版本号隐藏掉是最省心的做法。解压之后建议顺手看一眼目录结构。bin/是启动脚本conf/是全部配置文件所在lib/是发行版预编译好的依赖。了解lib目录为什么要单独看是因为它决定了你不能随便替换版本这个目录里的HDFS客户端版本是固定的和底层发行版配套如果你自己换成其他版本的客户端包集群连HDFS时会出现RPC协议不匹配这是最容易在配置阶段埋下的坑。2.3 目录规划与角色拆分单独用户、独立tmp与日志目录HBase跑起来之后Master和RegionServer都会写大量临时文件、日志和PID文件。默认情况下这些目录指向/tmp这是非常危险的做法因为很多Linux系统会定期清理/tmp下的产物一旦清理发生在运行期轻则RegionServer异常退出重则集群整个挂掉。我在做目录规划时习惯为HBase建立独立的系统用户并把tmp、logs、pids三个目录单独划分和系统临时目录彻底隔离。# 创建hbase系统用户不登录、无home只用于跑服务 useradd -r -s /bin/bash hbase # 单独创建tmp、日志、PID目录避免系统清理误伤 mkdir -p /data/hbase/tmp /data/hbase/logs /data/hbase/pids # 把安装目录和数据目录归属到hbase用户 chown -R hbase:hbase /data/hbase /opt/hbase创建系统用户而不是直接在root下运行是我的习惯。HBase的启动和关闭脚本会操作文件和目录用root跑虽然省事但一旦后续接监控、做日志采集权限模型会很混乱。chown -R这条命令把整个opt安装目录都给了hbase用户所以之前解压操作如果是用root做的这里必须执行否则后续切到hbase用户启动时连conf目录里的文件都读不了。目录规划完就要明确这次部署是单机实验还是分布式集群。这个包虽然是发行版产物但完全可以跑单机模式只要把rootdir设成file:///开头的本地路径不开HDFS也能启动。但如果你准备接收生产流量我强烈建议直接按分布式模式规划Master主机一台、备选Master一台、RegionServer若干。这里不列出具体机器数因为取决于数据量但有一条原则每台RegionServer的物理机内存至少要能给HBase堆留出物理内存一半的余量后面第4章会详细算这个账。规划完节点把每台机器的主机名写到各自的/etc/hosts里保证互相能解析这一步不做后面start-hbase.sh用ssh分发启动RegionServer时一定失败。3. 改五个文件把HBase 2.0.2拉起来单机与分布式的配置差异和启动检查3.1 hbase-env.shJAVA_HOME、堆内存与PID、日志路径这个文件是HBase启动脚本读取的第一个配置也是很多人忽略的一个。默认情况它只是提供最基础的变量如果不改JVM会用系统默认的JAVA_HOME堆内存也会落在很小的默认值上一旦业务写入上来GC停顿能让你怀疑人生。我一般会改下面这几行# 指定JDK路径不使用系统PATH里猜测到的那个 export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk # Master和RegionServer共用的默认堆大小分布式节点建议4G起步 export HBASE_HEAPSIZE4G # PID文件目录Master/RS进程启动后会在这里写pid export HBASE_PID_DIR/data/hbase/pids # 日志输出目录很多排查信息都依赖这个目录下的文件 export HBASE_LOG_DIR/data/hbase/logs如果RegionServer的机器内存充裕比如物理内存32G以上我建议再单独设置RegionServer的堆大小而不是和Master用同一个值。方法是在这个文件里加上export HBASE_REGIONSERVER_HEAPSIZE16G注意区分HBASE_HEAPSIZE和HBASE_REGIONSERVER_HEAPSIZE前者作用于HMaster进程后者单独作用在每台RegionServer上。如果你只改第一个Master和RS会用同一个堆大小在混合部署场景下很容易出现Master内存不够或RS内存不够的错配。至于GC参数HBase 2.0.2这个版本上我在4G到8G堆时用CMS堆超过8G才考虑G1不要在JDK 8上强行把GC模式调成G1又配一堆G1参数反而容易引起大对象分配异常。3.2 hbase-site.xml核心参数与单机、分布式的核心差异hbase-site.xml是整个HBase集群行为的中枢。这个文件在conf目录下默认几乎是空的需要按部署模式自行补全。下面的配置是我在发行版集群上的最小集它已经是从单机模式切换到分布式模式的完整示例?xml version1.0? configuration !-- 完全分布式false或不设置时HBase会尝试用本地文件系统跑standalone -- property namehbase.cluster.distributed/name valuetrue/value /property !-- 数据根目录写在底层HDFS上目录不存在会自动创建 -- property namehbase.rootdir/name valuehdfs://nameservice1/hbase/value /property !-- ZooKeeper集群地址多个节点用逗号分隔2181端口可省略 -- property namehbase.zookeeper.quorum/name valuemaster1,worker1,worker2/value /property !-- 临时目录务必指向第2章规划好的独立目录 -- property namehbase.tmp.dir/name value/data/hbase/tmp/value /property /configurationhbase.cluster.distributed是单机和分布式最关键的开关。如果你只是本地跑通实验不写这个属性或设为false再把hbase.rootdir改成file:///data/hbase-testHBase会以standalone模式在单个JVM里跑起来但这种模式不启动独立的Master和RegionServer无法模拟真实集群行为。生产环境必须设为true且rootdir必须写成HDFS路径。注意rootdir里我写的是hdfs://nameservice1/hbase而不是hdfs://ip:port/hbase因为底层HDFS如果启用了高可用用nameservice名称最稳系统会自动解析到当前active节点写死某个节点IP的话一旦它切到standbyHBase整个就不可用了。ZooKeeper地址这里也有一个常见误区hbase.zookeeper.quorum里只需要写主机名不需要带2181端口因为端口由另一个参数hbase.zookeeper.property.clientPort控制默认就是2181。如果你在quorum里写上带端口的地址反而会导致解析异常。3.3 regionservers和backup-masters角色清单决定了集群拓扑conf目录下有两个文件——regionservers和backup-masters它们决定了哪些节点承担什么角色。regionservers文件里一行一个主机名列出所有RegionServer节点backup-masters则列出备选Master。默认情况下backup-masters文件不存在意味着集群没有热备Master一旦主Master宕机整个集群的管理操作就会中断。# conf/regionservers 内容示例注意一行一个不能有多余空格 worker1 worker2 worker3 # conf/backup-masters 内容示例文件不存在时表示不配置备选Master master2这里执行start-hbase.sh时脚本会通过SSH依次登录到regionservers列表里的每台机器远程启动RegionServer进程。所以hbase用户必须配置好到所有RegionServer节点的免密钥登录。我见过一个跳过这步的案例Master在本地正常启动但所有RegionServer都没起来日志里全是被拒绝的SSH连接记录检查配置半天才发现是免密钥没做。backup-masters这个文件很多人会忽略但生产环境我强烈建议配上。备选Master平时处于standby状态不提供写服务只在主Master故障时接管如果不配HBase的Master故障恢复能力就是零。3.4 启动、日志与第一次健康检查全部配置改完后用hbase用户执行启动。启动顺序有讲究先确保底层HDFS和ZooKeeper集群都可用再执行HBase的启动脚本。# 切换到hbase用户并启动整个集群 su - hbase -c /opt/hbase/bin/start-hbase.sh # 检查进程是否都在jps是JDK自带的进程查看工具 jps -l | grep -E HMaster|HRegionServer # 查看Master日志确认没有初始化异常 tail -f /data/hbase/logs/hbase-hbase-master-master1.log启动脚本做的事情并不复杂先在本机启动HMaster然后再通过SSH到regionservers文件里记录的每台机器启动HRegionServer。如果你看到jps里Master和RS都出现了但Master日志里有一些“waiting for regionserver to report”之类的句子不用太紧张这是Master在等所有RegionServer完成注册注册完成后会自动消除。第一次健康检查我建议直接进shell看状态不要只看进程存活就以为万事大吉/opt/hbase/bin/hbase shell status detailed输出里重点关注region count和每个RegionServer的requests计数。如果某个RegionServer上报的region数为0说明它没有分配到任何region这种状态比进程崩溃更隐蔽多半是rootdir指向了错误路径或者ZooKeeper里残留了历史集群数据。第一次启动时遇到这类问题不要慌停掉集群清空ZooKeeper里hbase相关的znode再重新启动基本都能恢复。4. 让2.0.2跑稳的关键参数内存预算、Region拆分与客户端超时4.1 RegionServer内存预算Memstore和BlockCache的比例不是越大越好HBase 2.0.2的RegionServer堆内存里两个最大的消费者是Memstore和BlockCache。前者承担写入路径的临时数据累积后者承担读路径的缓存。默认情况下两者各占堆内存的40%剩下20%用于RPC处理、region元数据和各种临时对象。这个默认值适合混合负载但在写入密集或读取密集的偏科场景下必须主动调整。property namehbase.regionserver.global.memstore.size/name value0.4/value /property property namehfile.block.cache.size/name value0.4/value /property这两个参数配合起来有讲究。如果业务以实时写入为主比如接收日志或埋点数据Memstore占总堆的比例可以往上浮到0.45BlockCache降到0.25因为这类场景读缓存命中率本来就不高。反过来如果业务以分析查询为主比如给报表系统做数据服务BlockCache可以提到0.5Memstore降到0.3让热点HFile块尽量长时间留在内存里。但要注意两者的和不要超过0.8否则RegionServer在内存紧张时很容易触发频繁的GC甚至直接OOM。我之前调过一组组合Memstore给到0.5、BlockCache给到0.4结果Master日志里全是java.lang.OutOfMemoryError又是调整又是重启才悟到0.9的累计占比已经超出了安全线。这组参数在hbase面试题里经常被拿来问能把0.8这个上限说清楚的人一般对HBase内存模型是真的理解而不是背数字。4.2 Region预拆分不预规划热点会先打崩一台RegionServerHBase表刚创建时只有一个Region所有写入都会先落到这一个Region上由它来承担这台机器的全部流量。如果你的集群有三台RegionServer而表只有一个Region另外两台就闲置了。预分区能解决这个问题在建表时按rowkey的分布把数据拆到多个Region里。/opt/hbase/bin/hbase shell EOF # 预创建10个Regionsplit点按顺序从低位到高位排列 create user_behavior, {NAME cf, VERSION 1, TTL 604800}, {SPLITS [1,3,5,7,9,b,d,f,h]} EOF这里的SPLITS数组决定Region的边界。我用的split点是十六进制字符集合的均分适合rowkey是散列值或随机数的场景。如果rowkey是业务主键比如用户ID的自增序列千万别这么拆而要根据ID区间来做Range分区否则写入会全部打到某个Region上形成热点。这个操作很难事后无损调整所以我的习惯是表设计阶段就做先把split点按预估值算出来后面写入了大量数据再想加Region成本至少翻三倍。4.3 客户端超时与批量参数别用默认值扛大查询HBase客户端有一套独立的超时体系它和RegionServer自身的参数不是一回事。线上常见的故障是查询数据量大客户端超过默认超时时间还没等到结果于是重试重试又给RegionServer增加压力形成恶性循环。以下参数是我通常会在客户端配置里显式设置的property namehbase.client.operation.timeout/name value30000/value /property property namehbase.client.scanner.timeout.period/name value60000/value /property property namehbase.rpc.timeout/name value30000/value /property操作超时设置为30秒适合在线业务读写的常规场景扫描超时给到60秒是因为scan大表时RegionServer扫描完一批数据返回需要时间给太短会出现大量前期成功后期失败的半截结果。这三个参数的调整本质是在业务容忍度和服务端压力之间做平衡设小了大查询频繁失败设大了慢查询长期占用RegionServer线程拖垮整个节点。4.4 GC参数RegionServer堆超过8G时的选择GC参数在HBase这里不是锦上添花是保命配置。JDK 8下我前面提到过4G到8G堆用CMS超过8G换G1。这里补上对应的配置写法export HBASE_OPTS-XX:UseConcMarkSweepGC -XX:UseParNewGC -XX:CMSInitiatingOccupancyFraction70CMSInitiatingOccupancyFraction设为70的意思是老年代占用到70%时触发CMS回收给HBase留出足够余量处理并发写入。如果你用的是G1那JDK 8下需要设置-XX:UseG1GC并且放弃对CMS参数的调优。我见过一些人把CMS和G1的启动参数混在一起写结果JVM直接忽略后一个参数GC行为完全不可控。选型逻辑很简单堆小用CMS调低触发阈值就行堆大用G1让Region化回收自己处理不要再手动干预。5. 部署避坑五个高频翻车点与排查思路5.1 现象RegionServer活不过两小时日志出现tmp目录丢失这个坑可以说是发行版HBase部署的经典杀手。现象是RegionServer正常运行几小时后批量退出重启后能恢复但过一段时间又挂。查日志会看到类似/tmp/hbase-hbase-regionserver目录不存在的记录。原因是系统自带的定时清理任务会清掉/tmp下的旧文件而HBase默认把tmp和PID目录放在那里清理任务一跑RegionServer的临时状态全部丢失。解决方式比较直接把hbase.tmp.dir、HBASE_PID_DIR、HBASE_LOG_DIR全部改到独立的数据目录下也就是第2章里已经准备好的/data/hbase下。这三个参数必须同时改只改其中一个另外两个还会继续往/tmp里写。改完后重启集群这个坑就永久绕开了。5.2 现象日志里频繁出现ClockOutOfSyncException写入时好时坏HBase对时间同步要求比大多数中间件都严格。原因是HBase的写路径依赖时间戳对操作排序如果各节点系统时钟偏差过大RegionServer之间会出现无法共识的写入冲突。表现是同一个Region的写入时而成功时而失败Master日志里报ClockOutOfSyncException底层ZooKeeper会话也可能因为时钟跳变而频繁断开。解决方法是让所有HBase节点用同一套时间同步服务比如chrony或NTP协议。这里的关键是不要只同步Master所有RegionServer节点都要覆盖偏差控制在秒级以内。检查命令是chronyc tracking或ntpq -p看到时钟来源稳定后就做集群联动重启让会话重新建立。5.3 现象Web UI打不开连接16020/16030超时端口问题是部署完最容易发现的故障也是最容易被误判的。HBase 2.0.2的默认端口清单如下建议直接保存成表格贴到运维文档里端口进程用途16010HMasterMaster Web UI16020HRegionServerRegionServer RPC端口16030HRegionServerRegionServer Web UI2181ZooKeeper客户端协调服务9090ThriftThrift接口服务9095Thrift2Thrift2接口服务排查时先用netstat -lnpt | grep 1602确认端口是否在监听。如果端口有监听但从外部连不上检查防火墙如果端口根本没监听看对应进程是否存活再查日志。我遇到过一个端口冲突案例另一套监控系统占用了16020导致RegionServer启动绑定失败进程反复拉起又退出etstat检查时那两个端口全是TIME_WAIT状态排查方向差点跑偏到网络层。5.4 现象启动报UnsupportedClassVersionErrorclass版本错误这个问题多数发生在机器上装了多个JDK的集群里。现象是HMaster或HRegionServer进程启动后立刻退出日志抛UnsupportedClassVersionError。原因不是HBase版本有问题而是启动脚本用JAVA_HOME环境变量去定位JDK但实际运行进程时PATH里更高优先级的却是另一个版本的JDK。解决方式是先在hbase-env.sh里强制写上export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk然后停掉集群用su - hbase -c java -version确认当前用户解析到的Java路径确保和配置一致。这一步做完后再启动版本错误就会消失。我自己的习惯是配置完成后先执行/opt/hbase/bin/hbase version看到输出版本号是2.0.2且Java版本正确之后再启动把这个坑拦截在初始化之前。5.5 现象Master起来了RegionServer一个都没起来这个现象看起来像配置问题其实多半是SSH分发问题。start-hbase.sh在启动Master之后会遍历regionservers文件里的主机名逐个SSH过去启动RegionServer。如果hbase用户在这些节点上没有免密钥登录权限你会看到Master进程健康地活着但所有RegionServer都停滞在“未启动”状态。解决方法是分两步验证先看regionservers文件里写的主机名都能被解析ping hostname能通再确认hbase用户到每个节点的免密登录ssh hbaseworker1能直接登进去。如果本地DNS解析不到这些名字在每台机器的/etc/hosts里把全量主机名补上这一条在做目录规划时就必须完成。另一个隐蔽点是把IP地址写进regionservers文件但没写主机名启动脚本在某些配置下会对IP做反向解析解析失败就跳过这台节点这类玄学问题排查起来很耗时间我的原则是全部用统一的主机名不混用IP。6. 装完怎么验证从hbase shell建表到pyspark写入hbase的完整链路HBase 2.0.2部署完成只是第一步真正能体现部署质量的是「从外部写入数据并且正确读出来」这整条链路。我验证集群的第一步永远是在shell里建一张测试表写入一条数据再扫描出来/opt/hbase/bin/hbase shell EOF create test_table, cf put test_table, row1, cf:value, hello_hbase scan test_table, {LIMIT 1} EOF这一组命令能同时验证ZooKeeper会话、RegionServer分配、HFile写入路径三个关键环节。scan能看到数据说明这张表对应的Region已经被某台RegionServer接管写入后刷盘的流程也跑通了。数据链路验证通过之后我再去做应用层的接入。如果是Spark生态里用Pyspark往HBase写数据最常见的做法是经Thrift2接口写入。先启动Thrift2服务然后写一段Pyspark作业在executor端建立连接并批量写入/opt/hbase/bin/hbase-daemon.sh start thrift2import happybase from pyspark.sql import SparkSession # 初始化SparkSession读取一份带业务生成的DataFrame spark SparkSession.builder.appName(demo_write_hbase).getOrCreate() df spark.createDataFrame([(row_1, 100), (row_2, 200)], [rk, value]) # 每个executor分区内建立自己的Thrift连接分区结束后关闭 def write_partition(rows): conn happybase.Connection(master1, port9095) table conn.table(test_table) with table.batch(batch_size500) as batch: for row in rows: # rowkey和列名都需要字节类型Thrift2协议对类型要求严格 batch.put(row[rk].encode(), {bcf:value: str(row[value]).encode()}) conn.close() # 按分区并行写入避免单连接压力集中在driver端 df.foreachPartition(write_partition)写Pyspark时最需要注意的就是连接类型和字节编码。这里使用的happybase连接对应的是Thrift2服务端端口是9095而不是Thrift的9090。我初次接入时只启动了旧版Thrift服务端口也连的是9090结果写入时协议字段完全不匹配报错内容还很像权限问题绕了不少弯路。在这个方案里还有个容易被忽视的细节table.batch的批量提交不能跨分区如果单条数据很大batch_size调低一些否则一个batch内存占用会让executor OOM。这个验证链路跑通后HBase部署就算真正交付了剩下的就是观察Master和RegionServer的GC日志确认长时间运行没有明显的内存波动。这套部署方法在我经手的发行版集群上反复用过踩坑最多的地方其实就集中在前两章的版本匹配和目录规划希望帮到你。本文还有配套的精品资源点击获取