Spark 流作为事件处理/处理解决方案（微服务）答案

【问题标题】：Spark streaming as event processing/handling solution (micro-services)Spark 流作为事件处理/处理解决方案（微服务）
【发布时间】：2019-11-02 23:54:55
【问题描述】：

Spark 批处理为我们的业务带来了很多价值，因为它很容易横向扩展（我们使用 AWS EMR 和 YARN）。

但是，随着我们最新的专有解决方案采用微服务架构，新的挑战出现了。到目前为止，有 ~230 个微服务充当生产者，其中事件存储在 Kafka 中（这意味着 ~230 个 Kafka 主题）。

虽然我们已经成功验证了使用 Spark Streaming 作为事件处理来构建对象的最新状态，但我是否正确地说每个 Kafka 主题都需要一个 Spark 流应用程序（所以，大约 230 个应用程序） ?

如果是这样，我们具有 48 个 vCPU 和 192GiB 内存 的集群只能同时处理 52 个流处理应用程序。这听起来太少了，因为这些应用程序（需要 24 小时运行）并没有做太多事情，因为它们只是每 5 秒拉一次事件并对我们的数据存储执行 CRUD 操作。

我是否想念使用 Spark 流式传输？您会采用/使用哪些其他方法或框架？

【问题讨论】：

标签： apache-spark event-handling spark-streaming microservices

【解决方案1】：

这听起来不对，您的微服务不需要 230 个主题，也不需要 230 个 spark 流式应用程序，但是您将使用每个分区 1 个任务，这意味着您需要 230*（每个分区topic) 核心来运行您决定构建的 230 或 1 个应用程序，请注意这取决于流量，但您的最佳选择可能是只有 1 个主题或一组较小的主题，根据消耗进行过滤。您可以订阅任意数量的主题。至于使用什么来构建状态存储，您可以查看 kafka 流或 akka 流。我根本不建议将 spark 流用于生产应用程序（这种说法是固执己见的）。 Akka 流是使用 IMO 最简单的 API，您可能需要在其上编写您的商店和 API。

【讨论】：

是的，我一定遗漏了一些明显的东西。其他非数据工程团队的做法是：每个生产者都应该有一个匹配的消费者。这就是我最初想出 230 个流媒体应用程序的方式。我们 90% 的主题（例如产品、品牌、零售价格）的流量非常低，每天只有 10 或 100 次活动。我听说了关于 Akka 的好消息。您是否建议将合同和解析逻辑部署为 JAR 依赖项的一组主题（基于流量）使用一个流处理应用程序？
如此融合开源的东西称为模式注册表，您可以将其用于解析逻辑，或者您可以共享代码。现在有不同的方法来处理这种事情，我喜欢有一个单一的存储库，这是让你所有的东西一直保持同步的最简单的方法。我建议，如果您有 90% 的主题具有这种流量，您可以让它们全部生成 1 个具有 1 个分区的单个主题。分区是您的并行化单元，如果您可以在一个分区上轻松处理流量，则不应放置更多，而这种流量的价值不会超过 1。
我不确定你们在做什么，但我认为你们遇到了架构问题。而且我对您的组织了解不够，不知道他们为什么要这样做。拥有数百个主题最终会给集群带来不必要的压力，尽管您可以在前几百个中幸存下来。你最初的问题可能与火花流有关，但我真的建议你放弃那个东西，遗憾的是我没有什么好说的，我想不出火花流比任何其他方法有任何好处。
@fd8s0...这真的很有帮助。我们的组织对微服务还很陌生，所以它肯定是一个架构问题，我们仍然需要自己解决。我们将从将那些 90% 的服务与低流量结合起来，然后从那里开始。由于 Spark Streaming 的坏名声，我也在考虑使用 Akka 流。再一次，真的很感激。