HBase应用快速学习

HBase是一个高性能、面向列、可伸缩的开源分布式NoSQL数据库,是Google Bigtable的开源实现。 

HBase的思想和应用和传统的RDBMS,NoSQL等有比较大的区别,这篇文章从HBase的架构和关键的Rowkey设计入手,快速学习相关应用。

 

一、 HBase设计特性

HBase概述

HBase是一个构建在HDFS上的分布式列存储系统,将数据按照表、行和列进行存储,与hadoop一样,Hbase目标主要依靠横向扩展,通过不断增加廉价的商用服务器,来增加计算和存储能力。

HBase与HDFS区别

HDFS是Hadoop Distribute File System 的简称,也就是Hadoop的一个分布式文件系统。

HBase应用快速学习_第1张图片

实际应用中,Spark以及 Hadoop 的 MapReduce,可以理解为一种计算框架。

而 HDFS 可以认为是为计算框架服务的存储层。HBase 是一种列式的分布式数据库,类似于 Hive,HBase 底层依赖 HDFS 来作为其物理存储。

 

二、 HBase数据模型

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

Hbase逻辑视图

HBase应用快速学习_第2张图片
  • RowKey:是Byte array,是表中每条记录的“主键”,方便快速查找,Rowkey的设计非常重要。
  • Column Family:列族,拥有一个名称(string),包含一个或者多个相关列
  • Column:属于某一个columnfamily,familyName:columnName,每条记录可动态添加
  • Value:Byte array

Hbase支持的操作

所有操作均是基于rowkey的; 

支持CRUD( Create、 Read、 Update和Delete)和Scan; 

  • 单行操作 Put Get Scan 

  • 多行操作 Scan MultiPut 

没有内置join操作,可使用MapReduce解决。

 

三、 HBase物理结构

Region虽然是分布式存储的最小单元,但并不是存储的最小单元。Region由一个或者多个Store组成,每个store保存一个columns family,每个Strore又由一个memStore和0至多个StoreFile组成,StoreFile包含HFile;memStore存储在内存中,StoreFile存储在HDFS上。

Region的存储策略

  • Table中所有行都按照row key的字典序排列;
  • Table在行的方向上分割为多个Region;
  • Region按大小分割的,每个表开始只有一个region,随着数据增多,region不断增大,当增大到一个阀值的时候,region就会等分会两个新的region,之后会有越来越多的region;
  • Region是Hbase中分布式存储和负载均衡的最小单元,不同Region分布到不同RegionServer上。

HFile的结构

HFile是HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile。

HBase应用快速学习_第3张图片

除了HFile,HBase还有HLog File。

HLog File是HBase中WAL(Write Ahead Log) 的存储格式,物理上是Hadoop的Sequence File。

 

四、 HBase设计与架构

整体架构

HBase采用Master/Slave架构搭建集群,整体架构包括HMaster节点、HRegionServer节点、ZooKeeper集群,底层的数据存储于HDFS中,涉及到HDFS的NameNode、DataNode等。

HBase应用快速学习_第4张图片

HMaster解析

HMaster是HBase主/从集群架构中的中央节点,通常一个HBase集群存在多个HMaster节点,其中一个为Active Master,其余为Backup Master。HMaster管理HRegionServer,实现其负载均衡,负责管理和分配HRegion,比如在HRegion split时分配新的HRegion。

 

  • 发现失效的Region server并重新分配其上的region
  • 实现DDL操作(Data Definition Language,namespace和table的增删改,column familiy的增删改等)
  • 管理namespace和table的元数据(实际存储在HDFS上)
  • 处理schema更新请求

 

HRegionServer解析

HRegionServer存放和管理本地HRegion,读写HDFS,管理Table中的数据。 Client直接通过HRegionServer读写数据(从HMaster中获取元数据,找到RowKey所在的HRegion/HRegionServer后)。

  • 维护master分配给他的region,处理对这些region的io请求
  • 负责切分正在运行过程中变的过大的region

ZooKeeper集群

ZooKeeper是协调系统,用于存放整个HBase集群的元数据以及集群的状态信息。 实现HMaster主从节点的failover。

HBase Client通过RPC方式和HMaster、HRegionServer通信,一个HRegionServer可以存放1000个HRegion。 底层Table数据存储于HDFS中,而HRegion所处理的数据尽量和数据所在的DataNode在一起,实现数据的本地化,在HRegion移动(如因Split)时,需要等下一次Compact才能继续回到本地化。

 

五、 HBase最佳实践

 

HBase适合的场景

  • 大数据量存储,大数据量高并发操作
  • 读写访问均是非常简单的操作

 

Rowkey如何设计

(1)针对查询优化

除了全表扫描以外,HBase的查询实现只支持两种方式:

  • get:指定rowkey获取唯一一条记录
  • scan:按指定的条件获得一批记录,通过rowKey的range匹配一个范围,然后通过多种filter在范围内筛选

如果我们想提升查询效率,必须在rowKey的设计上下功夫。

HBase的rowKey是基于字典排序的,具体来说是基于key的ASCII码来排序,一般的rowkey是通过业务上的多个因素相互组合,一步步确定查找范围。

比如时间肯定是我们应该加到rowKey里的一个查询因子,一个开始时间跟一个截止时间就形成了一个时间段范围,就能固定一个结果集范围。

(2)合适的长度

rowkey是一个二进制码流,可以是任意字符串,最大长度64kb,实际应用中一般为10-100bytes,以byte[]形式保存,一般设计成定长。

  • 数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,在上亿级别的海量数据下,会造成存储空间的浪费
  • MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率
  • 目前操作系统是都是64位系统,内存8字节对齐,可以控制在16个字节或者32字节等

(3)更好的散列设计

如果rowkey按照时间戳的方式递增,不要将时间放在二进制码的前面,建议将rowkey的高位作为散列字段,由程序随机生成,低位放时间字段,这样将提高数据均衡分布在每个RegionServer,以实现负载均衡的几率。如果没有散列字段,字段前缀部分直接是时间信息,大量数据数据都会集中在一个RegionServer上,造成热点问题,降低查询效率。

 

Region分区优化

(1)避免热点Region

HBase中的行是按照rowkey的字典顺序排序的,这种设计将相关的行以及会被一起读取的行存取在临近位置,便于scan。

HBase中,表会被划分为n个Region,托管在RegionServer中,StartKey与EndKey表示这个Region维护的rowKey范围。

默认的策略是当一个Region过大时,进行一次分裂(region-split)操作,后续的rowkey会被分配到新的Region。

明显这种策略很容易出现热点Region,大量访问会使热点region所在的单个机器响应缓慢,引起性能下降甚至region不可用,

同时会影响同一个RegionServer上的其他region,由于主机无法服务其他region的请求。

在设计Region时应该设计良好的数据访问模式以使集群被充分,均衡的利用。

(2)预分区设计

解决热点Region问题的一个策略就是通过对rowkey进行Hash进行预分区。

这里又设计到rowkey的设计问题,设计rowkey时尽量把前缀部分打散,可以使用随机数等, 只要region所管理的start-end keys范围比较随机,那么就可以解决写热点问题。

更进一步,可以预估系统的容量,规划可能的Region数量,通过一个路由算法进行负载均衡。

 

 

你可能感兴趣的:(HBase应用快速学习)