Sparrow(SOSP13)—一种加速短作业的调度方法

背景: 当前大规模数据分析框架的发展朝着两个趋势在变化: 1)任务执行时间更短。 2)更大的任务并行度。 因此,在当前分布式计算框架的调度系统中,需要有所改变,以满足如下的需求: 1)更快的任务调度效率,mill-seconds级别。 2)良好的容错,High Availability. 3)较高的吞吐率,High Throughput. 分析一下:什么原因会造成多任务的作业执行时间较长? 1)作业内任务分配不合理,在同样的并行层次上,任务执行逻辑和处理的数据量不一致,从而拉长整个作业的执行时间。以MapReduce为例的大数据分析框架中,数据是等分的,并且,处理逻辑是一致的,因此,该问题仅仅出现在以DAG、或者具有Data-Skew的数据逻辑中。 2)调度的不均衡性。根据Hadoop作业调度的情况,作业的执行时间由最为执行时间最长的任务决定。例如,Hadoop调度的一个MapTask到

HDFS HA-Quorum Journal Manager

1、背景 HDFS HA,即NameNode单点故障问题,一直是关系到HDFS稳定性最为重要的特性。之前Hadoop0.23初探系列文章中,介绍了HDFS的Federeation概况、配置与部署的情况,以及有关HA的相关概念。  Hadoop0.23.0初探1—前因后果 Hadoop0.23.0初探2—HDFS Federation部署 Hadoop0.23.0初探3—HDFS NN,SNN,BN和HA HDFS HA的发展经历了如下几个阶段: 1)手动恢复阶段。手动备份fsimage、fsedits数据,NN故障之后,重启hdfs。这是最早期使用的办法,由于早期数据量、机器规模、以及对应用的影响还比较小,该方案勉强坚持了一段时间。 2)借助DRBD、HeartbeatHA实现主备切换。 使用DRBD实现两台物理机器之间块设备的同步,即通过网络实现Raid1,辅以Heartbeat HA实现两台机器动态角色切换,对外(DataNode、DFSClient)使用虚IP来统一配置。这种策略,可以

深入分析HBase-Phoenix执行机制与原理

针对HBase上SQL解决方案,目前社区内比较热门的有Cloudera的Impala,Horntworks的Drill,以及Hive。根据与HBase的操作方式,可以分为三种: 以MapReduce为核心,单个任务使用hbase-client原始接口访问; 以Google Dremel为核心,单个任务使用hbase-client原始接口访问; 以HBase-Coprocessor为核心,结合Google Dremel的思想,客户端合并多个节点的处理结果。 Phoenix的安装: 1)git clone https://github.com/forcedotcom/phoenix.git 2)安装apache-maven,可以自行google 3)mvn process-sources 4)mvn package -DskipTests 5)拷贝phoenix-{versionid}.jar到HBASE_HOME/lib/下,重启RS 6)java -jar phoenix-{versionid}-client.jar $(zkquorum) example/web_stat.sql example/web_stat.csv //导入数据 7)java -jar phoenix-{versioni

HBase新特性—Stripe Compaction

借鉴于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

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

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

HBase实战系列2—Region监控

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] ] where [opts] are: -help          Show this help and exit. -daemon  

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

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

系统性能分析的实践方法

任何系统的性能分析以及分布式负载平衡策略的执行,需要首先了解当前系统的资源使用情况。 从资源角度进行划分,可以把资源分为如下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是一个可以实时查看

HBase隔离技术

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

深入分析HBase Compaction机制

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