最近接触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的保证。
全文完 :)
