久久精品九九亚洲精品,亚洲av成人中文无码专区,亚洲男人天堂2022

Storm集成Kafka�~�程模型

SIMONE — Sun, 01 Mar 2015 07:47:00 GMT

摘要: 转蝲自http://www.cnblogs.com/tovin/p/3974417.html本文主要介绍如何在Storm�~�程实现与Kafka的集�?　　一、实现模�?　　　数据��程�Q?　　　　1、Kafka Producter生成topic1主题的消息　　　　　2、Storm中有个Topology�Q�包含了KafkaSpout、SenqueceBolt、KafkaBolt三个�l��g。其中KafkaS... 阅读全文

SIMONE 2015-03-01 15:47 发表评论

SIMONE — Wed, 19 Nov 2014 05:42:00 GMT

http://www.linuxidc.com/Linux/2012-01/51615.htm

1 Map side tuning 参数

1.1 MapTask �q�行内部原理

当map task 开始运��，�q��生中间数据时�Q�其产生的中间结果�ƈ非直接就��单的写入��盘。这中间的过�E�比较复杂，�q�且利用��C��内存buffer 来进行已�l��生的部分�l�果的缓存，�q�在内存buffer 中进行一些预排序来优化整个map 的性能。如上图所�C�，每一个map 都会对应存在一个内存buffer �Q�MapOutputBuffer �Q�即上图的buffer in memory �Q�，map 会将已经产生的部分结果先写入到该buffer 中，�q�个buffer 默认�?00MB 大小�Q�但是这个大��是可以�Ҏ��job 提交时的参数讑֮�来调整的�Q�该参数即�ؓ�Q?/span> io.sort.mb 。当map 的��生数据非常大�Ӟ��q�且把io.sort.mb 调大�Q�那么map 在整个计��过�E�中spill 的次数就势必会降低，map task 对磁盘的操作��׃��变少�Q�如果map tasks 的瓶颈在��盘上，�q�样调整��׃��大大提高map 的计��性能。map 做sort 和spill 的内存结构如下如所�C�：

