hbase shell的问题

zxpns18 回复了问题 • 3 人关注 • 2 个回复 • 232 次浏览 • 2019-02-28 15:32 • 来自相关话题

cdh4.5.0 hbase 如何定时删除数据

zxpns18 回复了问题 • 3 人关注 • 2 个回复 • 229 次浏览 • 2019-02-28 15:24 • 来自相关话题

hbase优化之旅(一)探索regionserver参数优化

chuxiao 发表了文章 • 2 个评论 • 242 次浏览 • 2019-02-28 13:51 • 来自相关话题

要有目录和章节标题功能,图片能直接粘贴过来就好了。
 优化的目的
我们线上hbase集群使用了group分组功能,但没有针对不同业务分组的特点做特殊优化,hbase服务能力没有彻底激发出来。
本文记录了对某个业务分组参数优化的探索,借此机会深入了解不同配置对regionserver监控指标和机器负载的影响。 优化后,单台regionserver查询延迟更低,磁盘IO降低,系统更稳定。从而提高吞吐能力,进而减少机器,提升资源利用率的能力,节约成本。
 
要解决那些问题
目前该业务分组发现的问题主要在写入。虽然资源利用率不高,但时不时会rpcp99变慢。从监控可以看到,队列等待时间会间隔性变长。看regionserver日志,hlogs上限触发同时刷太多region,flush和compact压力集中。刷了好多小文件,写放大效果明显。
 
问题分析
分组有17台regionserver,单台有大概520个region,白天请求量较为平稳。分析一台的使用情况。
 
物理资源使用情况
机器类型
2*E5-2650v4(2*12核),8*32G,2*150G(120G) SATA SSD+12*800G(960G) SATA SSD
 
机器负载
cpu和load并不高。



内存看,由于应用内存分配较为保守,regionserver堆内堆外共150g,datanode 4g,很大一块给了操作系统读cache。但regionserver本身也配置了100g的读cache,操作系统读cache没什么用。


磁盘读流量较高,写流量50MB/s。网络In 20MB,Out 40到80MB波动。



磁盘读流量主要是本地regionserver 业务读和compact读,写流量主要是本地regionserver写wal,flush,compact,以及其他datanode的写副本。
网络in主要是业务写入请求和其他datanode写副本请求,网络out主要是业务查询响应和regionserver 写wal,flush,compact写其他datanode副本的请求。
由于业务查询主要走内存缓存(95%),hifile又有很高的压缩比(1:5),如果不考虑服务端数据过滤的情况,业务读引起的磁盘IO应该只是网络查询响应IO的百分之一。
当然服务端数据过滤的影响是需要考虑的,但相比网络out磁盘读流量太高了不正常。compact 读小文件写大文件压缩率提高了,这也是磁盘读流量大于网络OUT的可能。 磁盘读流量很大应该是compact读引起的,这个时间段又没有major compacted,说明可能小文件很多引起了写放大。

regionserver使用情况
regionserver配置
版本0.98.21,配置见附录一。
 
指标监控
队列等待时间p99最多有150ms,执行时间p99(ProcessCallTime_99th_percentile)在45ms内。
 










 
读缓存命中率95%,还ok


 

有一些慢写入
 






大概20分钟memstore整体刷一次,slowput的出现在刷memstore时
 











 
compaction排队的频率和memstore刷新基本一致,无major,说明是memstore定期大flush引起。
 















 
 

flush排队也发生在定期memstore flush时
 






