hbase 异构迁移数据 hbase region迁移

转载

墨守成规de网工 2023-08-02 23:55:06

文章标签 hbase 异构迁移数据负载均衡数据使用场景 文章分类 Hbase 数据库

第八章负载均衡实现

8.1 Region迁移
8.2.Region合并
8.3 Region分裂
8.4Hbase负载均衡策略

数据库集群负载均衡的实现依赖于数据库的数据分片设计，

可以在一定程度上认为数据分片就是数据读写负载，

负载均衡功能就是数据分片在集群中均衡的实现。

Hbase中的数据分片的概念就是Region，本章将介绍Region迁移、合并、分裂等原理

8.1 Region迁移

分片迁移是最基础的核心功能，集群负载均衡、故障恢复等功能都是建立在分片的基础之上的。

    Hbase的Region迁移是一个非常轻量级的操作，因为Hbase 的实际数据存储在HDFS上，不需要独立进行管理，

    所以Region在迁移过程中不需要迁移实际的数据，只要将读写服务迁移即可。


    1.Region迁移流程

        region迁移复杂性表现在两个方面：

            1.Region迁移过程中涉及多种状态的改变

            2.迁移过程中涉及Master、ZK以及RegionServer等多个组件相互协调

        Hbase Region状态如下：

            状态              说明              状态          说明

            OFFLINE         下线             OPEANING      region正在打开
            OPEN          region正常打开      FAILED_OPEN   region打开失败
            CLOSEING      region正在关闭      CLOSED        region正常关闭
            FALED_CLOSE   regiong关闭失败     SPLITING      regio正在分裂
            SPLIT         region完成分裂      SPLTING_new   分裂产生新Region
            MERGING       region正在合并      MERGED        region完成合并
            MERGING_NEW   两个region合并成新的region  

            (打开 --- 合并/分裂 --- 关闭 )


        在实际执行过程中，Region迁移操作分两个阶段：unassign阶段 和 assgin阶段

            （1）unassign阶段
                unassign阶段表示Region 从 源RegionServer下线
                具体流程见书

            （2）assign阶段
                assign表示Region在目标RegionServer上线
                具体流程见书

8.2.Region合并

相比Region 分裂,在线合并Region的使用场景比较有限。

    经典使用场景：使用在线合并功能将空闲Region与相邻的Region 合并,

    减少集群中空闲Region的个数，降低集群管理运维成本。
    
    Region合并的主要流程如下:

        1)客户端发送merge请求给Master。

        2)Master 将待合并的所有Region都 move 到同一个RegionServer上。

        3) Master发送merge请求给该RegionServer。

        4)RegionServer启动一个本地事务执行 merge操作。

        5)merge 操作将待合并的两个Region下线,并将两个Region的文件进行合并。

        6)将这两个Region从hbase:meta中删除,并将新生成的Region添加到hbase:meta中。

        7)将新生成的Region上线。

8.3 Region分裂

Region分裂是Hbase最核心的功能之一

    Region分裂有多种触发策略可以配置，一旦触发就会寻找分裂点，然后执行真正的分裂操作。

1.Region分裂触发策略

