HBase存储剖析与数据迁移

1.概述

  HBase的存储结构和关系型数据库不一样,HBase面向半结构化数据进行存储。所以,对于结构化的SQL语言查询,HBase自身并没有接口支持。在大数据应用中,虽然也有SQL查询引擎可以查询HBase,比如Phoenix、Drill这类。但是阅读这类SQL查询引擎的底层实现,依然是调用了HBase的Java API来实现查询,写入等操作。这类查询引擎在业务层创建Schema来映射HBase表结构,然后通过解析SQL语法数,最后底层在调用HBase的Java API实现。

  本篇内容,笔者并不是给大家来介绍HBase的SQL引擎,我们来关注HBase更低层的东西,那就是HBase的存储实现。以及跨集群的HBase集群数据迁移。

2.内容

  HBase数据库是唯一索引就是RowKey,所有的数据分布和查询均依赖RowKey。所以,HBase数据库在表的设计上会有很严格的要求,从存储架构上来看,HBase是基于分布式来实现的,通过Zookeeper集群来管理HBase元数据信息,比如表名就存放在Zookeeper的/hbase/table目录下。如下图所示:

2.1 Architecture

  HBase是一个分布式存储系统,底层数据存储依赖Hadoop的分布式存储系统(HDFS)。HBase架构分三部分来组成,它们分别是:ZooKeeper、HMaster和HRegionServer。

  • ZooKeeper:HBase的元数据信息、HMaster进程的地址、Master和RegionServer的监控维护(节点之间的心跳,判断节点是否下线)等内容均需要依赖ZooKeeper来完成。是HBase集群中不可缺少的核心之一。
  • HMaster:HMaster进程在HBase中承担Master的责任,负责一些管理操作,比如给表分配Region、和数据节点的心跳维持等。一般客户端的读写数据的请求操作不会经过Master,所以在分配JVM内存的适合,一般32GB大小即可。
  • HRegionServer:HRegionServer进程在HBase中承担RegionServer的责任,负责数据的存储。每个RegionServer由多个Region组成,一个Region维护一定区间的RowKey的数据。如下图所示:

  图中Region(dn2:16030)维护的RowKey范围为0001~0002。HBase集群的存储结构如下图所示:

  Zookeeper通常由奇数个组成,便于分布式选举,可参考《分布式系统选举算法剖析》一文了解,这里不多赘述细节。HBase为了保证高可用性(HA),一般都会部署两个Master节点,其中一个作为主,另一个作为Backup节点。这里谁是主,谁是Backup取决于那个HMaster进程能从Zookeeper上对应的Master目录中竞争到Lock,持有该目录Lock的HMaster进程为主Master,而另外一个为Backup,当主Master发生意外或者宕机时,Backup的Master会立刻竞争到Master目录下的Lock从而接管服务,成为主Master对外提供服务,保证HBase集群的高可用性。

2.2 RegionServer

  HBase负责数据存储的就是RegionServer,简称RS。在HBase集群中,如果只有一份副本时,整个HBase集群中的数据都是唯一的,没有冗余的数据存在,也就是说HBase集群中的每个RegionServer节点上保存的数据都是不一样的,这种模式由于副本数只有一份,即是配置多个RegionServer组成集群,也并不是高可用的。这样的RegionServer是存在单点问题的。虽然,HBase集群内部数据有Region存储和Region迁移机制,RegionServer服务的单点问题可能花费很小的代价可以恢复,但是一旦停止RegionServre上含有ROOT或者META表的Region,那这个问题就严重,由于数据节点RegionServer停止,该节点的数据将在短期内无法访问,需要等待该节点的HRegionServer进程重新启动才能访问其数据。这样HBase的数据读写请求如果恰好指向该节点将会收到影响,比如:抛出连接异常、RegionServer不可用等异常。

