Hbase笔记

HBase

Hbase特点

• 海量存储
  HBase 适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与HBase的极易扩展性息息相关。正式因为HBase良好的扩展性，才为海量数据的存储提供了便利。
• 列式存储
  这里的列式存储其实说的是列族（ColumnFamily）存储，HBase 是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。
• 极易扩展
  HBase 的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
  通过横向添加RegionSever的机器，进行水平扩展，提升HBase上层的处理能力，提升HBsae服务更多Region的能力。
  备注：RegionServer的作用是管理region、承接业务的访问，这个后面会详细的介绍通过横向添加datanode的机器，进行存储层扩容，提升 HBase 的数据存储能力和提升后端存储的读写能力。
• 高并发
  由于目前大部分使用HBase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，HBase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
• 稀疏
  稀疏主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

Hbase的数据模型

ROW KEY

• 决定一行数据
• 按照字典数据排序
• Row Key只能存储64k的字节数据

TimeStamp时间戳

• 在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面。
• 时间戳的类型是 64位整型。
• 时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。
• 时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

Column Family列族 & qualifier列

• HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema)定义的一部分预先给出。如 create ‘test’, ‘info’；
• 列名以列族作为前缀，每个“列族”都可以有多个列成员(column)；如info:name, info:age,
• 新的列族成员（列）可以随后按需、动态加入
• 权限控制、存储以及调优都是在列族层面进行

• HBase把同一列族里面的数据存储在同一目录下，由几个文件保存。

Cell单元格

• 由行和列的坐标交叉决定
• 单元格是有版本的
• 单元格的内容是未解析的字节数组
• 由{row key， column( = +)， version} 唯一确定的单元
• cell中的数据是没有类型的，全部是字节码形式存贮。

HLog(WAL Log)

• HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是” 写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
• HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。

HBase集群最终的角色

一个或者多个主节点，HMaster

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

多个从节点HregioinServer

• 负责存储 HBase 的实际数据
• 处理分配给它的 Region
• 刷新缓存到 HDFS
• 维护 HLog
• 执行压缩
• 负责处理 Region 分片

基本原理

HBase 一种是作为存储的分布式文件系统，另一种是作为数据处理模型的 MR 框架。因为日常开发人员比较熟练的是结构化的数据进行处理，但是在 HDFS 直接存储的文件往往不具有结构化，所以催生出了 HBase 在 HDFS 上的操作。如果需要查询数据，只需要通过键值便可以成功访问。

​ HBase 内置有 Zookeeper，但一般我们会有其他的 Zookeeper 集群来监管 master 和 regionserver，Zookeeper 通过选举，保证任何时候，集群中只有一个活跃的 HMaster，HMaster 与 HRegionServer 启动时会向 ZooKeeper 注册，存储所有 HRegion 的寻址入口，实时监控 HRegionserver 的上线和下线信息。并实时通知给 HMaster，存储 HBase 的 schema 和 table 元数据，默认情况下，HBase 管理 ZooKeeper 实例，Zookeeper 的引入使得 HMaster 不再是单点故障。一般情况下会启动两个 HMaster，非 Active 的 HMaster 会定期的和 Active HMaster 通信以获取其最新状态，从而保证它是实时更新的，因而如果启动了多个 HMaster 反而增加了 Active HMaster 的负担。 一个 RegionServer 可以包含多个 HRegion，每个 RegionServer 维护一个 HLog，和多个 HFiles以及其对应的 MemStore。RegionServer 运行于 DataNode 上，数量可以与 DatNode 数量一致

组件说明

• Write-Ahead logs HBase 的修改记录，当对 HBase 读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阈值可以设定）。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在写入一个叫做 Write-Ahead logfile的文件中，再写到内存中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。
• HFile 这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。
• Store HFile 存储在 Store 中，一个 Store 对应 HBase 表中的一个列族。
• MemStore 顾名思义，就是内存存储，位于内存中，用来保存当前的数据操作，所以当数据保存在 WAL 中之后，RegsionServer 会在内存中存储键值对。
• Region Hbase 表的分片，HBase 表会根据 RowKey 值被切分成不同的 region 存储在 RegionServer 中，在一个 RegionServer 中可以有多个不同的 region。

Hbase的读写流程

