HBase 特性简要分析

HBase是一种构建在HDFS之上的分布式、面向存储列的存储系统。在需要实时读写、随机访问超大规模访问数据采集的时候，可以使用HBase。

尽管现在已经有很多数据存储和访问的策略和实现方法，但是事实上大多数解决方案，特别是一些关系类型的，在构建时并没有考虑超大规模和分布式的特点。许多商家通过复制和分区的方法来扩充数据库使其突破单个节点的界限，但这些功能通常都是事后增加的，安装和维护都很复杂。同时，也会影响RDBMS的特定功能，例如联接、复杂的查询、触发器、视图和外键约束这些操作在大型的RDBMS上的代价相当高，甚至根本无法实现。

HBase从另一个角度处理伸缩性的问题。它通过线性方式从下到上增加节点来进行扩展。HBase不是关系型数据库，也不支持SQL，但是他有自己的特长，这是RDBMS不能处理的，HBase巧妙的将稀疏的表放在商用的服务器的集群上。

HBase 是Google Bigtable 的开源实现，与Google Bigtable利用GFS作为文件存储系统类似，HBase利用Hadoop HDFS 作为文件存储系统，Google 运行MapReduce 来处理Bigtable中的海量数据，HBase 同样利用Hadoop  MapReduce来处理HBase的海量数据,Google Bigtable 利用Chubby作为协同服务。HBase利用Zookepper作为对应。

HBase的特点

1. 大：一个表可以有上亿行，上百万列。
2. 面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
3. 稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4. 无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
5. 数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
6. 数据类型单一：HBase中的数据都是字符串，没有类型。

HBase的高并发和实时处理数据

hadoop是一个高容错，高延时的文件分布式系统和高并发的批处理系统，不适用实时计算。HBase是可以提供实时计算的分布式数据库。数据被保存到HDFS分布式文件系统上。由HDFS保证期高容错性。但是在生产环境中。HBase是如何基于hadoop提供实时性呢？ HBase上的数据是以StoreFile(HFile)二进制流的形式存储在HDFS上block块儿中；但是HDFS并不知道hbase存入的是什么,它只把存储文件是为二进制文件，也就是说。hbase的存储数据对于HDFS文件系统是透明的。hbase的存储数据对于HDFS文件系统是透明的。

HBase HRegion servers集群中的所有的region的数据在服务器启动时都是被打开的，并且在内存初始化一些memstore，相应的这就在一定的程度上加快的系统的响应。而Hadoop中的block中的数据文件默认是关闭的，只有在需要的时候打开。处理完数据后就关闭。这在一定的程度上就增加了响应时间。

从根本上来说。HBase能提供实时计算的服务的主要原因是由架构和底层数据结构决定的。即由LSM-Tree + HTable(region分区) + Cache决定——客户端可以直接定位到要查数据所在的HRegion server服务器，然后直接在服务器的一个region上查找要匹配的数据，并且这些数据部分是经过cache缓存的。具体查询流程如下图所示：

具体数据访问流程如下：

1. 1.Client会通过内部缓存的相关的-ROOT-中的信息和.META.中的信息直接连接与请求数据匹配的HRegion server；
2. 2.然后直接定位到该服务器上与客户请求对应的Region，客户请求首先会查询该Region在内存中的缓存——Memstore(Memstore是一个按key排序的树形结构的缓冲区)；
3. 3.如果在Memstore中查到结果则直接将结果返回给Client；
4. 4.在Memstore中没有查到匹配的数据，接下来会读已持久化的StoreFile文件中的数据。前面的章节已经讲过，StoreFile也是按 key排序的树形结构的文件——并且是特别为范围查询或block查询优化过的，；另外HBase读取磁盘文件是按其基本I/O单元(即 HBase Block)读数据的。

具体过程就是：

如果在BlockCache中能查到要造的数据则这届返回结果，否则就读去相应的StoreFile文件中读取一block的数据，如果还没有读到要查的数据，就将该数据block放到HRegion Server的blockcache中，然后接着读下一block块儿的数据，一直到这样循环的block数据直到找到要请求的数据并返回结果；如果将该 Region中的数据都没有查到要找的数据，最后接直接返回null，表示没有找的匹配的数据。当然blockcache会在其大小大于一的阀值（heapsize * hfile.block.cache.size * 0.85）后启动基于LRU算法的淘汰机制，将最老最不常用的block删除。

HBase数据模型

HBase 以表的形式存储数据。表由行和列组成。列划分为若干个列族（row family），如下图所示。

HBase的逻辑数据模型：

HBase的物理数据模型（实际存储的数据模型）：

逻辑数据模型中空白cell在物理上是不存储的，因为根本没有必要存储，因此若一个请求为要获取t8时间的contents:html，他的结果就是空。相似的，若请求为获取t9时间的anchor:my.look.ca，结果也是空。但是，如果不指明时间，将会返回最新时间的行，每个最新的都会返回

Row Key

与 NoSQL 数据库一样，Row Key 是用来检索记录的主键。访问 HBase table 中的行，只有三种方式：

• 通过单个 Row Key 访问。
• 通过 Row Key 的 range 全表扫描。
• Row Key 可以使任意字符串（最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes），在HBase 内部，Row Key 保存为字节数组。

在存储时，数据按照* Row Key 的字典序（byte order）排序存储*。设计 Key 时，要充分排序存储这个特性，将经常一起读取的行存储到一起（位置相关性）。

注意 字典序对 int 排序的结果是 1，10,100,11,12,13,14,15,16,17,18,19,20,21，…， 9，91,92,93,94,95,96,97,98,99。要保存整形的自然序，Row Key 必须用 0 进行左填充。

行的一次读写是原子操作（不论一次读写多少列）。这个设计决策能够使用户很容易理解程序在对同一个行进行并发更新操作时的行为。

列族

HBase 表中的每个列都归属于某个列族。列族是表的 Schema 的一部分（而列不是），必须在使用表之前定义。列名都以列族作为前缀，例如 courses:history、courses:math 都属于 courses 这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。在实际应用中，列族上的控制权限能帮助我们管理不同类型的应用， 例如，允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、 
一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

时间戳

HBase 中通过 Row 和 Columns 确定的一个存储单元称为 Cell。每个 Cell 都保存着同一份数据的多个版本。 版本通过时间戳来索引，时间戳的类型是 64 位整型。时间戳可以由HBase（在数据写入时自动）赋值， 
此时时间戳是精确到毫秒的当前系统时间。时间戳也 可以由客户显示赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 Cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

为了避免数据存在过多版本造成的管理（包括存储和索引）负担，HBase 提供了两种数据版本回收方式。 一是保存数据的最后 n 个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

Cell

Cell 是由 {row key，column(=< family> + < label>)，version} 唯一确定的单元。Cell 中的数据是没有类型的，全部是字节码形式存储。

HBase物理存储

Table 在行的方向上分割为多个HRegion，每个HRegion分散在不同的RegionServer中。

每个HRegion由多个Store构成，每个Store由一个memStore和0或多个StoreFile组成，每个Store保存一个Columns Family

StoreFile以HFile格式保存在HDFS上。HFile的格式为：

 Trailer部分的格式:

HFile分为六个部分：

• Data Block 段–保存表中的数据，这部分可以被压缩
• Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。
• File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
• Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
• Meta Block Index段 (可选的)–Meta Block的索引。
• Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先 读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。

HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。目标HFile的压缩支持两种方式：Gzip，Lzo。

HLog(WAL log)

WAL 意为Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，类似mysql中的binlog,用来 做灾难恢复只用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。

每个Region Server维护一个Hlog，而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个 文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。