前言
前面的文章初入Hadoop生态系统里面有涉及到Hbase的一些特点和数据模型，这里来着重谈谈Hbase和其中的一些设计策略。
回顾
Hbase是一个分布式的面向列的开源数据库
rowKey决定Region(区域)，columnFamily(列族)决定HFile，并且由于Hbase的多版本性，不同的HFile也有不同的Timestamp区间，所以在查询时，指定columnFamily将大大提高查询效率，因为决定了读取的HFile个数，如果指定Timestamp也可以进一步对HFile进行过滤。
HFile是Hbase中key-value数据的存储格式。
Hbase的实现包括三个主要功能组件
库函数：链接到每个客户端。一个Master主服务器：主要负责均衡。
管理用户对Table的增删改查等操作
管理RegionServer的负载均衡，调整Region分布
在Region Split后负责新的Region的分配
RegionServer停机后，负责失效RegionServer上的Region迁移多个Region服务器：负责存储和维护分配给自己的Region，处理客户端的读写。
客户端不需要通过Master，直接通过Zookeeper来获得Region位置信息，然后直接从Region服务器获取数据，这种设计方式使得Master负载小。
Region开始只有一个，后面不断分裂、拆分非常快，原因是拆分时只需要修改指向配置，直到后台启动合并过程把存储文件异步写到独立文件之后，才会读取新文件。是由Master来完成。
Hbase架构
客户端读写数据的过程
用户写入数据时，被分配到相应Region服务器去执行，首先先写入到Memstore和HLog中，只有写入到HLog之后commit()调用才会将其返回给客户端。
用户取数据时，Region服务器会首先访问Memstore缓存，如果找不到，再取磁盘上面的StoreFile中寻找。缓存的刷新
系统周期性把Memstore缓存里的内容写到磁盘的StoreFile文件中，清空缓存，并在HLog里面写入一个标记，每次刷新都生产新的StoreFile文件，每个Store包含多个StoreFile文件。
每个Region服务器都有一个自己的HLog文件，每次启动都检查文件，确定最新操作，如发生更新，先写入Memstore，再刷写到StoreFile，最后删除旧的HLog文件，开始为用户提供服务。StoreFile的合并
每次刷写都生成一个新的StoreFile，数量太多影响查找速度，调用Store.compact()把多个合并成一个，合并操作比较耗费资源，只有数量达到一个阀值才启动合并。Store
Store是Region服务器的核心，多个StoreFile合并成一个，单个StoreFile过大时又触发分裂操作。HLog
分布式环境必须要考虑系统出错，Hbase采用HLog保证系统恢复，每个Region服务器配置一个，共享日志的优点能够提高对表的写操作性能，缺点是恢复时需要拆分日志。BlockCache
HBase中最小的数据存储单元Block，默认为64K，BlockCache也称为读缓存，HBase会将一次文件查找的Block块缓存到Cache中，以便后续同一请求或者邻近数据查找请求直接从内存中获取，避免昂贵的IO操作。
BlockCache有两种实现机制：LRUBlockCache(基于LRU做了分层设计)和BucketCache数据恢复
Zookeeper实时监测每个Region服务器的状态，当某个发生故障时，Zookeeper会通知Master，Master首先处理该故障Region服务器上面遗留的HLog文件，这个文件包含了来自多个Region对象的日志记录，系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，放到相应Region对象的目录下，再将失效的Region重新分配到可用的Region服务器中，并将该Region相关日志记录HLog也发送给相应的Region服务器，Region服务器领取到分配的Region与之相关的HLog日志记录后会重新做一遍日志记录中的各种操作写入MemStore缓存，刷新到StoreFile文件中，完成数据恢复。
Hbase中特殊的两张Table
-
-ROOT-：记录.META.表的Region信息，只有一个区域(Region) -
.META.：记录用户表的Region信息，可以有多个区域(Region)
目前Region最佳大小建议1GB-2GB，每个Region服务10-1000个Region。
客户端与Hbase交互步骤
多次的网络操作，客户端会做Cache缓存，加速寻址，如图：
表的设计
Hbase主要有两种表设计风格
-
Flat-Wide表：一行中有很多列
hbase只能在行的边界做split，所以行不可拆分，所以设计细节在于列族。 -
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条最新信息了。
列族的设计
列族尽量少：最好不超过三个，每个列族存在一个独立的HFile里，flush和compaction操作都是针对一个Region进行的，当数据很多的列族需要flush的时候，其它列族即使数据很少也需要flush，这样就产生大量不必要的io操作。
flush,compaction主要起的几个作用是：
合并文件--清除过期多余版本的数据--提高读写效率。多列族时：注意各列族数据的数量级要一致，如果相差太大，会使数量级少的列族的数据扫描效率低。针对查询：将经常查询和不经常查询的数据放在不同的列族，根据实际情况来划分，也体现Hbase的反规范化。取名：尽可能短，列族和列的名字会存在Hbase的每个cell中。
cell：通过row和columns确定的为一个存储单元称为cell。每个cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是64位整型。
性能优化
前面有提到关于针对表、行、列族的设计优化规范，下面讲讲一些其它设计的优化方式；
-
In Memory：建表时，通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。 -
Max Version：建表时，通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。 -
Time To Live：建表时，通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除。
关于其它的一些配置性能调优的方式建议查看相关文案结合实际情况来设置，这里就不一一阐述了。
性能监控(工具)
- Master Status(自带)：服务端口默认是60010
- Ganglia：是UC Berkeley发起的一个开源集群监视项目，用于监控系统性能
- OpenTSDB：可以从大规模集群中获取相应的metrics(metric就是1个监控项，譬如服务器的话，会有CPU使用率、内存使用率这些metric)并进行存储、索引及服务
- Ambari：作用就是创建、管理、监视Hadoop集群
Hbase上构建SQL引擎
- 使用Hive整合HBase，利用两者对外的API接口互相通信，注意版本一致性
- Phoenix，由saleforce开源的一个项目，构建在HBase上的一个SQL层，能让我们用标准的JDBC APIs而不是HBase客户端APIs来创建表，插入数据和对HBase数据进行查询。
构建Hbase二级缓存
hbase只有一个针对行键的索引，访问只有三种方式；
- 通过单个行键访问
- 通过一个行键的区间来访问(前面说的Rowkey模糊匹配)
- 全表扫描
可以使用其它产品为Hbase行键提供索引功能，来提高查询的效率。
- Redis：redis做客户端缓存，将索引实时更新到redis中，定时更新索引到Hbase的表中
- solr：solr中保存索引
- Hindex：华为公司研发的，特性是多个表索引、多个列索引、基于部分列值索引
- Coprocessor：Hbase0.92版本之后引入的特性，提供了两个实现
- Endpoint Coprocessor：相当于关系型数据库的存储过程
- Observer Coprocessors：相当于触发器，Observer允许在记录put前后做一些处理，因此可以在插入数据时同步写入索引表，缺点是每插入一条需要向索引表插入数据，因此耗时双倍，集群压力也是双倍
常用集群配置
Hbase生产集群不应该少于10个节点
小型生产集群(10-20台服务器)
一个HbaseMaster，一个Zookeeper就可以了，并且可以部署在一块
中型(50台以下)
把NameNode和JobTracker分开部署到不同的机器，建议部署3个Master，3个Zookeeper
大型(50台以上)
5个Zookeeper，其它和中型方式相同
结语
有很多还不够完善，未完待续吧~~~
个人博客~
~