考虑一个应用程序,它想要使用 Hadoop
来处理大量专有二进制编码的文本数据,大致如下简化的 MapReduce
序列:
- 获取文件或目录的 URL 作为输入
- 读取在输入 URL 下找到的二进制文件列表
- 从每个文件中提取文本数据
- 将文本数据保存到新的、提取的纯文本文件中
- 将提取的文件分类为具有特殊特征(例如,“上下文”)的(子)格式
- 如有必要,根据上下文拆分每个提取的文本文件
- 使用原始(未拆分)文件的上下文处理每个拆分
- 将处理结果提交给专有数据存储库
第 5 步中识别的格式特定特征(上下文)也作为键值对保存在(小)文本文件中,以便第 6 步和第 7 步可以访问它们。
第 6 步中的拆分使用自定义 InputFormat
类(每个自定义文件格式一个)进行。
为了在 Hadoop 中实现这个场景,可以将第 1 步到第 5 步集成到一个 Mapper
中,并为第 7 步使用另一个 Mapper
。
这种方法的一个问题是如何使自定义 InputFormat
知道要使用哪些提取的文件来生成拆分。例如,格式 A 可能代表 2 个具有略微不同特征(例如,不同的行定界符)的提取文件,因此有 2 个不同的上下文,保存在 2 个不同的文件中。
基于上述内容,每个自定义 InputFormat
的 getSplits(JobConf)
方法需要在拆分文件之前访问每个文件的上下文。但是,每种格式(最多)可以有 1 个 InputFormat
类,因此如何将一组适当的提取文件与正确的上下文文件相关联?
一个解决方案可能是使用一些特定的命名约定来关联提取的文件和上下文(反之亦然),但有没有更好的方法?
最佳答案
这听起来更像是一个 Storm(流处理)问题,其中有一个 spout 从一个 URL 加载二进制文件列表,然后拓扑中的后续 bolt 执行以下每个操作。
关于java - 复杂的 MapReduce 配置场景,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15672910/