我使用boto2.8.0在存储在s3中的大型日志文件上创建emr作业流。我对elasticmapreduce还比较陌生，并且正在了解如何正确处理这个问题带来的工作流。
有问题的日志文件存储在s3中，其密钥与日志服务器发出的日期相对应，例如： /2013/03/01/access.log . 这些文件非常非常大。我的mapreduce作业运行一个apachepig脚本，该脚本只检查存储在日志文件中的一些uri路径，并输出与我们的业务逻辑相对应的通用计数。
boto中的客户机代码将日期时间作为cli上的输入，并使用 PigStep 为每个需要的日期提供示例。因此，通过类似 python script.py 2013-02-01 2013-03-01 将迭代29天的datetime对象，并使用s3的相应输入键创建pigsteps。这意味着产生的jobflow可以有很多很多步骤，在两个步骤之间的timedelta中每天一个步骤 from_date 以及 to_date .
我的问题是，我的电子病历工作流程非常缓慢，几乎荒谬。它已经运行了一个晚上了，甚至还没有完成那个示例集的一半。我创建了许多这样的jobflow步骤，有什么不对吗？我是否应该尝试为不同的键泛化pig脚本，而不是在客户机代码中对其进行预处理并为每个日期创建一个步骤？这是一个可行的地方，寻找一个优化的弹性mapreduce？值得一提的是，一份类似的工作将一个月的可比数据传递给了美国焊接学会 elastic-mapreduce cli ruby client花了大约15分钟来执行（这个作业是由同一个pig脚本驱动的）
编辑
忽略了提及，job被安排用于两个m1.small类型的示例，这本身可能就是问题所在。