这是我参与「第四届青训营 」笔记创作活动的第15天。
HBase概述
HBase是一个构建在HDFS上的分布式列存储系统。HBase是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储。从逻辑上讲，HBase将数据按照表、行和列进行存储。
如图所示，Hbase构建在HDFS之上，hadoop之下。其内部管理的文件全部存储在HDFS中。与HDFS相比两者都具有良好的容错性和扩展性，都可以 扩展到成百上千个节点。但HDFS适合批处理场景，不支持数据随机查找，不适合增量数据处理且不支持数据更新。
Hbase是列存储的非关系数据库。传统数据库MySQL等，数据是按行存储的。其没有索引的查询将消耗大量I/O 并且建立索引和物化视图需要花费大量时间和资源。因此，为了满足面向查询的需求，数据库必须被大量膨胀才能满 足性能要求。
Hbase数据是按列存储-每一列单独存放。列存储的优点是数据即是索引。访问查询涉及的列-大量降低系统I/O 。并且每一列由一个线索来处理，可以实现查询的并发处理。基于Hbase数据类型一致性，可以实现数据库的高效压缩。
架构图
组件介绍
HBase由三种类型的服务器以主从模式构成：
- Region Server：负责数据的读写服务，用户通过与Region server交互来实现对数据的访问。
- HBase HMaster：负责Region的分配及数据库的创建和删除等操作。
- ZooKeeper：负责维护集群的状态（某台服务器是否在线，服务器之间数据的同步操作及master的选举等）。
HDFS的DataNode负责存储所有Region Server所管理的数据，即HBase中的所有数据都是以HDFS文件的形式存储的。出于使Region server所管理的数据更加本地化的考虑，Region server是根据DataNode分布的。HBase的数据在写入的时候都存储在本地。但当某一个region被移除或被重新分配的时候，就可能产生数据不在本地的情况。这种情况只有在所谓的compaction之后才能解决。
HBase 主要特性
HBase包含很多重要的特性，如下：
强一致性读写：HBase并不是最终一致性，而是强一致性的系统，这使得HBase非常适合做高速的聚合操作。
自动sharding：HBase的表在水平方向上以region为单位分布式存储在各个节点上，当region达到一定大小时，就会自动split重新分布数据。
自动故障转移：这是HBase高可用的体现，当某一个节点故障下线时，节点上的region也会下线并会自动转移到状态良好的节点上线。
面向列的存储：HBase是面向列的存储系统，相同特征（列族相同）的数据会被尽量放到一起，这有利于提高数据读取的效率。
无缝结合Hadoop：HBase被定义为Hadoop database，就是基于HDFS做的数据存储，同时原生的支持MapReduce计算引擎。
非常友好的API操作：HBase提供了简单易用的Java API，并且提供了Thrift与REST的API供非Java环境使用。
Block Cache与Bloom Filter：查询优化方面HBase支持Block Cache与Bloom Filter，使得HBase能够对海量数据做高效查询。
HBase数据模型
HBase是基于Google BigTable模型开发的， 典型的key/value系统。一个Row key对应很多Column Family，Column Family中有很多Column。其中，保存了不同时间戳的数据。
如图所示，Rowkey cutting对应列簇info和roles。其中，info中有key-value对hight-9ft，state-CA。更清晰的结构如下图所：
Hbase的所有操作均是基于rowkey的。支持CRUD（Create、Read、Update和Delete）和 Scan操作。 包括单行操作Put 、Get、Scan。多行操作包括Scan和MultiPut。但没有内置join操作，可使用MapReduce解决。
HBase物理模型
Hbase的Table中的所有行都按照row key的字典序排列。Table 在行的方向上分割为多个Region。、Region按大小分割的，每个表开始只有一个region，随 着数据增多，region不断增大，当增大到一个阀值的时候， region就会等分会两个新的region，之后会有越来越多的 region。
Region是HBase中分布式存储和负载均衡的最小单元。 不同Region分布到不同RegionServer上。
Region虽然是分布式存储的最小单元，但并不是存储 的最小单元。Region由一个或者多个Store组成，每个store保存一个 columns family。每个Strore又由一个memStore和0至多个StoreFile组成。memStore存储在内存中，StoreFile存储在HDFS上。
HBase基本架构
HBase构建在HDFS之上，其组件包括 Client、zookeeper、HDFS、Hmaster以及HRegionServer。Client包含访问HBase的接口，并维护cache来加快对HBase的访问。Zookeeper用来保证任何时候，集群中只有一个master，存贮所有Region的寻址入口以及实时监控Region server的上线和下线信息。并实时通知给Master存储HBase的schema和table元数据。HMaster负责为Region server分配region和Region server的负载均衡。如果发现失效的Region server并重新分配其上的region。同时，管理用户对table的增删改查操作。Region Server 负责维护region，处理对这些region的IO请求并且切分在运行过程中变得过大的region。
HBase 依赖ZooKeeper，默认情况下，HBase 管理ZooKeeper 实例。比如， 启动或者停止ZooKeeper。Master与RegionServers 启动时会向ZooKeeper注册。因此，Zookeeper的引入使得 Master不再是单点故障。
Client每次写数据库之前，都会首先血Hlog日志。记录写操作。如果不做日志记录，一旦发生故障，操作将不可恢复。HMaster一旦故障，Zookeeper将重新选择一个新的Master 。无Master过程中，数据读取仍照常进行。但是，无master过程中，region切分、负载均衡等无法进行。RegionServer出现故障的处理原理是定时向Zookeeper汇报心跳，如果一旦时 间内未出现心跳HMaster将该RegionServer上的Region重新分配到其他RegionServer上。失效服务器上“预写”日志由主服务器进行分割并派送给新的 RegionServer 。Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。
寻找RegionServer定位的顺序是ZooKeeper --ROOT-(单Region) -.META. -用户表 。如上图所示。-ROOT- 表包含.META.表所在的region列表，该表只会有一 个Region。 Zookeeper中记录了-ROOT-表的location。 .META. 表包含所有的用户空间region列表，以及 RegionServer的服务器地址。
应用场景
Hbase使用场景1：对象存储
我们知道不少的头条类、新闻类的的新闻、网页、图片存储在HBase之中，一些病毒公司的病毒库也是存储在HBase之中。
Hbase使用场景2：时序数据
HBase之上有OpenTSDB模块，可以满足时序类场景的需求。
Hbase使用场景3：用户画像
特别是用户的画像，是一个比较大的稀疏矩阵，蚂蚁的风控就是构建在HBase之上。
Hbase使用场景4：时空数据
主要是轨迹、气象网格之类，滴滴打车的轨迹数据主要存在HBase之中，另外在技术所有大一点的数据量的车联网企业，数据都是存在HBase之中。
Hbase使用场景5：CubeDB OLAP
Kylin一个cube分析工具，底层的数据就是存储在HBase之中，不少客户自己基于离线计算构建cube存储在hbase之中，满足在线报表查询的需求。
Hbase使用场景6：消息/订单
在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在HBase之上。聊天系统的日志存储。Facebook的在线聊天，每天数据量近百亿。哨兵监控系统，云信历史数据，日志归档数据等一系列重要应用底层都由HBase提供服务。
Hbase使用场景7：Feed
典型的应用就是xx朋友圈类似的应用。
使用案例
Mozilla: Moving Socorro to HBase
