Hadoop的应用经验文章搜集 [2008.11版][转]

[ Hadoop 实战:谁是最倒霉的人? ] 这次尝试用 Hadoop 来写一个简单的应用。要解决的问题是这样的:现在我手里有大量的邮件数据,并且我知道每封邮件是正常邮件还是垃圾邮件,现在我想要找出收到的邮件中垃圾邮 件最多的人,亦即找出“谁是最倒霉的人”。

首先是 Map 的过程,输入数据是一封一封的邮件,彼此之间没有任何关联,因此可以很自然地分组处理。Map 将邮件转化到以邮件的收件人进行分组,如果邮件是垃圾邮件,则映射到收件人的垃圾邮件数“+1”。Reduce 的过程就是将各个收件人的邮件数统计结果加起来。

在 Hadoop 中实现一个 map 过程只需要实现 Mapper 接口就行了,一般同时继承自 MapReduceBase ,可以省下不少力气。map 接受 key, value 的 pair ,这是按照初始输入数据进行分组的,通常 map 方法从 value 中解析感兴趣的内容,并进行重新分组。map 的另一个 OutputCollector 类型的参数就是专门用于收集 map 之后的新分组的。map 方法看起来是这个样子:

1
2
3
4
5
6
7
8
9
10
11
12
13
@Override
public void map(LongWritable key, Text value,
OutputCollector<Text, LongWritable> output, Reporter reporter)
throws IOException {
String header = value.toString();

if (isSpam(header)) {
String addr = getToAddr(header);
if (addr != null) {
output.collect(new Text(addr), new LongWritable(1));
}
}
}

由于数据需要在网络上传输,Hadoop 要求 Key 和 Value 的类型都必须是可以序列化的,不过这不是 Java 自带的那个序列化接口 Serializable ,而是 Hadoop 自己定义的一个更加简易的 Writable 接口。另外,由于 Key 是需要用于进行排序和分组的,所以需要实现的是更加具体的一个叫做 WriteComparable 的接口。不过,常用的数据类型 Hadoop 都提供了现成的支持,比如 Text 可以用于存放文本,LongWritable 可以用于存放长整型数据。

在这个任务中,我 map 的输入 key 是长整型,在这里是分组时在文件中的 offset ,这里不需要用到它,直接忽略。而 value 是一封邮件的邮件头的内容。首先我要判断邮件是否是垃圾邮件。原本我可以用作好的分类器进行在线分类,或者使用一个已经做好的 index 来进行判断,不过为了让示例简单一些,我对邮件内容进行了预处理,直接将垃圾邮件标记作为一个邮件头域插入了邮件首部。因此判断是否是垃圾邮件的代码是直 接从邮件头里搜索相应标签:

1
2
3
4
5
6
7
private boolean isSpam(String header) {
Matcher matcher = labelPattern.matcher(header);
if (matcher.find() && matcher.group(1).equalsIgnoreCase("spam"))
return true;
else
return false;
}

判断出是垃圾邮件之后,就解析出邮件的收件人地址,这里暂时不考虑多个收件人或者有抄送之类的情况。得到收件人之后(比如,是 foo@bar.com),就算得到了一组结果。这将作为后面 reduce 任务的输入:key 的类型是 Text ,亦即收件人地址;value 的类型是 LongWritable ,即收到的垃圾邮件数目。当发现一封垃圾邮件时,就将这个中间结果 (foo@bar.com, 1) 收集起来。

这就完成了 map 的过程,之后应该是 reduce ,这个过程很简单,系统会按照 map 的结果将各个分组的结果传递到 reduce 函数,这里 reduce 只要把各个 LongWritable 加起来得到总和就可以了。在 Hadoop 自带的 Word Count 的示例中有一个类似的例子(不过这里加的是 IntWritable):

1
2
3
4
5
6
7
8
9
10
11
12
public class Reduce extends MapReduceBase 
implements Reducer<Text, IntWritable, Text, IntWritable> {
public void reduce(Text key, Iterator<IntWritable> values,
OutputCollector<Text, IntWritable> output,
Reporter reporter) throws IOException {
int sum = 0;
while (values.hasNext()) {
sum += values.next().get();
}
output.collect(key, new IntWritable(sum));
}
}

不过因为 Hadoop 自带了一个 LongSumReducer 可以完成我们需要做的事情,就不用自己再费力写一个了。 :p 另外,Hadoop 在 map 和 reduce 之间还有一个叫做 combine 的步骤,可以看作是“本地的 reduce ”。除了某些特殊情况,一般 combine 和 reduce 做的事情是一样的(因此这两个任务通常也是通过同一段代码来实现的),只是 combine 只在本地运行,将当前节点得到的局部结果进行一下局部的 reduce ,这样通常可以减少需要进行网络传输的数据量。例如,如果当前节点发现了 5 封发给 foo@bar.com 的垃圾邮件,需要对 5 个 (foo@bar.com, 1) 进行 reduce 调度,而经过本地 combine 之后,只需要处理一个 (foo@bar.com, 5) 就可以了。