3.日志信息

  HBase在实现WAL方式时会产生日志信息,即HLog。每一个RegionServer节点上都有一个HLog,所有该RegionServer节点上的Region写入数据均会被记录到该HLog中。HLog的主要职责就是当遇到RegionServer异常时,能够尽量的恢复数据。

  在HBase运行的过程当中,HLog的容量会随着数据的写入越来越大,HBase会通过HLog过期策略来进行定期清理HLog,每个RegionServer内部均有一个HLog的监控线程。HLog数据从MemStore Flush到底层存储(HDFS)上后,说明该时间段的HLog已经不需要了,就会被移到“oldlogs”这个目录中,HLog监控线程监控该目录下的HLog,当该文件夹中的HLog达到“hbase.master.logcleaner.ttl”(单位是毫秒)属性所配置的阀值后,监控线程会立即删除过期的HLog数据。

4.数据存储

  HBase通过MemStore来缓存Region数据,大小可以通过“hbase.hregion.memstore.flush.size”(单位byte)属性来进行设置。RegionServer在写完HLog后,数据会接着写入到Region的MemStore。由于MemStore的存在,HBase的数据写入并非是同步的,不需要立刻响应客户端。由于是异步操作,具有高性能和高资源利用率等优秀的特性。数据在写入到MemStore中的数据后都是预先按照RowKey的值来进行排序的,这样便于查询的时候查找数据。

5.Region分割

  在HBase存储中,通过把数据分配到一定数量的Region来达到负载均衡。一个HBase表会被分配到一个或者多个Region,这些Region会被分配到一个或者多个RegionServer中。在自动分割策略中,当一个Region中的数据量达到阀值就会被自动分割成两个Region。HBase的表中的Region按照RowKey来进行排序,并且一个RowKey所对应的Region只有一个,保证了HBase的一致性。

  一个Region中由一个或者多个Store组成,每个Store对应一个列族。一个Store中包含一个MemStore和多个Store Files,每个列族是分开存放以及分开访问的。自动分割有三种策略,分别是:

  • ConstantSizeRegionSplitPolicy:在HBase-0.94版本之前是默认和唯一的分割策略。当某一个Store的大小超过阀值时(hbase.hregion.max.filesize,默认时10G),Region会自动分割。
  • IncreasingToUpperBoundRegionSplitPolicy:在HBase-0.94中,这个策略分割大小和表的RegionServer中的Region有关系。分割计算公式为:Min(R*R*‘hbase.hregion.memstore.flush.size‘,‘hbase.hregion.max.filesize‘),其中,R表示RegionServer中的Region数。比如:hbase.hregion.memstore.flush.size=256MB,hbase.hregion.max.filesize=20GB,那么第一次分割的大小为Min(1*1*256,20GB)=256MB,也就是在第一次大到256MB会分割成2个Region,后续以此公式类推计算。
  • KeyPrefixRegionSplitPolicy:可以保证相同前缀的RowKey存放在同一个Region中,可以通过hbase.regionserver.region.split.policy属性来指定分割策略。

6.磁盘合理规划

  部署HBase集群时,磁盘和内存的规划是有计算公式的。随意分配可能造成集群资源利用率不高导致存在浪费的情况。公式如下:

# 通过磁盘维度的Region数和Java Heap维度的Region数来推导 Disk Size/(RegionSize*ReplicationFactor)=Java Heap*HeapFractionForMemstore/(MemstoreSize/2)

  公式中对应的hbase-site.xml文件中的属性中,见下表:

Key Property
Disk Size 磁盘容量大小,一般一台服务器有多块磁盘
RegionSize hbase.hregion.max.filesize默认10G,推荐范围在10GB~30GB
ReplicationFactor dfs.replication默认为3
Java Heap 分配给HBase JVM的内存大小
HeapFractionForMemstore hbase.regionserver.global.memstore.lowerLimit默认为0.4
MemstoreSize hbase.hregion.memstore.flush.size默认为128M

  在实际使用中,MemstoreSize空间打下只使用了一半(1/2)的容量。 举个例子,一个RegionServer的副本数配置为3,RegionSize为10G,HBase的JVM内存分配45G,HBase的MemstoreSize为128M,那此时根据公式计算得出理想的磁盘容量为45G*1024*0.4*2*10G*1024*3/128M=8.5T左右磁盘空间。如果此时,分配一个节点中挂载10个可用盘,共27T。那将有两倍的磁盘空间不匹配造成浪费。 为了提升磁盘匹配度,可以将RegionSize值提升至30G,磁盘空间计算得出25.5T,基本和27T磁盘容量匹配。

