浅谈Hbase与中间的一些设计策略

前面的文章初入Hadoop生态系统里面有涉及到Hbase的一些特点和数据模型，这里来着重谈谈Hbase和其中的一些设计策略。

回顾

Hbase是一个分布式的面向列的开源数据库 rowKey决定Region(区域)，columnFamily(列族)决定HFile，并且由于Hbase的多版本性，不同的HFile也有不同的Timestamp区间，所以在查询时，指定columnFamily将大大提高查询效率，因为决定了读取的HFile个数，如果指定Timestamp也可以进一步对HFile进行过滤。 HFile是Hbase中key-value数据的存储格式。

Hbase的实现包括三个主要功能组件

1. 库函数： 链接到每个客户端。

2. 一个Master主服务器： 主要负责均衡。 管理用户对Table的增删改查等操作

   管理RegionServer的负载均衡，调整Region分布

   在Region Split后负责新的Region的分配 RegionServer停机后，负责失效RegionServer上的Region迁移

3. 多个Region服务器： 负责存储和维护分配给自己的Region，处理客户端的读写。

客户端不需要通过Master，直接通过Zookeeper来获得Region位置信息，然后直接从Region服务器获取数据，这种设计方式使得Master负载小。

Region开始只有一个，后面不断分裂、拆分非常快，原因是拆分时只需要修改指向配置，直到后台启动合并过程把存储文件异步写到独立文件之后，才会读取新文件。是由Master来完成。

Hbase架构

客户端读写数据的过程
缓存的刷新
StoreFile的合并
Store
HLog
BlockCache
数据恢复

Hbase中特殊的两张Table

-ROOT-：
.META.：

目前Region最佳大小建议1GB-2GB，每个Region服务10-1000个Region。

客户端与Hbase交互步骤

多次的网络操作，客户端会做Cache缓存，加速寻址，如图：

表的设计

Hbase主要有两种表设计风格

Flat-Wide表：
Tall-Narrow表：

如果查询模式以scan(扫描)为主可以把表设计成Tall-Narrow类型，如果查询模式以get为主可以把表设计成Flat-Wide类型

scan： 扫描整表，如上所述，如果是Tall-Narrow表，可以考虑在rowkey的设计上考虑，因为scan是可以模糊匹配的。 get： 获取数据，如果是Flat-Wide类型，获取的数据基本上是根据列族来分类的，get可以指定到某个列族以及还可以细化到Timestamp。

行的设计

因为Hbase只能在行键上建立索引，行键结构很重要，所以应该基于预期的访问模式来为行键建模。Hbase表是有序特性，行键是按照字典序存储的，所以基于IO的考虑在设计的时候从两个方面入手

• 为写优化： 牺牲读模式的效率，把数据分散到多个Region上，在大量数据写入的时候，就不会导致像使用时间戳做行键那样遭遇单个Region的热点问题。

  散列：使用MD5等提供随机分布的散列函数。

  salting：时间戳前面加上一个随机数前缀，可以用RegionServer的数量取模来生产随机salt数。(salt方法，就是加点“佐料”)

• 为读优化： 可以使用倒序时间戳(long.Max_value-时间戳)，然后附上用户ID来构成行键，这样就可以基于用户ID扫描N行就能找到用户需要的n条最新信息了。

列族的设计

1. 列族尽量少： 最好不超过三个，每个列族存在一个独立的HFile里，flush和compaction操作都是针对一个Region进行的，当数据很多的列族需要flush的时候，其它列族即使数据很少也需要flush，这样就产生大量不必要的io操作。

   flush,compaction主要起的几个作用是： 合并文件--清除过期多余版本的数据--提高读写效率。

2. 多列族时： 注意各列族数据的数量级要一致，如果相差太大，会使数量级少的列族的数据扫描效率低。

3. 针对查询： 将经常查询和不经常查询的数据放在不同的列族，根据实际情况来划分，也体现Hbase的反规范化。

4. 取名： 尽可能短，列族和列的名字会存在Hbase的每个cell中。 cell：通过row和columns确定的为一个存储单元称为cell。每个cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是64位整型。

常用集群配置

Hbase生产集群不应该少于10个节点

小型生产集群(10-20台服务器)

一个HbaseMaster，一个Zookeeper就可以了，并且可以部署在一块

中型(50台以下)

把NameNode和JobTracker分开部署到不同的机器，建议部署3个Master，3个Zookeeper

大型(50台以上)

5个Zookeeper，其它和中型方式相同