写入云存储作为云数据流中的副作用

Question

我有一个云数据流作业，它为 appengine 应用程序执行大量处理。在管道的一个阶段，我按特定键进行分组，对于与该键匹配的每条记录，我想将文件写入 Cloud Storage（使用该键作为文件名的一部分）。

我事先不知道这些记录会有多少。所以这种使用模式不符合标准的云数据流数据接收器模式（输出阶段的分片决定了#个输出文件，我无法控制每个分片的输出文件名）。

我正在考虑直接写入云存储作为 ParDo 函数的副作用，但有以下疑问：

1. 是否允许将写入云存储作为副作用？
2. 如果我是从数据流管道外部编写的，似乎我应该将 Java 客户端用于 JSON 云存储 API。但这涉及通过 OAUTH 进行身份验证以执行任何工作：对于已经在 GCE 机器上作为数据流管道的一部分运行的工作，这似乎不合适：这可行吗？

感谢您的任何建议。

Answer 1

回答你问题的第一部分：

虽然没有什么可以直接阻止您在我们的管道代码中执行副作用（例如写入 Cloud Storage），但通常这是一个非常糟糕的主意。您应该考虑您的代码不是在单台机器上以单线程方式运行的事实。你需要处理几个问题：

1. 多个写入器可以同时写入。你需要找到一种方法来避免作家之间的冲突。由于 Cloud Storage 不支持直接附加到对象，您可能需要使用 Composite objects 技术。
2. 工人可以被中止，例如如果基础设施出现暂时性故障或问题，这意味着您需要能够处理中断/不完整的写入问题。
3. 可以重新启动工作器（在它们被中止之后）。这将导致副作用代码再次运行。因此，您需要能够以一种或另一种方式处理输出中的重复条目。

Answer 2

Dataflow 中的任何内容都不会阻止您在 ParDo 中写入 GCS 文件。

您可以使用GcpOptions.getCredential() 获取用于身份验证的凭据。这将使用合适的机制来获取凭据，具体取决于作业的运行方式。例如，当作业在 Dataflow 服务上执行时，它将使用服务帐户。