Akka Stream Kafka 与 Kafka Streams
Akka Stream Kafka vs Kafka Streams
我目前正在与 Akka Stream Kafka to interact with kafka and I was wonderings what were the differences with Kafka Streams 合作。
我知道基于 Akka 的方法实现了响应式规范并处理背压，kafka 流似乎缺少这些功能。
使用 kafka streams 相对于 akka streams kafka 有什么优势？
你的问题很笼统，我就从我的角度作一个笼统的回答。
首先，我有两个使用场景：
- 我从 kafka 读取数据、处理它并将一些输出写回 kafka 的情况，对于这些我只使用 kafka 流。
- 数据源或接收器不是 kafka 的情况，对于那些我使用 akka 流的情况。
这已经让我可以回答关于背压的部分：对于上面的第一种情况，kafka 流中有一个背压机制。
现在我们只关注上述第一种情况。让我们看看如果我决定停止使用 Kafka 流我会失去什么：
- 我的一些流处理器阶段需要持久（分布式）状态存储，kafka 流为我提供了它。这是 akka 流不提供的。
- 缩放，kafka streams 会在流处理器的新实例启动或被杀死时自动平衡负载。这适用于同一个 JVM 以及其他节点：向上和向外扩展。这不是 akka 流提供的。
这些是对我来说最重要的差异，我希望它对你有意义！
Akka Stream 相对于 Kafka Streams 的最大优势在于可以实现非常复杂的处理图，这些图可以与 fan in/out 和反馈循环一起循环。如果我没记错的话，Kafka 流只允许非循环图。在 Kafka 流之上实现循环处理图会非常复杂
发现这篇文章很好地总结了 Kafka Streams 提供的分布式设计问题（补充 Akka Streams）。
https://www.beyondthelines.net/computing/kafka-streams/
message ordering: Kafka maintains a sort of append only log where it stores all the messages, Each message has a sequence id also known as its offset. The offset is used to indicate the position of a message in the log. Kafka streams uses these message offsets to maintain ordering.
partitioning: Kafka splits a topic into partitions and each partition is replicated among different brokers. The partitioning allows to spread the load and replication makes the application fault-tolerant (if a broker is down the data are still available). That’s good for data partitioning but we also need to distribute the processes in a similar way. Kafka Streams uses the processor topology that relies on Kafka group management. This is the same group management that is used by the Kafka consumer to distribute load evenly among brokers (This work is mainly managed by the brokers).
Fault tolerance: data replication ensures data fault tolerance. Group management has fault tolerance built-in as it redistributes the workload among remaining live broker instances.
State management: Kafka streams provides a local storage backed up by a kafka change-log topic which uses log compaction (keeps only latest value for a given key).Kafka log compaction
Reprocessing: When starting a new version of the app, we can reprocess the logs from the start to compute new state then redirect the traffic the new instance and shutdown old application.
Time management: “Stream data is never complete and can always arrive out-of-order” therefore one must distinguish the event time vs processed time and handle it correctly.
作者还说 “使用这个更改日志主题 Kafka Stream 能够维护应用程序状态的“table 视图”。”
我的看法是，这主要适用于“应用程序状态”……小的企业应用程序。
对于使用“大数据”的数据科学应用程序，由数据处理、机器学习模型和业务逻辑组合产生的用于协调所有这些的“应用程序状态”可能无法通过 Kafka Streams.
此外，我认为使用 “纯函数式事件源运行时”，如 https://github.com/notxcain/aecor 将有助于使突变显式化，并将应用程序逻辑与所使用的技术分开通过状态突变和 IO“效果”（函数式编程）的原则性管理来管理状态的持久形式。
换句话说，业务逻辑不会与 Kafka api 纠缠在一起。
Akka Streams 作为 Akka Actors 模型的以数据流为中心的抽象出现。
这些是为 JVM 构建的高性能库，专为通用微服务而设计。
而就Kafka Streams而言，这些都是用于处理无界数据的客户端库。它们用于从Kafka主题中读取数据，然后对其进行处理，并将结果写入新主题。
我目前正在与 Akka Stream Kafka to interact with kafka and I was wonderings what were the differences with Kafka Streams 合作。
我知道基于 Akka 的方法实现了响应式规范并处理背压，kafka 流似乎缺少这些功能。
使用 kafka streams 相对于 akka streams kafka 有什么优势？
你的问题很笼统，我就从我的角度作一个笼统的回答。
首先，我有两个使用场景：
- 我从 kafka 读取数据、处理它并将一些输出写回 kafka 的情况，对于这些我只使用 kafka 流。
- 数据源或接收器不是 kafka 的情况，对于那些我使用 akka 流的情况。
这已经让我可以回答关于背压的部分：对于上面的第一种情况，kafka 流中有一个背压机制。
现在我们只关注上述第一种情况。让我们看看如果我决定停止使用 Kafka 流我会失去什么：
- 我的一些流处理器阶段需要持久（分布式）状态存储，kafka 流为我提供了它。这是 akka 流不提供的。
- 缩放，kafka streams 会在流处理器的新实例启动或被杀死时自动平衡负载。这适用于同一个 JVM 以及其他节点：向上和向外扩展。这不是 akka 流提供的。
这些是对我来说最重要的差异，我希望它对你有意义！
Akka Stream 相对于 Kafka Streams 的最大优势在于可以实现非常复杂的处理图，这些图可以与 fan in/out 和反馈循环一起循环。如果我没记错的话，Kafka 流只允许非循环图。在 Kafka 流之上实现循环处理图会非常复杂
发现这篇文章很好地总结了 Kafka Streams 提供的分布式设计问题（补充 Akka Streams）。
https://www.beyondthelines.net/computing/kafka-streams/
message ordering: Kafka maintains a sort of append only log where it stores all the messages, Each message has a sequence id also known as its offset. The offset is used to indicate the position of a message in the log. Kafka streams uses these message offsets to maintain ordering.
partitioning: Kafka splits a topic into partitions and each partition is replicated among different brokers. The partitioning allows to spread the load and replication makes the application fault-tolerant (if a broker is down the data are still available). That’s good for data partitioning but we also need to distribute the processes in a similar way. Kafka Streams uses the processor topology that relies on Kafka group management. This is the same group management that is used by the Kafka consumer to distribute load evenly among brokers (This work is mainly managed by the brokers).
Fault tolerance: data replication ensures data fault tolerance. Group management has fault tolerance built-in as it redistributes the workload among remaining live broker instances.
State management: Kafka streams provides a local storage backed up by a kafka change-log topic which uses log compaction (keeps only latest value for a given key).Kafka log compaction
Reprocessing: When starting a new version of the app, we can reprocess the logs from the start to compute new state then redirect the traffic the new instance and shutdown old application.
Time management: “Stream data is never complete and can always arrive out-of-order” therefore one must distinguish the event time vs processed time and handle it correctly.
作者还说 “使用这个更改日志主题 Kafka Stream 能够维护应用程序状态的“table 视图”。”
我的看法是，这主要适用于“应用程序状态”……小的企业应用程序。
对于使用“大数据”的数据科学应用程序，由数据处理、机器学习模型和业务逻辑组合产生的用于协调所有这些的“应用程序状态”可能无法通过 Kafka Streams.
此外，我认为使用 “纯函数式事件源运行时”，如 https://github.com/notxcain/aecor 将有助于使突变显式化，并将应用程序逻辑与所使用的技术分开通过状态突变和 IO“效果”（函数式编程）的原则性管理来管理状态的持久形式。
换句话说，业务逻辑不会与 Kafka api 纠缠在一起。
Akka Streams 作为 Akka Actors 模型的以数据流为中心的抽象出现。 这些是为 JVM 构建的高性能库，专为通用微服务而设计。
而就Kafka Streams而言，这些都是用于处理无界数据的客户端库。它们用于从Kafka主题中读取数据，然后对其进行处理，并将结果写入新主题。