HBase 的服务器体系结构遵从简单的主从架构，右 HRegionServer 和 HMaster 构成。其中 HMaster 相当于集群的管理者，负责管理所有的 HRegionServer ，而 HRegionServer 相当于 HMaster 手下的很多员工。HBase 中所有的服务器都是使用 Zookeeper 来进行协调服务的，并处理 HBase 服务器运行期间的可能遇到的错误。HMaster 本身并不存储 HBase 中的任何数据，HBase 逻辑上的表可能会被划分成多个 HRegion，然后存储到 HRegionServer 群中。HMaster 中存储的是从数据到 HRegionServer 的映射。

HBase架构

Client

HBase Client 是使用 HBase 的 RPC 机制与HMaster 和HRegionServer 进行通信的。对于管理类型的操作，Client 与 HMaster 进行 RPC；对于数据读写类型的操作，Client 与 HRegionServer 进行RPC，Client 通过 meta 表找到正在服务中的所感兴趣的 RegionServer，找到所需要的 Region 之后，Client 联系该Region的RegionServer，而不是 Master，并发出读取或者写入数据的请求。

Zookeeper

每一台 RegionServer 都会在 Zookeeper 中注册一个自己的临时节点【其实就是一条数据】，HMaster 会利用这些临时节点来发现可用的 RegionServer，还可以利用临时节点来跟踪机器故障和网络分区。HBase 还可以利用 Zookeeper 确保只有一个主HMaster 在运行，一旦某一个 HMaster 死掉，那么Zookeeper会自动将备用的 HMaster 作为主服务器。

HMaster

HMaster 是主服务器的实现，主要负责监视集群中所有的 RegionServer 实例，并且是所有元数据更改的接口。每台 HRegionServer 都会与 HMaster 进行通信，HMaster 主要任务就是告诉每台 HRegionServer 要维护哪些 HRegion。当有一台新的 HRegionServer 登录 HMaster时，HMaster会告诉它等待分配数据。当一台 HRegionServer 死掉时，HMaster 会负责将该 HRegionServer 负责的 HRegion 标记为未分配，然后再将他们分配给其他 HRegionServer。因此 HMaster在功能上主要负责Table 和 HRegion 的管理工作

HRegionServer

在 HBase 中所有的数据一般被保存在 HDFS 上，用户可以通过一系列的 HRegionServer 获取这些数据，一台服务器只能运行 一个HRegionServer，并且每一个区段的 HRegion 也只会由一个 HRegionServer 维护。

HRegionServer 内部管理了一系列的 HRegion 对象，每个 HRegion 对应了 Table 中的一个 Region，HRegion 是由多个 HStore 组成，每个 HStore 对应了Table中的一个 Column Family 的存储，因此 每个 Column Family 其实就是一个集中的存储单元。

HRegion

对于用户来说，每个表都是一堆数据的集合，靠 RowKey 来区分，并且在内部都是有序的，当 HBase 的表的数据大小超过设定值的时候，HBase 会根据 RowKey 将表水平切分为两个 Region。

一般来说，HBase 在创建表的时候只有一个 Region，随着表的记录的增加，一个表就会被拆分成两块，每一块其实就是一个 Region。以此类推，随着表的记录数不断增加，还会继续分裂成若干个 Region。因此可以这么来说，Region 是HBase 分布式存储的最小单元。Region的层次结构如下:

HStore

HStore 是 HBase 存储的核心，由两部分组成：MemStore【Sorted Memory Buffer】 和 StoreFile。用户写入数据首先会存放在 MemStore 中，当* MemStore满了之后会 Flush 成一个 StoreFile（底层实现是 HFile），当 StoreFile 文件数量增长到一定的阈值，会触发 Compact 合并操作，将多个 StoreFile 合并成一个StoreFile，合并过程中会进行保本合并和数据的删除，由此可以看出，HBase 其实只有增加数据，所有的更新和删除操作其实都是在后续的 Compact 过程中进行的。对于用户来说，数据存储到 MemStore 中就可以了，提高了 IO 性能，后续的操作由HBase自动完成。

当 StoreFile Compact 后，StoreFile 会越来越大，当单个 StoreFile 大小超过了一定的阈值之后，就会触发 Split 操作，同时会把当前的 HRegion 差分成两个 Region，那么这个 HRegion 就会下线，被拆分出来的两个 Region 会被 HMaster 重新分配到相应的 HRegionServer 上，使原来一个 Region 的压力分流到两个 Region 上。

注意： StoreFile 以 HFile 格式保存在 HDFS 上。HFile 是Hadoop 的二进制格式文件。实际上 StoreFile 就是对 HFile 做了轻量级包装，即 StoreFile 底层就是 HFile 。
HFile 文件的特点：

