HBase新特性—Stripe Compaction

六月 25th, 2013 by klose | No Comments | Filed in 互联网应用, 海量数据存储与处理

借鉴于LevelDB、Cassandra的Compaction方法,https://issues.apache.org/jira/browse/HBASE-7667 提出了Stripe Compaction的方法。 Motivation: 1)过多Region会增大RS维护的开销,降低RS的读写性能。随着数据量的增大,在一定程度上增加Region个数,会提高系统的吞吐率。然而,RS上服务的Region个数增多,增加了RS下内存维护的开销,尤其每个Store下都配置有一个MemStore,从而会造成频率更高的Flush操作,影响系统的读写性能。因此,如果能够提出更轻量级的mini-Region,不仅能够降低服务多个Region的开销,而且能够提升读写数据的效率。 2) Region Compaction容易”放大”。例如,Region区间为[1FFF,2FFF),在该区间内仅有[1FFF,21FF)区间有大量的写操作(put、delete),但是,在触及MajorCompaction条件时,却需要对所有的文件执行Maj

Tags: , , , , ,

HBase实战系列3—搭建ThriftServer实时监控系统

六月 13th, 2013 by klose | No Comments | Filed in 互联网应用, 海量数据存储与处理

背景: 在hbase应用中,如果使用C++来访问HBase,往往通过ThriftServer进行数据的读写,ThriftServer服务的状况直接影响了应用服务的体验。因此,在HBase ThriftServer之上的Metrics系统、以及实时监控系统,可以第一时间发现服务质量变化以及相关问题,同时,良好的监控系统,也有助于服务的完善。 ThriftServer实时监控系统的挑战 1)ThriftServer的服务具有分散性。我们一般为不同的应用启动多个ThriftServer,那么如果我们想多维度统计分析某个应用的统计状况,就会比较困难。例如:百川抓取平台,随机使用多个ThriftServer进行读写操作,单个ThriftServer的实时请求状况可以很容易分析,但是如果想看整个百川平台对于HBase集群的整体压力,就必须实时地从不同的ThriftServer中收集相关读写请求的数据,然后还得将分散到不同节点上的数据,进行聚

Tags: , , , ,

HBase实战系列2—Region监控

六月 9th, 2013 by klose | 4 Comments | Filed in 互联网应用, 海量数据存储与处理

1、背景 随着大数据表格应用的驱动,我们的HBase集群越来越大,然而由于机器、网络以及HBase内部的一些不确定性的bug,使得系统面临着一些不确定性的故障。 因此,HBase上有很多的Region组成,需要控制每个表格的Region的状态。 分析: 1)实时掌控Region的状态。应用的每次访问要直接与HBase某个Region关联,需要探测Table上Region是否处于可用状态。 2)Region的读写与底层的HDFS的状态相互关联。这种关联决定了通过Region的读写状况的监控,也可以反映HDFS的状况。 2、实战工具  org.apache.hadoop.hbase.tool.Canary 监控Region的可用和读写状况。==>对应分析中前两个问题。 使用方法: Usage: bin/hbase org.apache.hadoop.hbase.tool.Canary [opts] [table 1 [table 2...]] where [opts] are: -help          Show this help

Tags: , ,

HBase实战系列1—压缩与编码技术

六月 9th, 2013 by klose | No Comments | Filed in 互联网应用, 海量数据存储与处理

1、hbase压缩与编码的配置 安装LZO 解决方案: 1)apt-get install liblzo2-dev 2)hadoop-gpl-compression-0.2.0-dev.jar 放入classpath 把libgpl下的共享库文件放入/opt/hbase/hbase/lib/native/Linux-amd64-64/ libgplcompression.a libgplcompression.la libgplcompression.so libgplcompression.so.0 libgplcompression.so.0.0.0 3)配置: <property> <name>io.compression.codecs</name> <value>com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec</value> </property> <property> <name>io.compression.codec.lzo.class</name> <value>com.hadoop.compression.lzo.LzoCodec</value> </property> 4)测试: hbase org.apache.hadoop.hbase.u

Tags: , , ,

系统性能分析的实践方法

六月 3rd, 2013 by klose | No Comments | Filed in 互联网应用, 海量数据存储与处理

任何系统的性能分析以及分布式负载平衡策略的执行,需要首先了解当前系统的资源使用情况。 从资源角度进行划分,可以把资源分为如下4类: 1)处理器资源,CPU 2)内存资源,Memory,从广义概念上讲,这还包括Swap\Cache\Buffer等 3)磁盘资源,Disk 4) 网络资源,Network IO,从广义概念上讲,还要考虑上层网络交换机的带宽和交换机之间的带宽。 1、CPU分析 CPU分析常用的工具top。 2、内存分析 内存分析最常用的工具有free、vmstat等。 一般内存的分析要分成两个层次来进行: 1)系统层面上。free可以查看当前系统的内存使用状况,用来分析机器的内存整体使用状况。 Linux内核为了获取更好的性能,总会尽可能地使用空余内存作为系统Cache,从上图可以看到有23G的系统Cache,对于读多写少的应用而言,这个数据是正常的。 vmstat是一个可以实时查看

Tags:

HBase隔离技术

五月 17th, 2013 by klose | No Comments | Filed in 互联网应用, 海量数据存储与处理

