HBase region size 到底设置多大

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HBase region size 到底设置多大相关的知识,希望对你有一定的参考价值。

参考技术A 具体还是看需要,一般设置1G就差不多了

hbase调优和protouf

hbase调优

一.表的设计

1.设置预分区表

原因:前期region读写都集中到一个regionserver上,直到文件足够大时,才进行分区,这样会降低性能.

解决方案:建表是设置预分区,这样当数据写入HBase时,会按照region分区情况,在集群内做数据的负载均衡。

public static boolean createTable(HBaseAdmin admin, HTableDescriptor table, byte[][] splits)
throws IOException {
  try {
    admin.createTable(table, splits);
    return true;
  } catch (TableExistsException e) {
    logger.info("table " + table.getNameAsString() + " already exists");
    // the table already exists...
    return false;  
  }
}

public static byte[][] getHexSplits(String startKey, String endKey, int numRegions) { //start:001,endkey:100,10region [001,010]
[011,020]
  byte[][] splits = new byte[numRegions-1][];
  BigInteger lowestKey = new BigInteger(startKey, 16);
  BigInteger highestKey = new BigInteger(endKey, 16);
  BigInteger range = highestKey.subtract(lowestKey);
  BigInteger regionIncrement = range.divide(BigInteger.valueOf(numRegions));
  lowestKey = lowestKey.add(regionIncrement);
  for(int i=0; i < numRegions-1;i++) {
    BigInteger key = lowestKey.add(regionIncrement.multiply(BigInteger.valueOf(i)));
    byte[] b = String.format("%016x", key).getBytes();
    splits[i] = b;
  }
  return splits;
}

2,rowkey

row key可以是任意字符串,最大长度64KB;实际应用中一般为10~100bytes,防止出现rowkey冗余;row key是按照字典序存储,将最近可能会被访问的数据放在一块;

解决方案:对数据进行逆反处理将数据进行散列.减少热点数据;进行rowkey设计时,越短越好;

3.列族

表中不能涉及过多的列族,原因有二:

(1) 当一个memstore溢写时,会触发临近的列族溢写,如果列族过多,会导致IO数量过大;

(2)如果我们按照rowkey查询数据的时候,会吧所有的列族的数据查询出来,导致读取storefile文件数过多

4.In memory

在regionserver中有一个内存共享区域;创建表的时候可以将表放入到memory,增加缓存命中率;

5.删除

Max Version:超过版本数的数据会被移除;这就需要我们设置合理的半本数了;

6.Time To Live

创建表的时候,可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期,过期数据将自动被删除,例如如果只需要存储最近两天的数据,那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

7.数据文件的合并与切分

在HBase中,数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中,MemStore中的数据是排序的,当MemStore累计到一定阈值时,就会创建一个新的MemStore,并且将老的MemStore添加到flush队列,由单独的线程flush到磁盘上,成为一个StoreFile。于此同时, 系统会在zookeeper中记录一个redo point,表示这个时刻之前的变更已经持久化了(minor compact)。 StoreFile是只读的,一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(major compact),将对同一个key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对 StoreFile进行分割(split),等分为两个StoreFile。 由于对表的更新是不断追加的,处理读请求时,需要访问Store中全部的StoreFile和MemStore,将它们按照row key进行合并,由于StoreFile和MemStore都是经过排序的,并且StoreFile带有内存中索引,通常合并过程还是比较快的。 实际应用中,可以考虑必要时手动进行major compact,将同一个row key的修改进行合并形成一个大的StoreFile。同时,可以将StoreFile设置大些,减少split的发生。

hbase为了防止小文件(被刷到磁盘的menstore)过多,以保证保证查询效率,hbase需要在必要的时候将这些小的store file合并成相对较大的store file,这个过程就称之为compaction。在hbase中,主要存在两种类型的compaction:minor compaction和major compaction。 minor compaction:的是较小、很少文件的合并。 major compaction 的功能是将所有的store file合并成一个,触发major compaction的可能条件有:major_compact 命令、majorCompact() API、region server自动运行(相关参数:hbase.hregion.majoucompaction 默认为24 小时、hbase.hregion.majorcompaction.jetter 默认值为0.2 防止region server 在同一时间进行major compaction)。 hbase.hregion.majorcompaction.jetter参数的作用是:对参数hbase.hregion.majoucompaction 规定的值起到浮动的作用,假如两个参数都为默认值24和0,2,那么major compact最终使用的数值为:19.2~28.8 这个范围

