全局窗口上 Combine.PerKey 的内存使用情况答案

【问题标题】：Memory usage of Combine.PerKey on a global window全局窗口上 Combine.PerKey 的内存使用情况
【发布时间】：2017-01-20 05:14:10
【问题描述】：

我们使用带有自定义 KeyedCombineFn 的 Combine.PerKey 对几个 PCollection 执行连接。在 AfterProcessingTime.pastFirstElementInPane 上使用 Repeatedly.forever 触发器将 PCollections 分配给 GlobalWindow。

PCollections 包含大约 1M 个键，但对于给定的键只有几百个元素。 KeyedCombineFn 在其累加器中保留大约几 KB（有时高达 5 MB）的数据。

现在我们已经增加了在管道中处理的数据量，我们看到了 java.lang.OutOfMemoryError: Java heap space error。该管道在 Google Cloud Dataflow 上的 n1-highmem-4 机器上运行。

我们的假设是，Dataflow 工作人员独立管理每个键的状态，并根据可用 RAM 的大小，采用启发式方法将其写入/加载到磁盘或从磁盘加载。因此，目标是让单个状态适合一个工人的记忆。

这个假设正确吗？如果是这样，为什么我们会看到 OOM 错误？如果没有，您介意详细说明 Dataflow 工作人员如何管理内存中的状态吗？

【问题讨论】：

标签： google-cloud-dataflow

【解决方案1】：

Dataflow 工作人员的行为确实与您的假设大致相同，但涉及到一些估计，您的数据可能会破坏这一点。您的累加器的序列化大小和对象的内存大小是否存在很大差异？

尝试解决此问题的最简单方法是在更少的大型机器上运行，例如 n1-highmem-8

【讨论】：

谢谢！我们很可能会出现这种情况。您所说的“大差异”是什么意思？有没有什么经验法则可以避免这个问题？并且，您对我们如何在正在运行的流式数据流作业中衡量这一点有任何建议吗？
工作工具当前缓存了 100MB 的序列化数据的内存对象。如果这足以超过机器限制，您可以点击它。最好的办法是分析一个堆转储，你可以通过设置 --heapDumpOnOOM 得到它：github.com/GoogleCloudPlatform/DataflowJavaSDK/blob/master/sdk/…
谢谢。改变我们的序列化器似乎已经成功了。