《HBase企业应用开发实战》—— 3.4 数据模型的特殊属性

本节书摘来自华章出版社《HBase企业应用开发实战》一 书中的第3章,第3.4节,作者:马延辉 孟鑫 李立松 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.4 数据模型的特殊属性

讨论完HBase的基本概念,我们来学习一下它特有的功能。这些常常使人感到困惑,对使用过关系型数据库的读者来说尤为如此。HBase的这些特性使得完成某些功能更加方便,同时它也存在一些有待完善的地方,这也正是HBase在大力改进的地方。

3.4.1 版本

Rowkey、Column(列族和列)、Version组合在一起称为HBase中的一个单元格。有可能会有很多单元的行和列是相同的,要区分不同的单元可以使用版本。
Rowkey和Column的值是用字节数组表示的,Version则是用一个长整型表示的。这个长整型值是使用java.util.Date.getTime()或者System.currentTimeMillis()产生的,这就意味着它的含义是“当前时间和1970-01-01 UTC的时间差,单位毫秒”。
在HBase中,版本是按倒序排列的,因此当读取这个文件的时候,最先找到的是最近的版本。关于版本的一些常见问题主要有如下两个:
如果有多个包含版本的写操作同时发起,HBase会保存全部还是会保持最新的一个?
可以发起包含版本的写操作,但是它们的版本顺序和操作顺序相反吗?
下面介绍一下在HBase中版本是如何工作的。
1.?含版本的操作
这里详细讲解如何在HBase的各个主要操作中使用版本属性。
(1)Get/Scan
Get是在Scan的基础上实现的。Get同样可以用Scan来描述。在默认情况下,如果没有指定版本,一旦使用Get操作,会返回最近版本的Cell(该Cell可能是最新写入的,但不能保证一定是)。默认的操作可以这样修改:
如果想要返回两个以上的版本,可以使用Get类的setMaxVersions(),如果想要返回的版本不只是最近的,可以使用Get类的setTimeRange()。
要想查询的最新版本小于或等于给定的这个值,这就意味着给定的“最近”的值可以是某一个时间点。可以使用0到想要的时间来设置,还要把Max Versions设置为1。
默认Get例子如下,其中的Get操作会只获得最新的一个版本。

Get get = new Get(Bytes.toBytes("row1"));
Result r = htable.get(get);
byte[] b = r.getValue(Bytes.toBytes("cf"), Bytes.toBytes("attr"));
    // returns current version of value
含有版本的Get例子如下,其中的Get操作会获得最近的3个版本。
Get get = new Get(Bytes.toBytes("row1"));
get.setMaxVersions(3);  // will return last 3 versions of row
Result r = htable.get(get);
byte[] b = r.getValue(Bytes.toBytes("cf"), Bytes.toBytes("attr"));
    // returns current version of value
List<KeyValue> kv = r.getColumn(Bytes.toBytes("cf"), Bytes.toBytes("attr"));
    // returns all versions of this column

(2)Put
一个Put操作会为一个Cell创建一个版本,默认使用当前时间戳,当然也可以自己设置时间戳,这就意味着可以把时间设置在过去或者未来,或者随意使用一个长整型值。覆盖一个现有的值,就意味着新写入Cell的Rowkey、Column Family、Column Qulifier和Version必须和原来的完全相同。
下面是不指明版本的例子,其中的Put操作不指明版本,所以HBase会将当前时间作为版本。

Put put = new Put(Bytes.toBytes(row));
put.add(Bytes.toBytes("cf"), Bytes.toBytes("attr1"), Bytes.toBytes( data));
htable.put(put);
下面是指明版本的例子,其中的Put操作指明了版本。
Put put = new Put( Bytes.toBytes(row ));
long explicitTimeInMs = 555;  // just an example
put.add(Bytes.toBytes("cf"), Bytes.toBytes("attr1"), explicitTimeInMs, Bytes.toBytes(data));
htable.put(put);

