浅析HBase架构和系统结构介绍（三）

3 数据模型

3.1 表和列族(Table & column family)

HBase以表的形式存储数据，表由行和列组成，列划分为若干个列族（column family）。

l row key：

row key是用来检索记录的主键。访问HBase table中的行，只有三种方式：

• 通过单个row key访问
• 通过row key的range
• 全表扫描

row key可以是任意字符串（最大长度是 64KB，实际应用中长度一般为 10-100bytes左右），在HBase内部，row key保存为字节数组。数据按照row key的字典序（byte order）排序存储，因此设计key时要充分排序存储这个特性，将经常一起读取的行存储放到一起。

HBase支持单行事务，行的一次读写是原子操作 （不论一次读写多少列），这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。

l column family：

列簇，table在水平方向有一个或者多个column family组成，一个column family中可以由任意多个column组成，即column family支持动态扩展，无需预先定义column的数量以及类型，所有column均以二进制格式存储，用户需要自行进行类型转换。

列名都以列族作为前缀。例如’courses:history’，’courses:math’，都属于courses 这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

l timestamp：

时间戳，每次数据操作对应的时间戳，可以看作是数据的version number。时间戳的类型是 64位整型。时间戳可以由HBase（在数据写入时自动）赋值，此时时间戳是精确到毫秒的当前系统时间；时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

为了避免数据存在过多版本造成的的管理 （包括存贮和索引）负担，HBase提供了两种数据版本回收方式：一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

l cell：

由{row key, column(= + ), version}唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

3.2 表和区域（Table & regsion）

当table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey,endkey)表示，不同的region会被HMaster分配给相应的HRegionServer进行管理：

3.3 -ROOT- && .META.表

HBase中有两张特殊的table，-ROOT-和.META.

Ø .META.：记录了用户表的region信息，.META.可以有多个region

Ø -ROOT-：记录了.META.表的region信息，-ROOT-只有一个region

Ø Zookeeper中记录了-ROOT-表的location

Client访问用户数据之前需要首先访问Zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过Client端会做cache缓存。

4 HBase存储格式

HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型：

1. HFile， HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装。

2.HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File。