分布式HBase安装配置和基础学习

详细的分布式配置步骤在本文第四部分，需要先完成本文第三部分单机版的配置。

hbase是一个在HDFS上开发的面向列族的分布式数据库，可以实时地随机访问超大规模数据集，主要用来存储非结构化和半结构化的松散数据。

特点：

1.面向列：Hbase是面向列的存储和权限控制，并支持独立索引。列式存储，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段时，能大大减少读取的数据量。

2.多版本：Hbase每一个列的存储有多个Version。

3.稀疏性：为空的列不占用存储空间，表可以设计得非常稀疏。

4.扩展性：底层依赖HDFS。

5.高可靠性：WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失，Replication机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。而且Hbase底层使用HDFS，HDFS本身也有备份。

6.高性能：底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得Hbase具有非常高的写入性能。region切分，主键索引和缓存机制使得Hbase在海量数据下具备一定的随机读取性能，该性能真对Rowkey的查询能到达到毫秒级别。

一、HBase数据模型

一个hbase表的一行如图所示：

Row Key	time stamp	column family1		column family2
		col1	col2	col3	col4
key1	t2		cf1:c2=v2	cf2:c3=v3
	t1	cf1:c1=v1			cf2:c4=v4

1、hbase表由若干行组成，行之间是有序的，按照唯一行键RowKey排序。

2、每一行由多个列族ColumnFamily组成，列族需要在创建表的时候定义好，如在语句create 'test','course1','course2'中，test为表名，course为列族名。HBase的权限控制、存储以及调优都是在列族层面进行的，同一列族的数据存储在同一目录下，建议列族数目不多于3个。

3、列族由多个列column组成，列不用预先定义，可以随时修改。

4、每一个单元格cell都有唯一的时间戳timestamp标记版本。因为Hbase不适合修改数据，所以用时间戳记录版本，修改数据就是添加新数据。单元格内的数据都是以字节数组表示的键值对。

二、HBase整体架构

1、hbase架构中有若干个从节点RegionServer，负责维护主节点Master分配给它的region，响应客户端Client的I/O请求，向HDFS文件系统中读写数据，切分在运行过程中变得过大的region。并发性能与regionserver的个数有关。

2、一个RegionServer中有若干个Region，若干连续的行构成一个Region，当一个region所有的storefile的大小超过阈值后，这个region会分割为两个，并由master分配到相应的regionserver服务器，实现负载均衡，所以一张完整的表可能被保存在多个regionserver上，Region是hbase中分布式存储和负载均衡的最小单元，但并不是存储的最小单元。

3、一个Region中有若干个Store，每个Store是一个列族，Store分两种，新插入的数据在内存数据memstore中，满了之后写到磁盘storefile中，数据以HFile的格式保存在hdfs的datanode中，storefile中有Hfile的元数据，方便索引。客户端在检索数据时，先在memstore找，找不到再找storefile。不断的写storefile生成hfile会产生很多小文件不利于性能，所以会合并小storefile形成更大的，过大的话再切分。

4、HLog是一种预写日志WAL log，即Write ahead log，对hbase操作之前会将指令先写入HLog，如memstore中的数据还没写入storefile时停电了，就可以进行数据恢复。每个regionserver只有一个HLog，缺点是如果一台regionserver下线，为了恢复其上的region，需要将HLog进行拆分，然后分发到其它regionserver上进行恢复。

5、Master管理用户的增删改查操作，管理RegionServer的负载均衡，调整Region分布，在RegionServer停机后，负责失效RegionServer上的Region迁移。由于master只维护表和region的元数据，而不参与表数据I/O的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region上下线，无法进行region的合并，唯一例外的是region的 split可以正常进行，因为只有regionserver参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个Hbase集群没有影响。从上线过程可以看到，master保存的 信息全是可以冗余信息(都可以从系统其它地方收集到或者计算出来)，因此，一般Hbase集群中总是有一个master在提供服务，还有一个以上的"master"在等待时机抢占它的位置。

6、客户端client包含有各种接口，client维护着一些cache来加快对Hbase的访问，比如regione的位置信息。读写操作时，客户端直接与RegionServer通信，建表等管理操作则请求ZooKeeper与Master通信。

7、ZooKeeper是分布式应用程序协调服务，保证集群中只有一个master，实时监控RegionServer的状态并通知给Master，保存-ROOT-表的地址。

8、-ROOT-表和.META.表是两个内置表。.META.表中每一行记录了一个用户表Region的信息，当用户表特别大时，region也会非常多，.META.表也变得非常大，这时.META.自己也需要划分成多个Region，托管到多个RegionServer上，此时需要用-ROOT-表去定位.META.，即-ROOT-表保存.META.表的region信息。-ROOT-表永远只有一个Region，也就只会存放在一台RegionServer上，定位任意region需要3次跳转。

三、单机版HBase安装和配置

所用HBase版本为hbase-0.98.23-hadoop2-bin.tar，具体的Hadoop版本以及Hadoop的搭建配置可以看我之前的文章：完全分布式Hadoop集群的安装搭建和配置（4节点），下文涉及的节点设置，目录等等一些东西都是根据这个来的。

