google-cloud-dataflow - 具有实例本地缓存 + 外部 REST API 调用的 Google Dataflow Pipeline

Question

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

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

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

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

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

谢谢

Answer 1

您可以执行以下操作:

• 您的 DoFn 可以有实例变量，并且您可以将缓存放在那里。
• 只要正确管理对它的多线程访问，也可以使用常规 Java 静态变量作为虚拟机本地的缓存。 Guava CacheBuilder 在这里可能真的很有帮助。
• 对工作线程上的临时文件使用常规 Java API 是安全的(但再次请注意对文件的多线程/多进程访问，并确保清理它们 - 您可能会发现 DoFn @Setup 和 @Teardown 方法很有用)。
• 您可以通过设备ID进行GroupByKey；那么，大多数时候，至少对于 Cloud Dataflow 运行程序，相同的 key 将由同一工作人员处理(尽管 key 分配可能会在管道运行时发生变化，但通常不会太频繁)。不过，您可能希望设置立即触发的窗口/触发策略。