(3)Delete
内部删除标记有三种不同类型:
Delete:删除列的指定版本。
Delete Column:删除列的所有版本。
Delete Family:删除特定列族所有列。
当删除一行时,HBase将内部为每个列族创建墓碑(非每个单独列)标记。
删除操作的实现是创建一个墓碑标记。例如,要删除一个版本,HBase不会去改那些数据,数据不会立即从文件中删除。它使用删除标记来屏蔽掉这些值。如果被标记的是最新一个版本的数据,就意味着这一行中的所有数据都会被删除。
2.?现有的限制
关于版本还有一些未实现的功能,计划在以后的版本中实现。
(1)删除标记后错误读取新数据
删除标记操作可能会标记其后Put的数据。注意,在写下一个墓碑标记后,只有下一个主合并(major compact)操作发起之后,墓碑标记才会清除。假设删除所有小于等于时间T的数据,但之后又执行了一个Put操作,其时间戳小于等于T,那么就算这个Put发生在删除操作之后,该数据也会被打上墓碑标记。这个Put并不会失败,但你做Get操作时,则无法查询刚刚Put进去的数据。只有一个主合并(major compact)执行后,一切才会恢复正常。所以使用一系列时间戳一直增长的Put操作就不会发生该问题。
(2)主合并改变查询的结果
一个Cell有三个版本数据t1、t2和t3,maxVersion设置为2,当请求获取全部版本的时候,只会返回两个:t2和t3。如果将t2和t3删除,就会返回t1。但是如果在删除之前,发生了major compaction操作,t1的值将会从磁盘上被彻底删除,结果是什么值都不会返回了。

3.4.2 排序

Get和Scan操作返回的是经过排序的数据。列在服务器端也是字典排序的,所以按照名称的字典序返回。总体来说,返回的数据首先按行字典序排序,其次是列族,然后是列修饰符(column qualifier),最后是时间戳反向排序,最新的在最前面。

3.4.3 列的元数据

对于HBase表中的列族,除了KeyValue实例以外,没有关于元数据的描述,KeyValue对象表示HBase的最小单位是Cell。HBase的表不仅在一行中支持很多列,而且支持行之间有不同的列,所以需要单独维护行和列之间的关系。获取列族的完整列名的唯一方法是处理所有行。

3.4.4 连接查询

HBase是否支持连接查询,即Join查询,是一个常见问题。简单来说是不支持,至少不像传统RDBMS那样支持。正如前面描述的,读数据模型只有Get和Scan两种操作。但这并不表示Join查询不能在应用程序中使用,只是必须用户自己实现。一般来讲,实现方法有两种:要么写入HBase的时候已经做好连接;要么查询表并在应用层实现连接。哪个更好?依赖于准备做什么,所以没有一个准确的答案适合所有情况。

3.4.5 计数器

IncrementColumnValue(简称ICV)是HBase的计数器,可以使用它完成一些诸如计算页面浏览量(PV)的操作。如果没有ICV,则需要首先读出HBase单元格中的值,然后加1再存入。ICV操作发生在RegionServer上,而不是在客户端,所以速度快,使用方式也没有那么烦琐。当其他客户端也在访问同一个单元格时,可以避免出现不一致的情况。可以把ICV等同于Java的AtomicLong.addAndGet()方法。如果想了解计数器的详细用法请阅读10.2节。

3.4.6 原子操作

类似Java的原子类,HTableInterface接口也提供checkAndPut()和checkAndDelete()方法,它们可以在维持原子语义的同时提供更精细的控制。可以用checkAndPut()来实现上一节提到的incrementColumnValue()方法:

Configuration conf = HBaseConfiguration.create();
HTable htable = new HTable(conf,"table1"); // instantiate HTable
Get g=new Get(Bytes.toBytes(rowkey));
Result r= htable.get(g);
long curVal=Bytes.toLong(r.getColumnLatest(Bytes.toBytes(family),
    Bytes.toBytes(qualifier)).getValue());
long incVal=curVal+1;
Put P=new Put(Bytes.toBytes(rowkey));
P.add(Bytes.toBytes(family), Bytes.toBytes(qualifier), Bytes.toBytes(incVal));
htable.checkAndPut(Bytes.toBytes(rowkey), Bytes.toBytes(family),
    Bytes.toBytes(qualifier), Bytes.toBytes(curVal),P);

上面的代码虽然有点长,但可以试试。使用checkAndDelete()的方式与此类似。

3.4.7 事务特性ACID

