Hadoop 处理 WARC 文件答案

【问题标题】：Hadoop process WARC filesHadoop 处理 WARC 文件
【发布时间】：2016-10-30 05:22:52
【问题描述】：

我有一个关于 Hadoop 文件拆分和多个映射器的一般性问题。我是 Hadoop 新手，正在尝试了解如何设置以获得最佳性能。我的项目目前正在处理 GZIPed 的 WARC 文件。

使用当前的 InputFileFormat，文件被发送到一个映射器并且不被拆分。我知道这是加密文件的正确行为。在运行作业以允许拆分作业并因此使用更多映射器之前将文件解密作为中间步骤是否会带来性能优势？那可能吗？拥有更多的映射器会产生更多的延迟开销，还是拥有一个映射器更好？谢谢你的帮助。

【问题讨论】：

基本上这取决于你在哪里运行它。如果您在单台机器上运行它，那么我认为不会有太大的性能提升。但是，如果您在分布式环境中运行它，那么是的。您可以拆分文件并将其发送到多个映射器，这些映射器又在其他机器上同时运行。以便您更快地得到答案。假设程序在一台机器上运行了 10 个小时。现在，如果您有 10 台机器并将其映射到这 10 台机器，并行执行 1 小时，您就可以查看结果。
感谢您的回复。我正在使用 Amazon Elastic Map Reduce 服务进行处理。使用当前配置，我只利用一个映射器，这意味着其他节点处于空闲状态，这对我来说似乎是一种浪费。理想情况下，我希望将文件拆分为多个映射器，以利用我提供的所有节点。我想你已经回答了我是否应该先将文件解密到本地存储以便可以通过 hadoop 系统将其拆分到多个映射器的问题。
请记住，每次爬网都有数以万计的 WARC 文件，因此拆分单个文件可能并不重要（至少对我的用例来说并不重要）。仅供参考，我在 github 上放了一些示例代码，以便能够读取 Hadoop/Spark 中的 WARC 文件 - github.com/banshee/ccsparkWarc。读入WARC文件后，将繁重的解析移到一个步骤，一切都会正常分发。

标签： java hadoop mapreduce elastic-map-reduce common-crawl

【解决方案1】：

虽然 WARC 文件经过 gzip 压缩，但它们是可拆分的（参见 Best splittable compression for Hadoop input = bz2?），因为每条记录都有自己的 deflate 块。但必须提前知道记录偏移量。

但这真的有必要吗？ Common Crawl WARC 文件的大小都在 1 GB 左右，应该在最大范围内正常处理。 15分钟。鉴于启动映射任务的开销是映射器运行的合理时间。例如，一个映射器也可以处理一些 WARC 文件，但重要的是您有足够的输入 WARC 文件列表拆分，以便所有节点都在运行任务。在 Hadoop 上处理单个 WARC 文件将意味着大量不必要的开销。

【讨论】：

感谢 Sebastian 的回复。我的映射器正在对 GZipped WARC 文件中包含的每条记录执行繁重的解析任务。我最初的测试用了大约 30 分钟来映射和缩减 1 个 GZipped 文件。我已经在本地测试了一种生产者/消费者方法，让一个线程遍历流中的所有记录，并将其放入队列中，以便消费者线程解析出内容主体。如果我可以拆分以让更多的映射器并行运行，我可能会将每个 WARC 存档文件的时间缩短到几分钟。这听起来合理还是错误的方法？