7.数据迁移

  对HBase集群做跨集群数据迁移时,可以使用Distcp方案来进行迁移。该方案需要依赖MapReduce任务来完成,所以在执行迁移命令之前确保新集群的ResourceManager、NodeManager进程已启动。同时,为了查看迁移进度,推荐开启proxyserver进程和historyserver进程,开启这2个进程可以方便在ResourceManager业务查看MapReduce任务进行的进度。 迁移的步骤并不复杂,在新集群中执行distcp命令即可。具体操作命令如下所示:

# 在新集群的NameNode节点执行命令
[[email protected] ~]$ hadoop distcp -Dmapreduce.job.queue.name=queue_0001_01 -update -skipcrccheck -m 100 hdfs://old_hbase:9000/hbase/data/tabname /hbase/data/tabname

  为了迁移方便,可以将上述命令封装成一个Shell脚本。具体实现如下所示:

#! /bin/bash
for i in `cat /home/hadoop/hbase/tbl`
do
echo $i
hadoop distcp -Dmapreduce.job.queue.name=queue_0001_01 -update -skipcrccheck -m 100 hdfs://old_hbase:9000/hbase/data/$i /hbase/data/$i
done
hbase hbck -repairHoles

  将待迁移的表名记录在/home/hadoop/hbase/tbl文件中,一行代表一个表。内容如下所示:

[email protected] ~]$ vi /home/hadoop/hbase/tbl

# 表名列表
tbl1
tbl2
tbl3
tbl4

  最后,在循环迭代迁移完成后,执行HBase命令“hbase hbck -repairHoles”来修复HBase表的元数据,如表名、表结构等内容,会从新注册到新集群的Zookeeper中。

8.总结

  HBase集群中如果RegionServer上的Region数量很大,可以适当调整“hbase.hregion.max.filesize”属性值的大小,来减少Region分割的次数。在执行HBase跨集群数据迁移时,使用Distcp方案来进行,需要保证HBase集群中的表是静态数据,换言之,需要停止业务表的写入。如果在执行HBase表中数据迁移时,表持续有数据写入,导致迁移异常,抛出某些文件找不到。

9.结束语

  这篇博客就和大家分享到这里,如果大家在研究学习的过程当中有什么问题,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉。

时间: 2024-10-16 05:23:03

HBase存储剖析与数据迁移的相关文章

ESX环境打通2套SAN存储交换机实现数据迁移

因vmware集群升级,需要将旧集群存储中的数据迁移到新集群的存储中,要求热迁移,尽可能的不中断业务,或短时间中断.有多种实现方式:1.将2套SAN交换机级联,使2个平台主机能看到对方的存储.(部分SAN交换机不支持与外厂交换机互联,像浪潮5800. 支持的型号有浪潮5610,博科交换机等)2.使用一台服务器进行存储中转.3.使用SAN交换机直连对方的存储控制器. 如有其他更好的方式,欢迎留言交流. 原文地址:https://blog.51cto.com/gaodi2002/2353983

在线数据迁移(转)

1.前期知识储备 在线数据迁移,是指将正在提供线上服务的数据,从一个地方迁移到另一个地方,整个迁移过程中要求不停机,服务不受影响.根据数据所处层次,可以分为cache迁移和存储迁移:根据数据迁移前后的变化,又可以分为平移和转移. 平移是指迁移前后数据组织形式不变.比如Mysql从1个实例扩展为4个实例,Redis从4个端口扩展到16个端口,HBase从20台机器扩展到30台机器等等.如果在最初的设计里就为以后的扩容缩容提供了方便,那么数据迁移工作就会简单很多,比如Mysql已经做了分库分表,扩展

HBase跨版本数据迁移总结

