大数据学习之HBase——01Hbase基础

一. Hbase简介

1. 什么是Hbase

HBase 是 BigTable 的开源（源码使用 Java 编写）版本。是 Apache Hadoop 的数据库，是建 立在 HDFS 之上，被设计用来提供高可靠性、高性能、列存储、可伸缩、多版本的 NoSQL 的分布式数据存储系统，实现对大型数据的实时、随机的读写访问。

HBase 依赖于 HDFS 做底层的数据存储，BigTable 依赖 Google GFS 做数据存储

HBase 依赖于 MapReduce 做数据计算，BigTable 依赖 Google MapReduce 做数据计算

HBase 依赖于 ZooKeeper 做服务协调，BigTable 依赖 Google Chubby 做服务协调

NoSQL = NO SQL
NoSQL = Not Only SQL：会有一些把 NoSQL 数据的原生查询语句封装成 SQL，比如 HBase 就有 Phoenix 工具

2. Hbase数据库的特点

1. 它介于 NoSQL 和 RDBMS 之间，仅能通过主键(rowkey)和主键的 range 来检索数据

2. HBase 查询数据功能很简单，不支持 join 等复杂操作

3. 不支持复杂的事务，只支持行级事务(可通过 hive 支持来实现多表 join 等复杂操作)。

4. HBase 中支持的数据类型：byte[]（底层所有数据的存储都是字节数组）

5. 主要用来存储结构化和半结构化的松散数据。

   结构化、半结构化和非结构化
   结构化：数据结构字段含义确定，清晰，典型的如数据库中的表结构
   半结构化：具有一定结构，但语义不够确定，典型的如 HTML 网页，有些字段是确定的(title)， 有些不确定(table)
   非结构化：杂乱无章的数据，很难按照一个概念去进行抽取，无规律性

3. HBase 中的表特点

1. 大：一个表可以有上十亿行，上百万列
2. 面向列：面向列(族)的存储和权限控制，列(簇)独立检索。
3. 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4. 无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一 张表中不同的行可以有截然不同的列
   

二. Hbase架构

1. 架构图

2. 组件相关功能

1. Client
   Client包含了访问Hbase的接口，另外Client还维护了对应的cache来加速Hbase的访问，比如cache的.META.元数据的信息。
2. Zookeeper
   **HBase通过Zookeeper来做master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。**具体工作如下：
   1. 通过Zoopkeeper来保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master提供服务
   2. 通过Zoopkeeper来监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master RegionServer上下线的信息
   3. 通过Zoopkeeper存储元数据的统一入口地址
3. Hmaster（NameNode）
   master节点的主要职责如下：
   1. 为RegionServer分配Region
   2. 维护整个集群的负载均衡
   3. 维护集群的元数据信息
   4. 发现失效的Region，并将失效的Region分配到正常的RegionServer上
   5. 当RegionSever失效的时候，协调对应Hlog的拆分
4. HregionServer(DataNode)
   HregionServer直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下：
   1. 管理master为其分配的Region
   2. 处理来自客户端的读写请求
   3. 负责和底层HDFS的交互，存储数据到HDFS
   4. 负责Region变大以后的拆分
   5. 负责Storefile的合并工作
5. HDFS
   HDFS为Hbase提供最终的底层数据存储服务，同时为HBase提供高可用（Hlog存储在HDFS）的支持，具体功能概括如下：
   1. 提供元数据和表数据的底层分布式存储服务
   2. 数据多副本，保证的高可靠和高可用性

3. 其他细节:

1. 一般一个HBase集群有一个Master服务器和几个RegionServer服务器。Master服务器负责维护表结构信息，实际的数据都存储在RegionServer服务器上

2. HBase有一点很特殊：客户端获取数据由客户端直连RegionServer的，所以你会发现Master挂掉之后你依然可以查询数据，但就是不能新建表了。

3. HBase采用的是Key/Value的存储方式，这意味着，即使随着数据量增大，也几乎不会导致查询的性能下降

4. 数据分析是HBase的弱项，因为对于HBase乃至整个NoSQL生态圈来说，基本上都是不支持表关联的。

5. RegionServer是直接负责存储数据的服务器。RegionServer保存的表数据直接存储在Hadoop的HDFS上
   

6. RegionServer一般跟DataNode在同一个节点上，目的是实现数据的本地性，提高读写效率。

7. 客户端每次与HBase连接，其实都是先与ZooKeeper通信，查询出哪个RegionServer需要连接，然后再连接RegionServer。
   

三. Hbase中角色的功能

1. HMaster

1. 监控RegionServer
2. 处理RegionServer故障转移
3. 处理元数据的变更
4. 处理region的分配或转移
5. 在空闲时间进行数据的负载均衡
6. 通过Zookeeper发布自己的位置给客户端

2. RegionServer

1. 负责存储HBase的实际数据
2. 处理分配给它的Region
3. 刷新缓存到HDFS
4. 维护Hlog
5. 执行压缩
6. 负责处理Region分片

3. 其他组件

