Hbase 热点(数据倾斜)问题解决方案---rowkey散列和预分区设计

最新推荐文章于 2025-01-26 14:39:34 发布

Jacob_llz

最新推荐文章于 2025-01-26 14:39:34 发布

阅读量472

点赞数

分类专栏：大数据 Hadoop

大数据同时被 2 个专栏收录

48 篇文章

订阅专栏

Hadoop

24 篇文章

订阅专栏

Hbase的表会被划分为1....n个Region,被托管在RegionServer中。Region二个重要的属性：Startkey与EndKey表示这个Region维护的rowkey的范围，当我们要读写数据时，如果rowkey落在某个start-end key范围内，那么就会定位到目标region并且读写到相关的数据。

默认情况下，当我们通过hbaseAdmin指定TableDescriptor来创建一张表时，只有一个region正处于混沌时期，start-end key无边界，可谓海纳百川。所有的rowkey都写入到这个region里，然后数据越来越多，region的size越来越大时，大到一定的阀值，hbase就会将region一分为二，成为2个region，这个过程称为分裂（region-split）。

如果我们就这样默认建表，表里不断的put数据，更严重的是我们的rowkey还是顺序增大的，是比较可怕的。存在的缺点比较明显：首先是热点写，我们总是向最大的start key所在的region写数据，因为我们的rowkey总是会比之前的大，并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中；其次，由于热点，我们总是往最大的start key的region写记录，之前分裂出来的region不会被写数据，有点打入冷宫的感觉，他们都处于半满状态，这样的分布也是不利的。

如果在写比较频繁的场景下，数据增长太快，split的次数也会增多，由于split是比较耗费资源的，所以我们并不希望这种事情经常发生。

在集群中为了得到更好的并行性，我们希望有好的load blance，让每个节点提供的请求都是均衡的，我们也不希望，region不要经常split，因为split会使server有一段时间的停顿，如何能做到呢？

随机散列与预分区二者结合起来，是比较完美的。预分区一开始就预建好了一部分region，这些region都维护着自己的start-end keys，在配合上随机散列，写数据能均衡的命中这些预建的region，就能解决上面的那些缺点，大大提供性能。

一、解决思路

提供两种思路：hash与partition。

1、hash方案

hash就是rowkey前面由一串随机字符串组成，随机字符串生成方式可以由SHA或者MD5方式生成，只要region所管理的start-end keys范围比较随机，那么就可以解决写热点问题。例如：

    Java代码   
    
  
long currentId = 1L;  
byte [] rowkey = Bytes.add(MD5Hash.getMD5AsHex(Bytes.toBytes(currentId))  
                    .substring(0, 8).getBytes(),Bytes.toBytes(currentId));  

假如rowkey原本是自增长的long型，可以将rowkey转为hash再转为bytes，加上本身id转为bytes，这样就生成随便的rowkey。那么对于这种方式的rowkey设计，如何去进行预分区呢？

取样，先随机生成一定数量的rowkey，将取样数据按升序排序放到一个集合里。
根据预分区的region个数，对整个集合平均分割，即是相关的splitkeys。
HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定预分区的splitkey，即指定region间的rowkey临界值。

创建split计算器，用于从抽样数据生成一个比较合适的splitkeys

    Java代码   
    
  
public class HashChoreWoker implements SplitKeysCalculator{  
    //随机取机数目  
    private int baseRecord;  
    //rowkey生成器  
    private RowKeyGenerator rkGen;  
    //取样时，由取样数目及region数相除所得的数量.  
    private int splitKeysBase;  
    //splitkeys个数  
    private int splitKeysNumber;  
    //由抽样计算出来的splitkeys结果  
    private byte[][] splitKeys;  
  
    public HashChoreWoker(int baseRecord, int prepareRegions) {  
        this.baseRecord = baseRecord;  
        //实例化rowkey生成器  
        rkGen = new HashRowKeyGenerator();  
        splitKeysNumber = prepareRegions - 1;  
        splitKeysBase = baseRecord / prepareRegions;  
    }  
  
    public byte[][] calcSplitKeys() {  
        splitKeys = new byte[splitKeysNumber][];  
        //使用treeset保存抽样数据，已排序过  
        TreeSet<byte[]> rows = new TreeSet<byte[]>(Bytes.BYTES_COMPARATOR);  
        for (int i = 0; i < baseRecord; i++) {  
            rows.add(rkGen.nextId());  
        }  
        int pointer = 0;  
        Iterator<byte[]> rowKeyIter = rows.iterator();  
        int index = 0;  
        while (rowKeyIter.hasNext()) {  
            byte[] tempRow = rowKeyIter.next();  
            rowKeyIter.remove();  
            if ((pointer != 0) && (pointer % splitKeysBase == 0)) {  
                if (index < splitKeysNumber) {  
                    splitKeys[index] = tempRow;  
                    index ++;  
                }  
            }  
            pointer ++;  
        }  
        rows.clear();  
        rows = null;  
        return splitKeys;  
    }  
}  

KeyGenerator及实现

    Java代码   
    
  
//interface  
public interface RowKeyGenerator {  
    byte [] nextId();  
}  
//implements  
public class HashRowKeyGenerator implements RowKeyGenerator {  
    private long currentId = 1;  
    private long currentTime = System.currentTimeMillis();  
    private Random random = new Random();  
    public byte[] nextId() {  
        try {  
            currentTime += random.nextInt(1000);  
            byte[] lowT = Bytes.copy(Bytes.toBytes(currentTime), 4, 4);  
            byte[] lowU = Bytes.copy(Bytes.toBytes(currentId), 4, 4);  
            return Bytes.add(MD5Hash.getMD5AsHex(Bytes.add(lowU, lowT)).substring(0, 8).getBytes(),  
                    Bytes.toBytes(currentId));  
        } finally {  
            currentId++;  
        }  
    }  
}  

