HBase in Action前三章笔记
近期接触HBase，看了HBase In Action的英文版。開始认为还行，做了些笔记。可是兴许看下去，越来越感觉到实战这本书比較偏使用上的细节，对于HBase的具体设计涉及得很少。把前三章的一些笔记帖一下。后面几章内容不打算整理了。并非说书内容不好。
key-value存储。强一致性，多个RegionServer节点对client端是不暴露细节的
使用场景：典型的web-search, capture incremental data, ad. click stream, content serving, info exchange
设置 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触发。所曾经者比較轻量级些。
仅仅有合并的时候，该删除的数据才会真正被删除。
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记录。
做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+树的查找。结构例如以下：
第一次和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的保证。
全文完 :)