map 和 reduce 做好之后,新建一个任务,并告知用于完成 map 和 reduce 任务的类:

countJob.setMapperClass(CountMapper.class);
countJob.setCombinerClass(LongSumReducer.class);
countJob.setReducerClass(LongSumReducer.class);

再设置输入输出的 key 和 value 的类型:

countJob.setInputKeyClass(LongWritable.class);
countJob.setInputValueClass(Text.class);

countJob.setOutputKeyClass(Text.class);
countJob.setOutputValueClass(LongWritable.class);

配置好之后调用 JobClient.runJob(countJob) 就可以开始 MapReduce 了。大致的流程就是这样,不过中间还有一些细节需要处理。一个问题就是结果如何输出?我们最终得到的是一些 (Text, LongWritable) 的 pair ,一个办法是让它以文本方式按行输出到文本文件中,这样只需要使用内置的 SequenceFileOutputFormat 即可:

countJob.setOutputFormat(SequenceFileOutputFormat.class);

另一个问题则是输入的格式,Hadoop 需要理解了输入文件的格式才能将其解析并作为参数传递给 map 函数,更重要的是:进行合适的分割,将任务分配到各个节点上去。Hadoop 使用 InputFormat 来控制输入格式,默认情况下,将输入目录中每个文件当作以行为单位的文本进行处理和分割,除此之外 Hadoop 也内置了二进制记录等文件类型的支持。不过我这里的情况比较特殊:一个文件中只有一封邮件,需要当作一个不可分割的原子来处理。因此我实现了一个 AtomFileInputFormat ,并在 isSplitable 方法中总是返回 false

public class AtomFileInputFormat extends FileInputFormat<LongWritable, Text> {

@Override
public RecordReader<LongWritable, Text> getRecordReader(InputSplit genericSplit,
JobConf job, Reporter reporter) throws IOException {
reporter.setStatus(genericSplit.toString());
return new FileRecordReader(job, (FileSplit)genericSplit);
}

@Override
protected boolean isSplitable(FileSystem fs, Path path) {
return false;
}
}

另外,我定制了一个 FileRecordReader (需要实现 RecordReader 接口),从每个文件中读取邮件头,丢掉邮件的内容部分。

@Override
public boolean next(LongWritable key, Text value) throws IOException {
if (hasRead) {
return false;
} else {
Path file = split.getPath();
FileSystem fs = file.getFileSystem(job);

key.set(0);

FSDataInputStream in = fs.open(file);
BufferedReader reader = new BufferedReader(new InputStreamReader(in));

StringBuilder sb = new StringBuilder();
while (true) {
String line = reader.readLine();
// empty string, email headers and body are separated by an
// empty line
if (line == null || line.length() == 0)
break;
sb.append(line);
sb.append('\n');
}
value.set(sb.toString());

reader.close();

pos = split.getLength();
hasRead = true;
return true;
}
}

这样差不多任务就完成了,不过还有一点就是最后的结果是按照 key 进行排序的,亦即按照收件人地址排序,而我期望找到“最倒霉”的人,甚至需要按照“倒霉程度”进行排序,所以我再启动另一个 MapReduce 任务,将 key 和 value 颠倒过来,并进行排序。由于这是一个非常常见的任务,Hadoop 内置了相应的支持,因此只需要把内置的 InverseMapperIdentityReducer 组装起来即可:

sortJob.setInputFormat(SequenceFileInputFormat.class);
sortJob.setMapperClass(InverseMapper.class);
sortJob.setNumReduceTasks(1); // write a single file
FileOutputFormat.setOutputPath(sortJob, new Path(args[1]));
sortJob.setOutputKeyComparatorClass(LongWritable.DecreasingComparator.class);

这样就能得到最终结果了!完整的代码可以从这里下载。

最后,总结一下:这样一个简单的 AtomFileInputFormat 似乎没有达到预期的目的,Hadoop 默认情况下似乎把“一个文件”当作一个“很大”的单位了,通常都是考虑将文件进行分割,再分派到各个节点,因此每个文件最少启动一个 map 任务,而现在我的情况是一个文件中只有一条数据,结果似乎是每一个 map 操作都启动了一个新的 map 任务。如果要改进的话,一个是更加深入地定制 InputFormat 的风割方法;另一个办法是对输入数据进行预处理,后者要方便一些,但是在实际应用中如果遇到数据量大到进行预处理本身就需要 MapReduce 的支持的话,就有些不现实了。 ;) 另外,这种分布式的应用出了问题之后不知道要怎样调试才好?且不说调试器的方法肯定不管用了,就算最原始的 printf 大法,也不知道最终的输出会 print 到苍穹的哪一个角落里去了 :p 必须要有一个强大的 log 系统才行,而且如果是在单机环境下也能成功重现的那种 bug 的话,应该也会好姐姐一些。