unit test case测试

    Java代码   
    
  
@Test  
public void testHashAndCreateTable() throws Exception{  
        HashChoreWoker worker = new HashChoreWoker(1000000,10);  
        byte [][] splitKeys = worker.calcSplitKeys();  
          
        HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create());  
        TableName tableName = TableName.valueOf("hash_split_table");  
          
        if (admin.tableExists(tableName)) {  
            try {  
                admin.disableTable(tableName);  
            } catch (Exception e) {  
            }  
            admin.deleteTable(tableName);  
        }  
  
        HTableDescriptor tableDesc = new HTableDescriptor(tableName);  
        HColumnDescriptor columnDesc = new HColumnDescriptor(Bytes.toBytes("info"));  
        columnDesc.setMaxVersions(1);  
        tableDesc.addFamily(columnDesc);  
  
        admin.createTable(tableDesc ,splitKeys);  
  
        admin.close();  
    }  

查看建表结果，执行：scan 'hbase:meta'

以上我们只是显示了部分region的信息，可以看到region的start-end key还是比较随机散列的。同样可以查看hdfs的目录结构，的确和预期的38个预分区一致：

以上就是按照hash方式，预建好分区，以后再插入数据的时候，也是按照此rowkeyGenerator的方式生成rowkey。

2、partition的方式

partition顾名思义就是分区式，这种分区有点类似于mapreduce中的partitioner，将区域用长整数作为分区号，每个region管理着相应的区域数据，在rowkey生成时，将ID取模后，然后拼上ID整体作为rowkey，这个比较简单，不需要取样，splitkeys也非常简单，直接是分区号即可。直接上代码：

    Java代码   
    
  
public class PartitionRowKeyManager implements RowKeyGenerator,  
        SplitKeysCalculator {  
  
    public static final int DEFAULT_PARTITION_AMOUNT = 20;  
    private long currentId = 1;  
    private int partition = DEFAULT_PARTITION_AMOUNT;  
    public void setPartition(int partition) {  
        this.partition = partition;  
    }  
  
    public byte[] nextId() {  
        try {  
            long partitionId = currentId % partition;  
            return Bytes.add(Bytes.toBytes(partitionId),  
                    Bytes.toBytes(currentId));  
        } finally {  
            currentId++;  
        }  
    }  
  
    public byte[][] calcSplitKeys() {  
        byte[][] splitKeys = new byte[partition - 1][];  
        for(int i = 1; i < partition ; i ++) {  
            splitKeys[i-1] = Bytes.toBytes((long)i);  
        }  
        return splitKeys;  
    }  
}  

calcSplitKeys方法比较单纯，splitkey就是partition的编号，测试类如下：

    Java代码   
    
  
@Test  
    public void testPartitionAndCreateTable() throws Exception{  
          
        PartitionRowKeyManager rkManager = new PartitionRowKeyManager();  
        //只预建10个分区  
        rkManager.setPartition(10);  
          
        byte [][] splitKeys = rkManager.calcSplitKeys();  
          
        HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create());  
        TableName tableName = TableName.valueOf("partition_split_table");  
          
        if (admin.tableExists(tableName)) {  
            try {  
                admin.disableTable(tableName);  
  
            } catch (Exception e) {  
            }  
            admin.deleteTable(tableName);  
        }  
  
        HTableDescriptor tableDesc = new HTableDescriptor(tableName);  
        HColumnDescriptor columnDesc = new HColumnDescriptor(Bytes.toBytes("info"));  
        columnDesc.setMaxVersions(1);  
        tableDesc.addFamily(columnDesc);  
  
        admin.createTable(tableDesc ,splitKeys);  
  
        admin.close();  
    }  

同样我们可以看看meta表和hdfs的目录结果，其实和hash类似，region都会分好区。

通过partition实现的loadblance写的话，当然生成rowkey方式也要结合当前的region数目取模而求得，大家同样也可以做些实验，看看数据插入后的分布。

在这里也顺提一下，如果是顺序的增长型原id,可以将id保存到一个数据库，传统的也好,redis的也好，每次取的时候，将数值设大1000左右，以后id可以在内存内增长，当内存数量已经超过1000的话，再去load下一个，有点类似于oracle中的sqeuence.

随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的，随着时间不断地推移，已经分好的区域，或许已经装不住更多的数据，当然就要进一步进行split了，同样也会出现性能损耗问题，所以我们还是要规划好数据增长速率，观察好数据定期维护，按需分析是否要进一步分行手工将分区再分好，也或者是更严重的是新建表，做好更大的预分区然后进行数据迁移。如果数据装不住了，对于partition方式预分区的话，如果让它自然分裂的话，情况分严重一点。因为分裂出来的分区号会是一样的，所以计算到partitionId的话，其实还是回到了顺序写年代，会有部分热点写问题出现，如果使用partition方式生成主键的话，数据增长后就要不断地调整分区了，比如增多预分区，或者加入子分区号的处理.(我们的分区号为long型，可以将它作为多级partition)

以上基本已经讲完了防止热点写使用的方法和防止频繁split而采取的预分区。但rowkey设计，远远也不止这些，比如rowkey长度，然后它的长度最大可以为char的MAXVALUE,但是看过之前我写KeyValue的分析知道，我们的数据都是以KeyValue方式存储在MemStore或者HFile中的，每个KeyValue都会存储rowKey的信息，如果rowkey太大的话，比如是128个字节，一行10个字段的表，100万行记录，光rowkey就占了1.2G+所以长度还是不要过长，另外设计，还是按需求来吧。