Ⅰ hbase与客户端的通信过程解析
hbase通信主要涵盖了两个技术，一个是 google的protobuf rpc通信框架 ，一个是 java的NIO通信 ；
org.apache.hadoop.hbase.regionserver.HRegionServer这个类是regionserver的启动类；
org.apache.hadoop.hbase.master.HMaster这个类是Hmaster的启动类，继承了HRegionServer;
而HRegionServer定义了一个org.apache.hadoop.hbase.regionserver.RSRpcServices变量：
因此整个通信过程最核心的就是这两个类：RSRpcServices和RpcServer
hbase的protobuf的使用流程如下：
此过程主要是以下要讨论的 JAVA NIO做的工作；
Message callBlockingMethod(MethodDescriptor var1, RpcController var2, Message var3) throws ServiceException;
关于 java NIO的使用，主要集中于RpcServer类中：
主要使用了一个listener，但是实际情况这不是一个常见的listener模式，而是用来监听请求的监听器。
而它的实现如下：
主要定义了一个acceptChannel，一个selector和多个readers，每个reader对应一个selector；
它的主线程是监控selector中的accept请求，进行doAccept操作：
主要是对每个accept请求创建了一个connection对象，每个connection对应一个读写数据的channel，然后注册channel给某一个reader的selector；
对于每个reader线程来说，会对自己selector绑定的所有的SelectionKey进行查看，如果接收到数据，那么对绑定的connection进行处理，最后调用connection的process方法；
解析收到的请求，然后创建请求；通过scheler执行，
scheler是整个regionserver处理所有请求的核心，创建scheler需要用到参数如下，因此hbase.regionserver.handler.count参数决定了同时进行处理请求的handler个数，即regionserver的并发能力。
最后再rpcserver中调用call函数：
Message result = service.callBlockingMethod(md, controller, param);
上边写到数据的具体执行在CallRunner中，执行结束后调用Call.setResponse方法，
其中通过IPCUtil.(result)把messgae数据序列化成buffer，调用google提供的com.google.protobuf.CodedOutputStream实现的序列化方法。
以下是reponder提供的方法：
最后将数据写进属于自己的channel中。
Ⅱ hbase java端调用
这是缺少必要的类org/apache/hadoop/thirdparty/guava/common/primitives/UnsignedBytes
你可以到jarsearch上搜索含有这个类的jar包，然后把它放到classpath下就行了
Ⅲ 【日更挑战】CDH下无法启动hbase节点的问题解决
继昨天解决Kafka的位移问题后，今天又发现一个hbase的region server无法重新启动的问题。这个server本身是有问题的，目前问题还未查。但是再重启的时候，会报三组错。其中一个明确为PG的错误，大意如下
首先想到的就是检查本地磁盘，发现其实并没有满，这就很奇怪了。之后想到CDH会使用pg，那就把这部分先了解下。
查询了一下，发现确实是的，会有一个地方存储着pg相关登录信息。按网文说是 /etc/cloudera-scm-server ，但我发现几个机器都只有 /etc/cloudera-scm-agent 。所以必须找到server的机器，而其他集群里的都是agent的机器。
找到这个机器后，发现确实是空间满了。
那么依次用 -h --max-depth 1 命令查看目录，最终发现CDH的kafka manager的nohup文件是罪魁祸首。
用 > nohup.out 把文件清空，再用CDH重启节点就没有问题了！
Ⅳ HBase探索篇 _ 单节点多RegionServer部署与性能测试
[toc]
随着集群中总的Region数持续增长，每个节点平均管理的Region数已达550左右，某些大表的写入流量一上来，Region Server就会不堪重负，相继挂掉。
在HBase中，Region的一个列族对应一个MemStore，通常一个MemStore的默认大小为128MB（我们设置的为256MB），见参数 hbase.hregion.memstore.flush.size 。当可用内存足够时，每个MemStore可以分配128MB的空间。
当表的写入流量上升时，假设每个Region的写入压力相同，则理论上每个MemStore会平均分配可用的内存空间。
因此，节点中Region过多时，每个MemStore分到的内存空间就会变小。此时，写入很小的数据量，就会被强制flush到磁盘，进而导致频繁刷写，会对集群HBase与HDFS造成很大的压力。
同时，Region过多导致的频繁刷写，又会在磁盘上产生非常多的HFile小文件，当小文件过多的时候，HBase为了优化查询性能就会做Compaction操作，合并HFile，减少文件数量。当小文件一直很多的时候，就会出现 “压缩风暴”。Compaction非常消耗系统的IO资源，还会降低数据的写入速度，严重时会影响正常业务的进行。
关于每个Region Server节点中，Region数量大致合理的范围，HBase官网上也给出了定义：
可见，通常情况下，每个节点拥有20-200个Region是比较正常的。
其实，每个Region Server的最大Region数量由总的MemStore内存大小决定。每个Region的每个列族会对应一个MemStore，假设HBase表都有一个列族，那么每个Region只包含一个MemStore。一个MemStore大小通常在128~256MB，见参数： hbase.hregion.memstore.flush.size 。默认情况下，RegionServer会将自身堆内存的40%（我们线上60%）（见参数： hbase.regionserver.global.memstore.size ）提供给节点上的所有MemStore使用，如果所有MemStore的总大小达到该配置大小，新的更新将会被阻塞并且会强制刷写磁盘。因此，每个节点最理想的Region数量应该由以下公式计算（假设HBase表都有统一的列族配置）：
((RS memory) * (total memstore fraction)) / ((memstore size)*(column families))
其中：
以我们线上集群的配置举例，我们每个RegionServer的堆内存是32GB，那么节点上最理想的Region数量应该是： 32768*0.6/256 ≈ 76 （32768*0.6/128 ≈ 153）
上述最理想的情况是假设每个Region上的填充率都一样，包括数据写入的频次、写入数据的大小，但实际上每个Region的负载各不相同，有的Region可能特别活跃、负载特别高，有的Region则比较空闲。所以，通常我们认为2 3倍的理想Region数量也是比较合理的，针对上面举例来说，大概200 300个Region左右算是合理的。
针对上文所述的Region数过多的隐患，以下内容主要从两方面考虑来优化。
提高内存的目的是为了增加每个Region拥有的MemStore的空间，避免其写入压力上升时，MemStore频繁刷写，形成小的HFile过多，引起压缩风暴，占用大量IO。
但其实RS的堆内存并不是越大越好，我们开始使用HBase的时候，对CMS和G1相关的参数，进行了大量压测，测试指标数据表明，内存分配的越大，吞吐量和p99读写平均延时会有一定程度的变差（也有可能是我们的JVM相关参数，当时调配的不合理）。
在我们为集群集成jdk15，设置为ZGC之后，多次压测并分析JVM日志之后，得出结论，在牺牲一定吞吐量的基础上，集群的GC表现能力确实提升的较为明显，尤其是GC的平均停顿时间，99.9%能维持在10ms以下。
而且ZGC号称管理上T的大内存，停顿时间控制在10ms之内（JDK16把GC停顿时间控制在1ms内，期待JDK17 LTS），STW时间不会因为堆的变大而变长。
因此理论上，增加RS堆内存之后，GC一样不会成为瓶颈。
之所以考虑在单节点上部署多个Region Server的进程，是因为我们单个物理机的资源配置很高，内存充足（三百多G，RS堆内存只分了32G）、而HBase又是弱计算类型的服务，平时CPU的利用率低的可怜，网络方面亦未见瓶颈，唯一掉链子的也就属磁盘了，未上SSD，IO延迟较为严重。
当然，也曾考虑过虚拟机的方案，但之前YCSB压测的数据都不太理想；K8s的调研又是起步都不算，没有技术积累。因此，简单、直接、易操作的方案就是多RS部署了。
以下内容先叙述CDH中多RS进程部署的一些关键流程，后续将在多RS、单RS、单RS大堆环境中，对集群进行基准性能测试，并对比试验数据，分析上述两种优化方案的优劣。
我们使用的HBase版本是 2.1.0-cdh6.3.2 ，非商业版，未上Kerberos，CDH中HBase相关的jar包已替换为用JDK15编译的jar。
多Region Server的部署比较简单，最关键的是修改 hbase-site.xml 中region server的相关端口，避免端口冲突即可。可操作流程如下。
修改所需配置文件
hbase-site.xml 配置文件一定不要直接从 /etc/hbase/conf 中获取，这里的配置文件是给客户端用的。CDH管理的HBase，配置文件都是运行时加载的，所以，找到HBase最新启动时创建的进程相关的目录，即可获取到服务端最新的配置文件，如：/var/run/cloudera-scm-agent/process/5347-hbase-REGIONSERVER。需要准备的目录结构如下：
不需要HBase完整安装包中的内容（在自编译的完整安装包中运行RS进程时，依赖冲突或其他莫名其妙的报错会折磨的你抓狂），只需要bin、conf目录即可，pids文件夹是自定义的，RS进程对应pid文件的输出目录，start_rs.sh、stop_rs.sh是自定义的RS进程的启动和关闭脚本。
重点修改下图标注的配置文件，
还有日志文件名的一些输出细节，可以按需在 bin/hbase-daemon.sh 中修改。
运行或关闭RS进程
中间有异常，请查看相关日志输出。
集群Region数疯涨，当写入存在压力时，会导致RS节点异常退出。为了解决目前的这种窘境，本次优化主要从单节点多Region Server部署和提高单个Region Server节点的堆内存两方面着手。
那这两种优化方案对HBase的读写性能指标，又会产生什么样的影响呢？我们以YCSB基准测试的结果指标数据做为参考，大致评价下这两种应急方案的优劣。
用于此次测试的HBase集群的配置
此次测试使用的数据集大小
测试方法
压测时选择的读写负载尽量模拟线上的读写场景，分别为：读写3/7、读写7/3、读写5/5；
压测时唯一的变量条件是：多RS部署（32G堆，在每个节点上启动3个RS进程，相当于集群中一共有15个RS节点）、单RS部署（32G小堆）和单RS部署（100G大堆），并尽可能保证其他实验条件不变，每个YCSB的工作负载各自运行20分钟左右，并且重复完整地运行5次，两次运行之间没有重新启动，以测量YCSB的吞吐量等指标，收集的测试结果数据是5次运行中最后3次运行的平均值，为了避免第一轮和第二轮的偶然性，忽略了前两次的测试。
YCSB压测的命令是：
收集实验数据后，大致得出不同读写负载场景下、各个实验条件下的指标数据，如下图。
上述的测试数据比较粗糙，但大致也能得出些结论，提供一定程度上的参考。
多RS进程部署的模式，起到了一定程度上的进程间资源隔离的作用，分担了原先单台RS管理Region的压力，最大化利用了物理机的资源，但多出来的一些Region Server，需要单独的管理脚本和监控系统来维护，增加了维护成本。多个RS依赖同一台物理机，物理节点宕机便会影响多个RS进程，同时，某一个Region Server出现热点，压力过大，资源消耗过度，也许会引起同机其他进程的不良，在一定程度上，牺牲了稳定性和可靠性。
增加单个RS进程的堆内存，MemStore在一定程度上会被分配更充裕的内存空间，减小了flush的频次，势必会削弱写入的压力，但也可能会增加GC的负担，我们或许需要调整出合适的GC参数，甚至需要调优HBase本身的一些核心参数，才能兼顾稳定和性能。然而，这就又是一件漫长而繁琐的事情了，在此不过分探讨。
面对性能瓶颈的出现，我们不能盲目地扩充机器，在应急方案采取之后，我们需要做一些额外的、大量的优化工作，这或许才是上上之策。
Ⅳ 求助帖，hbase新手，windows中的java怎么连接linux中的hbase
一、新建本地java工程
file->new->java project
二、添加jar包和配置文件
1、添加JAR包
右击Propertie在弹出的快捷菜单中选择Java Build Path对话框，在该对话框中单击Libraries选项卡，在该选项卡下单击
Add External JARs按钮，定位到$HBASE/lib目录下，并选取如下JAR包。
hadoop-core-1.0.0.jar
commons-loggings-version.jar
commons-cli-version.jar
commons-lang-version.jar
commons-configuration-version.jar
hbase-0.94.1.jar
zookeeper-3.4.3.jar
slf4j-api-1.5.8.jar
slf4j-log4j12-1.5.8.jar
log4j-1.2.16.jar
protobuf-java-2.4.1.jar
2、添加hbase-site.xml配置文件
在工程根目录下创建conf文件夹，将$HBASE_HOME/conf/目录中的hbase-site.xml文件复制到该文件夹中。通过右键
选择Propertie->Java Build Path->Libraries->Add Class Folder。
3、windows下开发HBase应用程序，HBase部署在linux环境中，在运行调试时可能会出现无法找到主机，类似异常信息如下：java.net.UnknownHostException: unknown host: master
解决办法如下：在C:\WINDOWS\system32\drivers\etc\hosts文件中添加如下信息
192.168.2.34 master
Ⅵ 如何解决CDH5中找不到JAVA
找不到JAVA_HOME 说明JDK环境变量没有配置正确,建议查看一下是否有安装JDK,再查看一下path里有没有增加JAVA_HOME的环境变量. eoch path 即可查看。
在安装presudo版本的CDH5中，第一次需要格式化HDFS，执行：
$ sudo -u hdfs hdfs namenode -format
但是会出现：
[root@AY1312280620257702e0Z conf]# sudo -u hdfs hdfs namenode -format
Error: JAVA_HOME is not set and could not be found.
[root@AY1312280620257702e0Z conf]# echo $JAVA_HOME
/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z conf]# echo $JAVA_HOME
/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z conf]# sudo -u hdfs hdfs namenode -format
Error: JAVA_HOME is not set and could not be found.
[root@AY1312280620257702e0Z conf]# java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
[root@AY1312280620257702e0Z conf]#
[root@AY1312280620257702e0Z ~]# for x in `cd /etc/init.d ; ls hadoop-hdfs-*` ; do sudo service $x start ; done
Starting Hadoop datanode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
Starting Hadoop namenode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
Starting Hadoop secondarynamenode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
需要进行如下配置，即可解决如上问题：
在/etc/sudores 的最后一行增加：
On systems on which
sudo
clears or restricts environment variables, you also need to add the following line to the
/etc/sudoers
file:
Defaults env_keep+=JAVA_HOME
同时需要配置：
If your JDK is located at one of the standard locations, it's detected by the script (using this component called bigtop-utils). However, if it's not, you'd have to go to /etc/default/bigtop-utils and set and export JAVA_HOME ( to /usr/qiuxin/software/jdk1.7.0_25) there. You only need to do it once and all CDH components would use that variable to figure out where JDK is.
[root@AY1312280620257702e0Z ~]# vi /etc/default/bigtop-utils
增加：export JAVA_HOME=/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z ~]# source /etc/default/bigtop-utils
Ⅶ hbase单机模式下，使用java API远程连接hbase的问题。
首先你应该看Master进程是否已经成功启动，检查下master的60010监控界面。这日志报的是连接拒绝 ，或者关闭防火墙
极有可能是你PC机网络无法连接到虚拟机里边，你可以从本机telnet下虚拟机上master的端口，看下能连上不
Ⅷ 如何修改cloudera默认的java路径
java默认路径？？
是java的系统变量 配置么？
右击我的电脑—>属性—>高级—>环境变量—>系统变量
在系统变量 选项里 -〉 新建
举例：
java_home 的路径 如C:\j2sdk1.4.2_01;
在path中添加 java的bin路径 如C:\j2sdk1.4.2_01\bin;
新建classpath 中添加.;lib\dt.jar;lib\tools.jar;
如 .;C:\j2sdk1.4.2_01\lib\dt.jar;C:\j2sdk1.4.2_01\lib\tools.jar;
一定记得有一个".;"要不你的java在本地编译的时候不好用.
Ⅸ Hbase扩容原理
Hbase是Hadoop的一个存储组件可以提供低延迟的读写操作，它一般构建在HDFS之上，可以处理海量的数据。Hbase有个很好的特性是可以自动分片，也就是意味着当表的数据量变得很大的时候，系统可以自动的分配这些数据。
Hbase的基本存储单位是Region，Region是表数据的子集，多个Region的数据集合可以组成一张完成的表数据。Region本质上存储的一些排好序的，连续的行数据。最初的时候一张表只有一个Region，当Region变得非常大的时候，Region就会从中间分裂成两个基本等大的Region。
在Hbase中，slave也被称作RegionServer，每个RegionServer负责管理一些Region，同时一个Region只能属于一个RegionServer。
一个RegionServer可以服务一个或多个Region，每个Region在Region Server启动的时候被分配。Master可以决定将一些Region从一个RegionServer中移动到令一个RegionServer里面，以便更好的负载均衡。当某个RegionServer故障的时候，Master也可以将它的Region分配给其他的RegionServer。
Region与RegionServer之间的映射关系存储在Zookeeper中的META表中，通过读取META表，你就可以知道那个Region可以负责处理你的rowkey操作，其实这也代表着在HBase读写操作的时候是不用经过Master节点的，你可以之间联系RegionServer。
如图，在客户端进行scan的时候，它可以之间联系多个RegionServer处理当前的操作。
Meta表是用来跟踪Region的，它包含服务器的名称，Region的名称，表名，还有Region的startkey。通过startkey的范围，客户端就可以定位到当前的key要去哪一个Region了。
客户端在请求过META表之后，一般会将表缓存起来，防止每次操作都去获取。在Region进行分裂的时候，客户端去RegionServer操作Region的时候回返回异常，然后客户端会重新获取最新的META表信息。
Hbase的Java客户端API有两个主要的接口：
通过上面介绍，可以知道HBase虽然是Master/Slave架构的，但是并不是每次操作都经过Master的，读写数据的时候HBase只需要直接联系RegionServer即可。这也是HBase可以“无限扩容”的原因。在吞吐量不够的时候，通过增加RegionServer节点，可以增加吞吐量。
Ⅹ 需要安装什么使用hbase shell客户端工具
进入hbase shell console
$HBASE_HOME/bin/hbase shell
如果有kerberos认证，需要事先使用相应的keytab进行一下认证（使用kinit命令），认证成功之后再使用hbase shell进入可以使用whoami命令可查看当前用户
hbase(main)> whoami
表的管理
1）查看有哪些表
hbase(main)> list
2）创建表
# 语法：create <table>, {NAME => <family>, VERSIONS => <VERSIONS>}
# 例如：创建表t1，有两个family name：f1，f2，且版本数均为2
hbase(main)> create 't1',{NAME => 'f1', VERSIONS => 2},{NAME => 'f2', VERSIONS => 2}
3）删除表
分两步：首先disable，然后drop
例如：删除表t1
hbase(main)> disable 't1'
hbase(main)> drop 't1'
4）查看表的结构
# 语法：describe <table>
# 例如：查看表t1的结构
hbase(main)> describe 't1'
5）修改表结构
修改表结构必须先disable
# 语法：alter 't1', {NAME => 'f1'}, {NAME => 'f2', METHOD => 'delete'}
# 例如：修改表test1的cf的TTL为180天
hbase(main)> disable 'test1'
hbase(main)> alter 'test1',{NAME=>'body',TTL=>'15552000'},{NAME=>'meta', TTL=>'15552000'}
hbase(main)> enable 'test1'
权限管理
1）分配权限
# 语法 : grant <user> <permissions> <table> <column family> <column qualifier> 参数后面用逗号分隔
# 权限用五个字母表示： "RWXCA".
# READ('R'), WRITE('W'), EXEC('X'), CREATE('C'), ADMIN('A')
# 例如，给用户‘test'分配对表t1有读写的权限，
hbase(main)> grant 'test','RW','t1'
2）查看权限
# 语法：user_permission <table>
# 例如，查看表t1的权限列表
hbase(main)> user_permission 't1'
3）收回权限
# 与分配权限类似，语法：revoke <user> <table> <column family> <column qualifier>
# 例如，收回test用户在表t1上的权限
hbase(main)> revoke 'test','t1'
表数据的增删改查
1）添加数据
# 语法：put <table>,<rowkey>,<family:column>,<value>,<timestamp>
# 例如：给表t1的添加一行记录：rowkey是rowkey001，family name：f1，column name：col1，value：value01，timestamp：系统默认
hbase(main)> put 't1','rowkey001','f1:col1','value01'
用法比较单一。
2）查询数据
a）查询某行记录
# 语法：get <table>,<rowkey>,[<family:column>,....]
# 例如：查询表t1，rowkey001中的f1下的col1的值
hbase(main)> get 't1','rowkey001', 'f1:col1'
# 或者：
hbase(main)> get 't1','rowkey001', {COLUMN=>'f1:col1'}
# 查询表t1，rowke002中的f1下的所有列值
hbase(main)> get 't1','rowkey001'
b）扫描表
# 语法：scan <table>, {COLUMNS => [ <family:column>,.... ], LIMIT => num}
# 另外，还可以添加STARTROW、TIMERANGE和FITLER等高级功能
# 例如：扫描表t1的前5条数据
hbase(main)> scan 't1',{LIMIT=>5}
c）查询表中的数据行数
# 语法：count <table>, {INTERVAL => intervalNum, CACHE => cacheNum}
# INTERVAL设置多少行显示一次及对应的rowkey，默认1000；CACHE每次去取的缓存区大小，默认是10，调整该参数可提高查询速度
# 例如，查询表t1中的行数，每100条显示一次，缓存区为500
hbase(main)> count 't1', {INTERVAL => 100, CACHE => 500}
3）删除数据
a )删除行中的某个列值
# 语法：delete <table>, <rowkey>, <family:column> , <timestamp>,必须指定列名
# 例如：删除表t1，rowkey001中的f1:col1的数据
hbase(main)> delete 't1','rowkey001','f1:col1'
注：将删除改行f1:col1列所有版本的数据
b )删除行
# 语法：deleteall <table>, <rowkey>, <family:column> , <timestamp>，可以不指定列名，删除整行数据
# 例如：删除表t1，rowk001的数据
hbase(main)> deleteall 't1','rowkey001'
c）删除表中的所有数据
# 语法： truncate <table>
# 其具体过程是：disable table -> drop table -> create table
# 例如：删除表t1的所有数据
hbase(main)> truncate 't1'
Region管理
1）移动region
# 语法：move 'encodeRegionName', 'ServerName'
# encodeRegionName指的regioName后面的编码，ServerName指的是master-status的Region Servers列表
# 示例
hbase(main)>move '', 'db-41.xxx.xxx.org,60020,1390274516739'
2）开启/关闭region
# 语法：balance_switch true|false
hbase(main)> balance_switch
3）手动split
# 语法：split 'regionName', 'splitKey'
4）手动触发major compaction
#语法：
#Compact all regions in a table:
#hbase> major_compact 't1'
#Compact an entire region:
#hbase> major_compact 'r1'
#Compact a single column family within a region:
#hbase> major_compact 'r1', 'c1'
#Compact a single column family within a table:
#hbase> major_compact 't1', 'c1'
配置管理及节点重启
1）修改hdfs配置
hdfs配置位置：/etc/hadoop/conf
# 同步hdfs配置
cat /home/hadoop/slaves|xargs -i -t scp /etc/hadoop/conf/hdfs-site.xml hadoop@{}:/etc/hadoop/conf/hdfs-site.xml
#关闭：
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf stop datanode"
#启动：
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf start datanode"
2）修改hbase配置
hbase配置位置：
# 同步hbase配置
cat /home/hadoop/hbase/conf/regionservers|xargs -i -t scp /home/hadoop/hbase/conf/hbase-site.xml hadoop@{}:/home/hadoop/hbase/conf/hbase-site.xml
# graceful重启
cd ~/hbase
bin/graceful_stop.sh --restart --reload --debug inspurXXX.xxx.xxx.org