我把单机版HBase安装在slave3节点，解压到/usr/local，重命名为hbase，进入hbase/conf目录，修改hbase-env.sh，把java环境变量那一行改为自己机器的路径。然后配置hbase-site.xml的文件：加入以下部分（这是数据存储在哪的配置，file说明是存在本地，存在hdfs的话就改成hdfs）：

	hbase.rootdir
	file:///opt/hbase

然后就搞定了，可以启动了，在hbase/bin目录下执行：

./start-hbase.sh（停止是./stop-hbase.sh）

单机版（一个节点）的hbase包含了zookeeper和regionserver，所以jps之后只有一个Hmaster，用浏览器看：节点名:60010

一些操作：

./hbase shell 进入hbase命令行
>help 列出全部指令（很有用）
>create ‘t_student’,’cf1’ 注意指令结尾没有分号！创建表，一个列族cf1。
>list  列出所有表名
>desc ‘t_student’ 查看表结构
>put ‘t_student’,’007’,’cf1:name’,’james’ 向表中添加数据，007是row key，name是cf1列族下的一个列，值是james
>scan ‘t_student’ 查看表内容

四、分布式HBase安装和配置

分布式HBase的安装还是基于之前的4节点的Hadoop，上边第四部分有链接可以查看，请先完成第四部分单机版的安装配置。

我把Hadoop的Slave2和3节点设为Hmaster（这是可变的，后边有讲解），所有节点都设为Hregionserver。

1、先进之前配好的的单机版slave3中，把存储位置从本地改为hdfs（参看上边，这个集群名字是配置hdfs时起的，可以看自己hadoop的core-site配置文件中hdfs://后边的是啥）：

	hbase.rootdir
	hdfs://集群名字/hbase


	hbase.cluster.distributed 
	true

2、再修改同目录的regionserver文件，把所有节点名都加进去，因为我们把所有节点都设为regionserver了（就像hadoop里的slaves文件一样）。

3、然后就是zooleeper了，默认情况下，一个hbase管理一个zk集群，这个集群会随hbase的启动而启动，但我们要自己管理，先修改conf/hbase-env.sh，把里面的HBASE_MANAGES_ZK设为false。
4、接着修改hbase-site.xml（第一个是哪些节点有zk，一般是奇数个，第二个是zk的工作目录，就是snapshot的存储目录）：

 
  hbase.zookeeper.quorum
  Master,Slave1,Slave2
 
 
  hbase.zookeeper.property.dataDir
  /opt/zookeeper
 

5、然后把hadoop的一个配置文件拷贝到hbase的conf目录下：

hadoop@slave3:/usr/local/hbase/conf$ cp -a /usr/local/hadoop/etc/hadoop/hdfs-site.xml .

6、注意以上操作都是在slave3节点进行的，现在到master节点，执行相同的解压hbase的操作，然后进入到conf目录下，把slave3中的配好的拷贝过来：

hadoop@Master:/usr/local/hbase/conf$ scp hadoop@Slave3:/usr/local/hbase/conf/* .

7、然后把master节点的整个hbase目录拷贝给slave1和2：

hadoop@Master:/usr/local$ scp -r ./hbase hadoop@Slave1:/usr/local/
hadoop@Master:/usr/local$ scp -r ./hbase hadoop@Slave2:/usr/local/

8、然后可以启动hbase啦，在master节点下hbase的bin目录下：

./start-hbase.sh

Jps一下，注意到启动了一个HMaster，即本节点，我们并没有说明哪台机器是HMaster，实际上任何有HBase的节点都可以启动HMaster，先启动的是唯一工作的，当我们要启动另外一个HMaster时，到相应节点的hbase/bin目录下：

hadoop@slave3:/usr/local/hbase/bin$ ./hbase-daemon.sh start master

jps之后会发现多了HMaster和regionserver（浏览器查看方式：节点名：60010），关闭HMaster的指令：kill -9 端口号（端口号是jps看到的）。

如果在创建表时，报错：

ERROR: java.io.IOException: Table NamespaceManager not ready yet, try again later

解决办法（应该是跟前边单机模式创建的hbase文件有关，删掉）：
在master节点执行：

hadoop fs -ls / 这是查看hdfs 的文件，看有没有hbase文件
hadoop fs -rm -R /hbase 这是删除其中的hbase文件

然后重启hbase即可，如果还报错：

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/local/hbase/lib/slf4j-log4j12-1.6.4.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

解决办法：jar包冲突，删掉其中一个jar包就行了。
然后可以按照单机模式中介绍的操作试一下，建个表，put一条数据，然后flush一下（手动溢写到hdfs）：

> flush 't_person'

可在浏览器（节点名:50070）中查看溢写的文件：

还能从文件中把所保存的信息打印出来（路径是复制上图中的路径）：

hadoop@Master:/usr/local/hbase/bin$ ./hbase hfile -p -f /hbase/data/default/t_person/3cb9be8f680f09cfbde1348a2b282c34/cf1/fec73f28248048ad9b0de4837306586e

得到结果（007是rowkey，然后是列族:列名、时间戳、put是插入方式）：

K: 007/cf1:name/1479459046232/Put/vlen=5/mvcc=0 V: james