我们有一个火花流微批处理过程，它使用来自 kafka 主题的数据，有 20 个分区。分区中的数据是独立的，可以独立处理。当前的问题是微批处理在开始下一个微批处理之前等待所有 20 个分区中的处理完成。因此，如果一个分区在 10 秒内完成处理，而另一个分区需要 2 分钟，那么第一个分区将不得不等待 110 秒才能消耗下一个偏移量。
我正在寻找一种流媒体解决方案，我们可以在其中独立处理 20 个分区，而无需等待其他分区完成处理。 Steaming 解决方案应以独立于其他分区的速率消耗来自每个分区的数据和进度偏移。
有人对哪种流媒体架构可以实现我的目标有任何建议吗？
答案 0 :(得分：1)
Flink (AFAIK)、KStreams 和 Akka Streams 中的任何一个都将能够独立地通过分区：除非您明确选择，否则它们都不会进行 Spark 风格的批处理。
Flink 与 Spark 的相似之处在于它有一个作业服务器模型； KStreams 和 Akka 都是您只需集成到您的项目中并像任何其他 JVM 应用程序一样部署的库（例如，您可以构建一个容器并在像 kubernetes 这样的调度程序上运行）。我个人更喜欢后一种方法：这通常意味着需要担心的基础设施更少，与其他地方使用的可观察性工具集成的阻抗不匹配也更少。
在基于时间窗口的处理和连接方面，Flink 是一个特别好的选择。
KStreams 从根本上将所有内容建模为从一个 kafka 主题到另一个主题的转换：主题拓扑由 KStreams 管理，但其中可能存在一些问题（尤其是当您处理任何时间序列时）。
Akka 是最通用的工具包，并且（在某种意义上）是最不自以为是的：您将不得不以更少的控制做出更多的决定（我说这是一个可以被称为 Akka 啦啦队长的人）；作为一个纯粹的流处理库，它可能不是理想的选择（尽管在资源消耗方面，能够更明确地管理背压（基本上，当数据进入速度快于处理速度时会发生什么）可能会使其更有效率比替代品）。如果您还打算利用集群分片（几乎可以肯定是事件源）actor，我可能只会选择它：这样做的好处是您可以将处理并行性与输入 Kafka 的数量完全分离分区（例如，您可以部署 40 个处理实例，并让每个实例处理来自 Kafka 的一半数据）。