看regionserver日志,固定间隔就会hlogs上限触发同时刷很多region,22MB的memstore刷5MB hifile,同时刷了好多小文件,又马上compact,写放大效果明显。09:34:04,075 INFO [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 69 regions(s) ...

09:34:27,339 INFO [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 222 regions(s) ...

...

09:34:27,601 INFO [MemStoreFlusher.1] regionserver.DefaultStoreFlusher: Flushed, sequenceid=311232252, memsize=22.6 M, hasBloomFilter=true, into tmp file ...

09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HStore: Added ...., entries=27282, sequenceid=311232252, filesize=5.4 M

09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HRegion: Finished memstore flush of ~23.6 M/24788698, currentsize=0/0 for region .... in 267ms, sequenceid=311232252, compaction requested=true

堆内存和gc情况,波动主要发生在周期刷memstore时。
 

 
问题总结
1.hbase.regionserver.maxlogs太少,
按照hlog和memstore的关系公式hbase.regionserver.hlog.blocksize * hbase.reionserver.logroll.mutiplier*hbase.regionserver.maxlogs
>= hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE至少应该是95。配置太低频繁由于hlog上限触发几百个region flush,flush的都是小文件,flush和compact压力都大。

2.内存空闲太多,预留20%空闲就可以了。但要注意g1内存过大可能导致gc时间变长。

3.region数太多,大部分region的memstore没有128MB就强制flush了。正常应尽量保证每个 region 能够分配到 Flushsize 大小的内存,尽可能的 flush 大文件,从而减少后续 Compaction 开销。region数可以通过region合并减少,但这次先不优化,通过增大内存方式缓解。

参数优化探索
第一次修改
期望优化hlogs触发强刷memstore。
hbase.regionserver.maxlogs 52改为95.
重启regionserver。

变成47分钟触发hlog上限刷一次memstore了。











日志看,47分钟左右hlogs上限触发257 region同时刷新。和之前强刷一样,很多memstore20MB,压缩后的hfile5MB。总memstore峰值最多18.35GB,部分region 128MB提前flush了,所以到不了理论上限22.5GB。
 
 
compaction排队的频率降低了






 
队列等待时间波峰的间隔变长,有所改善。
 










 

gc次数和时间平常值略有降低,波峰提高。
 










 

slowput略有减少。





优化有一定效果。
 
 
第二次修改
由于region数太多,单个region可能不到128MB就触发hlog的强刷了。调大内存从而增加memstore和hlogs上限。计算预计在hlog上限前肯定能触发每小时一刷。调大了handler线程数。hbase-env.sh
1.jvm XX:MaxDirectMemoryize 调为110GB 2.堆内Xmx调为80g
hbase-site.xml
3.hbase.bucketcache.size 112640 110g,hfile.block.cache.size 0.14 4.hbase.regionserver.global.memstore.upperLimit 0.56 44.8g, hbase.regionserver.global.memstore.lowerLimit 0.5 40g, 5.hbase.regionserver.hlog.blocksize 268435456 256MB,显示配置,默认和hdfs块大小一致,也是配置的这个值。 hbase.regionserver.maxlogs 1776.hbase.regionserver.handler.count 384







重启regionserver,观察监控。

memstore1小时一降,并不是hlog上限触发的,是每小时定时刷新触发的。
 









 

看日志,16:31陆续有region128MB flush。16:59 memstore 17.5GB, hlogs 125时,大部分region触发1小时刷新,delay几秒到几十秒。刷新时间还是较为集中,有flush和compact排队。其中6点的compactsize大且持续,应该是很多region需要compact的hfile变大了。
 













慢put变多,rpc执行时间峰值变高了,队列等待时间p99最长居然到2s!















  
 

原因是gc峰值变高了,影响regionserver业务了。
 






堆内存变大了,gc回收的变多,gc时间就变长了。
 






优化有些副作用,要消除。


第三次修改
期望优化增大堆内存引起的gc问题。memstore刷新间隔改为2小时,刷新size改为256MB1.XX:InitiatingHeapOccupancyPercent=65 调整为XX:InitiatingHeapOccupancyPercent=75 之前hmaxlogs52限制实际memstore最大12g左右,堆内读写缓存加起来0.45左右。现在读写缓存加起来最多0.7了,所以调大触发gc的上限(bad modify) 2. -XX:ConcGCThreads=8,-XX:ParallelGCThreads=30,-XX:G1MixedGCCountTarget=32 增大gc并发,文档说建议逻辑核的5/8,48核30。并发标记跟着调大。拆解gc次数降低单次时间。 3.hbase.regionserver.optionalcacheflushinterval 改 7200000 4.hbase.hregion.memstore.flush.size 268435456 128MB的压缩会也就22MB hfile没多大,所以单个memstore内存改为256MB。
重启观察。

发现由于同时调大间隔时间和flush size,又变成1小时40分钟hlog上限触发强刷了


 
看日志,同时刷的region数少了,170个,flush和compact排队有所改善。



rpc和队列时间p99峰值还是太高,慢put不少




整体gc count减少,gc时间峰值变多变高


看gc的日志,调整gc并发,gc的系统时间依然很长,需要继续调整。
 
第四五次修改
gc触发阈值降低,提前gc。gc并发改小,一次最大10%的region。间隔时间改回1小时。改了两次,最终修改如下1.XX:InitiatingHeapOccupancyPercent=65, 又改到60 提前
2. -XX:ConcGCThreads=4,-XX:ParallelGCThreads=16,-XX:G1OldCSetRegionThresholdPercent=10 提高一次gc最多回收的region数。
3. hbase.regionserver.optionalcacheflushinterval 去掉,改回一小时。重启观察。

memstore又是1小时一刷很多region,由于启动时间较短只执行了几个周期,还没有分散开。


flush和compact排队还是按小时出现


 

慢put少了,rpc和队列等待p99降低了,但希望能更低一些。




gc变多了,而时间少了一些但峰值依然挺高,看gc日志young gc时间也有挺长的,mixed gc时间依然挺长。


需要继续调优。
 
 
第六次修改
继续调gc参数,young gc内存控制大小。继续增大memstore配置让其能2小时一刷。由于region数太多,去掉flush 256MB设置。-XX:G1MixedGCCountTarget=16 增大一次全局标记后mixed gc最多执行的次数
-XX:G1HeapWastePercent=10 允许保留10%垃圾
-XX:G1MaxNewSizePercent=20 young 上限20%,避免young区太大gc慢
hbase.regionserver.global.memstore.upperLimit 0.6 调大上限
hbase.regionserver.global.memstore.lowerLimit 0.54
hbase.regionserver.maxlogs 200 调大上限
hbase.regionserver.optionalcacheflushinterval 7200000 2小时一刷
hbase.hregion.memstore.flush.size 去掉用默认128MB
regionserver指标
2小时一刷memstore


flush和compact排队都少了

 

慢put减少,rpc和队列等待时间p99整体降低,峰值也降了很多



 

gc更平衡,峰值时间更短

 

机器负载
cpu load依然很低



磁盘读IO下降到1/4,网络out有所下降。



内存还有20%+的空闲,还可以多用点。

优化有效果。
 
 
总结
优化成果
本次优化通过调整regionserver参数和gc参数,减少小文件flush,降低compact写放大。平均响应时间降低,响应时间高峰次数减少。磁盘读写IO减少很多,从而增加了磁盘的使用时间。
 
后续优化方向
减少region数
单台regionserver上的region偏多。
region都是预分区,预分区时按预估总数据大小计算的分区数,但没考虑hfile压缩。几张大表单region的存储量都是region hfile上限容量的几分之一,可以合并region,减少region数。
 
增大内存配置
保留10%空闲即可
 
gc深入调优
这次gc参数调优没有明确目标,没有优化方法论,双盲优化,事倍功半,要深入gc参数细节,用明确的方法论,朝明确的目标优化。敬请期待。
 
减少服务器
瓶颈可能在存储容量上。hdfs逻辑存储共36.0 T,17台regionserver可以支持50TB逻辑存储容量,可以迭代减少几台,达到节约成本的目的。
 
附录
hbase-site.xml原始配置


hbase-env.sh原始配置export HBASE_REGIONSERVER_OPTS="-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:${HBASE_LOG_DIR}/gc-`date +'%Y%m%d%H%M'` -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=512M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${HBASE_LOG_DIR}/hbase.heapdump -XX:ErrorFile=${HBASE_LOG_DIR}/hs_err_pid%p.log -XX:+PrintAdaptiveSizePolicy -XX:+PrintFlagsFinal -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UnlockExperimentalVMOptions -XX:+ParallelRefProcEnabled -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60 -XX:MaxTenuringThreshold=1 -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=8 -XX:InitiatingHeapOccupancyPercent=65 -XX:MaxDirectMemorySize=100g -XX:G1OldCSetRegionThresholdPercent=5 -Xmx50g -Xms50g"




g1参考资料
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html 
 
专栏地址
https://zhuanlan.zhihu.com/p/57438971
 
 
 
 
 
 
 
 
 
 
 
 
==============分割线=============附件删了就编辑不过了==================
  查看全部
要有目录和章节标题功能,图片能直接粘贴过来就好了。
 优化的目的
我们线上hbase集群使用了group分组功能,但没有针对不同业务分组的特点做特殊优化,hbase服务能力没有彻底激发出来。
本文记录了对某个业务分组参数优化的探索,借此机会深入了解不同配置对regionserver监控指标和机器负载的影响。 优化后,单台regionserver查询延迟更低,磁盘IO降低,系统更稳定。从而提高吞吐能力,进而减少机器,提升资源利用率的能力,节约成本。
 
要解决那些问题
目前该业务分组发现的问题主要在写入。虽然资源利用率不高,但时不时会rpcp99变慢。从监控可以看到,队列等待时间会间隔性变长。看regionserver日志,hlogs上限触发同时刷太多region,flush和compact压力集中。刷了好多小文件,写放大效果明显。
 
问题分析
分组有17台regionserver,单台有大概520个region,白天请求量较为平稳。分析一台的使用情况。
 
物理资源使用情况
机器类型
2*E5-2650v4(2*12核),8*32G,2*150G(120G) SATA SSD+12*800G(960G) SATA SSD
 
机器负载
cpu和load并不高。



内存看,由于应用内存分配较为保守,regionserver堆内堆外共150g,datanode 4g,很大一块给了操作系统读cache。但regionserver本身也配置了100g的读cache,操作系统读cache没什么用。


磁盘读流量较高,写流量50MB/s。网络In 20MB,Out 40到80MB波动。



磁盘读流量主要是本地regionserver 业务读和compact读,写流量主要是本地regionserver写wal,flush,compact,以及其他datanode的写副本。
网络in主要是业务写入请求和其他datanode写副本请求,网络out主要是业务查询响应和regionserver 写wal,flush,compact写其他datanode副本的请求。
由于业务查询主要走内存缓存(95%),hifile又有很高的压缩比(1:5),如果不考虑服务端数据过滤的情况,业务读引起的磁盘IO应该只是网络查询响应IO的百分之一。
当然服务端数据过滤的影响是需要考虑的,但相比网络out磁盘读流量太高了不正常。compact 读小文件写大文件压缩率提高了,这也是磁盘读流量大于网络OUT的可能。 磁盘读流量很大应该是compact读引起的,这个时间段又没有major compacted,说明可能小文件很多引起了写放大。

regionserver使用情况
regionserver配置
版本0.98.21,配置见附录一。
 
指标监控
队列等待时间p99最多有150ms,执行时间p99(ProcessCallTime_99th_percentile)在45ms内。
 
0QueueCallTime.png


0rpc99.png


 
读缓存命中率95%,还ok


 

有一些慢写入
 
0slowput.png



大概20分钟memstore整体刷一次,slowput的出现在刷memstore时
 
0memstore.png


0hlongfilecount.png



 
compaction排队的频率和memstore刷新基本一致,无major,说明是memstore定期大flush引起。
 
0compactionQueue.png


0compactedcellsize.png


0major.png


 
 

flush排队也发生在定期memstore flush时
 
0flushqueue.png



看regionserver日志,固定间隔就会hlogs上限触发同时刷很多region,22MB的memstore刷5MB hifile,同时刷了好多小文件,又马上compact,写放大效果明显。
09:34:04,075 INFO  [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 69 regions(s) ...

09:34:27,339 INFO [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 222 regions(s) ...

...

09:34:27,601 INFO [MemStoreFlusher.1] regionserver.DefaultStoreFlusher: Flushed, sequenceid=311232252, memsize=22.6 M, hasBloomFilter=true, into tmp file ...

09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HStore: Added ...., entries=27282, sequenceid=311232252, filesize=5.4 M

09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HRegion: Finished memstore flush of ~23.6 M/24788698, currentsize=0/0 for region .... in 267ms, sequenceid=311232252, compaction requested=true


堆内存和gc情况,波动主要发生在周期刷memstore时。
 

 
问题总结
1.hbase.regionserver.maxlogs太少,
按照hlog和memstore的关系公式
hbase.regionserver.hlog.blocksize * hbase.reionserver.logroll.mutiplier*hbase.regionserver.maxlogs 
>= hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE
至少应该是95。配置太低频繁由于hlog上限触发几百个region flush,flush的都是小文件,flush和compact压力都大。

2.内存空闲太多,预留20%空闲就可以了。但要注意g1内存过大可能导致gc时间变长。

3.region数太多,大部分region的memstore没有128MB就强制flush了。正常应尽量保证每个 region 能够分配到 Flushsize 大小的内存,尽可能的 flush 大文件,从而减少后续 Compaction 开销。region数可以通过region合并减少,但这次先不优化,通过增大内存方式缓解。

参数优化探索
第一次修改
期望优化hlogs触发强刷memstore。
hbase.regionserver.maxlogs 52改为95.
重启regionserver。

变成47分钟触发hlog上限刷一次memstore了。

1hlog.png


1memstore.png


日志看,47分钟左右hlogs上限触发257 region同时刷新。和之前强刷一样,很多memstore20MB,压缩后的hfile5MB。总memstore峰值最多18.35GB,部分region 128MB提前flush了,所以到不了理论上限22.5GB。
 
 
compaction排队的频率降低了

1compact.png


 
队列等待时间波峰的间隔变长,有所改善。
 
1queuecalltime.png


1rpc.png


 

gc次数和时间平常值略有降低,波峰提高。
 
1memstore.png


1gc.png


 

slowput略有减少。
1slowput.png


优化有一定效果。
 
 
第二次修改
由于region数太多,单个region可能不到128MB就触发hlog的强刷了。调大内存从而增加memstore和hlogs上限。计算预计在hlog上限前肯定能触发每小时一刷。调大了handler线程数。
hbase-env.sh
1.jvm XX:MaxDirectMemoryize 调为110GB 2.堆内Xmx调为80g
hbase-site.xml
3.hbase.bucketcache.size 112640 110g,hfile.block.cache.size 0.14 4.hbase.regionserver.global.memstore.upperLimit 0.56 44.8g, hbase.regionserver.global.memstore.lowerLimit 0.5 40g, 5.hbase.regionserver.hlog.blocksize 268435456 256MB,显示配置,默认和hdfs块大小一致,也是配置的这个值。
 hbase.regionserver.maxlogs 177
6.hbase.regionserver.handler.count 384







重启regionserver,观察监控。

memstore1小时一降,并不是hlog上限触发的,是每小时定时刷新触发的。
 
2memstore.png


2hlog.png

 

看日志,16:31陆续有region128MB flush。16:59 memstore 17.5GB, hlogs 125时,大部分region触发1小时刷新,delay几秒到几十秒。刷新时间还是较为集中,有flush和compact排队。其中6点的compactsize大且持续,应该是很多region需要compact的hfile变大了。
 

2flush_compact.png


2compactsize.png




慢put变多,rpc执行时间峰值变高了,队列等待时间p99最长居然到2s!

2slowput.png


2rpc.png


2queuecalltime.png

  
 

原因是gc峰值变高了,影响regionserver业务了。
 
2gc.png



堆内存变大了,gc回收的变多,gc时间就变长了。
 
2memheap.png



优化有些副作用,要消除。


第三次修改
期望优化增大堆内存引起的gc问题。memstore刷新间隔改为2小时,刷新size改为256MB
1.XX:InitiatingHeapOccupancyPercent=65 调整为XX:InitiatingHeapOccupancyPercent=75 之前hmaxlogs52限制实际memstore最大12g左右,堆内读写缓存加起来0.45左右。现在读写缓存加起来最多0.7了,所以调大触发gc的上限(bad modify) 
2. -XX:ConcGCThreads=8,-XX:ParallelGCThreads=30,-XX:G1MixedGCCountTarget=32 增大gc并发,文档说建议逻辑核的5/8,48核30。并发标记跟着调大。拆解gc次数降低单次时间。 3.hbase.regionserver.optionalcacheflushinterval 改 7200000 4.hbase.hregion.memstore.flush.size 268435456 128MB的压缩会也就22MB hfile没多大,所以单个memstore内存改为256MB。

重启观察。

发现由于同时调大间隔时间和flush size,又变成1小时40分钟hlog上限触发强刷了


 
看日志,同时刷的region数少了,170个,flush和compact排队有所改善。



rpc和队列时间p99峰值还是太高,慢put不少




整体gc count减少,gc时间峰值变多变高


看gc的日志,调整gc并发,gc的系统时间依然很长,需要继续调整。
 
第四五次修改
gc触发阈值降低,提前gc。gc并发改小,一次最大10%的region。间隔时间改回1小时。改了两次,最终修改如下
1.XX:InitiatingHeapOccupancyPercent=65, 又改到60 提前 
2. -XX:ConcGCThreads=4,-XX:ParallelGCThreads=16,-XX:G1OldCSetRegionThresholdPercent=10 提高一次gc最多回收的region数。
3. hbase.regionserver.optionalcacheflushinterval 去掉,改回一小时。
重启观察。

memstore又是1小时一刷很多region,由于启动时间较短只执行了几个周期,还没有分散开。


flush和compact排队还是按小时出现


 

慢put少了,rpc和队列等待p99降低了,但希望能更低一些。




gc变多了,而时间少了一些但峰值依然挺高,看gc日志young gc时间也有挺长的,mixed gc时间依然挺长。


需要继续调优。
 
 
第六次修改
继续调gc参数,young gc内存控制大小。继续增大memstore配置让其能2小时一刷。由于region数太多,去掉flush 256MB设置。
-XX:G1MixedGCCountTarget=16 增大一次全局标记后mixed gc最多执行的次数 
-XX:G1HeapWastePercent=10 允许保留10%垃圾
-XX:G1MaxNewSizePercent=20 young 上限20%,避免young区太大gc慢
hbase.regionserver.global.memstore.upperLimit 0.6 调大上限
hbase.regionserver.global.memstore.lowerLimit 0.54
hbase.regionserver.maxlogs 200 调大上限
hbase.regionserver.optionalcacheflushinterval 7200000 2小时一刷
hbase.hregion.memstore.flush.size 去掉用默认128MB

regionserver指标
2小时一刷memstore


flush和compact排队都少了

 

慢put减少,rpc和队列等待时间p99整体降低,峰值也降了很多



 

gc更平衡,峰值时间更短

 

机器负载
cpu load依然很低



磁盘读IO下降到1/4,网络out有所下降。



内存还有20%+的空闲,还可以多用点。

优化有效果。
 
 
总结
优化成果
本次优化通过调整regionserver参数和gc参数,减少小文件flush,降低compact写放大。平均响应时间降低,响应时间高峰次数减少。磁盘读写IO减少很多,从而增加了磁盘的使用时间。
 
后续优化方向
减少region数
单台regionserver上的region偏多。
region都是预分区,预分区时按预估总数据大小计算的分区数,但没考虑hfile压缩。几张大表单region的存储量都是region hfile上限容量的几分之一,可以合并region,减少region数。
 
增大内存配置
保留10%空闲即可
 
gc深入调优
这次gc参数调优没有明确目标,没有优化方法论,双盲优化,事倍功半,要深入gc参数细节,用明确的方法论,朝明确的目标优化。敬请期待。
 
减少服务器
瓶颈可能在存储容量上。hdfs逻辑存储共36.0 T,17台regionserver可以支持50TB逻辑存储容量,可以迭代减少几台,达到节约成本的目的。
 
附录
hbase-site.xml原始配置


hbase-env.sh原始配置
export HBASE_REGIONSERVER_OPTS="-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:${HBASE_LOG_DIR}/gc-`date +'%Y%m%d%H%M'` -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=512M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${HBASE_LOG_DIR}/hbase.heapdump -XX:ErrorFile=${HBASE_LOG_DIR}/hs_err_pid%p.log -XX:+PrintAdaptiveSizePolicy -XX:+PrintFlagsFinal -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UnlockExperimentalVMOptions -XX:+ParallelRefProcEnabled -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60 -XX:MaxTenuringThreshold=1 -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=8 -XX:InitiatingHeapOccupancyPercent=65 -XX:MaxDirectMemorySize=100g -XX:G1OldCSetRegionThresholdPercent=5 -Xmx50g -Xms50g"




g1参考资料
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html 
 
专栏地址
https://zhuanlan.zhihu.com/p/57438971
 
 
 
 
 
 
 
 
 
 
 
 
==============分割线=============附件删了就编辑不过了==================
 

请问如何发表技术文章

过往记忆 回复了问题 • 2 人关注 • 1 个回复 • 131 次浏览 • 2019-02-28 10:36 • 来自相关话题

hbase中存储视频文件,下载视频文件流程?

zxpns18 回复了问题 • 6 人关注 • 6 个回复 • 615 次浏览 • 2019-02-28 09:53 • 来自相关话题

hbase hdfs性能指标集成到zabbix方法共享

回复

zxpns18 发起了问题 • 1 人关注 • 0 个回复 • 152 次浏览 • 2019-02-28 09:51 • 来自相关话题

中国HBase技术社区第十届meetup--HBase生态实践 (杭州站)

过往记忆 发表了文章 • 0 个评论 • 258 次浏览 • 2019-02-27 14:16 • 来自相关话题

报名地址:点我报名
 
演讲主题及嘉宾
Topic1:基于HBase和Spark构建企业级数据处理平台
           首先介绍下Spark的发展之路,HBase结合Spark如何构建企业级数据处理平台,最后介绍下相关的案例。
Topic2:HBase在有赞的平台实践和应用
          介绍HBase在有赞的部署实践,管控平台实践,我们在社区1.2.6版本之上做了哪些改造,修复了哪些bug,以及结合在有赞的业务场景,介绍HBase的应用实践。
Topic3:云HBase之OpenTSDB时序引擎压缩优化
          1.OpenTSDB设计介绍
          2.介绍云HBase OpenTSDB 压缩优化
          3.介绍云HBase OpenTSDB 使用模式
Topic4:Flink+HBase实时计算场景
         1.Flink简介
         2.Flink优势
         3.Flink典型应用场景
         4.Flink和HBase结合的案例分享

议程安排

13:30-14:00  签到
14:00-14:40  基于HBase和Spark构建企业级数据处理平台   讲师:沐远
14:40-15:20  HBase在有赞的平台实践和应用 讲师:赵原
15:20-15:30  抽奖环节
15:30-16:10  云HBase之OpenTSDB时序引擎压缩优化  讲师:郭泽晖
16:10-16:50  Flink+HBase实时计算场景 讲师:吾与

*主办:中国HBase技术社区;云栖社区

*协办:阿里云飞天八部多模型数据库组;DataFun社区

*合作伙伴:云栖TechDay;开源中国;SegmentFault;掘金;活动行;示说网
 




  查看全部
报名地址:点我报名
 
演讲主题及嘉宾
  • Topic1:基于HBase和Spark构建企业级数据处理平台

           首先介绍下Spark的发展之路,HBase结合Spark如何构建企业级数据处理平台,最后介绍下相关的案例。
  • Topic2:HBase在有赞的平台实践和应用

          介绍HBase在有赞的部署实践,管控平台实践,我们在社区1.2.6版本之上做了哪些改造,修复了哪些bug,以及结合在有赞的业务场景,介绍HBase的应用实践。
  • Topic3:云HBase之OpenTSDB时序引擎压缩优化

          1.OpenTSDB设计介绍
          2.介绍云HBase OpenTSDB 压缩优化
          3.介绍云HBase OpenTSDB 使用模式
  • Topic4:Flink+HBase实时计算场景

         1.Flink简介
         2.Flink优势
         3.Flink典型应用场景
         4.Flink和HBase结合的案例分享

议程安排

13:30-14:00  签到
14:00-14:40  基于HBase和Spark构建企业级数据处理平台   讲师:沐远
14:40-15:20  HBase在有赞的平台实践和应用 讲师:赵原
15:20-15:30  抽奖环节
15:30-16:10  云HBase之OpenTSDB时序引擎压缩优化  讲师:郭泽晖
16:10-16:50  Flink+HBase实时计算场景 讲师:吾与

*主办:中国HBase技术社区;云栖社区

*协办:阿里云飞天八部多模型数据库组;DataFun社区

*合作伙伴:云栖TechDay;开源中国;SegmentFault;掘金;活动行;示说网
 
议程图-2.jpg

 

HBase社区福利 | HBase初学者的福利来袭

过往记忆 发表了文章 • 0 个评论 • 288 次浏览 • 2019-02-20 13:46 • 来自相关话题

HBase 是一个分布式存储、数据库引擎,可以支持千万的QPS、PB级别的存储,这些都已经在生产环境验证,并且在广大的公司有大量的应用。根据目前公开的数据,阿里巴巴 HBase 集群规模为 12000 多台;京东 HBase 集群规模为 5000 多台;360 HBase 规模为 12500 台;爱奇艺 6000 多台。

HBase 可以说是一个数据库,也可以说是一个存储。拥有双重属性的 HBase 天生就具备广阔的应用场景。在2.0中,引入了OffHeap降低了延迟,可以满足在线的需求。引入MOB,可以存储10M左右的对象,完全适应了对象存储。另外由于自身的并发能力、存储能力,可以说是一个很有竞争力的引擎。HBase 在各大公司的应用场景包括以下几点:
 
推荐画像:特别是用户的画像,是一个比较大的稀疏矩阵,蚂蚁的风控就是构建在HBase之上对象存储:我们知道不少的头条类、新闻类的的新闻、网页、图片存储在HBase之中,一些病毒公司的病毒库也是存储在HBase之中时序数据:HBase之上有OpenTSDB模块,可以满足时序类场景的需求时空数据:主要是轨迹、气象网格之类,滴滴打车的轨迹数据主要存在HBase之中,另外在技术所有大一点的数据量的车联网企业,数据都是存在HBase之中CubeDB OLAP:Kylin一个cube分析工具,底层的数据就是存储在HBase之中,不少客户自己基于离线计算构建cube存储在hbase之中,满足在线报表查询的需求消息/订单:在电信领域、银行领域,不少的订单查询底层的存储,另外不少通信、消息同步的应用构建在HBase之上Feeds流:典型的应用就是xx朋友圈类似的应用NewSQL:之上有Phoenix的插件,可以满足二级索引、SQL的需求,对接传统数据需要SQL非事务的需求。

HBase 有着如此多的应用,越来越多的公司都在使用它,这就导致越来越多的开发者们需要学习 HBase。但是HBase是一种分布式的数据库,其正常运行需要部署 HDFS、Zookeeper以及HBase等相关组件;这对于一个新手来说特别复杂,间接增加了我们的学习成本。其实对大部分用户来说,只是想简单的使用 HBase,比如使用它来读写数据,验证某些场景的可行性。对这部分用户,其实他们并不想花太多时间在部署各种组件上面。

基于这些原因,中国HBase技术社区联合阿里云HBase数据库团队为大家带来了福利。阿里云HBase为我们提供了免费的HBase环境,如下:




我们可以通过 https://promotion.aliyun.com/ntms/act/hbasefree.html 链接去申请入。 查看全部
HBase 是一个分布式存储、数据库引擎,可以支持千万的QPS、PB级别的存储,这些都已经在生产环境验证,并且在广大的公司有大量的应用。根据目前公开的数据,阿里巴巴 HBase 集群规模为 12000 多台;京东 HBase 集群规模为 5000 多台;360 HBase 规模为 12500 台;爱奇艺 6000 多台。

HBase 可以说是一个数据库,也可以说是一个存储。拥有双重属性的 HBase 天生就具备广阔的应用场景。在2.0中,引入了OffHeap降低了延迟,可以满足在线的需求。引入MOB,可以存储10M左右的对象,完全适应了对象存储。另外由于自身的并发能力、存储能力,可以说是一个很有竞争力的引擎。HBase 在各大公司的应用场景包括以下几点:
 
  • 推荐画像:特别是用户的画像,是一个比较大的稀疏矩阵,蚂蚁的风控就是构建在HBase之上
  • 对象存储:我们知道不少的头条类、新闻类的的新闻、网页、图片存储在HBase之中,一些病毒公司的病毒库也是存储在HBase之中
  • 时序数据:HBase之上有OpenTSDB模块,可以满足时序类场景的需求
  • 时空数据:主要是轨迹、气象网格之类,滴滴打车的轨迹数据主要存在HBase之中,另外在技术所有大一点的数据量的车联网企业,数据都是存在HBase之中
  • CubeDB OLAP:Kylin一个cube分析工具,底层的数据就是存储在HBase之中,不少客户自己基于离线计算构建cube存储在hbase之中,满足在线报表查询的需求
  • 消息/订单:在电信领域、银行领域,不少的订单查询底层的存储,另外不少通信、消息同步的应用构建在HBase之上
  • Feeds流:典型的应用就是xx朋友圈类似的应用
  • NewSQL:之上有Phoenix的插件,可以满足二级索引、SQL的需求,对接传统数据需要SQL非事务的需求。


HBase 有着如此多的应用,越来越多的公司都在使用它,这就导致越来越多的开发者们需要学习 HBase。但是HBase是一种分布式的数据库,其正常运行需要部署 HDFS、Zookeeper以及HBase等相关组件;这对于一个新手来说特别复杂,间接增加了我们的学习成本。其实对大部分用户来说,只是想简单的使用 HBase,比如使用它来读写数据,验证某些场景的可行性。对这部分用户,其实他们并不想花太多时间在部署各种组件上面。

基于这些原因,中国HBase技术社区联合阿里云HBase数据库团队为大家带来了福利。阿里云HBase为我们提供了免费的HBase环境,如下:
微信截图_20190220134510.png

我们可以通过 https://promotion.aliyun.com/ntms/act/hbasefree.html 链接去申请入。

hbase 根据时间拆分表格的具体实现

ProgramGeek 回复了问题 • 4 人关注 • 3 个回复 • 163 次浏览 • 2019-02-19 20:13 • 来自相关话题

编译hbase出错

回复

point 发起了问题 • 1 人关注 • 0 个回复 • 148 次浏览 • 2019-02-18 20:28 • 来自相关话题

如何记录每一次请求的时间?

过往记忆 回复了问题 • 2 人关注 • 1 个回复 • 161 次浏览 • 2019-02-15 19:12 • 来自相关话题

有没有大佬做过cdh manager主机迁移的

果农 回复了问题 • 2 人关注 • 2 个回复 • 227 次浏览 • 2019-02-11 22:40 • 来自相关话题

hbck2 问题咨询

Sophie 回复了问题 • 4 人关注 • 2 个回复 • 202 次浏览 • 2019-02-03 11:10 • 来自相关话题

hbase的表无法删除(drop),提示:The procedure 28 is still running

HBaseAiHaoZhe 回复了问题 • 5 人关注 • 4 个回复 • 1086 次浏览 • 2019-01-28 14:46 • 来自相关话题

hbase异常退出

Jepson 回复了问题 • 2 人关注 • 1 个回复 • 189 次浏览 • 2019-01-28 10:04 • 来自相关话题

hbase scan的顺序问题

Leo 回复了问题 • 2 人关注 • 1 个回复 • 181 次浏览 • 2019-01-25 16:10 • 来自相关话题

Hbase 总是启动不起来

lxj276058885 回复了问题 • 2 人关注 • 1 个回复 • 210 次浏览 • 2019-01-24 17:01 • 来自相关话题

snapshot 能用纠删码技术吗

回复

datasir 发起了问题 • 1 人关注 • 0 个回复 • 172 次浏览 • 2019-01-23 15:31 • 来自相关话题


中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群