Hbase基础与原理详解

Hbase简介

1.1 Hbase的含义

    HBASE是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，因此可以容错地存储海量稀疏的数据。

    HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。但是也有很多不同之处。比如：Google Bigtable利用GFS作为其文件存储系统，HBASE利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBASE同样利用Hadoop MapReduce来处理HBASE中的海量数据；Google Bigtable利用Chubby作为协同服务，HBASE利用Zookeeper作为对应。

1.2 传统数据库的对比

1、传统数据库遇到的问题：

     1）数据量很大的时候无法存储
     2）没有很好的备份机制

    3）数据达到一定数量开始缓慢，很大的话基本无法支撑

 2、HBASE优势：

     1）海量数据存储：线性扩展，随着数据量增多可以通过节点扩展进行支撑
     2）大量写操作的应用：数据存储在hdfs上，备份机制健全

    3）快速随机访问：通过zookeeper协调查找数据，访问速度块。

1.3 Hbase集群中的角色

1、一个或者多个主节点，Hmaster

2、多个从节点，HregionServer

1.4 行存储vs列存储

• 行存储：
    – 优点：写入一次性完成，保持数据完整性
    – 缺点：数据读取过程中产生冗余数据，若有少量数据可以忽略
• 列存储
    – 优点：读取过程，不会产生冗余数据，特别适合对数据完整性要求不高的大数据领域
    – 缺点：写入效率差，保证数据完整性方面差

1.5 Hbase应用场景

• 互联网搜索引擎数据存储
• 海量数据写入
• 消息中心
• 内容服务系统（schema-free）
• 大表复杂&多维度索引
• 大批量数据读取

（三）Hbase数据模型

• RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
• Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
• Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加
• Version Number：类型为Long，默认值是系统时间戳，可由用户自定义

• Value(Cell)：Byte array

• {rowkey => {family => {qualifier => {version => value}}}}
• a:cf1:bar:1368394583:7

• a:cf1:foo:1368394261:hello

3.1 Row key

与nosql数据库们一样,row key是用来检索记录的主键。访问HBASE table中的行，只有三种方式：

1.通过单个row key访问

2.通过row key的range（正则）

3.全表扫描

Row key行键 (Row key)可以是任意字符串(最大长度 是 64KB，实际应用中长度一般为10-100bytes)，在HBASE内部，row key保存为字节数组。存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

3.2 Column Family

列簇：HBASE表中的每个列，都归属于某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如 courses:history，courses:math都属于courses 这个列族。

3.3 Cell

由{row key, columnFamily, version} 唯一确定的单元。cell中 的数据是没有类型的，全部是字节码形式存贮。

关键字：无类型、字节码

3.4 Time Stamp

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

为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，HBASE提供 了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段 时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

（四）H b a s e 物 理 模 型

• Hbase一张表由一个或多个Hregion组成
• 记录之间按照Row Key的字典序排列

• Region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

• 表 -> HTable
• 按RowKey范围分的Region-> HRegion ->Region Servers
• HRegion按列族（Column Family） ->多个HStore
• HStore -> memstore + HFiles(均为有序的KV)
• HFiles -> HDFS

 HRegion是Hbase中分布式存储和负载均衡的最小单元。
• 最小单元就表示不同的Hregion可以分布在不同的HRegion server上。
• 但一个Hregion是不会拆分到多个server上的。

• HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。

（五）Hbase系统架构

• Client
    – 访问Hbase的接口，并维护Cache加速Region Server的访问
• Master
    – 负载均衡，分配Region到RegionServer
• Region Server
    – 维护Region，负责Region的IO请求
• Zookeeper
    – 保证集群中只有一个Master
    – 存储所有Region的入口（ROOT）地址
    – 实时监控Region Server的上下线信息，并通知Master

（六）Hbase容错

• ZooKeeper协调集群所有节点的共享信息，在HMaster和HRegionServer连接到ZooKeeper后创建Ephemeral节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点实效，则HMaster会收到通知，并做相应的处理。

• 除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息：
    – /hbase/root-region-server ，Root region的位置
    – /hbase/table/-ROOT-，根元数据信息
    – /hbase/table/.META.，元数据信息
    – /hbase/master，当选的Mater
    – /hbase/backup-masters，备选的Master
    – /hbase/rs ，Region Server的信息
    – /hbase/unassigned，未分配的Region

• Master容错：

    – Zookeeper重新选择一个新的Master
        • 无Master过程中，数据读取仍照常进行；
        • 无master过程中，region切分、负载均衡等无法进行

• Region Server容错：

    – 定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer

• Zookeeper容错：

    – Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例

• WAL(Write-Ahead-Log)预写日志

• 是Hbase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志

