HBase Compaction策略 RegionServer这种类LSM存储引擎需要不断的进行Compaction来减少磁盘上数据文件的个数和删除无用的数据从而保证读性能. RegionServer后台有一组负责flush region的线程(MemStoreFlusher),每次从flushQueue中拿出一个flush region请求,会检查这个region是否有某个store包含的storefile个数超过配置 hbase.hstore.blockingStoreFiles,默认7,如

Compaction有两种类型: (1)minor compaction:属于轻量级.将多个小的storefile文件重写为数量较少的大storefile文件,减少存储文件的数量,实际上是个多路归并的过程.它不会删除被标记为“删除”的数据和以往过期的数据,并且执行过一次minor合并操作后,还会有多个storefile文件.因为Hfile的每个文件都是经过归类的,所以合并速度很快,只受到磁盘I/O性能的影响. (2)major compaction:属于重量级.将一个region中,一个列簇的若

执行HBase时常会遇到个错误,我就有这种经历. ERROR: org.apache.hadoop.hbase.MasterNotRunningException: Retried 7 times 检查日志:org.apache.hadoop.ipc.RPC$VersionMismatch: Protocol org.apache.hadoop.hdfs.protocol.ClientProtocol version mismatch. (client = 42, server = 41) 假设

本文主要涉及flush流程,探讨flush流程过程中引入的问题并阐述2种解决策略,最后简要说明Flush执行策略. 对于Compaction,本文主要探讨Compaction要解决的本质问题以及由Compaction引入的问题.面对Compaction带来的双刃剑,如何根据自己的业务模型合理的执行Compaciton,不同的场景可以采用不同的Compaction策略以及如何选择待合并文件. Flush 1. Flush流程(HBase 1.*) MemStore中的数据,达到一定的阈值,被Flu

任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题.HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少.总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题.RIT问题.写吞吐量太低以及读延迟较大. Full GC问题之前在一些文章里面已经讲过它的来龙去脉,主要的解决方案目前主要有两方面需要注意,一方面需要查看GC日志确认是哪种Full GC,根据Full GC类型对JVM参数进行调优,另一方

1.概述 客户端读写数据是先从HBase Master获取RegionServer的元数据信息,比如Region地址信息.在执行数据写操作时,HBase会先写MetaStore,为什么会写到MetaStore.本篇博客将为读者剖析HBase MetaStore和Compaction的详细内容. 2.内容 HBase的内部通信和数据交互是通过RPC来实现,关于HBase的RPC实现机制下篇博客为大家分享.客户端应用程序通过RPC调用HBase服务端的写入.删除.读取等请求,由HBase的Maste

当 client 向 hregion 端 put() 数据时, HRegion 会判断当前的 memstore 的大小是否大于参数hbase.hregion.memstore.flush.size 值,如果大于,则执行 flushcache() 操作,将 hregion 上的 memstore 刷新到 store files 文件里. 而在 flushcache 时,会先判断当前的 region 是否满足以下条件 Store files number > 参数hbase.hstore.block

转载:http://blog.csdn.net/kalaamong/article/details/7290192 接上文啊: 测试机性能 CPU 16* Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz MEMORY 48GB DISK 12*SATA 2TB NET  4*1Gb Ethernet 测试数据: 类型 国内某视频网站近半年用户访问日志 结构 一行九列,包括用户访问页,关键词及其它用户信息.对应HBase一个family下9个colu

版本:0.94-cdh4.2.1 hbase-site.xml配置 hbase.tmp.dir 本地文件系统tmp目录,一般配置成local模式的设置一下,但是最好还是需要设置一下,因为很多文件都会默认设置成它下面的 线上配置 <property>      <name>hbase.tmp.dir</name>      <value>/mnt/dfs/11/hbase/hbase-tmp</value> </property> 默认

任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题.HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少.总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题.RIT问题.写吞吐量太低以及读延迟较大. Full GC问题之前在一些文章里面已经讲过它的来龙去脉,主要的解决方案目前主要有两方面需要注意,一方面需要查看GC日志确认是哪种Full GC,根据Full GC类型对JVM参数进行调优,另一方