总之,在上一次介绍的时候我就说了:MapReduce 是对分布式任务进行了一定的限制而得到的结果,考虑到 80%/20% 原则,它可以相当棒地完成一部分类型的任务(也许还不到 80% 吧),但是如果妄图任何事情都要用它来搞,大概也就是削足而适履了。还有就是,没有像样的硬件环境,玩 MapReduce 真的一点都不好玩!

[ HADOOP中一种非典型两表JOIN的处理方法 ]

HADOOP中两表JOIN一直以来是很困扰我的一个问题,如果是两个大表JOIN更是如此!比如说有一件商品,收藏者有100万,而这件商品同时有 100万个类目(虽然这是不可能的),我的要求是要把每个用户和每一个类目关联起来,这样的话,对于同一个商品,就需要在内存中存放所有的收藏者100万 和类目100万,再来遍历这两个数组,将其关联。注意,由于是同一个key,因此,这个做法和单机上处理一个100万阶层的循环没有两样,程序跑死是非常 正常的!
       当然,类目不可能是100万,但按照正常需求来看,100万用户对1个类目,在单机上处理,也会耗费很多的时间和空间,实际测算来看,20分钟都不能跑出这个关联结果!
        根据剑英的一个想法,和志远讨论以后,这个问题现在看来已经可以被一种不典型做法解决了,现详述如下:
        实际案例就如上所说:一张表是商品和用户的关系,一张表是商品和类目的关系,一件商品最多可能被几百万用户收藏,而其对应的类目则是唯一。现在的要求就是把用户和类目关联起来,结果为用户和类目的对应关系。
        做法和结果如下:
        a.将同一个商品和其对应的百万用户按照HASH进行区分,也就是说,如果一件商品A,对应的有100万用户,我们人为的将这100万用户拆成N份,分别 丢进N个reduce中去处理。这样做的好处就是,原来一个reduce中要处理100万的数据量,现在则变成了只要处理100/n个,降低了每个 reduce的压力。
        b.由于将商品进行了拆分,所以其对应的类目我们要COPY N份给每个reduce,保证所有的用户都可以和其商品类目关联到。
         c.这样做,在map阶段其实是增加了数据量,由于原来只要1份类目表就可以了,但是现在需要N份类目表,因此,在map阶段的时间明显增加.
         d.原先没有按照HASH分布,20分钟整个程序都不能跑完,现在分开处理以后(HASH分布成5个),6分钟可以跑完,但是原先MAP只要1分钟,现在MAP用了有4分钟,整个程序用在MAP上的时间超过了REDUCE.

         对于我这个实例,经过几次实验后,发现HASH分成5个的时候时间最短,是6分钟。原因在于如果HASH分的多的话,类目表的拷贝也会多,由于类目表有2000万条数据,拷贝一遍就是2000万,现在5个HASH,也就是要多出1亿条数据!
        当然,这是一个特殊情况,对于同一个key来说,是“一组”极大的数据和“一条”数据进行关联,对于多对多,目前还没想出什么很好的办法!

使用 Hadoop 实现 Inner Join 操作

本文可以任意转载,转载时请务必以超链接形式标明文章 原始出处版权信息
http://www.guwendong.cn/post/2008/hadoop_inner_join.html

2008年10月22日 15:30:30 发布:guwendong

淘宝数据仓库团队,在“HADOOP中一种非典型两表JOIN的处理方法”这篇文章里, 无私地 share 了他们的方法。我就着他们的写一个续,权当讨论,抛砖引玉。淘宝团队的文章主要说的是大规模数据情况下如何计算,我这篇接着他们最后的问题,即“多对多”的情况说一下思路。

要解决的问题可以简化描述一下:
  1. 有两组数据,input1 { P1, U1; P1, U2; P2, U3; P3, U4; P4, U4 },input2 { P1, C1; P1, C2; P2, C3; P3, C3; P3, C4; P4, C4 }。
  2. 要 求执行类似于数据库两表 Inner Join 的操作,以 P 为 key,建立起 U 和 C 直接的对应关系,即最终结果为 output { U1, C1; U1, C2; U2, C1; U2, C2; U3, C3; U4, C3; U4, C4 }。

在数据库里,使用类似的 SQL 可以达到要求:SELECT DISTINCT(U, C) FROM input1 INNER JOIN input2 ON input1.P=input2.P。但如果要放在 Hadoop 里面求解,就需要动些脑筋了。

