一:GC的调优 1.jvm的内存 新生代:存活时间较短,一般存储刚生成的一些对象 老年代:存活时间较长,主要存储在应用程序中生命周期较长的对象 永久代:一般存储meta和class的信息 2.GC策略 Parrallel New Collector,垃圾回收策略 并行标记回收器(Concurrent Mark-Sweep Collector) 3.Parrallel New Collector 速度快,但是数据量一大,容易造成GC停顿,一般应用在新生代 4.Concurrent Mark-Swe

flush触发方式 1. Server端执行更新操作(put.delete.multi(MultiAction<R>multi).(private)checkAndMutate.mutateRow (byte[] regionName, RowMutations rm))执行前后触发内存检查 操作执行前 MemStoreFlusher .reclaimMemStoreMemory,如果regionserver使用memstore大于upper,则循环创建flush任务加入flushQueue,

compact一中介绍了HBASE compact的调度流程,本篇文章主要介绍实际进行compact的过程.先从上文中的chore中接入,在HRegionserver中的compactChecker chore方法中,会判断是否需要compact,如下: protected void chore() { //遍历instance下的所有online的region 进行循环检测 //onlineRegions是HRegionServer上存储的所有能够提供有效服务的在线Region集合: for

hbase compact流程较多,这里分章节介绍,首先介绍compact在regionserver中的调用流程,并不会涉及真正的compact读取合并文件的流程,后续介绍. 在regionserver启动时,会初始化compactsplitthread以及CompactionChecker. /* * Check for compactions requests. * 检查合并请求 */ ScheduledChore compactionChecker; // Compactions publ

hbase(main)::> create 'test_table_region', 'username' row(s) in 1.2150 seconds hbase(main)::> put ' row(s) in 0.0050 seconds hbase(main)::> scan 'test_table_region' ROW COLUMN+CELL column=username:nick, timestamp=, value= row(s) in 0.1370 seconds

1. 简介 HBase 的最小管理单位为region,region会按照region 分裂策略进行分裂. 基于CDH5.4.2 2. 总览

版权声明:本文为博主原创文章,未经博主允许不得转载.     转: http://blog.csdn.net/u013980127/article/details/52443155 下面代码在Hadoop 2.6.4 + Hbase 1.2.2 + centos 6.5 + jdk 1.8上运行通过. HBase操作 一般操作 命令 说明 status 显示集群状态. 选项:‘summary’, ‘simple’, or ‘detailed’. 默认值:‘summary’. hbase> sta

年前的时候系统梳理了一下hbase rpc的实现,并且对组里的小伙伴做了一次分享.趁着热乎劲还没完全消失殆尽,准备赶紧记录下来. hbase中rpc概况 作为一个分布式系统,hbase的设计是典型的master-salve架构.hbase中主要有master,regionserver,client这三个角色.这三个角色之间rpc的调用关系可以用下图来描述. client client有很多,比方说:hbase shell, Java client API等.client没有提供任何rpc服务,它

hbase region split操作的一些细节,具体split步骤很多文档都有说明,本文主要关注regionserver如何选取split point 首先推荐web ui查看hbase region分布的一个开源工具hannibal,建议用daemontool管理hannibal意外退出,自动重启,之前博文写了博文介绍如何使用daemontool管理 假设有一张hbase的table如下表所示,有一个region的大小比较大,可以对这个region进行手动split操作 HBase的物理存

Hbase Flush机制最小Flush单元为HRegion,尽量减少CF数量以减少HStrore数量从而减少MemStore的数量,最终减少每次Flush的开销.1.Region级别触发条件:    a)    hbase.hregion.memstore.flush.size        Region中任意MemStore大小达到上限(默认128MB),触发Memstore,flush该region.    b)    hbase.hstore.blockingStoreFiles 默认值