1. Write-Ahead logs
   HBase的修改记录，当对HBase读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阈值可以设定）。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入内存中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

2. Region
   Region是Hbase表的分片，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的region。

3. Store
   HFile存储在Store中，一个Store对应HBase表中的一个列族(列簇， Column Family)。

4. MemStore
   顾名思义，就是内存存储，位于内存中，用来保存当前的数据操作，所以当数据保存在WAL中之后，RegsionServer会在内存中存储键值对。

5. HFile
   这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile是以Hfile的形式存储在HDFS的。

5. 注意

1. 客户端从 ZooKeeper获取了RegionServer的地址后，会直接从RegionServer获取数据。其实不光是获取数据，包括插入、删除等所有的数据操作都是直接操作RegionServer，而不需要经过Master。
2. Master只负责各种协调工作（其实就是打杂），比如建表、删表、移动Region、合并等操作。它们的共性就是需要跨RegionServer，这些操作由哪个RegionServer来执行都不合适，所以HBase就将这些操作放到了Master上了。
3. 这种结构的好处是大大降低了集群对Master的依赖。而Master节点一般只有一个到两个，一旦宕机，如果集群对Master的依赖度很大，那么就会产生单点故障问题。在HBase中，即使Master宕机了，集群依然可以正常地运行，依然可以存储和删除数据。

四. Region

1. 概念

1. Region是Hbase表的分片，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的region。
2. region 是部分数据，所以是所有数据的一个子集，但region包括完整的行，所以region 是行为单位的一个子集。
3. 一个Region就是多个行的集合。在Region中行的排序按照行键（rowkey）字典排序。

2. 特性:

1. Region不能跨服务器，一个RegionServer上有一个或者多个Region。
2. 当HBase在进行负载均衡的时候，也有可能会从一台RegionServer上把Region移动到另一台RegionServer上。Region是基于HDFS的，它的所有数据存取操作都是调用了HDFS的客户端接口来实现的。

3. Region的三大要素:

1. 它所属于哪张表
2. 它所包含的第一行(第一个region 没有首行)
3. 他所包含的最后一行(末一个region 没有末行)

4. 细节

1. 当表初写数据时, 此时表只有一个region, 当随着数据的增多, region开始变大, 等到它达到限定的阀值大小时, 变化把region分裂为两个大小基本相同的region, 而这个阀值就是storefile的设定大小.
2. 在第一次分裂region前, 所有加载的数据都放在原始区域的那台服务器上, 随着表的变大region的个数也会相应的增加, 而region是Hbase集群分布数据的最小单位.
3. region是属于单一的regionserver, 除非这个regionserver宕机, 或者其它方式挂掉,再或者执行balance时, 才可能会将这部分region的信息转移到其它机器上.
4. 这也就是为什么region比较少的时候, 导致region分配不均, 总是分派到少数的节点上, 读写并发效果不显著,这就是hbase读写效率比较低的原因.

五. HBase表结构逻辑视图

1. HBase表结构逻辑视图

2. 名词概念

1. RowKey

1. 每个行(row)都拥有唯一的行键(rowkey)来标定这个行的唯一性。
2. rowkey完全是由用户指定的一串不重复的字符串
3. HBase中无法根据某个column来排序，系统永远是根据rowkey进行字典排序
4. rowkey 行键可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，最好是 16。在 HBase 内部，rowkey 保存为字节数组。

2. ColumnFamily

1. Hbase表的创建的时候就必须指定列族。 就像关系型数据库创建的时候必须指定具体的列是一样的。
2. HBase的所有数据属性都是定义在列族上的
3. Hbase的列族不是越多越好，官方推荐的是列族最好小于或者等于3。我们使用的场景一般是1个列族。
4. Hbase通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。就像是家族的概念，我们知道一个家族是由于很多个的家庭组成的。列族也类似，列族是由一个一个的列组成（任意多）。
5. 列族存在的意义是：HBase会把相同列族的列尽量放在同一台机器上，所以说，如果想让某几个列被放到一起，你就给他们定义相同的列族。

3. Column

1. Column是Hbase最基本的存储单位, 一个列或者多个列形成一行(row)
2. 列名称的规范是列族:列名，比如brother:age

4. TimeStamp

1. TimeStamp对Hbase来说至关重要，因为它是实现Hbase多版本的关键。

2. HBase的单元格并没有version这个属性，它用timestamp来存储该条记录的时间戳，这个时间戳就用来当版本号使用。

3. HBase 中通过 rowkey 和 columns 确定的为一个存储单元称为 cell。每个 cell 都保存着同一份 数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64 位整型。时间戳可以由 hbase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由 客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。 每个 cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

4. 为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，hbase 提供了两种数据版 本回收方式：

   1. 保存数据的最后 n 个版本
   2. 保存最近一段时间内的版本（设置数据的生命周期 TTL）。

   用户可以针对每个列簇进行设置。

5. Cell

1. 单元格就是数据存储的最小单元。
2. 唯一确定一条结果的表达式应该是行键:列族:列:版本号（rowkey:column family:column:version）。