Spark 批处理为我们的业务带来了很多价值，因为它非常容易水平扩展（我们将 AWS EMR 与 YARN 结合使用）。
然而，由于我们最新的专有解决方案遵循微服务架构，因此出现了新的挑战。到目前为止，有 ~230 个微服务充当生产者，其中事件存储在 Kafka 中（这意味着~230 个 Kafka 主题）。
虽然我们已经成功验证了使用 Spark Streaming 作为事件处理来构建对象的最新状态，但我说的对吗？每个 Kafka 主题需要一个 Spark Streaming 应用程序（因此，大约 230 个应用程序）？
如果是这样，我们具有48 vCPU和192GiB内存的集群只能同时处理52个流处理应用程序。这听起来太少了，因为这些应用程序（需要运行 24 小时）并没有做太多事情，因为它们只是每 5 秒提取一次事件并对我们的数据存储执行 CRUD 操作。
我怀念使用 Spark Streaming 的日子吗？您会采取/使用什么其他方法或框架？
这听起来不对，您的微服务不需要 230 个主题，也不需要 230 个 Spark 流应用程序，但是每个分区将使用 1 个任务，这意味着您需要 230*（每个主题的分区）核心来运行您决定构建的 230 或 1 个应用程序，请注意，这取决于流量，但您的最佳选择可能是只有 1 个主题或一组较小的主题，根据消耗进行过滤。您可以订阅任意数量的主题。 至于使用什么来构建状态存储，您可以查看 kafka 流或 akka 流。我根本不推荐将 Spark Streaming 用于生产应用程序（此声明属于固执己见）。在我看来，Akka Streams 是最容易使用的 API，您可能需要在其上编写您的商店和 API。
编辑：使用 fs2-kafka 或 zio-kafka