• 在每次Put、Delete等一条记录时，首先将其数据写入到RegionServer对应的HLog文件的过程
• 客户端往RegionServer端提交数据的时候，会写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败
• 数据落地的过程

• 在一个RegionServer上的所有的Region都共享一个HLog，一次数据的提交是先写WAL，写入成功后，再写memstore。当memstore值到达一定阈值，就会形成一个个StoreFile（理解为HFile格式的封装，本质上还是以HFile的形式存储的）

（七）Hbase 核心

Hbase的操作

• 基本的单行操作：PUT，GET，DELETE
• 扫描一段范围的Rowkey: SCAN
    – 由于Rowkey有序而让Scan变得有效
• GET和SCAN支持各种Filter，将逻辑推给Region Server
    – 以此为基础可以实现复杂的查询
• 支持一些原子操作：INCREMENT、APPEND、CheckAnd{Put,Delete}
• MapReduce
• 注：在单行上可以加锁，具备强一致性。这能满足很多应用的需求。

Hbase的特殊的表

• -ROOT- 表和.META.表是两个比较特殊的表
• .META.记录了用户表的Region信息，.META.可以有多个regoin。
• -ROOT-记录了.META.表的Region信息，-ROOT-只有一个region，Zookeeper中记录了-ROOT-表的location

• Hbase 0.96之后去掉了-ROOT- 表，因为：
    – 三次请求才能直到用户Table真正所在的位置也是性能低下的
    – 即使去掉-ROOT- Table，也还可以支持2^17(131072)个Hregion，对于集群来说，存储空间也足够
• 所以目前流程为：
    – 从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位置（HRegionServer的位置），缓存该位置信息
    – 从HRegionServer中查询用户Table对应请求的RowKey所在的HRegionServer，缓存该位置信息
    – 从查询到HRegionServer中读取Row。

Hbase的写入流程——寻址

• 从这个过程中，我们发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的RowKey不在同一个HRegion中，则需要继续查询hbase:meta所在的HRegion，然而随着时间的推移，客户端缓存的
位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存

• hbase:meta表存储了所有用户HRegion的位置信息

Hbase的写入流程——写入

• 当客户端发起一个Put请求时，首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer。然后客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操作写入WAL日志(Flush到磁盘中)。
• Memstore是一个写缓存，每一个Column Family有一个自己的MemStore

• 写完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore中。此时写成功，并返回通知客户端。

• MemStore是一个In Memory Sorted Buffer，在每个HStore中都有一个MemStore，即它是一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序。

Hbase的读取流程

• HBase中扫瞄的顺序依次是：BlockCache、MemStore、StoreFile(HFile)

Hbase的Compaction和Split

• 问题：随着写入不断增多，flush次数不断增多，Hfile文件越来越多,所以Hbase需要对这些文件进行合并
• Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单，先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务
    • Minor Compaction：是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile
    • Major Compaction：是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据
    • Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发

• Compaction本质：使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟
• compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度
• Split
    – 当一个Region太大时，将其分裂成两个Region
• Split和Major Compaction可以手动或者自动做。

（八）Hbase原理

1、写流程

1、  client向hregionserver发送写请求。
2、  hregionserver将数据写到hlog（write ahead log）。为了数据的持久化和恢复。
3、  hregionserver将数据写到内存（memstore）

4、  反馈client写成功。

2、数据flush过程

1、  当memstore数据达到阈值（默认是64M），将数据刷到硬盘，将内存中的数据删除，同时删除Hlog中的历史数据。
2、  并将数据存储到hdfs中。

3、  在hlog中做标记点。

3.  数据合并过程

1、  当数据块达到4块，hmaster将数据块加载到本地，进行合并
2、  当合并的数据超过256M，进行拆分，将拆分后的region分配给不同的hregionserver管理
3、  当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META. 

4、  注意：hlog会同步到hdfs

4、Hbase的读流程

1、  通过zookeeper和-ROOT-.META.表定位hregionserver。
2、  数据从内存和硬盘合并后返回给client

3、  数据块会缓存

5、Hmaster的职责

1、管理用户对Table的增、删、改、查操作；
2、记录region在哪台Hregionserver上
3、在Region Split后，负责新Region的分配；
4、新机器加入时，管理HRegionServer的负载均衡，调整Region分布

5、在HRegion Server宕机后，负责失效HRegionServer 上的Regions迁移。

6、hregionserver的职责

HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。

HRegion Server管理了很多table的分区，也就是region。

7、client职责

HBASE Client使用HBASE的RPC机制与HMaster和RegionServer进行通信
管理类操作：Client与HMaster进行RPC；

数据读写类操作：Client与HRegionServer进行RPC。