传统的SQL数据库的事务通常都是支持ACID的强事务机制。而HBase这种NoSQL数据库仅提供对行级别的原子性保证,也就是说同时对同一个Key下的数据进行的两个操作,在实际执行的时候是会串行的执行,保证了每一个KeyValue对不会被破坏。
之前版本的HBase提供行级的事务,不过每次事务只能执行一个写操作,假如连续地执行一系列Put、Delete操作,那么这些操作是单独一个个的事务,其整体并不是原子性执行的。而在0.94.*版本中,可以实现Put、Delete在同一个事务中一起原子性执行。
同一Region有多行原子性,因此对一个多Region表来说,还是无法保证每次修改都能封装为一个事务。HBase不是一个具备完整ACID特性的数据库,它只实现了某些属性。
HBase的ACID操作是复杂的,下面总结了ACID操作的一些主要原则,这些原则可以由点及面,逐步了解HBase ACID的特征。
HBase中考虑了事务(ACID)特性的数据操作包含以下这些:
获取数据的API:Get、Scan
修改数据的API:Put、Batch put、Delete
多项操作在一起的API:IncrementColumnValue、CheckAndPut
1)关于HBaseACID设计原则如下:对于同一行所有列的修改是原子性的,对于该行的Put操作要么整体成功要么整体失败。
2)一个返回“成功”标志的操作肯定是完全成功的。
3)一个返回“失败”标志的操作肯定是完全失败的。
4)超时的操作可能成功也可能失败。但也不会是部分成功或失败。
5)对于同一行跨多个列族的操作也遵循上面的原则。
6)多行操作不能保证原子性,例如:对a、b、c三行进行操作,一些可能有返回,一些可能没有,在这种情况下,API会返回一个对这三行操作的结果列表,包括成功、失败或者超时。
7)CheckAndPut()操作就像许多编程语言的CompareAndSet()操作一样是原子性的。
8)所有修改操作是保证顺序的,例如:如果一个写操作将数据修改成"a=1,b=1,c=1",另一个修改成"a=2,b=2,c=2",那么行的状态肯定是"a=1,b=1,c=1"或者"a=2,b=2,c=2",不可能出现"a=1,b=2,c=1"这种状态。
9)请注意批量修改操作不能跨越多行。
10)一致性和隔离性。通过API得到的行的数据是一个完整的行,数据由表中某个时刻的数据构成。
11)持久性。所有可以读取到的数据保证都是已经被持久化到磁盘上的。也就是说不会读到没有写到磁盘上的数据。所有返回成功的操作的数据都是处于持久化到磁盘上的。返回失败的都没有持久化。
关于HBase的ACID语义详情可以参见:http://hbase.apache.org/acid-semantics.html

3.4.8 行锁

HBase API中put()、delete()、checkAndPut()等修改操作是独立执行的,这意味着在一个串行方式的执行中,对于每一行必须保证行级别的操作是原子性的。RegionServer提供了一个行锁特性,这个特性保证了只有一个客户端能获取一行数据相应的锁,同时对该行进行修改。

3.4.9 自动分区

HBase中一个表的数据会被划分成很多的Region,Region可以动态扩展并且HBase保证Region的负载均衡。Region实际上是行键排序后的按规则分割的连续的存储空间。如果Region太大,会被动态拆分,相反,多个Region会合并成一个较大的Region,以减少HDFS上存储文件的数量。这两个过程就是HBase的split和compaction,在第9章会详细讲解这两个操作。
刚刚创建的表只有一个Region,随着数据的写入,达到Region上限配置值时,Region会按照中间键自动地拆分成两个大致相等的Region,每个Region由一个RegionServer管理,一个RegionServer处理器管理着许多的Region。图3-3展示了多个Region是如何分布在不同RegionServer上的,注意每个Region包含起始Rowkey的记录,不包含结束Rowkey的记录。
《HBase企业应用开发实战》—— 3.4 数据模型的特殊属性

每个RegionServer管理多少个Region合适?每个Region大小是多少合适?按照现在主流硬件的配置,每个RegionServer可以管理大约100~1000个Region,每个Region的大小可以是1~20GB。
Region的拆分和转移是由HBase自动完成的,用户感知不到,当一个RegionServer服务器发生故障时,Region可以快速地被转移到其他服务器上,Region的拆分过程也是瞬间完成的。当Region进行拆分时,首先要将该Region下线(offline),拆分完成后新的Region再上线(online),下线的Region暂时不可用,不过由于速度极快,通常不会对数据的读写造成影响。

上一篇:AKKA文档(java版)—位置透明性


下一篇:《数据库技术原理与应用教程》一3.5.2关系模型简介