任务是独立地处理大量（大约10000000个）小文件（每个大约1mb）（即处理文件f1的结果独立于处理f2的结果）。
有人建议我的任务使用MapReduce（在AmazonEMRHadoop上）。然而，我对李先生有严重的怀疑。
原因是处理文件在我的情况下，是独立的。据我所知，当输出依赖于许多单独的文件时，mr工作得最好（例如，考虑到许多文档，计算每个单词的频率，因为一个单词可能包含在输入文件的任何文档中）。但在我的例子中，我只需要很多独立的cpu/内核。
我想知道你对此有什么建议。
旁注：还有一个问题是mr最适合“大文件而不是大量小文件”。尽管似乎有解决办法。所以我现在忽略它。
2条答案
按热度按时间ljsrvy3e1#
可以根据您的需要使用map reduce。在mapreduce中，有两个阶段
Map以及Reduce然而reduce阶段不是必须的，只是针对你的情况，你可以写一个map-onlymapreduce作业，并且单个文件上的所有计算都应放入定制的Map功能。但是，我没有在一个作业中处理这么多的文件，不知道它的效率。你自己试试，和我们分享：）
yh2wf1be2#
这很容易做到。在这种情况下，mr job的数据通常是文件列表（而不是文件本身）。因此，提交给hadoop的数据的大小是10m文件名的大小-这是最多两个gigs的顺序。
一种是使用mr将文件列表分割成更小的片段（有多少片段可以通过各种选项控制）。然后每个Map器都会得到一个文件列表。它可以一次处理一个文件并生成输出。
（fwiw-我建议使用qubole（我是这里的创始人）而不是emr，因为它可以通过自动缩放和现场集成为您节省大量资金）。