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