我有一个事件流，我想计算其属性如何在客户 ID 级别随时间变化。示例事件类似于 {“customer_ID”: 1, “property_1”: “val_1”, “property_2”: “val_2”}。预期输出类似于 {“customer_ID”: 1, “property_1_list”: “val_1, val_3, …”, “property_2_list”:”val_2, val_5, …”}。 此输出将存储在远程数据库中，因此我的 Flink 应用程序需要首先从数据库检索以前的值，然后更新该值。
棘手的部分是，某些客户 ID 可能比其他客户 ID 拥有更多事件，从而成为热键并导致某些 Flink 子任务持续繁忙。我发现的一个潜在的优化是进行预洗牌聚合。但是，热门客户 ID 可能会发生变化，如何动态设置热键并对其进行更积极的聚合，同时保持这些常规键不变？
关于处理热键还有其他建议吗？也许一个单独的 Flink 应用程序首先检测哪些是热门客户，将它们放入远程缓存中，然后使用专用的 Flink 应用程序来处理带有热键的事件？
如果您要为每个客户进行远程数据库获取，请使用 Flink 的Async IO 支持和足够的线程，并且您不应该看到“热”子任务，因为大多数时候您的工作流程将等待来自数据库。
请注意，您的工作流程将受到数据库处理多个请求的速度的限制。这通常是使用外部数据库的 Flink 工作流程的瓶颈。
您可以通过缓存数据库中的结果来加快速度，这对于“热键”情况应该非常有效。只需在 RichAsyncFunction 的 asyncInvoke 方法中使用简单的内存缓存（例如 Java LinkedHashMap）即可。
问候，
--肯