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