hbase.tmp.dir:本地文件系统的临时目录,默认是java.io.tmpdir/hbase−java.io.tmpdir/hbase−{user.name}: hbase.rootdir:hbase持久化的目录,被所有regionserver共享,默认${hbase.tmp.dir}/hbase,一般设置为hdfs://namenode.example.org:9000/hbase类似,带全限定名: hbase.cluster.distributed:hbase集群模式运作与否的标志,默

版本:0.94-cdh4.2.1 hbase-site.xml配置 hbase.tmp.dir 本地文件系统tmp目录,一般配置成local模式的设置一下,但是最好还是需要设置一下,因为很多文件都会默认设置成它下面的 线上配置 <property>      <name>hbase.tmp.dir</name>      <value>/mnt/dfs/11/hbase/hbase-tmp</value> </property> 默认

2013年马上就要过去了,总结下这一年HBase在这么一年中发生的主要变化.影响最大的事件就是HBase 0.96的发布,代码结构已经按照模块化release了,而且提供了许多大家迫切需求的特点.这些特点大多在Yahoo/Facebook/淘宝/小米 等公司内部的集群中跑了挺长时间了,可以算是比较稳定可用了. 1,Compaction优化 HBase的Compaction是长期以来广受诟病的一个feature,很多人吐槽 HBase也是因为这个特征.不过我们不能因为HBase有这样一个缺点就把它

Region Compact请求是在Region MemStore Flush之后被触发的: boolean shouldCompact = region.flushcache(); // We just want to check the size boolean shouldSplit = region.checkSplit() != null; if (shouldSplit) { this.server.compactSplitThread.requestSplit(region); }

版本:HBase-0.98.6-cdh5.3.6 HBase参数调优 1. zookeeper.session.timeout: 默认90000(毫秒), 控制连接zk的timeout时间.由于hbase的集群是由zk管理的,所以当一个regionserver挂掉的时候,master是从zk集群上得到的,如果该值比较大,那么可能就会有比较高的延时:如果该值比较小,那么当有一个较长时间的gc发生的时候,可能会出现假宕机. 2. dfs.datanode.failed.volumes.tolerat

hbase性能优化总结 1. 表的设计 1.1 Pre-Creating Regions 默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据,直到这个region足够大了才进行切分.一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按照region分区情况,在集群内做数据的负载均衡. 有关预分区,详情参见:Table Creation: Pre-Creating

Hbase有两种压缩 策略:minor和major.Minor compactions通常选择几个临近的小的storefiles把他们重写成一个.Minors 不会丢掉已删除或者过期的cells,只有major compactions才会做这些.有时一次Minor compactions将会选择一个store里的全部storefiles,因此,它实际上是一次局部的major compaction. 当进行完一次major compaction以后所有的store都只有一个storefiles,这

本文由  网易云发布. 背景 Cloudera在2016年发布了新型的分布式存储系统--kudu,kudu目前也是apache下面的开源项目.Hadoop生态圈中的技术繁多,HDFS作为底层数据存储的地位一直很牢固.而HBase作为Google BigTable的开源产品,一直也是Hadoop生态圈中的核心组件,其数据存储的底层采用了HDFS,主要解决的是在超大数据集场景下的随机读写和更新的问题.Kudu的设计有参考HBase的结构,也能够实现HBase擅长的快速的随机读写.更新功能.那么同为分

hbase.tmp.dir \({java.io.tmpdir}/hbase-\){user.name} 本地文件系统上的临时目录.将'/tmp'改为其他可以持久保存文件的位置,通常能够解决java.io.tmpdir.'/tmp'目录在机器重启后将会被清空. hbase.rootdir \({hbase.tmp.dir}/hbase</value> <description>该目录被region server共享并且用来保存HBase的持久化数据.这个URL应该完全按照文件系统模