map连接

最新推荐文章于 2021-01-18 20:34:21 发布

阿豪963

最新推荐文章于 2021-01-18 20:34:21 发布

阅读量1k

点赞数

分类专栏： hadoop

hadoop 专栏收录该内容

33 篇文章 0 订阅

订阅专栏

复制连接（Replication join）

复制连接是map端的连接。复制连接得名于它的具体实现：连接中最小的数据集将会被复制到所有的map主机节点。复制连接有一个假设前提：在被连接的数据集中，有一个数据集足够小到可以缓存在内存中。

如图4.5所示，MapReduce复制连接工作原理如下：

使用分布式缓存（Districubted cache）将这个小数据集复制到所有运行map任务的节点。
用各个map任务初始化方法将这个小数据集装载到一个哈希表（hashtable）中。
逐条用大数据集中的记录遍历这个哈希表，逐个判断是否符合连接条件。
输出符合连接条件的结果。

复制连接的实现非常直接明了。这个框架支持任意类型的InputFormat和OutputFormat的数据。（我们将在下一个技术中使用这个框架。）复制连接框架根据内存足迹的大小从分布式缓存的内容和输入块（input split）两者中动态地决定需要缓存的对象。

如果所有的输入数据集都不能够小到可以放到缓存中，那有没有办法来优化map端连接呢？那就到了看半连接（semi-join）的时间了。

半连接（Semi-join）

假设一个场景，需要连接两个很大的数据集，例如，用户日志和OLTP的用户数据。任何一个数据集都不是足够小到可以缓存在map作业的内存中。这样看来，似乎就不能使用reduce端的连接了。尽管不是必须，可以思考以下问题：如果在数据集的连接操作中，一个数据集中有的记录由于因为无法连接到另一个数据集的记录，将会被移除。这样还需要将整个数据集放到内存中吗？在这个例子中，在用户日志中的用户仅仅是OLTP用户数据中的用户中的很小的一部分。那么就可以从OLTP用户数据中只取出存在于用户日志中的那部分用户的用户数据。然后就可以得到足够小到可以放在内存中的数据集。这种的解决方案就叫做半连接。

图4.6说明了在半连接中将要执行的三个MapReduce作业（Job）。

接下来介绍如何实现一个半连接。

实现半连接

当需要连接两个都很大的数据集时，很容易想到要用重分区连接（利用了整个MapReduce框架的reduce端的连接）。如果这么想了，又不能够将其中一个数据集过滤到一个较小的尺寸以便放到map端的内存中，那也就是想想而已。然而，如果能够将一个数据集减小到一个可管理的大小，也许就用不着使用重分区连接了。

问题

需要连接两个都很大的数据集，同时减少整理和排序阶段的消耗。

解决方案

在这个技术中，将会用到三个MapReduce作业来连接两个数据集，以此来减少reduce端连接的消耗。对于很大的数据集，这个技术非常有用。

作业1的map和reduce的代码如下

public static class Map extends Mapper<Text, Text, Text, NullWritable> {

private Set<String> keys = new HashSet<String>();

@Override
protected void map(Text key, Text value, Context context)
throws IOException, InterruptedException {
keys.add(key.toString());
}

@Override
protected void cleanup(Context context)
throws IOException, InterruptedException {

Text outputKey = new Text();

for(String key: keys) {
outputKey.set(key);
context.write(outputKey, NullWritable.get());
}

}

}

public static class Reduce extends Reducer<Text, NullWritable, Text, NullWritable> {

@Override
protected void reduce(Text key, Iterable<NullWritable> values, Context context)
throws IOException, InterruptedException {
context.write(key, NullWritable.get());
}

}

作业1的结果就是来自于日志文件中的所有用户的集合。集合中的用户名是唯一的。

作业2包含了复杂的过滤过程。目的是从全体用户的用户数据集中移除不存在于日志文件中的用户。这是一个只包含map的作业。它用到了复制连接来缓存出现在日志文件中的用户名，并把他们和全体用户的数据集连接。由于来自于作业1的用户唯一的数据集要远远小于全体用户的数据集，就把来自作业1的用户集放到缓存中了。图4.8说明了这个作业的流程：

现在是个不错的时间去熟悉一下附录D中的复制连接框架。这个框架对KeyValueTextInputFormat和TextOutputFormat提供了内置支持，并假设 KeyValueTextInputFormat生成的键是连接键。同时，这也是数据被展开的过程。图4.9是这个框架的类图：

