我正在使用 boto 2.8.0 在存储在 S3 中的大型日志文件上创建 EMR 作业流。我对 Elastic Mapreduce 比较陌生，并且正在了解如何正确处理此问题的工作流。
有问题的日志文件存储在 s3 中，其键对应于它们从日志服务器发出的日期，例如：/2013/03/01/access.log. 这些文件非常非常大。我的 mapreduce 作业运行一个 Apache Pig 脚本，它只检查存储在日志文件中的一些 uri 路径并输出与我们的业务逻辑相对应的通用计数。
我在 boto 中的客户端代码将日期时间作为 cli 的输入，并为每个需要的日期安排一个带有PigStep实例的工作流。因此，传递类似的东西python script.py 2013-02-01 2013-03-01会迭代超过 29 天的 datetime 对象，并使用 s3 的相应输入键创建 pigsteps。from_date这意味着生成的工作流可能有很多很多步骤，在和之间的时间增量中每天一个to_date。
我的问题是我的 EMR 工作流程非常缓慢，几乎是荒谬的。它已经运行了一个晚上，甚至还没有完成该示例集的一半。我在创建许多这样的工作流程步骤时有什么问题吗？我是否应该尝试为不同的键概括猪脚本，而不是在客户端代码中对其进行预处理并为每个日期创建一个步骤？这是在 Elastic Mapreduce 上寻找优化的可行地方吗？值得一提的是，一项类似的工作需要将几个月的可比数据传递给 AWS elastic-mapreducecli ruby 客户端大约需要 15 分钟才能执行（这项工作是由同一个 pig 脚本推动的。）
编辑
不得不提的是，作业被安排在两个 m1.small 类型的实例上，诚然，这本身可能就是问题所在。