1.概述
- HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳。 每个值是一个未经解释的字符串，没有数据类型。
- 用户在表中存储数据，每一行都有一个可排序的行键和任意多的列。
- 表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。
- 列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储。因此对于整个映射表的每行数据而言，有些列的值是空的，所以说HBase是稀疏的。
- HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）。
2.相关概念
表 ：一个表由行和列组成，列划分为若干列族
行 ：每张表由若干行组成，每个行由行键标识
列族 ：一张表是许多列族的集合，是基本的访问控制单元。表中的每个列都属于某一列族。
列限定符 ：列族中的数据通过限定符或列来定位。
单元格 ：单元格存储的数据没有数据类型，总被视为字节数组。通过行、列族、列限定符定位一个单元格。
时间戳 ：每个单元格都保存着同一份数据的不同版本，并采用时间戳索引。
3.数据坐标
该数据库中使用行键、列族、列限定符和时间戳确定一个单元格的值，可以视为一个四维坐标：[行键, 列族, 列限定符, 时间戳]
4.概念视图
HBase是按照行键的字典序排序数据的。
可以看出，在一个HBase表的概念视图中，每个行都包含相同的列族，尽管行不需要在每个列族里存储数据。从这个角度来说，HBase表是一个稀疏的映射关系，即里面存在很多空的单元格。
5.物理视图
从概念视图层面，HBase中的每个表是许多行组成的，但是在物理存储层面，它采用基于列的存储方式，而不是像传统关系数据库那样采用基于行的存储方式，
6.实现原理
①功能组件：库函数（用于连接到每个客户端）、一个Master主服务器、许多个Region服务器。
主服务器Master：负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡。
Region服务器：负责存储和维护分配给自己的Region，处理来自客户端的读写请求。
客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据。
客户端并不依赖Master，而是通过Zookeeper获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小 。
②表和region
根据行键的值对表中的行进行分区。每个行区间构成一个分区，被称为Region。Region包含了位于某个值域区间内的所有数据，是负载均衡和数据分发的基本单位
③region定位
每个Region都有一个RegionID来标识它的唯一性，这样，一个Region标识符就可以表示成表名＋开始主键+RegionID。
7.运行机制
包括HBase系统架构以及Region服务器、Store和HLog的工作原理。
1.系统架构：
**客户端：**包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程。
**Zookeeper服务器：**可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的"单点失效"问题。
**Master服务器：**主服务器Master主要负责表和Region的管理工作。
**Region服务器：**Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。
2.region工作原理
①用户读写数据：
用户写入数据时，被分配到相应Region服务器去执行
用户数据首先被写入到MemStore和Hlog中
只有当操作写入Hlog之后，调用commit() 方法才会将其返回给客户端
当用户读取数据时， Region服务器会首先访问MemStore缓存，如果找不到，再到磁盘的StoreFile中寻找
②缓存的刷新
系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
每个Region服务器都有一个自己的HLog文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务
③StoreFile的合并
每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
调用Store.compact()把多个StoreFile合并成一个
合并操作比较耗费资源，只有数量达到一定阈值后才会启动合并
3.Store工作原理
Store是Region服务器的核心
多个StoreFile合并成一个StoreFile
单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region
4.HLog工作原理
HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）。
用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘后，该缓存内容才能被刷写到磁盘。
Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。
Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。
系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器。
Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复。
共用日志的优点是提高对表的写操作性能；其缺点是恢复时需要分拆日志。
5.HBase性能优化
行键（Row Key）： 行键是按照字典序存储。因此，设计行键时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。例如：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为行键的一部分 。
InMemory：创建表的时候，可将表放到Region服务器的缓存中，保证在读取的时候被cache命中。
Max Version：创建表的时候，可设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。
Time To Live：创建表的时候，可设置表中数据的存储生命期，过期数据将自动被删除。