某客户大数据测试场景为:Solr类似画像的数据查出用户标签--通过这些标签在HBase查询详细信息.以上测试功能以及性能. 其中HBase的数据量为500G,Solr约5T.数据均需要从对方的集群人工迁移到我们自己搭建的集群.由于Solr没有在我们集群中集成,优先开始做HBase的数据迁移,以下总结了HBase使用以及数据迁移遇到的各种问题以及解决方法. 一.迁移过程遇到问题以及解决 客户HBase版本:Version 0.94.15腾讯大数据套件HBase版本:Version 1.2.1客户私

HBase存储时间相关多列数据的两种方案

所谓“时间相关多列数据”指的是同一个Key下具有多个属性数据,并且这些数据与时间具有相关性,多数场景是该Key对应在不同时间时刻的行为数据.在实际应用中,这类数据很多,例如电子商务网站上用户最近一段时间浏览的宝贝集合.访问的URL列表等. 使用HBase存储此类数据时,有以下两种常用的方案: 多行单列 表结构设计 Row Key:用户标识ID + (Long.MAX_VALUE - timestamp) Column Family:’cf’ Column Qualifier:’’ Value:宝

2个Kubernetes使用同一个Ceph存储达到Kubernetes间持久化数据迁移

2个Kubernetes使用同一个Ceph存储达到Kubernetes间持久化数据迁移 [TOC] 当前最新Kubernetes稳定版为1.14.现在为止,还没有不同Kubernetes间持久化存储迁移的方案.但根据Kubernetes pv/pvc绑定流程和原理,只要 "存储"-->"PV"-->"PVC" 的绑定关系相同,即可保证不同间Kubernetes可挂载相同的存储,并且里面是相同数据. 1. 环境 原来我的Kubernet

“数据迁移”考虑

1.hortonwork 和 cloudera 比较 除了功能,还需要对维护性能进行比较 2.环境部署需要细化 部署哪些组件 部署哪些webservice服务 各节点之间如何规划 内存磁盘资源如何分配 是否开启组件高可用 若开启组件高可用,是否考虑部署2套zookeeper 离线集群与在线集群如何互通 3.大数据组件中存储列表应该列出 列出存储的表 给出各表的数据逻辑,即从和数据源来,可如何使用 是否需要考虑历史数据,是否考虑使用拉链表 4.数据迁移方案需要优化 迁移时是否需要停服务  (NO)

在线数据迁移经验:如何为正在飞行的飞机更换引擎

在线数据迁移,是指将正在提供线上服务的数据,从一个地方迁移到另一个地方,整个迁移过程中要求不停机,服务不受影响.根据数据所处层次,可以分为cache迁移和存储迁移:根据数据迁移前后的变化,又可以分为平移和转移. 平移是指迁移前后数据组织形式不变,比如Mysql从1个实例扩展为4个实例,Redis从4个端口扩展到16个端口,HBase从20台机器扩展到 30台机器等等.如果在最初的设计里就为以后的扩容缩容提供了方便,那么数据迁移工作就会简单很多,比如Mysql已经做了分库分表,扩展实例的时候,只需

sqoop 数据迁移

sqoop 数据迁移 1 概述 sqoop是apache旗下一款"Hadoop和关系数据库服务器之间传送数据"的工具. 导入数据:MySQL,Oracle导入数据到Hadoop的HDFS.HIVE.HBASE等数据存储系统. 导出数据:从Hadoop的文件系统中导出数据到关系数据库. 2 工作机制 将导入或导出命令翻译成mapreduce程序来实现. 在翻译出的mapreduce中主要是对inputformat和outputformat进行定制. 3 sqoop 安装 安装sqoop的

MD3200存储中虚拟机数据文件丢失的数据恢复过程

简介: 由于MD3200存储中虚拟机的数据文件丢失,导致整个Hyper-V服务瘫痪,虚拟机无法使用,故障环境为Windows Server 2012服务器,系统中部署了Hyper-V虚拟机环境,虚拟机的硬盘文件和配置文件放在朝阳区某托管中心托管的DELL MD3200存储中(注:硬盘600G*4,4T*1).MD3200存储是由4块600G硬盘组成的阵列,用作存储虚拟机的数据文件.单块4T硬盘用作虚拟机数据文件的备份. 故障: 由于MD3200存储中虚拟机的数据文件丢失,导致整个Hyper-V服