在当前版本中,HBase 已经有6种分裂触发策略。
        
        每种触发策略都有各自的适用场景 用户可以根据业务在表级别选择不同的分裂触发策略。
        
        常见的分裂策略有以下三种

            **ConstantSizeRegionSpliPolicy**

            **IncreasingToUpperBoundRegionSplirPolicy**

            **SteppingSplitPolicy**

        (1)ConstantsizeRegionSplirPolicy:
              
              0.94版本之前默认分裂策略。
              表示一个Region最大Store的大小超过设置阈值(hbase.hregion.max.filesize)之后会触发分裂

              ConstantsizeRegionSplitrPolicy最简单,但是在生产线上这种分裂策略却有相当大的弊端，
              分裂策略对于大表和小表没有明显的区分。
              
              阈值设置较大对大表比较友好,但是小表就有可能不会触发分裂,极端情况下可能就只有1个Region,这对业务来说并不是什么好事。

              如果阅值设置较小则对小表友好,但一个大表就会在整个集群产生大量的Region,对于集群的管理、资源使用来说都不是一件好事。

        (2)IncreasingToUpperBoundRegionSplitPolicy:
            
            0.94版本～2.0版本默认分裂策略。
            这种分裂策略总体来看和 ConstantSizeRegionSplitrolicy思路相同。

            一个Region中最大Store大小超过设置阈值就会触发分裂。
            但是这个阈值并不像ConstantSizeRegionSplitPolicy 是一个固定的值,而是在一定条件下不断调整,

            调整后的阈值 = (regions) * (regions) * (regions) *fush size*2,
            当然阈值并不会无限增大,最大值为用户设置的MaxRegionFileSize。

            这种分裂策略很好地弥补了 ConstantSizeRegionSplitPolicy 的短板,能够自适应大表和小表,
            而且在集群规模较大的场景下,对很多大表来说表现很优秀。

            然而,这种策略并不完美,比如在大集群场景下,很多小表就会产生大量小Region,分散在整个集群中。

        (3)SteppingSplirPolicy:
            
            2.0版本默认分裂策略。
            这种分裂策略的分裂阅值也发生了变化,相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些,

            分裂阈值大小 如果Region个数 = 1 ,分裂阈值 = fush size*2,否则 = MaxRegionFileSize。
            
            这种分裂策略对于大集群中的大表、小表会更加友好,小表不会再产生大量的小Region。

2.Region 分裂准备工作——寻找分裂点

满足Region 分裂策略之后就会触发Region分裂。分裂被触发后的第一件事是寻找分裂点。

        所有有默认分裂策略,对于分裂点的定义都是一致的。当然,用户手动iorsPs可以指定分裂点进行分裂

        分裂点的定义为:
            整个Region中 最大Store中的 最大文件中 最中心的一个Block的 首个rowkey。

            如果定位到的rowkey是整个文件的首个rowkey  或者最后一个rowkey,则认为没有分裂点。

3.Region核心分裂流程

HBase将整个分裂过程包装成了一个事务,目的是保证分裂事务的原子性。

        整个分裂备过程分为三个阶段:prepare、execute和rollback。操作模板如下:

            if(!st.prepare()) return;
            try{
                st.execute(this.server, this.server, user);

                success = true;
            }catch(Exception e){
                try{
                    st.rollback(this.server, this.server);

                } catch (IOException re){

                    string msg ="Failed rollback of failed split of parent.go-- aborting server";

                    LOG.info(msg, re);
                }
            }

        prepare、execute和rollback 具体流程见书

8.4Hbase负载均衡策略

1.负载均衡策略

        HBse官方目前支持两种负载均衡策略:SimpleLoadBalancer 策略和 StochastilLoadBalancer策略。

        (1)SimpleLoadBalancer 策略

            这种策略能够保证每个RegionServer的Region个数基本相等,

            假设集群中一共有n个RegionServer, m个Region,那么集群的平均负载就是average =m/n,

            这种策略能够保证所有RegionServer上的Region个数都在[ floor(average), ceil(average)]之间。


            很显然这种策略简单易懂,但是考虑的因素太过单一,对于RegionServer上的读写QPA、数据量大小等因素都没有实际考虑,

            这样就可能出现一种情况:虽然集群中每个RegionServer的Region个数都基本相同,

            但因为某台Regionserver上的Region全部都是热点数据,导致90%的读写请求还是落在了这台RegionServer上

        (2)StochasticLoadBalancer策略

            StochasticLoadBalancer策略相比 SimpleLoadBalancer策略更复杂,

            它对于负载的定义不再是Region个数这么简单,而是由多种独立负载加权计算的复合值

            这些独立负载包括:

                ● Region个数(RegionCountSkewCostFunction)

                ● Region负载

                ●读请求数(ReadRequestCostFunction)

                ●写请求数(WriteRequestCostFunction)

                ● Storefile大小(StoreFileCostFunction)

                ●MemStore大小(MemStoreSizeCostFunction)●数据本地率(LocalityCostFunction)

                ●移动代价(MoveCostfunction)

            这些独立负载经过加权计算会得到一个代价值,系统使用这个代价值来评估当前Region分布是否均衡,越均衡代价值越低。

            HBase通过不断随机挑选送代来找到一组Region迁移计划,使得代价值最小。

    2.负载均衡策略的配置

        StochasticLoadBalancer是目前HBase默认的负载均衡策略。用户可以通过配置选择具体负载均衡策略

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。