二.数据的写入

1.多HTable并发写

创建多个HTable客户端用于写操作,提高写数据的吞吐量

static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
wTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {
   wTableLog[i] = new HTable(conf, table_log_name);
   wTableLog[i].setWriteBufferSize(5 * 1024 * 1024); //5MB
   wTableLog[i].setAutoFlush(false);
}

2.设置参数

2.1 Auto Flush 通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭,这样可以批量写入数据到HBase,而不是有一条put就执行一次更新,只有当put填满客户端写缓存时,才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。 2.2 Write Buffer 通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小,如果新设置的buffer小于当前写buffer中的数据时,buffer将会被flush到服务端。其中,writeBufferSize的单位是byte字节数,可以根据实际写入数据量的多少来设置该值。 2.3 WAL Flag 在HBae中,客户端向集群中的RegionServer提交数据时(Put/Delete操作),首先会先写WAL(Write Ahead Log)日志(即HLog,一个RegionSe··rver上的所有Region共享一个HLog),只有当WAL日志写成功后,再接着写MemStore,然后客户端被通知提交数据成功;如果写WAL日志失败,客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。 因此,对于相对不太重要的数据,可以在Put/Delete操作时,通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数,放弃写WAL日志,从而提高数据写入的性能。 值得注意的是:谨慎选择关闭WAL日志,因为这样的话,一旦RegionServer宕机,Put/Delete的数据将会无法根据WAL日志进行恢复

3.批量插入数据

通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase,同样HBase提供了另一个方法:通过调用HTable.put(List)方法可以将指定的row key列表,批量写入多行记录,这样做的好处是批量执行,只需要一次网络I/O开销,这对于对数据实时性要求高,网络传输RTT高的情景下可能带来明显的性能提升

4.多线程并发写

在客户端开启多个HTable写线程,每个写线程负责一个HTable对象的flush操作,这样结合定时flush和写buffer(writeBufferSize),可以既保证在数据量小的时候,数据可以在较短时间内被flush(如1秒内),同时又保证在数据量大的时候,写buffer一满就及时进行flush

for (int i = 0; i < threadN; i++) {
   Thread th = new Thread() {
       public void run() {
           while (true) {
               try {
                   sleep(1000); //1 second
              } catch (InterruptedException e) {
                   e.printStackTrace();
              }
synchronized (wTableLog[i]) {
                   try {
                       wTableLog[i].flushCommits();
                  } catch (IOException e) {
                       e.printStackTrace();
                  }
              }
          }
}
  };
   th.setDaemon(true);
   th.start();
}

三.数据读取

1.多HTable并发读

创建多个HTable客户端用于读操作,提高读数据的吞吐量

static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
rTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {
   rTableLog[i] = new HTable(conf, table_log_name);
   rTableLog[i].setScannerCaching(50);
}

2.HTable参数设置

2.1 Scanner Caching hbase.client.scanner.caching配置项可以设置HBase scanner一次从服务端抓取的数据条数,默认情况下一次一条。通过将其设置成一个合理的值,可以减少scan过程中next()的时间开销,代价是scanner需要通过客户端的内存来维持这些被cache的行记录。 有三个地方可以进行配置:1)在HBase的conf配置文件中进行配置;2)通过调用HTable.setScannerCaching(int scannerCaching)进行配置;3)通过调用Scan.setCaching(int caching)进行配置。三者的优先级越来越高。 2.2 Scan Attribute Selection scan时指定需要的Column Family,可以减少网络传输数据量,否则默认scan操作会返回整行所有Column Family的数据。 2.3 Close ResultScanner 通过scan取完数据后,记得要关闭ResultScanner,否则RegionServer可能会出现问题(对应的Server资源无法释放)。

3.批量读