背景: 随着HBase在性能和稳定性持续改善和成功案例的积累,HBase逐渐成为了在大数据NoSQL领域的事实标准。越来越多有着大数据应用和处理需求的互联网公司、IT公司,将离线或者半在线的数据平台搭建在HBase之上。 在深入使用和运维过程中,我们发现当新的应用需求而来时,处于性能和效率的考虑,我们就要根据数据规模单独搭建系统,而应用需求和规模的变化,会给HBase的运维和资源使用带来了一定的困扰: 1)HBase集群越多,运维成本就越大。因为稳健的Hbase监控是要从底层存储设备、网络资源、内存、CPU、hdfs、RegionServer到应用服务器读写性能的自下向上的体系,搭建HBase集群的运维开销较大。 2)应用需求的改变,短时间内资源扩容与平衡资源利用率之间存在矛盾。因为需求对于资源需求的变化,可以通过短时间内牺牲非优先的存储性能来平衡。 于是

Tags: , ,

深入分析HBase Compaction机制

四月 27th, 2013 by klose | 2 Comments | Filed in 互联网应用, 海量数据存储与处理

Compaction介绍 Compaction是buffer->flush->merge的Log-Structured Merge-Tree模型的关键操作,主要起到如下几个作用: 1)合并文件 2)清除删除、过期、多余版本的数据 3)提高读写数据的效率 Minor & Major Compaction的区别 1)Minor操作只用来做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理,不做任何删除数据、多版本数据的清理工作。 2)Major操作是对Region下的HStore下的所有StoreFile执行合并操作,最终的结果是整理合并出一个文件。 从这个功能上理解,Minor Compaction也不适合做Major的工作,因为部分的数据清理可能没有意义,例如,maxVersions=2,那么在少部分文件中,是否是kv仅有的2个版本也无法判断。 下面是引用: There are two types of compactions: minor and major. Minor compactions will

Tags: , ,

HBase Flush操作流程以及对读写服务的影响

四月 19th, 2013 by klose | No Comments | Filed in 海量数据存储与处理

HBase Flush操作流程以及对读写服务的影响   HBase的Flush操作的触发条件: 1)Manual调用,HRegionInterface#flushRegion,可以被用户态org.apache.hadoop.hbase.client.HBaseAdmin调用flush操作实现,该操作会直接触发HRegion的internalFlush。 2)HRegionServer的一次更新操作,使得整个内存使用超过警戒线。警戒线是globalMemStoreLimit, RS_JVM_HEAPSIZE * conf.getFloat(“hbase.regionserver.global.memstore.upperLimit”),凡是超过这个值的情况,会直接触发FlushThread,从全局的HRegion中选择一个,将其MemStore刷入hdfs,从而保证rs全局的memstore容量在可控的范围。   RS上HRegion的选择算法: 步骤1:RS上的Region,按照其MemStore的容量进行排序。 步骤2:选出Region下的Store中的StoreFile的个数未达到hbase.hstore.blocking

Tags: , , , ,

HBase Metrics参数详解

四月 2nd, 2013 by klose | 5 Comments | Filed in 互联网应用, 海量数据存储与处理

本研究针对HBase 0.94.* 及以上版本的系统。 RegionServer 本目标主要集中分析在RegionServer提供的相关Metrics接口。在0.94新版本中,Metrics包括:RegionServerMetrics、JvmMetrics、以及RegionServerDynamicMetrics。下面分别进行介绍。 1、RegionServerMetrics 这是延续了以前版本的Metrics。它主要是以RegionServer为单位的基本功能的监控信息的收集,主要包括: 1)通用信息的收集。例如RS内store个数、storefiles的个数等。 2)与RS整体读写性能指标相关的参数。例如Cacheblock相关的信息、RS内读写请求个数、写操作相关的性能、以及读操作相关的性能。 3)功能性调整的参数个数。如Compaction、Split等。 下面细化这些参数的含义。(ps:参数名省略了前两位的hbase.regionserver.,例如如果blockCacheCount,那么Metrics上实际名字是hbase.regi

Tags: , ,

OpenTSDB的设计之道

二月 26th, 2013 by klose | 2 Comments | Filed in 互联网应用, 海量数据存储与处理

OpenTSDB是一个架构在Hbase系统之上的实时监控信息收集和展示平台。 它在海量数据的压力下,仍然保证了存储的效率,那么它背后有什么值得借鉴的地方呢? 1)使用AsyncHbase而非HBase自带的HTable。使用线程安全、非阻塞、异步、多线程并发的HBase API,在高并发和高吞吐时,可以获得更好的效果。建议在使用AsyncHBase​时,在CPU core有保证的前提下,可以设置16或者24。 2)采用固定长度的Rowkey,让Rowkey包含尽可能多的检索信息。这一点的话,OpenTSDB存储的数据要包含大量的metrics和tag信息,这些信息的长度是变长的,因此,在实现上设置了一个表格uid-tsdb存储这些信息,作为一个全局唯一的编号,并把编号与TimeStamp合并作为Rowkey。   3)每一行要存储尽可能多的信息,这一点在OpenTSDB被发挥到了极致。例如,把某个时间段的分散采集的数据合

Tags: , ,