HBase是一种构建在HDFS之上的分布式、面向列的存储系统，适用于实时读写、随机访问超大规模数据的集群。
HBase的特点
大：一个表可以有上亿行，上百万列。
面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
数据类型单一：HBase中的数据都是字符串，没有类型。
HBase的高并发和实时处理数据
Hadoop是一个高容错、高延时的分布式文件系统和高并发的批处理系统，不适用于提供实时计算；
HBase是可以提供实时计算的分布式数据库，数据被保存在HDFS分布式文件系统上，由HDFS保证期高容错性，但是再生产环境中，HBase是如何基于hadoop提供实时性呢？ HBase上的数据是以StoreFile(HFile)二进制流的形式存储在HDFS上block块儿中；但是HDFS并不知道的hbase存的是什么，它只把存储文件是为二进制文件，也就是说，hbase的存储数据对于HDFS文件系统是透明的。下面是HBase文件在HDFS上的存储示意图。
从根本上说，HBase能提供实时计算服务主要原因是由其架构和底层的数据结构决定的，即由LSM-Tree + HTable(region分区) + Cache决定——客户端可以直接定位到要查数据所在的HRegion server服务器，然后直接在服务器的一个region上查找要匹配的数据，并且这些数据部分是经过cache缓存的。具体查询流程如下图所示：
具体数据访问流程如下：
Client会通过内部缓存的相关的-ROOT-中的信息和.META.中的信息直接连接与请求数据匹配的HRegion server；
然后直接定位到该服务器上与客户请求对应的Region，客户请求首先会查询该Region在内存中的缓存——Memstore(Memstore是一个按key排序的树形结构的缓冲区)；
如果在Memstore中查到结果则直接将结果返回给Client；
在Memstore中没有查到匹配的数据，接下来会读已持久化的StoreFile文件中的数据。前面的章节已经讲过，StoreFile也是按 key排序的树形结构的文件——并且是特别为范围查询或block查询优化过的，；另外HBase读取磁盘文件是按其基本I/O单元(即 HBase Block)读数据的。
HBase数据模型
Row Key
与 NoSQL 数据库一样，Row Key 是用来检索记录的主键。访问 HBase table 中的行，只有三种方式：1)通过单个 Row Key 访问。
2)通过 Row Key 的 range 全表扫描。
3)Row Key 可以使任意字符串（最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes），在HBase 内部，Row Key 保存为字节数组。
列族
HBase 表中的每个列都归属于某个列族。列族是表的 Schema 的一部分（而列不是），必须在使用表之前定义。列名都以列族作为前缀，例如 courses:history、courses:math 都属于 courses 这个列族。
时间戳
HBase 中通过 Row 和 Columns 确定的一个存储单元称为 Cell。每个 Cell 都保存着同一份数据的多个版本。 版本通过时间戳来索引，时间戳的类型是 64 位整型。时间戳可以由HBase（在数据写入时自动）赋值， 此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显示赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 Cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
Cell
Cell 是由 {row key，column(=< family> + < label>)，version} 唯一确定的单元。Cell 中的数据是没有类型的，全部是字节码形式存储。
HBase物理存储
Table 在行的方向上分割为多个HRegion，每个HRegion分散在不同的RegionServer中。
每个HRegion由多个Store构成，每个Store由一个memStore和0或多个StoreFile组成，每个Store保存一个Columns Family
HBase系统架构
从HBase的架构图上可以看出，HBase中的组件包括Client、Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，接下来介绍他们的作用。
HBase中的每张表都通过行键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过256M就要被分割成两个，这个过程由HRegionServer管理，而HRegion的分配由HMaster管理。
Client
包含访问HBase的接口，并维护cache来加快对HBase的访问。
Zookeeper的作用
HBase依赖Zookeeper，默认情况下HBase管理Zookeeper实例(启动或关闭Zookeeper),Master与RegionServers启动时会向Zookeeper注册。
Zookeeper的作用：
保证任何时候，集群中只有一个master
存储所有Region的寻址入口
实时监控Region server的上线和下线信息。并实时通知给master
存储HBase的schema和table元数据
HMaster的作用
为Region server分配region
负责Region server的负载均衡
发现失效的Region server并重新分配其上的region。
HDFS上的垃圾文件回收。
处理schema更新请求。
HRegionServer的作用
维护master分配给他的region，处理对这些region的io请求。
负责切分正在运行过程中变的过大的region。
注意：client访问hbase上的数据时不需要master的参与，因为数据寻址访问zookeeper和region server，而数据读写访问region server。master仅仅维护table和region的元数据信息，而table的元数据信息保存在zookeeper上，因此master负载很低。
HRegion
table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。
Region按大小分隔，每个表一般是只有一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。
每个region由以下信息标识：
< 表名,startRowkey,创建时间>
由目录表(-ROOT-和.META.)记录该region的endRowkey
Region被分配给哪个Region Server是完全动态的，所以需要机制来定位Region具体在哪个region server。
Store
每一个region由一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个 ColumnFamily建一个store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者 多个StoreFile组成。 HBase以store的大小来判断是否需要切分region
MemStore
memStore 是放在内存里的。保存修改的数据即keyValues。当memStore的大小达到一个阀值（默认64MB）时，memStore会被flush到文 件，即生成一个快照。目前hbase 会有一个线程来负责memStore的flush操作。
StoreFile
memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。
HLog
HLog(WAL log)：WAL意为write ahead log，用来做灾难恢复使用，HLog记录数据的所有变更，一旦region server 宕机，就可以从log中进行恢复。
HLog文件就是一个普通的Hadoop Sequence File， Sequence File的value是key时HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。 Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。
LogFlusher
前面提到，数据以KeyValue形式到达HRegionServer，将写入WAL之后，写入一个SequenceFile。看过去没问题，但是因为数 据流在写入文件系统时，经常会缓存以提高性能。这样，有些本以为在日志文件中的数据实际在内存中。
这里，我们提供了一个LogFlusher的类。它调用 HLog.optionalSync(),后者根据 hbase.regionserver.optionallogflushinterval (默认是10秒)，定期调用Hlog.sync()。另外，HLog.doWrite()也会根据
hbase.regionserver.flushlogentries (默认100秒)定期调用Hlog.sync()。Sync() 本身调用HLog.Writer.sync()，它由SequenceFileLogWriter实现。
LogRoller
Log的大小通过$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默认是一个小时。所以每60分钟，会打开一个新的log文件。久而久之，会有一大堆的文件需要维护。首先，LogRoller调用 HLog.rollWriter()，定时滚动日志，之后，利用HLog.cleanOldLogs()可以清除旧的日志。它首先取得存储文件中的最大的 sequence number，之后检查是否存在一个log所有的条目的“sequence
number”均低于这个值，如果存在，将删除这个log。 每个region server维护一个HLog，而不是每一个region一个，这样不同region（来自不同的table）的日志会混在一起，这样做的目的是不断追加 单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高table的写性能。带来麻烦的时，如果一个region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其他region server上进行恢复。
HBase工作流程
Client
首先当一个请求产生时，HBase Client使用RPC(远程过程调用)机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC;对于数据读写操作，Client与HRegionServer进行RPC。
Zookeeper
HBase Client使用RPC(远程过程调用)机制与HMaster和HRegionServer进行通信，但如何寻址呢？由于Zookeeper中存储了-ROOT-表的地址和HMaster的地址，所以需要先到Zookeeper上进行寻址。
HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点故障。
HMaster
当用户需要进行Table和Region的管理工作时，就需要和HMaster进行通信。HBase中可以启动多个HMaster,通过Zookeeper的Master Eletion机制保证总有一个Master运行。
管理用户对Table的增删改查操作
管理HRegionServer的负载均衡，调整Region的分布
在Region Split后，负责新Region的分配
在HRegionServer停机后，负责失效HRegionServer上的Regions迁移
HRegionServer
当用户需要对数据进行读写操作时，需要访问HRegionServer。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列族创建一个Store实例，每个Store都会有一个 MemStore和0个或多个StoreFile与之对应，每个StoreFile都会对应一个HFile， HFile就是实际的存储文件。因此，一个HRegion有多少个列族就有多少个Store。 一个HRegionServer会有多个HRegion和一个HLog。
当HStore存储是HBase的核心了，其中由两部分组成：MemStore和StoreFiles。 MemStore是Sorted Memory Buffer,用户
写入数据首先 会放在MemStore,当MemStore满了以后会Flush成一个 StoreFile（实际存储在HDHS上的是HFile），当StoreFile文件数量增长到一定阀值，就会触发Compact合并操作，并将多个StoreFile合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的 读写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。
HBase Put流程
下面是put流程的时序图：
客户端：
客户端发起Put写请求，讲put写入writeBuffer，如果是批量提交，写满缓存后自动提交
根据rowkey将put吩咐给不同regionserver
服务端：
RegionServer将put按rowkey分给不同的region
Region首先把数据写入wal
wal写入成功后，把数据写入memstore
Memstore写完后，检查memstore大小是否达到flush阀值
如果达到flush阀值，将memstore写入HDFS，生成HFile文件
HBase Compact &&Split
当StoreFile文件数量增长到一定阀值，就会触发Compact合并操作，并将多个StoreFile合并成一个StoreFile，当这个StoreFile大小超过一定阀值后，会触发Split操作，同时把当前Region Split成2个Region,这是旧的Region会下线，新Split出的2个Region会被HMaster分配到相应的HregionServer上，使得原先1个Region的压力得以分散到2个Region上。
如下图四个Storefile文件（从memstore文件经过flush而得到，默认64M的storefile文件）经过Compact合并成一个大的256M storefile文件，当设定的Region阀值为128M时，就会Split为两个128M的Storefile文件，然后HMaster再把这两个storefile文件分配到不停地Regionserver上。
HFile
HBase中所有的数据文件都存储在Hadoop HDFS上，主要包括两种文件类型：
Hfile:HBase中KeyValue数据的存储格式，HFile是Hadoop的 二进制格式文件，实际上StoreFile就是对Hfile做了轻量级包装，即StoreFile底层就是HFile
HLog File:HBase中WAL(write ahead log)的存储格式，物理上是Hadoop的Sequence File
HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。
Trailer中有指针指向其他数据块的起始点，FileInfo记录了文件的一些meta信息。 Data Block是hbase io的基本单元，为了提高效率，HRegionServer中有基于LRU的block cache机制。
每个Data块的大小可以在创建一个Table的时候通过参数指定（默认块大小64KB），大号的Block有利于顺序Scan，小号的 Block利于随机查询。
每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成，Magic内容就是一些随机数字，目的是防止数 据损坏，结构如下。
上图可知，开始是两个固定长度的数值，分别表示key的长度和alue的长度。紧接着是Key,开始是固定长度的数值，表示RowKey的长度，紧接着是RowKey，然后是固定长度的数值，表示Family的长度，然后是Family,接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type(Put/Delete)。Value部分没有那么复杂的结构，就是纯粹的二进制数据。
优化HBase支撑系统
(1)硬件选择
总的原则是，根据业务情况和集群规模大小选择合理的硬件。
(2)网络配置
基于当前阶段硬件的典型分布式系统都会受到网络的限制，HBase也不例外。在节点和机架顶置交换机之间建议采用10Gb以太网交换机。千万不要过于满额配置地使用网络，否则在高负载时，会影响HBase应用系统的性能。
(3)操作系统
一般情况下，只要使用Hadoop和HBase，操作系统通常选择Linux。可以选择Red Hat Enterprise Linux，CentOS，也可以选择成功部署过的其他操作系统。
(4)本地文件系统
本地Linux文件系统在HBase集群体系里起到了重要作用，并且严重影响到HBase的性能。虽然EXT4是推荐使用的本地文件系统，但没有大规模使用，相反EXT3和XFS已经在生产系统里得到成功使用，建议使用EXT3和XFS作为本地文件系统。
(5)HDFS
根据业务访问特点优化
根据业务访问特点，将Hbase的工作负载大致分为以下四类：
(1)随机读密集型
对于随机读密集型工作负载，高效利用缓存和更好地索引会给HBase系统带来更高的性能。
(2)顺序读密集型
对于顺序读密集型工作负载，读缓存不会带来太多好处；除非顺序读的规模很小并且限定在一个特定的行键范围内，否则很可能使用缓存会比不使用缓存需要更频繁地访问硬盘。
(3)写密集型
写密集型工作负载的优化方法需要有别于读密集型负载。缓存不再起到重要作用。写操作总是进入MemStore，然后被刷写生成新的Hfile，以后再被合并。获得更好写性能的办法是不要太频繁刷写、合并或者拆分，因为在这段时间里IO压力上升，系统会变慢
(4)混合型
对于完全混合型工作负载，优化方法会变得复杂些。优化时，需要混合调整多个参数来得到一个最优的组合。
其它角度来优化HBase性能
(1)JVM垃圾回收优化
(2)本地memstore分配缓存优化
(3)Region拆分优化
(4)Region合并优化**
(5)Region预先加载优化
(6)负载均衡优化
(7)启用压缩
(8)GZIP、snappy、lzo，推荐snappy,压缩比稍差于lzo；但是压缩速度高于lzo,并且与lzo有差不多的 解压缩速度。
（9）进行预分区，从而避免自动split，提高hbase响应速度
（10）避免出现region热点现象，启动按照table级别进行balance