HBase
1. HBase简介
首先来说HBase是针对谷歌三宝之一的BigTable的开源实现，是一个高可靠、高性能、面向列、可伸缩的分布式数据库，主要用来存储非结构化和半结构化数据。其目标是处理非常庞大的表，通过水平的扩展方式，利用廉价的计算机集群来处理数据。
其利用Hadoop中的MapReduce来处理海量的数据；利用Zookeeper作为协同服务，实现稳定的失败和恢复；利用HDFS作为底层的数据存储方式。
2. 与传统数据库的比较
（1）数据类型。传统的关系型数据库有丰富的数据类型，但HBase分布式数据库采用了简单的数据类型，他把数据均存储为简单的未经解释的字符串，用户可以把结构化数据和非结构化数据都序列化成字符串保存到HBase当中，在用户需要的时候再自己通过编程将字符串解析为不同类型的数据。
（2）数据操作。关系数据库有丰富的增、删、改、查、更新、查询等，其中会涉及到很多的复杂的表的连接，通常是借助表之间的主外键来实现的。但HBase的操作不存在表与表之间的关系，只有简单的插入、删除、查询、清空等，通常只采用单表的主键结构。
（3）存储模式。关系数据库是基于行的存储模式，但HBse是基于列的存储模式，每个列族都有由几个文件保存，不同列族的文件是分离的。
（4）数据索引。关系数据库通常可以针对不同列构建复杂的多个索引，但HBase只有一个索引——行键。
（5）数据维护。在关系型数据库中，数据更新后原始的数据就会被覆盖更新，但在HBase中数据更新后原始数据依然存在。
（6）可伸缩性。关系型数据库很难实现横向的扩展，纵向扩展的空间也比较有限，但HBase具有灵活的水平扩展能力。
3. HBase的相关概念
- 表。HBase用表来组织数据，表由行和列组成，列被划分为若干列族。
- 行。表有若干行组成，每行由键来标识，表中的行有三种访问方式：（1）单个行键访问（2）行键区间来访问（3）全表扫描。行键保存为字节数组时，按照行键的字典序来存储。
- 列族。表被分组为许多“列族”的集合，是基本的访问控制单元。其需要在创建表时就定义好，数量设置的不能太多（只限于十几个）。
- 列限定符。列族中的数据通过其来定位（不需要事先定义）。
- 单元格。实际存储数据的地方，其中的数据没有数据类型，总被视为字节数组byte[]，单元格中的数据可以保存一个数据的多个版本，每个版本对应不同的时间戳，通过行、列族、列限定符确定一个单元格。
- 时间戳。每个单元格都保存着同一份数据的多个版本，这些版本通过时间戳进行索引。
4. 数据坐标
HBase通过坐标来定位表中的数据，每个值都是通过坐标来访问的，一个四维的坐标：[行键，列族，列限定符，时间戳]。
5. 列式数据库的DSM模型
HBase就是一个列式数据库，其使用的是DSM模型，这个模型的原理是：1个具有n个属性的关系会被分解为n个子关系，每个子关系单独存储，每个子关系只有当其相应属性被请求访问的时候才会被访问。同一属性值（或同一列值）会被存储在一起。
6. HBase的实现原理
6.1 HBase的功能组件
- 库函数。链接到每个客户端。
- 一个Master主服务器。负责存储和维护Hbase表的分区信息（分区信息包括一个表被分成了哪些Region，每个Region被存放在哪台服务器上），维护Region服务器列表。其实时监控集群中的Region服务器，使得不同的Region服务器的负载均衡。
- 多个Region服务器。存储和维护分配给自己的Region，处理来自用户端的请求。
- 补充：客户端通过Master得知Region的存储位置信息后，直接从Region服务器上读取数据。
- 补充：客户端并不依赖于Master而是借助于Zookeeper来获得Region的位置信息。
6.2 表和Region（附有图片解释）
HBase中有许多的表，表中的行是根据行键的值的字典序进行维护的。
Region：根据行键的值对表中的行进行分区，每个行区间构成一个分区，被称为“Region”，包含了位于某个区域间的所有数据。
初始时是一个Region，但当一个Region（行数）增大到一定的阙值时，就会自动等分为两个新的Region。（阙值100-300MB）
不同的Region会被分配到不同的服务器上，但同一个Region不会被分配到不同的服务器上。
图片解释：
6.3 Region定位机制（三级寻址）
6.3.1 .META. 表
每个Region都有自己的RegionID来表示它的唯一性，其表示为“表名+开始主键+RegionID“。
有了Region标识符就可很轻松的定位特定的Region，为了定位每一个Region，就构建了一张映射表，表的每个条目（每行）包含两项内容：一个是Region标识符，一个是Region服务器标识符，这个条目就表明了Region和Region服务器之间的对应关系，从而就可以定位Region被保存在哪个Region的服务器当中。这张表就叫 .META. 表。
6.3.2 -ROOT-表
当一个HBase表中的Region数量非常庞大的时候，.META.表中的条目就会变得非常多，一个服务器就会保存不下，也需要分区存储到不同的服务器上。因此 .META.表也会被分裂成多个Region，为了定位这些Region，就需要再构建一张新的映射表，记录所有元数据的位置，这个数据表就是”根数据表”，又称-ROOT-表。
注意：该表是不可分割的，永远只存在一个Region服务器上，只有唯一一个Region，它的名字是在程序中被写死的，Master主服务器永远知道它的位置。
6.3.3 三层结构图展
6.3.4 寻址过程
- 客户端先访问Zookeeper，获取-ROOT-表的位置信息。
- 然后访问-ROOT-表，获得.META.表位置信息。
- 访问.META.表，找到所需要的Region具体位于哪个Region服务器。
- 最后到该Region服务器读取数据。
- 用户会把这写查询过的Region的服务器的位置信息保存起来，以后访问相同的数据的时候，就可以直接与服务器进行交互。
7. Zookeeper服务器
- 可能是由多台机器构成的集群来提供稳定可靠的服务。
- Master作为“总管“，监控众多的Region服务器端的信息状态。
- 可以启动多个Master，但是Zookeeper会选出唯一一个Master。
- 每个Region服务器都要在Zookeeper中注册，其实时监控每个Region服务器的状态并发送给Master。
- 其保存了-ROOT-表的地址和Master的地址信息。
8. Region服务器的工作原理
- Region服务器管理了一系列的Region对象和一个Hlog文件（记录了所有的更新操作）。
- 一个Region由多个Stroe组成（一个Store对应一个列族的存储）。
- 一个Store由一个MemStore和多个StoreFile组成。
8.1 数据存储过程
- 数据先分配到相应的Region服务器当中去执行操作。
- 将数据的更新操作写入HLog当中。
- 数据之后会写入MenStore缓存当中，当缓存满时，就会刷新缓存，每一次刷新就会生成一个StoreFile文件，刷新的数据变存在其中。
- StoreFile文件会被永久的保存在磁盘当中。
- 当StoreFile文件的数量逐渐增多达到一个阙值的时候就会触发合并操作，合并为一个大的StoreFile文件。