Mapreduce、MR-IncrementalTask、ApiProxy$RequestTooLargeException答案

【问题标题】：Mapreduce, MR-IncrementalTask, ApiProxy$RequestTooLargeExceptionMapreduce、MR-IncrementalTask、ApiProxy$RequestTooLargeException
【发布时间】：2013-10-15 16:20:47
【问题描述】：

在应用引擎的 java 实例中，我使用 mapreduce 进行迭代用来做一些总结的实体集合。

当我运行 10 个分片时，我得到了很多：

/mapreduce/workerCallback
com.google.apphosting.api.ApiProxy$RequestTooLargeException: 
The request to API call datastore_v3.Put() was too large.

我的映射器正在尝试处理大约 70,000 个实体，每个实体大约 750 个字节。对于我的映射器的每次调用，我可能会读取几十个数据存储区，并且可能会读取两个数据存储更新。

我确信我的个人实体远未达到 1MB 数据存储限制。运行更多的分片并没有真正的帮助。

我注意到 mapreduce 添加了一些实体类型，其中之一是 MR-IncrementalTask。当这些错误出现时，MR-IncrementalTask 实体会变大，比如 800k 或 900k。我怀疑这些错误与这些变得太大有关。

那么，为什么这些会变得这么大，我可能会做什么样的事情有什么贡献？

谢谢大家。

【问题讨论】：

像往常一样，我现在回答我自己的问题。这是猜想，但我认为 mapreduce 正在序列化我的映射器类并将其存储在 MR-IncrementalTask 中。最近，我在类中添加了一些新数据（用于优化）。我认为这些数据在分片的生命周期内不断积累。从图片中删除这些数据已经解决了我的问题。

标签： java google-app-engine mapreduce

【解决方案1】：

您是正确的，映射器类在任务队列中的任务执行之间被序列化并写入数据存储区。这为在运行时更新的映射器的任何成员变量提供了连续性。

减少与此数据变大相关的问题，并降低开销或读写它。较新版本的 MapReduce 会压缩此状态。

【讨论】：