研究这个问题,首先需要理解 Hadoop 的运行机制。简单来讲,Hadoop 分为 Map 和 Reduce 两个操作:Map 操作将输入(如一行数据)格式化为 <key: value1><key: value2><key: value3> ... <key: valueN>这样的一组结果,作为 Map 的输出。Hadoop 在 Map 和 Reduce 之间,会自动把 Map 的输出按照 key 合并起来,作为 Reduce 的输入。Reduce 得到这样一个 {key: [value1, value2, value3, ..., valueN]} 的输入之后,就可以进行自己的处理,完成最终计算了。

针对于我们这里要解决的问题,步骤如下。
  1. 将 Map 的输入构造为下面的格式:来自于 input1 的输入格式化为 {<input1, P1>: U1, U2};来自于 input2 的输入格式化为 {<input2, P1>: C1, C2}。
  2. 在 Map 操作内,将数据转化为 {P1: <input1, U1>},{P1: <input1, U2>},{P1: <input2, C1>},{P1: <input2, C2>},作为 Reduce 操作的输入。
  3. 经过 Hadoop 内部自己的操作,实际 Reduce 操作的输入为:{P1: <input1, U1>, <input1, U2>, <input2, C1>, <input2, C2>}。
  4. Reduce 里操作会复杂一下。首先需要执行一次 regroup,得到如下的结果 {<input1>: <input1, U1>, <input1, U2>; <input2>: <input2, C1>, <input2, C2>}。把这个结果拆开,可以得到两个集合:{<input1>, <input2>} 与 {[<input1, U1>, <input1, U2>], [<input2, C1>, <input2, C2>]}。
  5. 循环集合2,即可以得到最终结果。不过在 Reduce 里面作这个循环是需要一定技巧的,讲起来比较绕,大家就直接看后面的代码吧。
  6. 在此 Reduce 的结果之上,再跑一个 Map/Reduce,还可以得到 <U, C>的次数,作为每个组合的权重。
对于大数据量,需要启用 Hadoop 的数据压缩功能。

这是一个通用地解决 Inner Join 问题的思路,在 Hadoop 的 contrib package 里有具体的代码实现,参见 org.apache.hadoop.contrib.utils.join
国内还有哪个 team 在用 Hadoop?欢迎交流!


hadoop上对文件进行压缩



hadoop计算需要在hdfs文件系统上进行,因此每次计算之前必须把需要用到的文件(我们称为原始文件)都上传到hdfs上。文件上传到hdfs上通常有两种方法:

    a hadoop自带的dfs服务,put;

b hadoop的API,Writer对象可以实现这一功能;

将a、b方案进行对比,如下:

    1 空间:方案a在hdfs上占用空间同本地,因此假设只上传日志文件,则保存一个月日志文件将消耗掉约10T空间,如果加上这期间的各种维表、事实表,将占用大约25T空间

                  方案b经测试,压缩比大约为3~4:1,因此假设hdfs空间为100T,原来只能保存约4个月的数据,现在可以保存约1年

    2 上传时间:方案a的上传时间经测试,200G数据上传约1小时

                            方案b的上传时间,程序不做任何优化,大约是以上的4~6倍,但存在一定程度提升速度的余地

    3 运算时间:经过对200G数据,大约4亿条记录的测试,如果程序以IO操作为主,则压缩数据的计算可以提高大约50%的速度,但如果程序以内存操作为主,则只能提高5%~10%的速度

    4 其它:未压缩的数据还有一个好处是可以直接在hdfs上查看原始数据。压缩数据想看原始数据只能用程序把它导到本地,或者利用本地备份数据

    压缩格式:按照hadoop api的介绍,压缩格式分两种:BLOCK和RECORD,其中RECORD是只对value进行压缩,一般采用BLOCK进行压缩。

    对压缩文件进行计算,需要用SequenceFileInputFormat类来读入压缩文件,以下是计算程序的典型配置代码:

JobConf conf = new JobConf(getConf(), log.class);
    conf.setJobName(”log”);
    conf.setOutputKeyClass(Text.class);//set the map output key type
    conf.setOutputValueClass(Text.class);//set the map output value type

    conf.setMapperClass(MapClass.class);
    //conf.setCombinerClass(Reduce.class);//set the combiner class ,if havenot, use Recuce class for default
    conf.setReducerClass(Reduce.class);
    conf.setInputFormat(SequenceFileInputFormat.class);//necessary if use compress

     SequenceFileInputFormat.setInputPath(new Path(your file path here));//your file path in hdfs

    接下来的处理与非压缩格式的处理一样

[ 本期目录 ]
Hadoop 实战:谁是最倒霉的人?
HADOOP中一种非典型两表JOIN的处理方法
使用 Hadoop 实现 Inner Join 操作
hadoop上对文件进行压缩
posted @ 2010-04-27 22:05  searchDM  阅读(613)  评论(0编辑  收藏  举报