map 在运行过�E�中�Q�不停的向该buffer 中写入已有的计算�l�果�Q�但是该buffer �q�不一定能��全部的map 输出�~�存下来�Q�当map 输出��出一定阈��|��比如100M �Q�，那么map ��必��d��该buffer 中的数据写入到磁盘中去，�q�个�q�程在mapreduce 中叫做spill 。map �q�不是要�{�到��该buffer 全部写满时才�q�行spill �Q�因为如果全部写满了再去写spill �Q�势必会造成map 的计��部分等待buffer 释放�I�间的情��c��所以，map 其实是当buffer 被写满到一定程度（比如80% �Q�时�Q�就开始进行spill 。这个阈��g��是由一个job 的配�|�参数来控制�Q�即 io.sort.spill.percent �Q�默认�ؓ0.80 �?0% 。这个参数同样也是媄响spill 频繁�E�度�Q�进而媄响map task �q�行周期对磁盘的��d��频率的。但非特�D�情况下�Q�通常不需要�h为的调整。调整io.sort.mb 对用��h��说更加方�ѝ�?/span>

当map task 的计��部分全部完成后�Q�如果map 有输出，��׃��生成一个或者多个spill 文�g�Q�这些文件就是map 的输出结果。map 在正帔R��Z��前，需要将�q�些spill 合�ƈ�Q�merge �Q�成一个，所以map 在结束之前还有一个merge 的过�E�。merge 的过�E�中�Q�有一个参数可以调整这个过�E�的行�ؓ�Q�该参数为： io.sort.factor 。该参数默认�?0 。它表示当merge spill 文�g�Ӟ��最多能有多��ƈ行的stream 向merge 文�g中写入。比如如果map 产生的数据非常的大，产生的spill 文�g大于10 �Q�而io.sort.factor 使用的是默认�?0 �Q�那么当map 计算完成做merge �Ӟ��没有办法一�ơ将所有的spill 文�gmerge 成一个，而是会分多次�Q�每�ơ最�?0 个stream 。这也就是说�Q�当map 的中间结果非常大�Q�调大io.sort.factor �Q�有利于减少merge �ơ数�Q�进而减��map 对磁盘的��d��频率�Q�有可能辑ֈ�优化作业的目的�?/span>

当job 指定了combiner 的时候，我们都知道map 介绍后会在map 端根据combiner 定义的函数将map �l�果�q�行合�ƈ。运行combiner 函数的时机有可能会是merge 完成之前�Q�或者之后，�q�个时机可以�׃��个参数控�Ӟ��?/span> min.num.spill.for.combine �Q�default 3 �Q�，当job 中设定了combiner �Q��ƈ且spill 数最��有3 个的时候，那么combiner 函数��׃��在merge 产生�l�果文�g之前�q�行。通过�q�样的方式，��可以在spill 非常多需要merge �Q��ƈ且很多数据需要做conbine 的时候，减少写入到磁盘文件的数据数量�Q�同��h��Z��减少对磁盘的��d��频率�Q�有可能辑ֈ�优化作业的目的�?/span>

减少中间�l�果��d��q�出��盘的方法不止这些，�q�有��是压羃。也��是说map 的中��_��无论是spill 的时候，�q�是最后merge 产生的结果文�Ӟ��都是可以压羃的。压�~�的好处在于�Q�通过压羃减少写入��d��盘的数据量。对中间�l�果非常大，��盘速度成�ؓmap 执行瓉��的job �Q�尤其有用。控制map 中间�l�果是否使用压羃的参��Cؓ�Q?/span> mapred.compress.map.output (true/false) 。将�q�个参数讄��为true �Ӟ��那么map 在写中间�l�果�Ӟ��׃��数据压�~�后再写入磁盘，�ȝ��果时也会采用先解压后��d��数据。这样做的后果就是：写入��盘的中间结果数据量会变��，但是cpu 会消耗一些用来压�~�和解压。所以这�U�方式通常适合job 中间�l�果非常大，瓉��不在cpu �Q�而是在磁盘的��d��的情��c��说的直白一些就是用cpu 换IO 。根据观察，通常大部分的作业cpu 都不是瓶颈，除非�q�算逻辑异常复杂。所以对中间�l�果采用压羃通常来说是有收益的。以下是一个wordcount 中间�l�果采用压羃和不采用压羃产生的map 中间�l�果本地��盘��d��的数据量�Ҏ��Q?/span>

map 中间�l�果不压�~�：

map 中间�l�果压羃�Q?/span>

可以看出�Q�同��L��job �Q�同��L��数据�Q�在采用压羃的情况下�Q�map 中间�l�果能羃��将�q?0 倍，如果map 的瓶颈在��盘�Q�那么job 的性能提升��会非常可观�?/span>

当采用map 中间�l�果压羃的情况下�Q�用戯��可以选择压羃�Ӟ��K��用哪�U�压�~�格式进行压�~�，现在Hadoop 支持的压�~�格式有�Q?/span> GzipCodec �Q?/span> LzoCodec �Q?/span> BZip2Codec �Q?/span> LzmaCodec �{�压�~�格式。通常来说�Q�想要达到比较��^衡的 cpu 和磁盘压�~�比�Q?/span> LzoCodec 比较适合。但也要取决�?/span> job 的具体情��c��用戯��惌��自行选择中间�l�果的压�~�算法，可以讄��配置参数�Q?/span> mapred.map.output.compression.codec =org.apache.hadoop.io.compress.DefaultCodec 或者其他用戯��行选择的压�~�方式�?/span>

1.2 Map side 相关参数调优

选项	�c�d��	默认�?/span>	描述
io.sort.mb	int	100	�~�存 map 中间�l�果�?/span> buffer 大小 (in MB)
io.sort.record.percent	float	0.05	io.sort.mb 中用来保�?/span> map output 记录边界的百分比�Q�其他缓存用来保存数�?/span>
io.sort.spill.percent	float	0.80	map 开始做 spill 操作的阈�?/span>
io.sort.factor	int	10	�?/span> merge 操作时同时操作的 stream ��C��限�?/span>
min.num.spill.for.combine	int	3	combiner 函数�q�行的最��?/span> spill �?/span>
mapred.compress.map.output	boolean	false	map 中间�l�果是否采用压羃
mapred.map.output.compression.codec	class name	org.apache.Hadoop.io. compress.DefaultCodec	map 中间�l�果的压�~�格�?/span>

2 Reduce side tuning 参数

2.1 ReduceTask �q�行内部原理

reduce 的运行是分成三个阶段的。分别�ؓ copy->sort->reduce 。由�?/span> job 的每一�?/span> map 都会�Ҏ�� reduce(n) 数将数据分成 map 输出�l�果分成 n �?/span> partition �Q�所�?/span> map 的中间结果中是有可能包含每一�?/span> reduce 需要处理的部分数据的。所以，��Z��优化 reduce 的执行时��_�� hadoop 中是�{?/span> job 的第一�?/span> map �l�束后，所有的 reduce ��开始尝试从完成�?/span> map 中下载该 reduce 对应�?/span> partition 部分数据。这个过�E�就是通常所说的 shuffle �Q�也��是 copy �q�程�?/span>

Reduce task 在做 shuffle �Ӟ��实际上就是从不同的已�l�完成的 map 上去下蝲属于自己�q�个 reduce 的部分数据，�׃�� map 通常有许多个�Q�所以对一�?/span> reduce 来说�Q�下载也可以是�ƈ行的从多�?/span> map 下蝲�Q�这个�ƈ行度是可以调整的�Q�调整参��Cؓ�Q?/span> mapred.reduce.parallel.copies �Q?/span> default 5 �Q�。默认情况下�Q�每个只会有 5 个�ƈ行的下蝲�U�程在从 map 下数据，如果一个时间段�?/span> job 完成�?/span> map �?/span> 100 个或者更多，那么 reduce 也最多只能同时下�?/span> 5 �?/span> map 的数据，所以这个参数比较适合 map 很多�q�且完成的比较快�?/span> job 的情况下调大�Q�有利于 reduce 更快的获取属于自己部分的数据�?/span>

reduce 的每一个下载线�E�在下蝲某个 map 数据的时候，有可能因为那�?/span> map 中间�l�果所在机器发生错误，或者中间结果的文�g丢失�Q�或者网�l�瞬断等�{�情况，�q�样 reduce 的下载就有可能失败，所�?/span> reduce 的下载线�E��ƈ不会无休止的�{�待下去�Q�当一定时间后下蝲仍然��p�|�Q�那么下载线�E�就会放弃这�ơ下载，�q�在随后��试从另外的地方下蝲�Q�因��D�|��?/span> map 可能重跑�Q�。所�?/span> reduce 下蝲�U�程的这个最大的下蝲旉��D�|��可以调整的，调整参数为： mapred.reduce.copy.backoff �Q?/span> default 300 �U�）。如果集��环境的�|�络本��n是瓶颈，那么用户可以通过调大�q�个参数来避�?/span> reduce 下蝲�U�程被误判�ؓ��p�|的情��c��不�q�在�|�络环境比较好的情况下，没有必要调整。通常来说专业的集��网�l�不应该有太大问题，所以这个参数需要调整的情况不多�?/span>

Reduce ��?/span> map �l�果下蝲到本地时�Q�同样也是需要进�?/span> merge 的，所�?/span> io.sort.factor 的配�|�选项同样会媄�?/span> reduce �q�行 merge 时的行�ؓ�Q�该参数的详�l�介�l�上文已�l�提刎ͼ�当发�?/span> reduce �?/span> shuffle 阶段 iowait 非常的高的时候，��有可能通过调大�q�个参数来加大一��?/span> merge 时的�q�发吞吐�Q�优�?/span> reduce 效率�?/span>

Reduce �?/span> shuffle 阶段对下载来�?/span> map 数据�Q��ƈ不是立刻��写入磁盘的�Q�而是会先�~�存在内存中�Q�然后当使用内存辑ֈ�一定量的时候才刷入��盘。这个内存大��的控制��׃��?/span> map 一样可以通过 io.sort.mb 来设定了�Q�而是通过另外一个参数来讄��Q?/span> mapred.job.shuffle.input.buffer.percent �Q?/span> default 0.7 �Q�，�q�个参数其实是一个百分比�Q�意思是��_�� shuffile �?/span> reduce 内存中的数据最多��用内存量为： 0.7 × maxHeap of reduce task 。也��是��_��如果�?/span> reduce task 的最�?/span> heap 使用量（通常通过 mapred.child.java.opts 来设�|�，比如讄��?/span> -Xmx1024m �Q�的一定比例用来缓存数据。默认情况下�Q?/span> reduce 会��用其 heapsize �?/span> 70% 来在内存中缓存数据。如�?/span> reduce �?/span> heap �׃��业务原因调整的比较大�Q�相应的�~�存大小也会变大�Q�这也是��Z��?/span> reduce 用来做缓存的参数是一个百分比�Q�而不是一个固定的��g��?/span>

假设 mapred.job.shuffle.input.buffer.percent �?/span> 0.7 �Q?/span> reduce task �?/span> max heapsize �?/span> 1G �Q�那么用来做下蝲数据�~�存的内存就为大�?/span> 700MB 左右�Q�这 700M 的内存，�?/span> map 端一��P��也不是要�{�到全部写满才会往��盘��L��Q�而是当这 700M 中被使用��C��一定的限度�Q�通常是一个百分比�Q�，��׃��开始往��盘列��这个限度阈��g��是可以通过 job 参数来设定的�Q�设定参��Cؓ�Q?/span> mapred.job.shuffle.merge.percent �Q?/span> default 0.66 �Q�。如果下载速度很快�Q�很�Ҏ��把内存�~�存撑大�Q�那么调整一下这个参数有可能会对 reduce 的性能有所帮助�?/span>

�?/span> reduce ��所有的 map 上对应自�?/span> partition 的数据下载完成后�Q�就会开始真正的 reduce 计算阶段�Q�中间有�?/span> sort 阶段通常旉��非常短，几秒钟就完成了，因�ؓ整个下蝲阶段��已�l�是边下载边 sort �Q�然后边 merge 的）。当 reduce task 真正�q�入 reduce 函数的计��阶�D늚�时候，有一个参��C��是可以调�?/span> reduce 的计��行为。也��是�Q?/span> mapred.job.reduce.input.buffer.percent �Q?/span> default 0.0 �Q�。由�?/span> reduce 计算时肯定也是需要消耗内存的�Q�而在��d�� reduce 需要的数据�Ӟ��同样是需要内存作�?/span> buffer �Q�这个参数是控制�Q�需要多��的内存癑ֈ�比来作�ؓ reduce ��d��l?/span> sort 好的数据�?/span> buffer 癑ֈ�比。默认情况下�?/span> 0 �Q�也��是��_��默认情况下， reduce 是全部从��盘开始读处理数据。如果这个参数大�?/span> 0 �Q�那么就会有一定量的数据被�~�存在内存�ƈ输送给 reduce �Q�当 reduce 计算逻辑消耗内存很��时�Q�可以分一部分内存用来�~�存数据�Q�反�?/span> reduce 的内存闲着也是闲着�?/span>

2.2 Reduce side 相关参数调优

选项	�c�d��	默认�?/span>	描述
mapred.reduce.parallel.copies	int	5	每个 reduce �q�行下蝲 map �l�果的最大线�E�数
mapred.reduce.copy.backoff	int	300	reduce 下蝲�U�程最大等待时��_�� in sec io.sort.factor	int	10	同上
mapred.job.shuffle.input.buffer.percent	float	0.7	用来�~�存 shuffle 数据�?/span> reduce task heap 癑ֈ��?/span>
mapred.job.shuffle.merge.percent	float	0.66	�~�存的内存中多少癑ֈ�比后开始做 merge 操作
mapred.job.reduce.input.buffer.percent	float	0.0	sort 完成�?/span> reduce 计算阶段用来�~�存数据的百分比

SIMONE 2014-11-19 13:42 发表评论

SIMONE — Tue, 16 Sep 2014 01:28:00 GMT

http://www.rigongyizu.com/mapreduce-job-one-map-process-one-file/

有一�Ҏ��据用hadoop mapreduce job处理�Ӟ��业务特点要求一个文件对应一个map来处理，如果两个或多个map处理了同一个文�Ӟ��可能会有问题。开始想通过讄�� dfs.blocksize 或�?mapreduce.input.fileinputformat.split.minsize/maxsize 参数来控制map的个敎ͼ�后来惛_��其实不用�q�么复杂�Q�在自定义的InputFormat里面直接让文件不要进行split��可以了�?/p>

public class CustemDocInputFormat extends TextInputFormat {

@Override

public RecordReader createRecordReader(InputSplit split, TaskAttemptContext context) {

DocRecordReader reader = null;

try {

reader = new DocRecordReader(); // 自定义的reader

} catch (IOException e) {

e.printStackTrace();

}

return reader;

}

@Override

protected boolean isSplitable(JobContext context, Path file) {

return false;

}

�q�样�Q�输入文件有多少个，job��׃��启动多少个map了�?/p>

2014�q?�?9�?/small> Hadoop : 一个目录下的数据只�׃��个map处理
2014�q?�?7�?/small> 一个Hadoop�E�序的优化过�E?– �Ҏ��文�g实际大小实现CombineFileInputFormat
2013�q?�?3�?/small> hadoop用MultipleInputs/MultiInputFormat实现一个mapreduce job中读取不同格式的文�g
2012�q?�?�?/small> hadoop mapreduce和hive中��用SequeceFile+lzo格式数据
2014�q?�?1�?/small> hadoop集群DataNode起不来：“DiskChecker$DiskErrorException: Invalid volume failure config value: 1”

SIMONE 2014-09-16 09:28 发表评论

hadoop用MultipleInputs/MultiInputFormat实现一个mapreduce job中读取不同格式的文�g

SIMONE — Tue, 16 Sep 2014 01:27:00 GMT

http://www.rigongyizu.com/use-multiinputformat-read-different-files-in-one-job/

hadoop中提供了 MultiOutputFormat 能将�l�果数据输出��C��同的目录�Q�也提供�?FileInputFormat 来一�ơ读取多个目录的数据�Q�但是默认一个job只能使用 job.setInputFormatClass 讄��使用一个inputfomat处理一�U�格式的数据。如果需要实�?在一个job中同时读取来自不同目录的不同格式文�g 的功能，��需要自己实��C��?MultiInputFormat 来读取不同格式的文�g�?原来已经提供�?a title="MultipleInputs" target="_blank">MultipleInputs)�?/p>

例如�Q�有一个mapreduce job需要同时读取两�U�格式的数据�Q�一�U�格式是普通的文本文�g�Q�用 LineRecordReader 一行一行读取；另外一�U�文件是伪XML文�g�Q�用自定义的AJoinRecordReader��d��?/p>

自己实现了一个简单的 MultiInputFormat 如下�Q?/p>

import org.apache.hadoop.io.LongWritable;

import org.apache.hadoop.io.Text;

import org.apache.hadoop.mapreduce.InputSplit;

import org.apache.hadoop.mapreduce.RecordReader;

import org.apache.hadoop.mapreduce.TaskAttemptContext;

import org.apache.hadoop.mapreduce.lib.input.FileSplit;

import org.apache.hadoop.mapreduce.lib.input.LineRecordReader;

import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;

public class MultiInputFormat extends TextInputFormat {

@Override

public RecordReader createRecordReader(InputSplit split, TaskAttemptContext context) {

RecordReader reader = null;

try {

String inputfile = ((FileSplit) split).getPath().toString();

String xmlpath = context.getConfiguration().get("xml_prefix");

String textpath = context.getConfiguration().get("text_prefix");

if (-1 != inputfile.indexOf(xmlpath)) {

reader = new AJoinRecordReader();

} else if (-1 != inputfile.indexOf(textpath)) {

reader = new LineRecordReader();

} else {

reader = new LineRecordReader();

}

} catch (IOException e) {

// do something ...

}

return reader;

}

其实原理很简单，��是�?createRecordReader 的时候，通过 ((FileSplit) split).getPath().toString() 获取到当前要处理的文件名�Q�然后根据特征匹配，选取对应�?RecordReader 卛_��。xml_prefix和text_prefix可以在程序启动时通过 -D 传给Configuration�?/p>

比如某次执行打印的值如下：

inputfile=hdfs://test042092.sqa.cm4:9000/test/input_xml/common-part-00068

xmlpath_prefix=hdfs://test042092.sqa.cm4:9000/test/input_xml

textpath_prefix=hdfs://test042092.sqa.cm4:9000/test/input_txt

�q�里只是通过��单的文�g路径和标�C�符匚w��来做�Q�也可以采用更复杂的�Ҏ��Q�比如文件名、文件后�~��{��?/p>

接着在map�c�M��Q�也同样可以�Ҏ��不同的文件名特征�q�行不同的处理：

@Override

public void map(LongWritable offset, Text inValue, Context context)

throws IOException {

String inputfile = ((FileSplit) context.getInputSplit()).getPath()

.toString();

if (-1 != inputfile.indexOf(textpath)) {

......

} else if (-1 != inputfile.indexOf(xmlpath)) {

......

} else {

......

}

�q�种方式太土了，原来hadoop里面已经提供�?MultipleInputs 来实现对一个目录指定一�?a title="查看inputformat中的全部文章" target="_blank">inputformat和对应的map处理�c�R�?/p>

MultipleInputs.addInputPath(conf, new Path("/foo"), TextInputFormat.class,

MapClass.class);

MultipleInputs.addInputPath(conf, new Path("/bar"),

KeyValueTextInputFormat.class, MapClass2.class);

2014�q?�?9�?/small> Hadoop : 一个目录下的数据只�׃��个map处理
2014�q?�?7�?/small> 一个Hadoop�E�序的优化过�E?– �Ҏ��文�g实际大小实现CombineFileInputFormat
2013�q?0�?2�?/small> mapreduce job让一个文件只�׃��个map来处�?/a>
2012�q?�?�?/small> hadoop mapreduce和hive中��用SequeceFile+lzo格式数据
2014�q?�?1�?/small> hadoop集群DataNode起不来：“DiskChecker$DiskErrorException: Invalid volume failure config value: 1”

SIMONE 2014-09-16 09:27 发表评论

一个Hadoop�E�序的优化过�E?�?�Ҏ��文�g实际大小实现CombineFileInputFormat

SIMONE — Tue, 16 Sep 2014 01:25:00 GMT

http://www.rigongyizu.com/hadoop-job-optimize-combinefileinputformat/

某日�Q�接手了同事写的�?a title="查看hadoop中的全部文章" target="_blank">Hadoop集群拯��数据到另外一个集��的�E�序�Q�该�E�序是运行在Hadoop集群上的job。这个job只有map阶段�Q�读取hdfs目录下数据的数据�Q�然后写入到另外一个集��?/p>

昄��Q�这个程序没有考虑大数据量的情况，如果输入目录下文件很多或数据量很大，��׃��D��map数很多。而实际上我们需要拷贝的一个数据源��有�q?6T�Q�job启动��h��?w多个map�Q�一下子整个queue的资源就占满了。虽焉��过调整一些参数可以控制map�?也就是�ƈ发数)�Q�但是无法准��的�?制map敎ͼ�而且换个数据源又得重新配�|�参数�?/p>

�W�一个改�q�的版本是，加了Reduce�q�程�Q�以期望通过讄��Reduce数量来控制�ƈ发数。这栯��然能�_��地控制�ƈ发数�Q�但是增加了shuffle �q�程�Q�实际运行中发现输入数据有倾斜�Q�而partition的key�׃��业务需要无法更改）�Q�导致部分机器网�l�被打满�Q�从而媄响到了集��中的其他应用。即佉K��过 mapred.reduce.parallel.copies 参数来限制shuffle也是��L��不治本。这个��^白增加的shuffle�q�程实际上浪费了很多�|�络带宽和IO�?/p>

最理想的情况当然是只有map阶段�Q�而且能够准确的控制�ƈ发数了�?/p>

于是�Q�第二个优化版本诞生了。这个job只有map阶段�Q�采�?a title="CombineFileInputFormat" target="_blank">CombineFileInputFormat�Q?它可以将多个��文件打包成一个InputSplit提供�l�一个Map处理�Q�避免因为大量小文�g问题�Q�启动大量map。通过 mapred.max.split.size 参数可以大概地控制�ƈ发数。本以�ؓ�q�样��p��解决问题了，�l�果又发��C��数据倾斜的问题。这�U�粗略地分splits的方式，��D��有的map处理的数据少�Q�有�?map处理的数据多�Q��ƈ不均匀。几个拖后退的map��导致job的实际运行时间长了一倍多�?/p>

看来只有让每个map处理的数据量一样多�Q�才能完��的解决�q�个问题了�?/p>

�W�三个版本也诞生了，�q�次是重写了CombineFileInputFormat�Q�自己实现getSplits�Ҏ��。由于输入数据�ؓSequenceFile格式�Q�因此需要一个SequenceFileRecordReaderWrapper�c�R�?/p>

实现代码如下�Q?br /> CustomCombineSequenceFileInputFormat.java

import java.io.IOException;

import org.apache.hadoop.classification.InterfaceAudience;

import org.apache.hadoop.classification.InterfaceStability;

import org.apache.hadoop.mapreduce.InputSplit;

import org.apache.hadoop.mapreduce.RecordReader;

import org.apache.hadoop.mapreduce.TaskAttemptContext;

import org.apache.hadoop.mapreduce.lib.input.CombineFileInputFormat;

import org.apache.hadoop.mapreduce.lib.input.CombineFileRecordReader;

import org.apache.hadoop.mapreduce.lib.input.CombineFileRecordReaderWrapper;

import org.apache.hadoop.mapreduce.lib.input.CombineFileSplit;

import org.apache.hadoop.mapreduce.lib.input.SequenceFileInputFormat;

/**

* Input format that is a CombineFileInputFormat-equivalent for

* SequenceFileInputFormat.

*

* @see CombineFileInputFormat

*/

@InterfaceAudience.Public

@InterfaceStability.Stable

public class CustomCombineSequenceFileInputFormat extends MultiFileInputFormat {

@SuppressWarnings({"rawtypes", "unchecked"})

public RecordReader createRecordReader(InputSplit split, TaskAttemptContext context)

throws IOException {

return new CombineFileRecordReader((CombineFileSplit) split, context,

SequenceFileRecordReaderWrapper.class);

}

/**

* A record reader that may be passed to CombineFileRecordReader so that it can be

* used in a CombineFileInputFormat-equivalent for

* SequenceFileInputFormat.

*

* @see CombineFileRecordReader

* @see CombineFileInputFormat

* @see SequenceFileInputFormat

*/

private static class SequenceFileRecordReaderWrapper

extends CombineFileRecordReaderWrapper {

// this constructor signature is required by CombineFileRecordReader

public SequenceFileRecordReaderWrapper(CombineFileSplit split, TaskAttemptContext context,

Integer idx) throws IOException, InterruptedException {

super(new SequenceFileInputFormat(), split, context, idx);

}

MultiFileInputFormat.java

import java.io.IOException;

import java.util.ArrayList;

import java.util.List;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

import org.apache.hadoop.fs.FileStatus;

import org.apache.hadoop.fs.Path;

import org.apache.hadoop.mapreduce.InputSplit;

import org.apache.hadoop.mapreduce.Job;

import org.apache.hadoop.mapreduce.JobContext;

import org.apache.hadoop.mapreduce.lib.input.CombineFileInputFormat;

import org.apache.hadoop.mapreduce.lib.input.CombineFileSplit;

/**

* multiple files can be combined in one InputSplit so that InputSplit number can be limited!

*/

public abstract class MultiFileInputFormat extends CombineFileInputFormat {

private static final Log LOG = LogFactory.getLog(MultiFileInputFormat.class);

public static final String CONFNAME_INPUT_SPLIT_MAX_NUM = "multifileinputformat.max_split_num";

public static final Integer DEFAULT_MAX_SPLIT_NUM = 50;

public static void setMaxInputSplitNum(Job job, Integer maxSplitNum) {

job.getConfiguration().setInt(CONFNAME_INPUT_SPLIT_MAX_NUM, maxSplitNum);

}

@Override

public List getSplits(JobContext job) throws IOException {

// get all the files in input path

List stats = listStatus(job);

List splits = new ArrayList();

if (stats.size() == 0) {

return splits;

}

// 计算split的��^均长�?/code>

long totalLen = 0;

for (FileStatus stat : stats) {

totalLen += stat.getLen();

}

int maxSplitNum = job.getConfiguration().getInt(CONFNAME_INPUT_SPLIT_MAX_NUM, DEFAULT_MAX_SPLIT_NUM);

int expectSplitNum = maxSplitNum < stats.size() ? maxSplitNum : stats.size();

long averageLen = totalLen / expectSplitNum;

LOG.info("Prepare InputSplit : averageLen(" + averageLen + ") totalLen(" + totalLen

+ ") expectSplitNum(" + expectSplitNum + ") ");

// 讄��inputSplit

List pathLst = new ArrayList();

List offsetLst = new ArrayList();

List lengthLst = new ArrayList();

long currentLen = 0;

for (int i = 0; i < stats.size(); i++) {

FileStatus stat = stats.get(i);

pathLst.add(stat.getPath());

offsetLst.add(0L);

lengthLst.add(stat.getLen());

currentLen += stat.getLen();

if (splits.size() < expectSplitNum - 1 && currentLen > averageLen) {

Path[] pathArray = new Path[pathLst.size()];

CombineFileSplit thissplit = new CombineFileSplit(pathLst.toArray(pathArray),

getLongArray(offsetLst), getLongArray(lengthLst), new String[0]);

LOG.info("combineFileSplit(" + splits.size() + ") fileNum(" + pathLst.size()

+ ") length(" + currentLen + ")");

splits.add(thissplit);

//

pathLst.clear();

offsetLst.clear();

lengthLst.clear();

currentLen = 0;

}

if (pathLst.size() > 0) {

Path[] pathArray = new Path[pathLst.size()];

CombineFileSplit thissplit =

new CombineFileSplit(pathLst.toArray(pathArray), getLongArray(offsetLst),

getLongArray(lengthLst), new String[0]);

LOG.info("combineFileSplit(" + splits.size() + ") fileNum(" + pathLst.size()

+ ") length(" + currentLen + ")");

splits.add(thissplit);

}

return splits;

}

private long[] getLongArray(List lst) {

long[] rst = new long[lst.size()];

for (int i = 0; i < lst.size(); i++) {

rst[i] = lst.get(i);

}

return rst;

}

通过 multifileinputformat.max_split_num 参数��可以较为准��的控制map数量�Q�而且会发现每个map处理的数据量很均匀。至此，问题�ȝ��解决了�?/p>

2014�q?�?9�?/small> Hadoop : 一个目录下的数据只�׃��个map处理
2013�q?0�?2�?/small> mapreduce job让一个文件只�׃��个map来处�?/a>
2013�q?�?3�?/small> hadoop用MultipleInputs/MultiInputFormat实现一个mapreduce job中读取不同格式的文�g
2012�q?�?�?/small> hadoop mapreduce和hive中��用SequeceFile+lzo格式数据
2014�q?�?1�?/small> hadoop集群DataNode起不来：“DiskChecker$DiskErrorException: Invalid volume failure config value: 1”

SIMONE 2014-09-16 09:25 发表评论

久久精品九九亚洲精品,亚洲av成人中文无码专区,亚洲男人天堂2022

Storm集成Kafka�~�程模型

1 Map side tuning 参数

1.1 MapTask �q�行内部原理

1.2 Map side 相关参数调优

2 Reduce side tuning 参数

2.1 ReduceTask �q�行内部原理

2.2 Reduce side 相关参数调优

相关文章

hadoop用MultipleInputs/MultiInputFormat实现一个mapreduce job中读取不同格式的文�g

相关文章

一个Hadoop�E�序的优化过�E?�?�Ҏ��文�g实际大小实现CombineFileInputFormat

相关文章