通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录,同样HBase提供了另一个方法:通过调用HTable.get(List)方法可以根据一个指定的row key列表,批量获取多行记录,这样做的好处是批量执行,只需要一次网络I/O开销,这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。

4 多线程并发读

在客户端开启多个HTable读线程,每个读线程负责通过HTable对象进行get操作。下面是一个多线程并发读取HBase,获取店铺一天内各分钟PV值的例子:

public class DataReaderServer {
    //获取店铺一天内各分钟PV值的入口函数
    public static ConcurrentHashMap<String, String> getUnitMinutePV(long uid, long startStamp, long endStamp){
        long min = startStamp;
        int count = (int)((endStamp - startStamp) / (60*1000));
        List<String> lst = new ArrayList<String>();
        for (int i = 0; i <= count; i++) {
           min = startStamp + i * 60 * 1000;
           lst.add(uid + "_" + min);
        }
        return parallelBatchMinutePV(lst);
    }
     //多线程并发查询,获取分钟PV值
?
private static ConcurrentHashMap<String, String> parallelBatchMinutePV(List<String> lstKeys){
       ConcurrentHashMap<String, String> hashRet = new ConcurrentHashMap<String, String>();
       int parallel = 3;
       List<List<String>> lstBatchKeys  = null;
       if (lstKeys.size() < parallel ){
           lstBatchKeys  = new ArrayList<List<String>>(1);
           lstBatchKeys.add(lstKeys);
      }
       else{
           lstBatchKeys  = new ArrayList<List<String>>(parallel);
           for(int i = 0; i < parallel; i++ ){
               List<String> lst = new ArrayList<String>();
               lstBatchKeys.add(lst);
          }
?
           for(int i = 0 ; i < lstKeys.size() ; i ++ ){
               lstBatchKeys.get(i%parallel).add(lstKeys.get(i));
          }
      }
   
   List<Future< ConcurrentHashMap<String, String> >> futures = new ArrayList<Future< ConcurrentHashMap<String, String> >>(5);
   
   ThreadFactoryBuilder builder = new ThreadFactoryBuilder();
   builder.setNameFormat("ParallelBatchQuery");
   ThreadFactory factory = builder.build();
   ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(lstBatchKeys.size(), factory);
   
   for(List<String> keys : lstBatchKeys){
       Callable< ConcurrentHashMap<String, String> > callable = new BatchMinutePVCallable(keys);
       FutureTask< ConcurrentHashMap<String, String> > future = (FutureTask< ConcurrentHashMap<String, String> >) executor.submit(callable);
       futures.add(future);
  }
   executor.shutdown();
   
   // Wait for all the tasks to finish
   try {
     boolean stillRunning = !executor.awaitTermination(
         5000000, TimeUnit.MILLISECONDS);
     if (stillRunning) {
       try {
           executor.shutdownNow();
      } catch (Exception e) {
           // TODO Auto-generated catch block
           e.printStackTrace();
      }
    }
  } catch (InterruptedException e) {
     try {
         Thread.currentThread().interrupt();
    } catch (Exception e1) {
       // TODO Auto-generated catch block
       e1.printStackTrace();
    }
  }
   
   // Look for any exception
   for (Future f : futures) {
     try {
         if(f.get() != null)
        {
             hashRet.putAll((ConcurrentHashMap<String, String>)f.get());
        }
    } catch (InterruptedException e) {
       try {
            Thread.currentThread().interrupt();
      } catch (Exception e1) {
           // TODO Auto-generated catch block
           e1.printStackTrace();
      }
    } catch (ExecutionException e) {
       e.printStackTrace();
    }
  }
   
   return hashRet;
}
//一个线程批量查询,获取分钟PV值
protected static ConcurrentHashMap<String, String> getBatchMinutePV(List<String> lstKeys){
   ConcurrentHashMap<String, String> hashRet = null;
   List<Get> lstGet = new ArrayList<Get>();
   String[] splitValue = null;
   for (String s : lstKeys) {
       splitValue = s.split("_");
       long uid = Long.parseLong(splitValue[0]);
       long min = Long.parseLong(splitValue[1]);
       byte[] key = new byte[16];
       Bytes.putLong(key, 0, uid);
       Bytes.putLong(key, 8, min);
       Get g = new Get(key);
       g.addFamily(fp);
       lstGet.add(g);
  }
   Result[] res = null;
   try {
       res = tableMinutePV[rand.nextInt(tableN)].get(lstGet);
  } catch (IOException e1) {
       logger.error("tableMinutePV exception, e=" + e1.getStackTrace());
  }
?
   if (res != null && res.length > 0) {
       hashRet = new ConcurrentHashMap<String, String>(res.length);
       for (Result re : res) {
           if (re != null && !re.isEmpty()) {
               try {
                   byte[] key = re.getRow();
                   byte[] value = re.getValue(fp, cp);
                   if (key != null && value != null) {
                       hashRet.put(String.valueOf(Bytes.toLong(key,
                               Bytes.SIZEOF_LONG)), String.valueOf(Bytes
                              .toLong(value)));
                  }
              } catch (Exception e2) {
                   logger.error(e2.getStackTrace());
              }
          }
      }
  }
?
   return hashRet;
}
//调用接口类,实现Callable接口
class BatchMinutePVCallable implements Callable<ConcurrentHashMap<String, String>>{
    private List<String> keys;
?
    public BatchMinutePVCallable(List<String> lstKeys ) {
        this.keys = lstKeys;
    }
?
    public ConcurrentHashMap<String, String> call() throws Exception {
        return DataReadServer.getBatchMinutePV(keys);
    }
}

5 缓存查询结果

对于频繁查询HBase的应用场景,可以考虑在应用程序中做缓存,当有新的查询请求时,首先在缓存中查找,如果存在则直接返回,不再查询HBase;否则对HBase发起读请求查询,然后在应用程序中将查询结果缓存起来。至于缓存的替换策略,可以考虑LRU等常用的策略。

6 Blockcache

HBase上Regionserver的内存分为两个部分,一部分作为Memstore,主要用来写;另外一部分作为BlockCache,主要用于读。 写请求会先写入Memstore,Regionserver会给每个region提供一个Memstore,当Memstore满64MB以后,会启动 flush刷新到磁盘。当Memstore的总大小超过限制时(heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9),会强行启动flush进程,从最大的Memstore开始flush直到低于限制。 读请求先到Memstore中查数据,查不到就到BlockCache中查,再查不到就会到磁盘上读,并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略,因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后,会启动淘汰机制,淘汰掉最老的一批数据。 一个Regionserver上有一个BlockCache和N个Memstore,它们的大小之和不能大于等于heapsize * 0.8,否则HBase不能启动。默认BlockCache为0.2,而Memstore为0.4。对于注重读响应时间的系统,可以将 BlockCache设大些,比如设置BlockCache=0.4,Memstore=0.39,以加大缓存的命中率。 有关BlockCache机制,请参考这里:HBase的Block cache,HBase的blockcache机制,hbase中的缓存的计算与使用。

protouf

1.安装

上传protobuf-2.5.0.tar.gz

解压protobuf-2.5.0.tar.gz

tar -zxvf protobuf-2.5.0.tar.gz

添加依赖

yum install gcc-c++ -y

配置

./configure --prefix=/opt/sxt/protobuf/

编译安装

make && make install

2.使用

编写proto文件

package com.shsxt.util; 
?
//创建一个消息对象
message PhoneRecord
{
required string otherphone = 1;
optional int32 time = 2;
optional int64 date = 3;
optional string     type = 4;
}
?
message PhoneRecordDay
{
repeated PhoneRecord phoneRecord=1;
}
?
message PhoneRecordMonth
{
repeated PhoneRecordDay phoneRecordDay=1;
}

将proto文件编译成java类

./protoc --java_out=/root/ PhoneProto.proto

以上是关于HBase region size 到底设置多大的主要内容,如果未能解决你的问题,请参考以下文章

HBase探索篇 _ 单节点多RegionServer部署与性能测试

Hbase分区

hbase 基本架构

HBase集群规划

HBase优化之预分区

HBASE 系列 一个RegionServer的Region数量多少合适?