目录
关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce，为什么需要HBase?
Hadoop可以很好地解决大规模数据的离线批量处理问题，但受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求；
HDFS面向批量访问模式，不是随机访问模式；
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）；
传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间；
因此，出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如BigTable和HBase等），HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中。
HBase数据模型
表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族
行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。（访问表中的行只有3种方式：通过单个行键访问；通过一个行键的区间来访问；全表扫描。）
列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
列限定符：列族里的数据通过列限定符（或列）来定位
单元格：通过行、列族、列限定符、时间戳确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引
HBase的实现原理
HBase的实现包括三个主要的功能组件：库函数：链接到每个客户端；一个Master主服务器；许多个Region服务器。
主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡；处理模式变化（如表和列族的创建）
Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求
客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据；HBase客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这使得Master负载很小。
Region的定位
Region标识符：表名+开始主键+RegionId
元数据表(又名.META.表)，存储了Region和Region服务器的映射关系：Region标识符+Region服务器标识
当HBase表很大时， .META.表会被分裂成多个Region
根数据表（又名-ROOT-表），记录所有元数据（即Region和Region服务器的映射关系）的具体位置。-ROOT-表只有唯一一个Region，名字在程序中被写死，Master主服务器永远知道它的位置。Zookeeper文件记录了-ROOT-表的位置。
为了加快访问速度，.META.表的全部Region都会被保存在内存中。
假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目是：
（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）
一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=行，也就是说，一个-ROOT-表可以寻址
个.META.表的Region。同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是128MB/1KB=
。最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) =
个Region
客户端访问数据时的“三级寻址”：为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题；寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器。
HBase运行机制
HBase系统架构
1. 客户端
客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程
2. Zookeeper服务器
Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题。Zookeeper是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。
3. Master
主服务器Master主要负责表和Region的管理工作：管理用户对表的增加、删除、修改、查询等操作；实现不同Region服务器之间的负载均衡；在Region分裂或合并后，负责重新调整Region的分布；对发生故障失效的Region服务器上的Region进行迁移。
4. Region服务器
Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。
Region服务器工作原理
1. 用户读写数据过程
用户写入数据时，被分配到相应Region服务器去执行；数据首先被写入到MemStore和Hlog中；只有当操作写入Hlog之后，commit()调用才会将其返回给客户端；当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找。
2. 缓存的刷新
系统会周期性地调用Region.flushcache()把MemStore缓存里的内容写到磁盘的StoreFile文件中，清空缓存，并在HLog里面写入一个标记；每次刷新都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。
每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再写入StoreFile，最后删除旧的HLog文件，开始为用户提供服务
3. StoreFile的合并
每次刷写都生成一个新的StoreFile，数量太多，影响查找速度；调用Store.compact()把多个合并成一个；合并操作比较耗费资源，只有数量达到一个阈值才启动合并。
Store工作原理
Store是Region服务器的核心。多个StoreFile合并成一个；单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region。
HLog工作原理
Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master；
Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录；
系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器；
Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复；
共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志。