1. HBase的架构图
简易版架构图：
复杂版架构图：
架构讲解见《Hadoop系列四——HBase简介》。
2. HBase的数据模型
在《Hadoop系列四——HBase简介》里面已经介绍过HBase的数据模型了，但这个的确非常重要，这里再做一些补充。HBase是根据Google的Bigtable论文实现的开源版"Bigtable"，所以对Bigtable的描述同样适用于HBase：
A Bigtable is a sparse, distributed, persistent multi-dimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.
这里有几个关键词我已经加粗了，从这几个关键词可以引出来多个问题。
2.1 HBase里面的"NULL值"处理
第一个就是sparse关键字。首先NULL值是RDBMS里面的概念，HBase里面其实没有这个概念，这里只是为了作对比，介绍稀疏性这个特性。我们把HBase想成一个二维矩阵(这样不准确，但有助于理解)，那么其实就是一个稀疏矩阵。在RDBMS里面，没有值的地方一般用NULL表示，虽然相比于其他类型，NULL占很小的空间（一般是1bit），但仍然是占空间的，在RDBMS里面这没有问题，主要有两个原因：(1)RDBMS里面数据量不会很大，目前RDBMS能承载的最大数据量一般也就是百万级别的。(2)如果把RDBMS也看成二维矩阵的话，一般RDBMS都属于稠密矩阵，所以NULL值不会占大多数。
但HBase不一样，它正好与RDBMS的特性相反：数据量很大，一般都大于百万级别(如果小于这个量级，那你该重新考虑是否有必要使用HBase了)；NULL值可能占很大部分，这个和HBase的设计使用有关系。比如一个表里面有1百万个列，有1千万行数据，每一行里面可能只有一小部分列有值，其他列都是“NULL值”(实质是没有值)。所以，在HBase里面，"NULL值"是不存储的，即不占用任何存储。其实这个和稀疏矩阵的存储原理上是一样的，只存储有数据的cell的“坐标”及值，其它的默认就是NULL。当我们在HBase里面获取一行数据的时候，只会返回有数据的列，不像RDBMS会返回所有列，没有值的用NULL占位。
更多信息见本文“HBase的逻辑存储和物理存储”部分。
2.2 分布式
想想如果因为性能或存储等不够了，需要将RDBMS扩展成分布式的，能否做到？也许可以做到，但一般是受限的，而且难度比较高，比如像业内的GreenPlum，如果还想要保证RDBMS的所有特性，那就只能用更好的硬件做垂直扩展了。但HBase本身就是分布式的，扩展一个HBase节点基本上没有什么难度。所以这也是很多企业选择HBase的一个非常重要的考量。
2.3 多维有序map
多维的概念在我的《Hadoop系列四——HBase简介》里面已经讲过了。
有序之前也提过，在HBase里面，不论是内部存储，还是查询返回的数据，都是有序的：依次按照row key、Column Family、Column qualifier、Timestamp四个维度排序，时间戳是按照从新到旧排的，其它都是字典序。
2.4 HBase里面的数据是否有类型
上面对于value的描述是“uninterpreted array of bytes”，也就是没有类型，默认按字节流解析（我们知道任何类型其实都可以按字节流其解析）。其实在HBase里面除了会被作为路径的名称之外，其它都是作为字节流的，也就是没有类型。具体就是：表名、Column Family会作为路径名，所以名称必须是合法的路径名，也就是必须是可打印字符；row key，Column qualifier、Cell都是没有类型的，也就是可以是任何数据。实际中，我们经常会在row key、Column qualifier中存储数据，而不光是cell里面。
3. HBase的逻辑存储和物理存储
引用HBase:The Definitive Guide上的一幅图：
第一幅图（左上角）是HBase里面一个典型的表的逻辑图，里面有cf1和cf2两个Column Family（以下简称CF），每个CF里面有两列。里面的红色和黄色小块表示有数据，其他地方都没有数据（如前面所说，是一个稀疏矩阵），多个层叠的部分表示有多个版本的数据。
第二幅图（右上角）也是一个逻辑图，主要为了说明以下几个点：
- 不同CF里面的数据是分开存储的；
- 同一个CF里面的数据是按照row key顺序存储的；
- 统一cell里面有多个版本的数据的时候，新版本数据在前，旧版本数据在后，这样方便先取到新版本数据。
第三幅图（右下角）是上面的逻辑存储在物理文件上的存储形式，需要注意以下几个点：
- 不同CF的数据是存储在不同的文件里面的（Storefile或HFile），这就是为什么我们要将要一起使用的数据字段定义在同一个Column Family的原因；
- 同一个文件里面还是按照row key、CF、Column qualifier排序的；
- 每一条数据里面都要存储Key(row key、Column Family、Column qualifier、Timestamp)和value。在RDBMS里面我们设计字段名时一般要求能够“见名知意”，但在HBase里面不推荐这样做，Key的设计在保证功能的前提下，越短越好（比如仅用一个字母表示），至于其含义可以其它地方记录，比如文档里面。
第四幅图（左下角）是为了说明查询时指定各个Key对性能的影响：
- 指定row key可以大幅度提高查询性能，因为根据row key可以确定在哪些region上面查（也就是说可以跳过那些不包含该row key的region）。在scan命令里面，可以通过
STARTROW和STOPROW指定row key范围。 - 指定Column Family可以大幅度提高查询性能，因为根据CF可以确定跳过哪些Storefile/HFile，一般查询时都建议指定CF。
- 指定Timestamp也可以较大幅度提高查询性能，因为每个Storefile会存储它所保存的所有数据的时间区间，如果所指定的Timestamp不在该区间内，则直接跳过。
- 指定Column Qualifier和Value的过滤条件可以提高查询性能，但提高的很少。因为必须把每个Cell的值读出来和指定的条件做对比。
4. Tall-Narrow or Flat-Wide表
Tall-Narrow也就是我们所说的“窄表”，Flat-Wide是“宽表”。举个例子，比如我们要存储一个用户的邮件信息：用户ID、邮件ID、邮件内容。如果按照Tall-Narrow的思想去设计，表结构可能是下面这样：
# 将用户id和邮件id拼接成row key，邮件内容作为一列数据
userid-emailid, cf:emailbaody如果按照Tall-Narrow思路去设计，表结构可能是下面这样：
# userid为row key，emailid和emailbody作为两个列
userid, cf:emailid, cf:emailbody两种设计各有利弊，使用宽表的好处主要在于HBase的ACID特性仅限于行内，所以如果把所有数据都放在一行，那可以很好的利用其ACID特性。而窄表在实际使用中更加常见一些，因为HBase里面的的row key类似于RDBMS里面的主键，所以我们尽可能将要经常查询的维度放在row key里面，可以提高查询性能；另外一个表里面不推荐有太多的Column Family，一般1个最好，最多也不要超过3个，具体见本文“Column Family的数量”部分。
5. HBase的表和Column Family能不能修改
先说结论：可以修改。使用alter命令可以修改表和Column Family，具体语法可以help "alter"查看。这里需要注意两点：
- 0.92版本之前，表必须先disable后才可以修改。之后的版本增加了一个配置项hbase.online.schema.update.enable，如果设为true，那可以直接修改，不需要disable。但官方推荐生产环境最好还是先disable再修改，在线修改可能会引发一些问题。
- 修改动作并非立即生效，而是等待下一次major compaction，Storefile重写之后才会生效。
6. HBase的Compaction
我们知道当MemStore里面的数据量达到一定值的时候，就会落盘形成StoreFile(HFile)，这样就会形成很多文件，而Compaction就是将这些文件合并成大文件。HBase里面有两种Compaction：Minor compactions和Major compactions，主要有如下区别：
- Minor compactions一次只选取少量存储在一起的文件做合并压缩，其结果就是一个store(或Column Family)的数据被合并成了多个大一些的Storefile，而Major compactions合并之后的结果是一个store(或Column Family)的数据全部到一个Storefile里面去了。
- Minor compactions合并时不删除已经标记删除或者过期版本的数据，而Major compactions会删掉那些标记删除或过期版本的数据。所以需要注意，HBase里面的删除是标记删除，真正的物理删除发生在Major compactions阶段。
虽然Compaction合并文件是为了提高性能，但合并这个操作却是消耗资源的，就跟Jvm的GC一样。默认Major compactions一周一次。
7. Column Family的数量
先说结论：一个表内的Column Family最好1个，最多不要超过3个。原因主要有两点：
- 现在HBase的flush(MemStore满了之后就会flush)和Compaction操作都是基于region的，从前面的架构图中可以看到一个region里面是包含多个Column Family的，所以当region内的某个Column Family需要flush或Compaction的时候，和它处于同一region内的其它Column Family也会一起flush或Compaction，但它们可能只有少量新增数据，这就会浪费IO。
- 假设有两个Column Family：CF-A和CF-B，其中CF-A有一百万条数据，CF-B有一千万条数据。假设CF-A占了100个HFile，CF-B占了1000个HFile，因为数据写入的先后顺序，很可能CF-A的100个文件会被CF-B的1000个文件打散，本来可能一个RegionServer上面的region足够存储所有的CF-A的HFile了，现在可能被打散到多个RegionServer上面去了，这样查询CF-A的数据的时候效率就会降低。这种现象称为“Cardinality of ColumnFamilies”。
8. Value的版本数和TTL
版本数指我们之前说的Timestamp，和这个特性相关的设置有两个：max versions和min versions，其含义也很明确。max versions的默认值是1，min versions的默认值是0，表示不启用多版本这个特性，即往一个Cell里面重复写数据会覆盖，而不是保留多个版本。
min versions和HBase的TTL(time-to-live)一起使用。我们可以给Column Family设置一个TTL时间（单位为秒），时间到期后的row会自动被删除。如果一个Storefile里面的row全部是过期的，那么在minor compaction阶段这个Storefile会被删除，我们可以通过把hbase.store.delete.expired.storefile设置为false或者把min versions设置为非0值来关闭删除这个特性。
9. 选择HBase还是RDBMS
一般来说，这个选择是比较好做的。HBase、Impala等数据库的诞生并不是为了替代传统的RDBMS，只是为了解决新的RDBMS解决不了或者解决起来比较困难的问题。所以，如果你的数据量并不大（一般以百万为分界线），那一般应该优先选择RDBMS，毕竟RDBMS支持完善的ACID，SQL，多级索引，各种Join，完善的类型等丰富的特性，这些都是HBase所不具备的。
但如果你的数据量非常大，RDBMS已经无法支撑了，那就可以考虑HBase等分布式数据库了。但如果你的业务离不开RDBMS的一些特性（比如各种Join、SQL、完善的ACID等），那可能就需要考虑类似于GreenPlum这种MPP数据库了。
10. FAQ
- HBase是否支持ACID？
HBase里面只支持受限的ACID(Atomicity, Consistency, Isolation, and Durability)：仅支持行内的ACID，跨行不支持。也就是对于同一行的操作是可以保证ACID的，但是多行操作是不行的。更多信息可参考：ACID in HBase。
- HBase和Hive如何选择？
这两个不是一个层级的东西，没有可比性。如果你还在这二者之间纠结，那可能你对它们有些误会，或者还不清楚你自己的需求。非要比的话，那就是HBase一般做实时查询；而Hive一般作为离线数据仓库，Hive后面是MapReduce/Spark，所以无法做到实时。
- HBase支不支持join？
先说结论：不支持。HBase读取数据时支持Get和Scan（Get的后台实现是Scan的一种特殊情况而已）操作，RDBMS里面的join在HBase里面是不支持的，但我们可以在表设计上支持一定程度上的"join"操作，比如将需要join的字段拼接起来作为row key。
HBase支持SQL吗？
HBase不支持SQL，只提供了各种API。但Apache下有个Phoenix项目，通过该项目可以使用SQL语句操作HBase。
- HBase的一个region多大合适？
注意，这里说的是region，不是RegionServer。一个region保持在10~50GB比较好。
- HBase一个表包含多少个region比较好？
一般一个表包含50~100个region和1~2个Column Family比较好。
- HBase的Cell里面存储的Value有大小限制吗？
没有，但一般不要超过10MB（对于MOB对象不要超过50MB）。如果超过了这个大小，可以将对象存到HDFS上面，然后再HBase里面存储HDFS路径。
- HBase里面的daughter是什么？
HBase的region分裂的时候，分裂出来的两个新region称为"daughter"，原来的称为"parent"。
11. Row key设计
Last but not the least，row key的设计是HBase表设计里面最重要的部分，没有之一。Row key设计不合理很容易会引起热点问题（hotspotting)——大量的客户端请求到达同一个节点（RegionServer）或少数一些节点，导致该节点负载急剧上升，性能下降，甚至不可用。这个问题容易出现的原因和HBase自身的设计有关系——row key是按照字典序排列的。当然这个设计是没有问题的，主要是为了快速访问。这里介绍一些常用的避免热点问题的方法。
11.1 Salt
第一种方式就是加盐值，这里的盐值不同于密码学里面的盐值。实质就是事先定几个随机的前缀，然后给每一个row key加上一个前缀，前缀的选择是随机的。如果你想让数据分布在N个region上，一般就有N个前缀。比如现在我们有如下形式的row key：
foo0001
foo0002
foo0003
foo0004
...显然这样的row key在HBase里面会连续存储在一起，这样在写的时候就会出现热点问题。此时如果使用加盐值的方式解决的话，我们可以这样操作：假设我们想让数据分布到不同的四个region上，那我们可以选取四个前缀，比如a~d四个字母，这样我们新的row key就变成下面这样了：
a-foo0001
b-foo0002
c-foo0003
d-foo0004
...这样就将数据打散了。由于这种前缀的选择是随机的，所以相同的row key可能拼接了不同的前缀：
b-foo0001
c-foo0002
a-foo0003
d-foo0004
...所以这种方式提高了写的吐吞量，但读的时候就会比较麻烦。
11.2 Hash
Hash其实是对Salt的一种优化。在Salt里面，前缀的选择是随机的，这样相同的row key可能加了不同的前缀。而Hash就是在row key和前缀之间建立一种哈希，使得相同的row key总是加相同的前缀，其它和Salt相同。
11.3 Key逆序
这种应该是现在使用比较普遍的一种解决row key热点的技术，对于固定长度（比如卡号、时间戳等）或者固定结构（比如域名）等非常好用。但其缺点就是牺牲了原来key的顺序。
Row key的设计和读写模式、业务、数据都有很大关系，所以不可一概而论，介绍的几种方法没有哪个是普适的，也没有哪个是完美的，具体问题还需具体分析。上面介绍的都是一些理论，关于row key的设计实战的话，这里强力推荐一篇文章：Introduction to hbase Schema Design by AMANDEEP KHURANA)。篇幅稍微有点多，有兴趣的可以看一下原文，这里列一下作者提到的设计表的时候要考虑的一些比较重要的点：
- What should the row key structure be and what should it contain?
- How many column families should the table have?
- What data goes into what column family?
- How many columns are in each column family?
- What should the column names be? Although column names don’t need to be defined on table creation, you need to know them when you write or read data .
- What information should go into the cells?
- How many versions should be stored for each cell?
设计的时候需要将HBase一些重要的特性考虑到：
- Indexing is only done based on the Key.
- Tables are stored sorted based on the row key. Each region in the table is respon-sible for a part of the row key space and is identified by the start and end row key.The region contains a sorted list of rows from the start key to the end key.
- Everything in HBase tables is stored as a byte[ ]. There are no types.
- Atomicity is guaranteed only at a row level. There is no atomicity guarantee across rows, which means that there are no multi-row transactions.
- Column families have to be defined up front at table creation time.
- Column qualifiers are dynamic and can be defined at write time. They are stored as byte[ ] so you can even put data in them.
不论是上面的7个问题，还是后面的6个特性，基本上在本文或者之前HBase的介绍中都有提到。其实，我个人认为对于这些开源系统的学习分两个方面：一方面学习这些系统如何使用，另一方面也可以学习一下它的设计，很多理念和方法在我们设计自己产品的时候也是可以借鉴的。
References：
- Apache HBase Reference Guide(Version3.0.0-SNAPSHOT).
- HBase:The Definitive Guide.