GenericReplicatedJoin类是执行连接的类。如图4.9中所示，在GenericReplicatedJoin的类列表中前三个类是可扩展的，相对应的复制连接的行为也是可定制的。readFromInputFormat方法可以用于任意的输入类型（InputFormat）。getDistributedCacheReader方法可以被重载来支持来自于分布式缓存（distributed cache）的任意文件类型。在这一步中的核心是join方法。join方法将会生成作业的输出键和输出值。在默认的实现中，两个数据集的值将会被合并以生成最终的输出值。这个join方法可以自定义，可以指定仅仅输出来自于OLTP的用户表的值，如下所示：

public class ReplicatedFilterJob extends GenericReplicatedJoin {

@Override
public Pair join(Pair inputSplitPair, Pair distCachePair) {
return inputSplitPair;
}

}

还需要把来自于作业1的文件放到分布式缓存中：

for(FileStatus f: fs.listStatus(uniqueUserStatus)) {
     if(f.getPath().getName().startsWith("part")) {
         DistributedCache.addCacheFile(f.getPath().toUri(), conf);
     }
 }

然后，在驱动（driver）代码中，调用GenericReplicatedJoin类

public class ReplicatedFilterJob extends GenericReplicatedJoin {

public static void runJob(Path usersPath,
Path uniqueUsersPath,
Path outputPath)
throws Exception {

Configuration conf = new Configuration();

for(FileStatus f: fs.listStatus(uniqueUsersPath)) {
if(f.getPath().getName().startsWith("part")) {
DistributedCache.addCacheFile(f.getPath().toUri(), conf);
}
}

Job job = new Job(conf);
job.setJarByClass(ReplicatedFilterJob.class);
job.setMapperClass(ReplicatedFilterJob.class);
job.setNumReduceTasks(0);
job.setInputFormatClass(KeyValueTextInputFormat.class);
outputPath.getFileSystem(conf).delete(outputPath, true);
FileInputFormat.setInputPaths(job, usersPath);
FileOutputFormat.setOutputPath(job, outputPath);

if(!job.waitForCompletion(true)) {
throw new Exception("Job failed");
}

}

@Override
public Pair join(Pair inputSplitPair, Pair distCachePair) {
return inputSplitPair;
}

}

作业2的输出就是已被用户日志数据集的用户过滤过的用户集了。

作业3

在最后一步中，需要将作业2生成的已过滤的用户集和原始的用户日志合并了。表面上，已过滤的用户集是足够小到可以放到内存中，同样也可以放到分布式缓存中。图4.10说明了这个作业的流程：

FileStatus usersStatus = fs.getFileStatus(usersPath);

for(FileStatus f: fs.listStatus(usersPath)) {

if(f.getPath().getName().startsWith("part")) {
DistributedCache.addCacheFile(f.getPath().toUri(), conf);
}

...

这里要再次用到复制连接框架来执行连接。但这次不用自定义join方法的行为，因为两个数据集中的数据都要出现在最后的输出中。

执行这个代码，观察前述步骤生成的输出。

$ bin/run.sh com.manning.hip.ch4.joins.semijoin.Main users.txt user-logs.txt output

$ hadoop fs -ls output
/user/aholmes/output/filtered
/user/aholmes/output/result
/user/aholmes/output/unique

$ hadoop fs -cat output/unique/part*
bob
jim
marie
mike

$ hadoop fs -cat output/filtered/part*
mike 69 VA
marie 27 OR
jim 21 OR
bob 71 CA

$ hadoop fs -cat output/result/part*
jim logout 93.24.237.12 21 OR
mike new_tweet 87.124.79.252 69 VA
bob new_tweet 58.133.120.100 71 CA
mike logout 55.237.104.36 69 VA
jim new_tweet 93.24.237.12 21 OR
marie view_user 122.158.130.90 27 OR
jim login 198.184.237.49 21 OR

marie login 58.133.120.100 27 OR

这些输出说明了在半连接的作业中的逻辑进程和最终连接的输出。

小结

在这个技术中说明了如何使用半连接来合并两个数据集。半连接的创建包括了比其他连接类型更多的步骤。但它确实是一个处理大的数据集的map端连接的强大的工具。当然，这些很大的数据集要能够被减小到能够放到内存中。