什么是HBase？

1.HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库 

2. HBASE是Google Bigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable使用GFS作为其文件存储系统，HBASE利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBASE同样利用Hadoop MapReduce来处理HBASE中的海量数据；Google Bigtable利用Chubby作为协同服务，HBASE利用Zookeeper作为协同服务。

3.HBase是一个分布式存储、数据库引擎，可以支持千万的QPS、PB级别的存储，这些都已经在生产环境验证，并且在广大的公司已经验证。特别是阿里（淘宝、天猫、蚂蚁金服）、小米米聊、小米云、小米推送服务）、京东、滴滴内部都有数千、上万台的HBase集群。Hbase PMC。阿里1个。 Hbase Committer。阿里4个，小米4个。 2016年双11，HBase承载访问量达到了上百GB/秒(写入)与上百GB/秒(读取)，相当于全国人民一秒收发一条短信，在业务记录、安全风控、实时计算、日志监控、消息聊天等多个场景发挥重要价值。

1.存储数据量大：一个表可以有上亿行，上百万列。

2.面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。

3.稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。

4.无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。

5.数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。

6.数据类型单一：HBase中的数据都是字符串，没有类型。

    MySQL：关系型数据库，主要面向OLTP（面向交易的处理过程），支持事务，支持二级索引，支持sql，支持主从、支持存储引擎）。

HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql, 不支持条件查询和Order by等查询。

1.数据存储方式

MySQL中要提前定义表结构，也就是说表共有多少列（属性）需要提前定义好，并且同时需要定义好每个列所占用的存储空间。数据以行为单位组织在一起的，假如某一行的某一列没有数据，也需要占用存储空间。

HBase则是以列为单位存储数据，每一列就是一个key-value，HBase的表列（属性）不用提前定义，而且列可以动态扩展，比如人员信息表中需要添加一个新的“address”字段，MySQL需要提前alter表，HBase的话直接插入即可。

2. 数据类型：

HBase只有简单的字符类型，它只保存字符串。而关系数据库有丰富的类型和存储方式。

3. 数据操作：

HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作。  

  4.超大数据量

        当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

     1.Row Key:可以看成表中每条记录的主键，方便快速查找。

2.Column family：拥有一个名称，包含一个或多个相关的列称为列族。

3.Column：属于某一个Column family，包含在某一列中。

4.Cell：通过Row Key、Column family和Column 可以定位到该cell。

5.Version number：cell 中存放了多个版本的内容，每个row key 唯一，默认系统时间戳

1.Client：使用HBase RPC机制与HMaster和HRegionServer进行通信

Client与HMaster进行管理类操作

Client与HRegionServer进行数据读写类操作也可以看做是整个HBase集群的入口

2.Master：主要负责Table和Region的管理工作：

管理用户对表的增删改查操作

管理HRegionServer的负载均衡，调整Region分布

Region Split后，负责新Region的分布

在HRegionServer停机后，负责失效HRegionServer上Region迁移。

3.Zookeeper：维护HBase集群，Master与RegionServers启动时会向Zookeeper注册。集群内可以有多个Master，但是ZK保证只有一个对外提供服务，其他做Stand by，出现宕机有相应的选举机制选出新Master

4.Region Server：对于一个RegionServer而言，其包括了多个Region。RegionServer的作用是维护Master分配给他的region，以及实现读写IO操作。Client通过ZK寻址，最终也是直接连接RegionServer实现读取数据。

5.Region：table在行的方向上分隔为多个region，不同的region可以分别在不同的Region Server上。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值时就会分成两个新的region。

对Region的解析：

(1)Store：每一个region由一个或多个store组成，一个store存放一个列族，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者 多个StoreFile组成。HBase以store的大小来判断是否需要切分region。

(2)MemStore：存放在内存中，保存修改的数据。当memStore的大小达到一个阀值（默认128MB）时，memStore会被flush到StoreFile。

(3)StoreFile：MemStore快照后存储在StoreFile中，其底层是以HFile的格式保存。

(4)HFile：HFile是Hadoop的二进制格式文件，就是按照一定的结构存储信息。

(5)HLog(WAL log)：WAL意为write ahead log，用来做灾难恢复使用。每个RegionServer中都会有一个HLog的实例，会将RegionServer的所有更新操作记录在HLog中，一旦regionServer宕机，就可以从log中进行恢复。

HBase基本体系架构从宏观上理解：Client作为API接口，访问HBase；Master是整个集群的大脑，负责维护RegionServer；RegionServer管理若干个Region，并实现与Client的数据通信；Region是逻辑上分布式存储和负载均衡的最小单元；Zookeeper实现对集群的监护和HA。

从微观上理解Region，一个table会至少有一个Region，随着数据量的增大，Region实现分裂。Region内部由多个Store构成，每个Store存储一个列族。Store又由MemStore、StoreFile构成，MemStore内存写到一定程度后落磁盘到StoreFile。

1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息；

2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer；

3) 通过RegionServer获取需要查找的数据；

4) RegionServer的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

寻址过程：client—>Zookeeper—>ROOT表—>.META. 表—>RegionServer—>Region—>client