HBase in Action前三章笔记

近期接触HBase，看了HBase In Action的英文版。開始认为还行，做了些笔记。可是兴许看下去，越来越感觉到实战这本书比較偏使用上的细节，对于HBase的具体设计涉及得很少。把前三章的一些笔记帖一下。后面几章内容不打算整理了。并非说书内容不好。

key-value存储。强一致性，多个RegionServer节点对client端是不暴露细节的

使用场景：典型的web-search, capture incremental data, ad. click stream, content serving, info exchange

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcGVsaWNr/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

设置 hbase.root 来改写本来写/tmp的数据路径

HBase shell是jruby写，hbase shell来启动

一些命令：

list
create 'pelick', 'cf'
put 'pelick', 'first', 'cf:msg', 'wefewfwf'
put 'pelick', 'sec', 'cf:num', 12234
get 'pelick', 'first' 默认返回version最新的数据。实际上put的时候会有带新的版本
scan 'pelick'
describe 'pelick'

一些相应的API类和简单使用

HTableInterface usersTable = new HTable("users");

Configuration myConf = HBaseConfiguration.create();
HTableInterface usersTable = new HTable(myConf, "users");

HTablePool pool = new HTablePool();
HTableInterface usersTable = pool.getTable("users");
... // work with the table
usersTable.close();

Get, Put, Delete, Scan, Increment

Put p = new Put(Bytes.toBytes(" TheRealMT"));
p.add(Bytes.toBytes("info"),
Bytes.toBytes("name"),
Bytes.toBytes("Mark Twain"));

Put的时候。成功运行须要两个保证。write-ahead log(WAL，即HLog)和MemStore

这两部分保证了data durability，能够选择不要WAL，就不保证数据不丢了。

Put p = new Put();
p.setWriteToWAL(false);

原因例如以下：

MemStore是内存的write buffer。到一定量会flush到磁盘上成为HFile。假设region server挂了。数据就丢失。而WAL能够用来恢复数据。

一个column family能够有多个HFile。可是一个HFile不能有多个column family的数据。每一个column family相应一个MemStore。

每台HBase机器都保存一份WAL。而这份WAL的durable取决于以下的文件系统，HDFS保证了这点。

一台HBase机器的WAL被全部的表、列簇共享。

Get的时候能够控制获得数据内容。通过addColumn()和addFamily()

Get g = new Get(Bytes.toBytes("TheRealMT"));
g.addColumn(
Bytes.toBytes("info"),
Bytes.toBytes("password"));
Result r = usersTable.get(g);

读数据的时候。有一个LRU cache来缓存常常訪问的数据，即BlockCache，用来缓存HFile内容。提升读性能。

每一个column family有自己的BlockCache。

HFile本质上是由Block组成的，index定位的。默认block大小是64K，可调整来影响顺序/随机读性能。

block是读的最小单位。

Delete也相似。

Delete d = new Delete(Bytes.toBytes("TheRealMT"));
d.deleteColumns(
Bytes.toBytes("info"),
Bytes.toBytes("email"));
usersTable.delete(d);

对Delete来说。数据并没有及时删除，是做了标记，不能被scan和get到。实际上。在compaction的时候会删除。

compaction分为minor和major两种。前者是合并HFile，比較常发生，对于合并的HFile大小和数目的设定会影响写性能。

合并比較吃IO的。

后者是把给定的region的一个列簇的全部HFile合并为一个HFile。开销大。要手动shell触发。所曾经者比較轻量级些。

仅仅有合并的时候，该删除的数据才会真正被删除。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcGVsaWNr/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

HBase除了是schema-less的，也是版本号化的。

对同一个列，能够写多次，每次会带版本号，是个long值，默认依赖时间戳。所以机器的时间应该要设置为同步。默认保留三份版本号，假设多了，会把之前的旧版本号替掉。

Table，Row，Column Family。Column qualifier，Cell，Version，这些组成了HBase数据构成。

Row：row key是唯一的，byte[]。列簇影响物理数据分布。Column qualifier的话各个row能够设置为不一样。

cell是rowkey+cf+cq组成的一条唯一记录。理解为一行数据。也是byte[]

在訪问上述这些元素的时候。是通过协调输入的rowkey, column family, column qualifier, version四个维度来找的

能够用4D的查找方式来理解一个普通的二维表，下图解释非常清楚

所以呢，我们能够把查找理解为key是一个map(能够是四维里的前几个组成的查询条件)，value为一个map或多个maps

HBase数据模型是半结构化的。即列数能够不同，域值长度也能够不同

从逻辑模型的角度看，HBase提供的是无限制的，持久的。嵌套不同版本号的结构。能够把整个结构理解为java里的这样一个Map：

Map<RowKey, Map<ColumnFamily, Map<ColumnQualifier,Map<Version, Data>>>>

且里面是降序排列的

从物理模型的角度看。一个列簇有多个HFile，本身是二进制文件。里面不包括null记录。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcGVsaWNr/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

做Table Scan的时候，能够传filter。详细API不列举。

在设置rowkey的时候，尽量让rowkey长度一致，比方hash一次。rowkey的设计影响重大，要尽量高效。

hbase.client.scanner.caching能够设置每次RPC返回的row个数，cache在client端，默认是1，比較影响性能。

HBase的原子操作。即Incremental Column Value(ICV)，

long ret = usersTable.incrementColumnValue(
  Bytes.toBytes("TheRealMT"),
  Bytes.toBytes("info"),
  Bytes.toBytes("tweet_count"),
1L);

类似java的AtomicLong.addAndGet()

HBase的region存在于region server上。与HDFS的datanode共存。由matser进程来分布region。

hbase.hregion.max.filesize影响一个region的分裂

client读写数据的时候，主要靠-ROOT-和.META.来做类似B+树的查找。结构例如以下：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcGVsaWNr/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

第一次和zk通信，得到-ROOT-在哪里。然后向某RS问。得到.META.在哪里。

然后向某RS2问，得到目标RS在哪里。最后向目标RS问。数据的详细位置。

这两表在client端会缓存。

HBase和MR的交互：能够把HBase当MR的数据源和写入目标，HBase还能够參与map-side join。

reduce-side join须要把全部数据shuffle到reduce端而且sort。开销大，那么map端的join能够减小IO和网络开销。

小表能够直接放内存进行map-side join，此时把这步直接变成读HBase，就节省了内存。详细样例不举了。

本质上，把HBase当作一个外部的巨大的hash table。

MR要注意是幂等的，对于有map里有状态的操纵。要注意避免影响，比方HBase的increment命令

部署要注意。HBase部署的datanode上尽量不要起MR的进程了，会影响性能。

最后说说HBase的可用性和可靠性。

可用性指系统处理失败的能力。

RegionServer是具备可用性的，一台挂了。还有一个能够取代它工作（数据在HDFS上保证。信息能够从master获取）。

要达到高可用。还能够做一些防御性部署，比方考虑多master的机架分布。

可靠性是一个数据库系统的名词，指数据durability和性能保证的结合。

那么HDFS作为HBase的支撑。带来了什么呢？

全部region servers是HDFS文件系统上的同一套namespace，保证了可用性。

RS和datanode共同部署，降低网络IO开销。

可靠性方面，HDFS保证数据的备份和不丢失。HBase本身的写语义具备durability的保证。

全文完 :)