Detailed HBase (very comprehensive)
Very Long Story simply looked again a lot of places do not understand ..
I. Introduction
history
started by chad walters and jim
2006.11 G release paper on BigTable
2007.2 inital HBase prototype created as Hadoop contrib
2007.10 First useable Hbase
2008.1 Hadoop become Apache top-level project and Hbase becomes subproject
2008.10 Hbase 0.18,0.19 released
hbase cottage is bigtable open source version. Hdfs above is established to provide high reliability, high performance, storage columns, scalable, real-time database system to read and write.
Nosql between it and the RDBMS, the data can only be retrieved by a primary key range, and the primary key (row key), only supports single transaction (may be achieved by hive supports multi-table join complex operations, etc.). Loose primary data store for unstructured and semi-structured.
Like with hadoop, Hbase target mainly depend on scale, by increasing low-cost commodity servers to increase the computing and storage capacity.
HBase tables generally have such characteristics:
1 large: a table can have hundreds of millions of rows on one million
For 2 columns: a column-oriented (group) and memory access control, the column (group) independent retrieval.
3 sparse: For column is empty (null) and does not take up storage space, so the table can be designed very sparse.
FIG Hbase is below a position in the Hadoop Ecosystem.
Second, logical view
HBase stores data in tabular form. Table has rows and columns. Column group is divided into several columns (row family)
Row Key
And nosql database are the same, row key is the primary key used to retrieve records. Access hbase table in a row, only three ways:
1 accessed through a single row key
2 by the row key range
3 full table scan
Row key key row (Row key) can be any string (maximum length 64KB, practical length typically 10-100bytes), inside hbase, row key stored as the byte array.
When stored, the data is stored ordered according Row key lexicographic order (byte order). When designing key, to fully sort store this feature, store the rows often read together put together. (Location relevance)
note:
The results of the lexicographical sort is 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21 int, ..., 9,91,92,93,94,95, 96,97,98,99. To keep the shaping of the natural order, as a row of keys must be left filled with zeros.
A write line is an atomic operation (regardless of how many columns a reader). The behavior of this design decision enables the user to easily understand program during concurrent update operations on the same line.
Column family
hbase each column in the table, are vested with a column family. Chema column family is part of the table (rather than columns), the table must be defined before use. Column name as a prefix to the column family. For example courses: history, courses: math courses belong to this column family.
Access control, disk and memory usage statistics are carried out in a column family level. Practical applications, control permissions on the column family can help us to manage different types of applications: we allow some basic application can add new data, some applications can read the data and create basic column family inheritance, some applications only allow browsing data (may not even see all the data because of privacy).
Timestamp
HBase as determined by a cell called a memory cell row and columns. Each cell holds are multiple versions of the same data. Version indexed by time stamp. Type of stamp is 64-bit integer. Timestamp may (automatically writing data) assigned by hbase, this time stamp is accurate to the current system time in milliseconds. Time stamp can also be explicitly assigned by the customer. If the application data to avoid version conflicts, it must generate their own unique stamp. Each cell, different versions of the data in reverse chronological order, ie the latest data at the top.
In order to avoid the presence of too many versions of data management caused (including storage and indexing) burden, hbase offers two versions of data recovery systems. First, save the data of the last n version, the second version is saved in the most recent period (such as the last seven days). Users can be set for each column family.
Cell
From the {Key Row, column ( = <Family> + <label> ), Version} uniquely determined unit. The cell data is not of the type, all bytecode stored.
Third, the physical storage
1 has already been mentioned, all the rows in the Table row key according to the lexicographic order.
2 Table row direction is divided into a plurality of Hregion.
3 region divided by the size of each table is only the beginning of a Region, inserted into the table as data continuously, region growing, when the time is increased to a threshold, other clubs will HRegion two new Hregion. When the table rows in growing, there will be more and more Hregion.
4 Hregion Hbase is the minimum unit in the distributed storage and load balancing. It means a minimum unit may be distributed in different Hregion different HRegion server. But Hregion is not split into a plurality of the server.
Although the minimum unit 5 HRegion distributed storage, but not the smallest unit of storage.
In fact, by one or more HRegion Store, each store a storage columns family.
每个Strore又由一个memStore和0至多个StoreFile组成。如图：
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，可参见上文描述。
四、 系统架构
Client
1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
Zookeeper
1 保证任何时候，集群中只有一个master
2 存贮所有Region的寻址入口。
3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
4 存储Hbase的schema,包括有哪些table，每个table有哪些column family
Master
1 为Region server分配region
2 负责region server的负载均衡
3 发现失效的region server并重新分配其上的region
4 GFS上的垃圾文件回收
5 处理schema更新请求
Region Server
1 Region server维护Master分配给它的region，处理对这些region的IO请求
2 Region server负责切分在运行过程中变得过大的region
可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。
五、关键算法 / 流程
region定位
系统如何找到某个row key (或者某个 row key range)所在的region
bigtable 使用三层类似B+树的结构来保存region位置。
第一层是保存zookeeper里面的文件，它持有root region的位置。
第二层root region是.META.表的第一个region其中保存了.META.z表其它region的位置。通过root region，我们就可以访问.META.表的数据。
.META.是第三层，它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。
说明：
1 root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。
2.META.表每行保存一个region的位置信息，row key 采用表名+表的最后一样编码而成。
3 为了加快访问，.META.表的全部region都保存在内存中。
假设，.META.表的一行在内存中大约占用1KB。并且每个region限制为128MB。
那么上面的三层结构可以保存的region数目为：
(128MB/1KB) * (128MB/1KB) = = 2(34)个region
4 client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。
读写过程
上文提到，hbase使用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并 且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中 记录一个redo point，表示这个时刻之前的变更已经持久化了。(minor compact)
当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。
前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更 新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的 StoreFile和MemStore，将他们的按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。
写请求处理过程
1 client向region server提交写请求
2 region server找到目标region
3 region检查数据是否与schema一致
4 如果客户端没有指定版本，则获取当前系统时间作为数据版本
5 将更新写入WAL log
6 将更新写入Memstore
7 判断Memstore的是否需要flush为Store文件。
region分配
任何时刻，一个region只能分配给一个region server。master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。当存在未分配的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。region server得到请求后，就开始对此region提供服务。
region server上线
master使用zookeeper来跟踪region server状态。当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的文件，并获得该文件的独占锁。由于master订阅了server 目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。
region server下线
当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。而master不断轮询 server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁，(或者master连续几次和region server通信都无法成功),master就是尝试去获取代表这个region server的读写锁，一旦获取成功，就可以确定：
1 region server和zookeeper之间的网络断开了。
2 region server挂了。
的其中一种情况发生了，无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的文件，并将这台region server的region分配给其它还活着的同志。
如果网络短暂出现问题导致region server丢失了它的锁，那么region server重新连接到zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。
master上线
master启动进行以下步骤:
1 从zookeeper上获取唯一一个代码master的锁，用来阻止其它master成为master。
2 扫描zookeeper上的server目录，获得当前可用的region server列表。
3 和2中的每个region server通信，获得当前已分配的region和region server的对应关系。
4 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
master下线
由于master只维护表和region的元数据，而不参与表数据IO的过 程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。从上线过程可以看到，master保存的 信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般hbase集群中总是有一个master在提供服务，还有一个以上 的’master’在等待时机抢占它的位置。
六、访问接口
- HBase Shell
- Java clietn API
- HBase non-java access
-
- languages talking to the JVM
-
- Jython interface to HBase
- Groovy DSL for HBase
- Scala interface to HBase
- languages with a custom protocol
-
- REST gateway specification for HBase
- 充分利用HTTP协议：GET POST PUT DELETE
§
-
-
- text/plain
- text/xml
- application/json
- application/x-protobuf
- Thrift gateway specification for HBase
-
- java
- cpp
- rb
- py
- perl
- php
-
- HBase Map Reduce
- Hive/Pig
七、结语：
全文对 Hbase做了 简单的介绍，有错误之处，敬请指正。未来将结合 Hbase 在淘宝数据平台的应用场景，在更多细节上进行深入。
参考文档
Bigtable: A Distributed Storage System for Structured Data
HFile: A Block-Indexed File Format to Store Sorted Key-Value Pairs for a thorough introduction Hbase Architecture 101
Hbase source code