在我的云数据准备冒险中，我遇到了另一个非常烦人的错误。
当创建需要通过参考数据集连接的复杂流结构时会出现问题。如果在执行多个联合或与这些集合的连接时超过了某个限制，数据流将无法启动作业。
我与支持部门有很多联系，他们正在解决这个问题：
“我们的系统工程师团队能够确定导致工作失败的根本原因。他们提到工作太大。这意味着配方（从所有数据集组合）太大，Dataflow 拒绝它。我们的工程团队仍在研究解决此问题的方法。
一种解决方法是将作业拆分为两个较小的作业。首先运行用于数据丰富的流，然后将输出用作另一个流中的输入。虽然这并不理想，但这暂时是一个可行的解决方案。”
我遇到了同样的问题，并且对答案有一个相当有根据的猜测。请记住，DataPrep 只是获取所有基于 GUI 的输入并将其转换为 Apache Beam 代码。当您传入参考数据集时，它可能会编写一些 AB 代码，将参考数据集转换为侧输入 ( https://beam.apache.org/documentation/programming-guide/ )。DataFlow 将执行 Parellel Do (ParDo) 函数，它从 PCollection 中获取每个元素，将其填充到工作节点中，然后应用侧输入数据进行转换。
所以我很确定如果参考集太大（这可能发生在 Joins 中），底层代码将从数据集 A 中获取一个元素，将其传递给带有侧输入 B 的函数......但如果侧输入 B非常大，将无法放入工作人员内存中。查看 Stackdriver 日志以了解您的工作是否属于这种情况。如果您在日志中看到“GC（分配失败）”，则表明内存不足。
您可以尝试这样做：假设您有两个 CSV 文件要读取和处理，文件 A 为 4 GB，文件 B 也是 4 GB。如果您开始工作以执行某种类型的联接，它将很快超出工作人员的记忆和呕吐。如果可以，请查看是否可以以其中一个文件在 MB 范围内的方式进行预处理，然后只增加另一个文件。
如果您的数据结构不适合该选项，您可以按照 Sys Engs 的建议进行操作，将一个文件分成许多小块，然后针对另一个较大的文件迭代地将其提供给配方。
另一个测试选项是为工作人员指定计算类型。您可以迭代地将计算类型越来越大，以查看它是否最终通过。
另一种选择是在 Apache Beam 中自己编写代码，在本地进行测试，然后移植到 Google Cloud DataFlow。
希望这些人能尽快解决问题，他们不会轻易向他们提问，这是肯定的。