• HFile由 DataBlock、Meta 信息 (Index、BloomFilter)、Info等信息组成。
• 整个DataBlock 由一个或者多个KeyValue组成。(注：Value是指一个单元格，Key 指的并不是 RowKey) KeyValue： HFile里面的每个 KeyValue 对就是一个简单的 Byte 数组。但是这个 Byte 数组里面包含了很多项，并且有固定的结构。
• 在文件内按照 Key 排序。

HLog

HLog 其实就是 Write Ahead Log ，由于在HBase 2.0版本之前，WAL继承了HLog接口，因此说WAL就是HLog，在新的版本中WAL就是继承了WAL接口。在集群正常工作情况下写数据不会出现什么问题，但是，一旦出现异常情况，比如 MemStore 数据写入了，但是还没有 Flush 成 StoreFile 的时候，集群宕机了，该怎么办呢？这个时候就需要 HLog 发挥相应的作用了。每个 HRegionServer 中都会有一个 HLog 对象，在用户每次操作写入 MemStore 的同时，也会写一份数据到 HLog 中，HLog 文件定期滚动出新的文件并删除旧的文件【已经持久化到 StoreFile 中的数据文件】。当 HRegionServer 意外终止服务的时候，HMaster 就会处理遗留下来的 HLog 文件，将其中不同的Region 的 Log 数据进行拆分，分配到相应的 Region 下，将失效的 Region 重新分配，领取到这些 Region 的 HRegionServer 在加载 Region 的过程中，会发现有历史 HLog 需要处理，那么就会将遗留的 HLog 中的数据加载到 MemStore 中，然后 Flush 到 StoreFile，完成数据恢复。

BlockCache

BlockCache 称为块缓存 ， HBase会将一次文件查找的Block块缓存到Cache中，以便后续同一请求或者邻近数据查找请求，可以直接从内存中获取，避免昂贵的IO操作。

HBase读取数据流程

读数据流程

• RegionServer 保存着 meta 表以及数据，要想访问数据，客户端必须先通过 Zookeeper 获取 -ROOT- 的位置信息

• 通过 -ROOT- 来获取 meta 中的 Region 的位置，

• 客户端通过 meta 获取数据的 Region 位置

• 通过region的位置获取数据
  
  
  
  写数据的流程

• 客户端先访问 Zookeeper，找到元数据信息

• 确定要写入的数据是在哪一个 Region 上

• 然后客户端向该 RegionServer 发送写数据的请求

• 客户端先把数据写入到 HLog 中，以及所需要的操作，防止数据的丢失

• 然后写入 MemStore

• 如果 HLog 和 MemStore 均写入成功，则表示该数据写入成功。如果在这个过程中，Memstore的数据达到了阈值，就会将Memstore中的数据刷新到 StoreFile

• StoreFile 过多的时候，Region 就会越来越大，如果达到阈值，那么 Region 会被 HMaster 一分为二
  

RowKey设计

一条数据的唯一标识就是 RowKey，那么这条数据存储于哪个分区，取决于 RowKey 处于哪个一个预分区的区间内，设计 RowKey 的主要目的 ，就是让数据均匀的分布于所有的 Region 中，在一定程度上防止数据倾斜。

• Rowkey长度原则
  Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议设计在10-100个字节，不过建议是越短越好，不要超过16个字节。

  原因如下：

  • 数据的持久化文件 HFile 中是按照 KeyValue 存储的，如果 Rowkey 过长比如 100 个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响 HFile 的存储效率；
  • MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率降低，系统将无法缓存更多的数据，这会降低检索效率，因此 Rowkey 的字节长度越短越好。
  • 目前操作系统一般都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用操作系统的最佳特性。有点类似于 SSD 的 4K 对齐。

• Rowkey散列原则

  • 如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。
  • Rowkey唯一原则
    必须在设计Rowkey上保证其唯一性。

避免热点问题

• 加盐

加盐指的是将随机数据添加到 RowKey 设计值的开头。

• 哈希

k恶意使用单向散列，而不是随机分配。这样可以使给定的行时钟以相同的前缀“被盐化”，使用确定的哈希可以让客户端重构完整的RowKey，可以使用 Get 操作。

• 反转

反转固定长度或者数字格式的 RowKey，以使最经常变化的部分放在前面，例如：手机号和时间戳作为Rowkey设计时的反转