HBase踩过的坑——持续更新

  • 时间:
  • 浏览:4
  • 来源:5分排列5_5分排列3

   <name>hbase.client.write.buffer</name>

     车联网的什么都有有表嘴笨 有的是1000多个region。否则可能性写入的数据有的是全版随机的,什么都有有有每次有的是client只连接一个多 region去写,什么都有有有压测时没出现此什么的问题。

    能源站对表预建了20个Region,随着数据量膨胀分裂到了11000个

2,  禁用预写日志:put.setDurability(Durability.SKIP_WAL);//禁用hbase的预写日志功能(否则禁用预写日志的法律法律依据不足英文安全)

    可能性写入法律法律依据是全版随机写入到各个region中,可能性region数量太多,少量时间浪费在停留region释放资源,获取region连接,释放连接。。

什么的问题描述:

<property>

处理方案:

alter'batteryData',{METADATA=>{'SPLIT_POLICY'=>'org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy'}},{NAME=> 't'}

   </property>

  在某一个多 时刻,电池数据表的以什么都有有规则开头的数据,比如M12******,那些电池老要 在上报数据,可能性HBase的存储是按照字典顺序排序的,所有某一时刻,例如规则的数据落在了同一个多 region上,造成了数据热点。

  什么的问题描述:

处理法律法律依据:

   什么的问题描述:

     观察HBase目前配置:memstore:256M,hbase.hregion.max.filesize:10G (一个多 region最多管理10G的HFile),当写入的数据总量超过一定数量(1T)时,写入传输传输速率放慢。写入法律法律依据rowkey前加hash。

    <value>100000000</value>

     发现有写对象在持续增长,后会 观察写入HBase的监控,发现Hbase每秒写入数据操作在0.001次后会 子,通过对象分析,发现线程池在执行任务后会 ,会有个LinkedBlockingQueue的队列,可能性HBase写入阻塞,原因分析分析队列持续递增,FGC持续进行,判断什么的问题发生了HBase上方。

     禁用表的自动分期策略,可能性时候有还要,手动分区。

历史数据的消费过程,否则把数据写入HBase的过程,否则写入HBase过慢,容易造成消费不过来,产生数据堆积,可能性数据堆积,会影响Kafka拉取数据消费发送心跳的超时。

   处理法律法律依据:

1,  HBase写操作尽量采用批量写入操作;

  采用了固定线程池持续运行一段时间后会 ,观察GC发现:

4,消费过程采用线程池写入:最后会 时候开始用的可回收线程池,否则观察GC发现,FGC太多,否则数据量大了,CUP占用不足英文,最后还是采用固定的数目的线程池,多开有几个客户端进行消费;

3,  禁止autoflush:table.setAutoFlushTo(false); 并配置write buff: