Hbase的介绍和工作原理
本文主要对Hbase的作用、使用场景及工作原理做基本的讲解。首先我列出基本的学习网站
Hbase官方文档：https://hbase.apache.org/book.html（英文的），
不懂英文也没事，下面给出中文的：http://abloz.com/hbase/book.html，文档介绍的很详细，以及相关API都可以从官网上查看https://hbase.apache.org/，如下图：
上面主要是提供的一个学习一门技术的一个起始方向，因为官方文档才是最正确的，如果直接百度Hbase,虽然能看到很多文档，不过文档都是从官方文档理解的基础上编写的，不免有的文档作者会理解错误，导致学习者跟上错误的节奏，带入误区，进入一个坑，爬半天才可能都出不来，因此从开始学习的话还是建议先浏览一下官方的文档。其他的文档仅供参考。好了话不多说，我们进入正题...
1、Hbase介绍
（1） HBase是一个分布式，版本化，面向列的数据库，构建在 Apache Hadoop和 Apache ZooKeeper之上。
这里值得说一下的是，Hbase必须构建在hadoop和zookeeper运行环境的基础之上，基于HDFS存储，HBASE具有命令行界面我们可以用脚本去操作数据，也提供了很多语言的API接入。初始者可以下载一个单机版的玩耍一下
（2）Hbase简易学习版
选择一个 Apache 下载镜像，下载 HBase Releases. 点击 stable目录，然后下载后缀为 .tar.gz 的文件; 例如 hbase-0.95-SNAPSHOT.tar.gz. 解压到对应的目录编辑conf/hbase-site.xml 文件
此目录是Hbase写文件的目录，这个单机版的是包含了hadoop和zookeeper的，不过此单机版写文件是写在本地文件系统的
（3）shell脚本练习
./bin/hbase shell，会进入命令行模式
通过基本的命令操作：
创建表：
create ‘taiping’ ‘fuzulin’ （表示的是创建一个表名为‘taiping’,列簇名为'fuzulin'）
插入数据：
put 'taiping', 'row1', 'fuzulin:a', 'value1' （表示的是往表taiping中插入一个行key为’row1’的列簇‘fuzulin’下面列为’a’的值为’value1’）
HBase中的列是由 列族前缀和列的名字组成的，以冒号间隔
（4）查看表
Scan ‘taiping’ 查看’taiping’表的数据
Get ‘taiping’ ‘row1’ 获取‘taiping’表中的行key为’row1’的数据
（5）Hadoop与Hbase版本对应
此图来源于最新官方文档，如今最新Hbase版本是2.2.2，因此下载此版本我们一般根据对应规则去选择合适的Hadoop版本，其中感叹号表示的是没有测试过，× 代表不是所有的功能都适配，测试不充分，不过也是可以用的，为了避免踩不必要的坑还是选择最合适的。
（6）Hbase与关系型数据库的比较
HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
关系型数据库中的列是固定的。Hbase的数据非结构化一般用于大数据应用中，存储海量的非结构化的数据。
HBase在Hadoop的生态圈是扮演这一个重要的角色那就是 实时、分布式、高维数据 的数据存储。Hbase利用Hadoop MapReduce来处理Hbase中的海量数据，利用zookeeper作为其分布式协同服务。
（7）Hbase数据模型
先看一下下面这张图
这是一行数据，Rowkey是一个唯一标识，是按照字典顺序排序的。
A、 HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema) 定义的一部分预先给出。如create ‘test’, ‘course’；
B、 列名以列族作为前缀，每个“列族”都可以有多个列成员(column，每个列族中可以存放几千~上千万个列)；如 CF1:q1, CF2:qw,
C、 新的列族成员（列）可以随后按需、动态加入，Family下面可以有多个Qualifier，所以可以简单的理解为，HBase中的列是二级列，
也就是说Family是第一级列，Qualifier是第二级列。两个是父子关系。
D、 权限控制、存储以及调优都是在列族层面进行的；
E、 HBase把同一列族里面的数据存储在同一目录下，由几个文件保存。
F、目前为止HBase的列族能能够很好处理最多不超过3个列族。（建议不要超过3个，就像索引一样，多了少了都不好）
G、在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间 戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，
H、最新的数据版本排在最前面。
I、时间戳的类型是64位整型。时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫 秒的当前系统时间。
J、 时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突， 就必须自己生成具有唯一性的时间戳。
K、单元格由行和列的坐标交叉决定；单元格是有版本的（由时间戳来作为版本）；
L、 单元格的内容是未解析的字节数组（Byte[]），cell中的数据是没有类型的，全部是字节码形式存贮。由{row key，column(=<family> +<qualifier>)，version}唯一确定的单元。
2、工作原理
（1）系统架构
要想弄清楚具体的工作原理，文字描述对于新手没有一个整体的印象，先上一张图
看到这张图是不是很熟悉，这是Hbase的系统架构图，对hadoop生态圈是不是有了一个轮廓，知道Hbase的所处的地位了吧，现在就结合自己的理解对这张图加以描述，往下看
（2）进程
Master可能的进程（通过jps可以查看）：
HMaster//必须的，表明该hbase是Master
QuorumPeerMain//必须单独配置的Zookeeper集群，如果是内置的则为HQuorumPeer
HRegionServer//不是必须的，因为我们也将该Master设置为Region
NameNode//必须，任务调度器
SencondNameNode//必须，任务调度器
HRegion可能的进程：
QuorumPeerMain//必须单独配置的Zookeeper集群，如果是内置的则为HQuorumPeer
DataNode//必须，数据存储相关
HRegionServer//必须，表明是hbase存储节点
（3）Zookeeper在架构中的作用
A、ZooKeeper 为 HBase 提供 Failover 机制，选举 Master，避免单点 Master 单点故障问题
B、存储所有 Region 的寻址入口：-ROOT-表在哪台服务器上。-ROOT-这张表的位置信息
C、实时监控 RegionServer 的状态，将 RegionServer 的上线和下线信息实时通知给 Master
D、存储 HBase 的 Schema，包括有哪些 Table，每个 Table 有哪些 Column Family
总之zookeeper是作为一个协调服务，就像Kafka也需要使用zookeeper来提供相关服务
（4）HMaster在架构中的作用
为 RegionServer 分配 Region，负责 RegionServer 的负载均衡，发现失效的 RegionServer 并重新分配其上的 Region，HDFS 上的垃圾文件（HBase）回收，处理 Schema 更新请求（表的创建，删除，修改，列簇的增加等等）
（5）RegionServer 的作用
任何时刻，一个 Region 只能分配给一个 RegionServer。master 记录了当前有哪些可用的 RegionServer。以及当前哪些 Region 分配给了哪些 RegionServer，哪些 Region 还没有分配。当需要分配的新的 Region，并且有一个 RegionServer 上有可用空间时，Master 就给这个 RegionServer 发送一个装载请求，把 Region 分配给这个 RegionServer。RegionServer 得到请求后，就开始对此 Region 提供服务。
（6）StoreFile和Hfile
其实StoreFile是包含Hfile的，底层即是Hfile的实现，memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile。HFile是Hadoop的 二进制格式文件，是一种key-value的存储格式。
（7）数据流
如下图
RegionServer去获取RowLock，region更新共享锁；接着Hbase会先写写日志WAL（数据可靠性）再写缓存MemStore（阈值默认64M，每个列族对应一个Store下的MemStore）；然后释放锁后将日志落到HDFS；若MemStore达到阈值则将缓存数据落磁盘StoreFile，最后多个StoreFile发生合并；若StoreFile很大会触发split操作，将当前region分割成2个Region，并同步到Hmaster。
3、总结
Hbase适用于大数据场景，如果没有海量的数据支撑什么时候也可以用列，我们也可以基于日志数据做相应的分析和存储。不过确定就是能满足的查询场景有限，因为是基于rowkey的，对于rowkey的设计也显得尤为重要。
一般而言，单表数据量如果只有百万级或者更少，不是非常建议使用HBase而应该考虑关系型数据库是否能够满足需求；单表数据量超过千万或者十亿百亿的时候，并且伴有较高并发，可以考虑使用HBase。这主要是充分利用分布式存储系统的优势，如果数据量比较小，单个节点就能有效存储的话则其他节点的资源就会存在浪费。
如果业务场景是需要事务支持、复杂的关联查询等，不建议使用HBase。HBase有它适合的业务场景，我们不能苛求它能够帮我们解决所有问题。