在Hbase中split是一个很重要的功能,Hbase是通过把数据分配到一定数量的region来达到负载均衡的.一个table会被分配到一个或多个region中,这些region会被分配到一个或者多个regionServer中.在自动split策略中,当一个region达到一定的大小就会自动split成两个region.table在region中是按照row key来排序的,并且一个row key所对应的行只会存储在一个region中,这一点保证了Hbase的强一致性 . 在一个region中有

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源代码分析之HRegionServer上MemStore的flush处理流程(一)>遗留的问题之后,本文我们接着研究HRegionServer上MemStore的flush处理流程.重点讲述下怎样选择一个HRegion进行flush以缓解MemStore压力,还有HRegion的flush是怎样发起的. 我们先来看下第一个问题:怎样选择一个HRegion进行flush以缓解MemStore压力.上文中我们讲到过flush处理线程假设从flushQueue队列中拉取出的一个

版权声明:本文为博主原创文章,遵循版权协议,转载请附上原文出处链接和本声明. 在介绍HBASE flush源码之前,我们先在逻辑上大体梳理一下,便于后续看代码.flush的整体流程分三个阶段 1.第一阶段:prepare阶段,这个阶段主要是将当前memstore的内存结构做snapshot.HBASE写入内存的数据结构(memstore以及snapshot)是跳跃表,用的是jdk自带的ConcurrentSkipListMap结构.这个过程其实就是将memstore赋值给snapshot,并构造

在<HBase源代码分析之MemStore的flush发起时机.推断条件等详情>一文中,我们具体介绍了MemStore flush的发起时机.推断条件等详情.主要是两类操作.一是会引起MemStore数据大小变化的Put.Delete.Append.Increment等操作,二是会引起HRegion变化的诸如Regin的分裂.合并以及做快照时的复制拷贝等.相同会触发MemStore的flush流程.同一时候.在<HBase源代码分析之compact请求发起时机.推断条件等详情(一)>

接触过 HBase 的同学应该对 HBase 写数据的过程比较熟悉(不熟悉也没关系).HBase 写数据(比如 put.delete)的时候,都是写 WAL(假设 WAL 没有被关闭) ,然后将数据写到一个称为 MemStore 的内存结构里面的,如下图: 如果想及时了解Spark.Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop 但是,MemStore 毕竟是内存里面的数据结构,写到这里面的数据最终还是需要持久化到磁盘的,生成 HFile.如下图: 如果

1.为何要 BulkLoad 导入?传统的 HTableOutputFormat 写 HBase 有什么问题? 我们先看下 HBase 的写流程: 通常 MapReduce 在写HBase时使用的是 TableOutputFormat 方式,在reduce中直接生成put对象写入HBase,该方式在大数据量写入时效率低下(HBase会block写入,频繁进行flush,split,compact等大量IO操作),并对HBase节点的稳定性造成一定的影响(GC时间过长,响应变慢,导致节点超时退出,

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集群模式运作与否的标志,默

     总所周知,HBase 是天生就是架设在 HDFS 上,在这个分布式文件系统中,HBase 是怎么去构建自己的目录树的呢? 这里只介绍系统级别的目录树. 一.0.94-cdh4.2.1版本 系统级别的一级目录如下,用户自定义的均在这个/hbase 下的一级子目录下 /hbase/-ROOT- /hbase/.META. /hbase/.archive /hbase/.corrupt /hbase/.hbck /hbase/.logs /hbase/.oldlogs /hbase/.sna

一.0.94-cdh4.2.1版本系统级别的一级目录如下,用户自定义的均在这个/hbase 下的一级子目录下/hbase/-ROOT-/hbase/.META./hbase/.archive/hbase/.corrupt/hbase/.hbck/hbase/.logs/hbase/.oldlogs/hbase/.snapshot/hbase/.tmp/hbase/hbase.id/hbase/hbase.version 1./hbase/-ROOT- hbase读写数据的时候采用三级寻址方式,首

1         Hbase日常运维 1.1       监控Hbase运行状况 1.1.1        操作系统 1.1.1.1 IO 群集网络IO,磁盘IO,HDFS IO IO越大说明文件读写操作越多.当IO突然增加时,有可能:1.compact队列较大,集群正在进行大量压缩操作. 2.正在执行mapreduce作业 可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据: Io wait 磁盘IO对集群的影响比较大,如果io wait时间过长需检查系统或磁盘是