具有实例本地缓存 + 外部 REST API 调用的 Google 数据流管道

Question

我们希望构建一个 Cloud Dataflow 流式传输管道，该管道从 Pubsub 提取事件并对每个单独的事件执行多个类似 ETL 的操作。这些操作之一是每个事件都有一个 device-id 需要转换为不同的值（我们称之为 mapped-id），从 em>device-id->mapped-id 由外部服务通过 REST API 提供。相同的 device-id 可能会在多个事件中重复 - 因此这些 device-id->mapped-id 映射可以被缓存和重用。由于我们可能在峰值时通过管道每秒处理多达 3M 的事件，因此需要尽可能减少对 REST API 的调用，并在实际需要调用时进行优化。

考虑到这个设置，我有以下问题。

• 为了优化 REST API 调用，Dataflow 是否提供任何内置优化，例如连接池，或者如果我们决定使用自己的此类机制，是否需要牢记任何限制/限制？

• 我们正在研究一些内存缓存选项，以在本地缓存映射，其中一些也由本地文件支持。那么，对于这些缓存可以使用多少内存（作为总实例内存的一小部分）而不影响工作人员中的常规数据流操作，是否有任何限制？如果我们使用文件支持的缓存，每个工作人员上是否有一个路径可以安全地被应用程序本身用来构建这些文件？

• 唯一 device-id 的数量可能在数百万的数量级 - 因此并非所有这些映射都可以存储在每个实例中。因此，为了更好地利用本地缓存，我们需要在 device-id 和处理它们的 worker 之间建立一些关联。我可以在发生此转换的阶段之前根据 device-id 进行分组。如果我这样做，是否可以保证相同的 device-id 或多或少会由同一个工作人员处理？如果有一些合理的保证，那么除了第一次调用应该没问题之外，我大部分时间都不必点击外部 REST API。或者有没有更好的方法来确保 id 和工人之间的这种亲和力。

谢谢

Answer 1

您可以做以下几件事：

• 您的 DoFn 可以有实例变量，您可以将缓存放在那里。
• 也可以使用常规 Java 静态变量作为 VM 本地的缓存，只要您正确管理对它的多线程访问。 Guava CacheBuilder 在这里可能真的很有帮助。
• 对工作人员的临时文件使用常规 Java API 是安全的（但同样，请注意对文件的多线程/多进程访问，并确保清理它们 - 您可能会发现 DoFn @Setup 和 @ 987654324@ 方法有用）。
• 你可以通过设备ID做一个GroupByKey；然后，大多数情况下，至少对于 Cloud Dataflow 运行器，相同的键将由相同的工作程序处理（尽管键分配可以在管道运行时更改，但通常不会太频繁）。不过，您可能希望设置立即触发的窗口/触发策略。