HBase踩过的坑——持续更新

  • 时间:
  • 浏览:0
  • 来源:大发快三代理—大发大发彩票app

避免最好的妙招:

     发现有写对象在持续增长,日后 观察写入HBase的监控,发现Hbase每秒写入数据操作在0.001次从前子,通过对象分析,发现tcp连接池在执行任务完后 ,会有个LinkedBlockingQueue的队列,机会HBase写入阻塞,意味分析队列持续递增,FGC持续进行,判断问题图片位于了HBase里边。

4,消费过程采用tcp连接池写入:最刚现在开始用的可回收tcp连接池,否则观察GC发现,FGC这麼多 ,否则数据量大了,CUP占用不足,最后还是采用固定的数目的tcp连接池,多开十几只 客户端进行消费;

    <value>300000</value>

问题图片描述:

   避免最好的妙招:

     观察HBase目前配置:memstore:256M,hbase.hregion.max.filesize:10G (从前region最多管理10G的HFile),当写入的数据总量超过一定数量(1T)时,写入时延更慢。写入最好的妙招rowkey前加hash。

  在某从前时刻,电池数据表的以某些规则开头的数据,比如M12******,有有哪些电池无缘无故在上报数据,机会HBase的存储是按照字典顺序排序的,所有某一时刻,之类规则的数据落在了同从前region上,造成了数据热点。

  问题图片描述:

   问题图片描述:

避免方案:

  采用了固定tcp连接池持续运行一段时间完后 ,观察GC发现:

    机会写入最好的妙招是完整篇 随机写入到各个region中,机会region数量这麼多 ,多量时间浪费在在等待region释放资源,获取region连接,释放连接。。

     车联网的某些表虽否则会30多个region。否则机会写入的数据后该完整篇 随机的,就说 我每次后该client只连接从前region去写,就说 我压测时没出現此问题图片。

     禁用表的自动分期策略,机会日后有可以,手动分区。

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

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

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

<property>

   </property>

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

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

2,  禁用预写日志:put.setDurability(Durability.SKIP_WAL);//禁用hbase的预写日志功能(否则禁用预写日志的最好的妙招不足安全)

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