不确定这是否是正确的询问位置，但我目前正在尝试运行一个数据流作业，该作业会将数据源划分为多个位置的多个块。但是我觉得如果我尝试在一项作业中一次写入太多表，则数据流作业更有可能因 HTTP 传输异常错误而失败，并且我假设有一个绑定的多少 I/O我可以将源和汇的条款打包成一份工作吗？
为避免这种情况，我能想到的最佳解决方案是将这个作业拆分为多个数据流作业，但是这意味着我需要多次处理同一个数据源（针对哪个数据流作业一次） .现在还可以，但理想情况下，如果以后我的数据源变得庞大，我有点想避免它。
因此，我想知道我可以将多少数据源和接收器组合成一份稳定的工作，有什么经验法则吗？对于我的用例还有其他更好的解决方案吗？
【问题讨论】：
来自the Dataflow service description of structuring user code：
Dataflow 服务具有容错性，如果出现工作线程问题，可能会多次重试您的代码。 Dataflow 服务可能会为您的代码创建备份副本，并且可能会出现手动副作用的问题（例如，如果您的代码依赖于或创建具有非唯一名称的临时文件）。
一般来说，Dataflow 应该具有相对弹性。您可以根据您希望输出的位置Partition您的数据。对这些输出位置的写入将被自动分成包，任何未能写入的包都将被重试。
如果您要写入的位置尚不支持，您可以查看writing a custom sink。那里的文档描述了如何以容错的方式执行此操作。
在一项工作中可以拥有多少个源和汇是有限制的。你有关于你预计使用多少的任何细节吗？如果超过限制，也可以使用单个自定义接收器而不是多个接收器，具体取决于您的需要。
如果您还有其他问题，请随时发表评论。除了更多地了解您想要做什么之外，了解您是否计划将其作为批处理作业或流式作业运行也会有所帮助。
【讨论】：
我们对此的解决方案是编写一个支持分区的自定义 GCS 接收器。虽然我得到的回复我不确定这是否是正确的做法。 Writing Output of a Dataflow Pipeline to a Partitioned Destination
【讨论】：