什么是HBase？

 HBase 介绍

 

  1、什么是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/秒(读取)，至关于全国人民一秒收发一条短信，在业务记录、安全风控、实时计算、日志监控、消息聊天等多个场景发挥重要价值。

   2、哪些是HBase的特色？

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

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

3.稀疏：对于为空（NULL）的列，并不占用存储空间，所以，表能够设计的很是稀疏。

4.无模式：每一行都有一个能够排序的主键和任意多的列，列能够根据须要动态增长，同一张表中不一样的行能够有大相径庭的列。

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

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

   3、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）。

4、HBase基本术语的理解

     1.Row Key:能够当作表中每条记录的主键，方便快速查找。

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

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

4.Cell：经过Row Key、Column family和Column 能够定位到该cell。

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

 

5、HBase的体系架构都有哪几部分？

 

 

 

 

 

 

 

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