HBase应用场景、原理与基本架构

一、为什么使用HBase？

       传统的RDBMS关系型数据库（例如SQL）存储一定量数据时进行数据检索没有问题，可当数据量上升到非常巨大规模的数据（TB或PB）级别时，传统的RDBMS已无法支撑，这时候就需要一种新型的数据库系统更好更快的处理这些数据。我们可以选择HBase。 

二、HBase概述

       HBase（Hadoop Database）是一个开源的、面向列（Column-Oriented）、适合存储海量非结构化数据或半结构化数据的、具备高可靠性、高性能、可灵活扩展伸缩的、支持实时数据读写的分布式存储系统。

       它是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储。从逻辑上讲，HBase将数据按照表、行和列进行存储。

2.1 HBase与HDFS比较

        HBase与HDFS两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点。但是，HDFS适合批处理的场景，它不支持数据随机查找，不支持增量数据处理，不支持数据更新。

2.2 HBase表的特点

        1）大：一个表可以有数十亿行，上百万列；

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

        3）面向列：面向列（族）的存储和权限控制，列（族）独立检索；

        4）稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏；

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

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

2.3 行存储与列存储的比较

        行存储：数据是按行存储的的；没有索引的查询使用大量I/O；建立索引和物化视图需要花费大量的时间和资源；面向查询的需求，数据库必须被大量膨胀才能满足性能要求。

        列存储：数据是按每一列单独存放；数据即是索引；大量降低系统I/O；每一列由一个线索来处理（查询的并发处理）；数据类型一致，数据特征相似（高效压缩）。

三、HBase数据模型

        HBase是基于Google BigTable模型开发的，典型的key/value系统。

3.1 HBase的基本概念

        Row Key（行键）：表中每条记录的“主键”，方便快速查找；

        Column Family（列族）：拥有一个名称，包含一个或多个相关列；

        Column：属于某一个Column Family，包含在某一个列中；

        Version Number（版本）：HBase能够为一个单元格元组（行、列族和列）保存多个值，每个单元格被称为一个记录的版本。默认值为系统的时间戳，类型为Long。默认情况下，HBase保留3个版本的记录。当然，我们也可以改变保留版本的数量，我们也可以通过制定来获取某个特定的版本。

        时间戳：对于每个插入的数据，当前的时间戳与值是相关的，它表示了数值插入到表中的时间。

        单元格：最小或基本的存储单位，在内部是一个列的实际值存储。所以插单元格数据时必须包含RowKey + ColumnFamily（列族名）+ ColumnName（列名）+ timeStamp：value。

 

        HBase schema可以有多个Table，每一个表可以有多个Column Family组成，HBase可以有Dynamic Column（列名称是编码在cell中的，不同cell可以有不同的列），version number可由用户提供，无需以递增的顺序插入，每一行的Row Key必须是唯一的，Table可能是非常稀松的，很多的cell可以是空的。

3.2 HBase支持的操作

        1）所有的操作均是基于Row Key的；

        2）支持CRUD（Create、Read、Update、Delete）和Scan；

        3）单行操作：Put、Get、Scan；

        4）多行操作：Scan、MultiPut；

        5）没有内置的join操作，可以使用MapReduce解决。

四、HBase物理模型

         每一个Column Family存储在HDFS上的一个单独文件中；Key和Version Number在每个Column Family中均有一份，空值不会保存。

4.1 物理存储

         1）Table中的所有行都按照Row Key的字典序排列；

         2）Table在行的方向上分割为多个Region；

         3）Region按大小分割的，每个表开始只有一个Region，随着数据增多，Region不断增大，当增大到一个阀值的时候，Region就会等分为两个新的Region，之后就会有越来越多的Region；

        4）Region是HBase中分布式存储和负载均衡的最小单元。不同的Region分布到不同的RegionServer上；

        5）Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或多个Store组成，每个store保存一个Column Family，每一个Store又有一个memStore和0至多个StoreFile组成，memStore存储在内存中，StoreFile存储在HDFS上。

五、HBase架构

5.1 HBase基本组件

1）Client

        包含访问HBase的接口，并维护cache来加快对HBase的访问。

2）Zookeeper

       保证任何时候，集群中只有一个master；存储所有Region的寻址入口；实时监控Region Server的上线和下线信息，并实时的通知给Master；存储HBase的schema和table的元数据。

3）Master

      为Region Server分配Region；负责Region Server的负载均衡；发现失效的Region Server并重新分配其上的Region；管理用户对table的增删改查操作。

4）Region Server

        Region Server维护Region，处理对这些Region的IO请求；Region Server负责切分在运行过程中变得过大的Region。

5.2 Zookeeper作用

      HBase依赖zookeeper，默认情况下，HBase管理zookeeper实例；Master与RegionServer启动时会向zookeeper注册；zookeeper的引入是的Master不再是单点故障。

5.3 Write-Ahead-Log

5.4 HBase容错性

1）Master容错：zookeeper重新选择一个新的Master

       无Master过程中，数据读取仍照常进行，Region切分、负载均衡等无法进行。

2）RegionServer容错：定时向zookeeper汇报心跳，如果一旦一定时间内未出现心跳

      Master将该RegionServer上的Region重新分配到其他RegionServer上；失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer。

3）zookeeper容错：zookeeper是一个可靠的服务

       一般配置3或5个zookeeper实例。

5.5关系数据库与HBase比较

5.6 HBase与Hadoop比较