Kafka：消费者 API 与流 API
Kafka: Consumer API vs Streams API
我最近开始学习Kafka，最后遇到了这些问题。
Consumer 和 Stream 有什么区别？对我来说，if any tool/application consumer messages from Kafka 就是 Kafka 世界中的消费者。
Stream 有何不同，因为它也从 Kafka 消费消息或向 Kafka 产生消息？为什么需要它，因为我们可以编写自己的消费者
使用 Consumer API 的应用程序并根据需要处理它们或将它们从消费者应用程序发送到 Spark?
我对此做了 Google，但没有得到任何好的答案。对不起，如果这个问题太琐碎了。
2021 年 1 月更新： 我写了一篇 four-part blog series on Kafka fundamentals that I'd recommend to read for questions like these. For this question in particular, take a look at part 3 on processing fundamentals.
2018 年 4 月更新：现在您还可以使用 Kafka 的事件流数据库 ksqlDB 来处理 Kafka 中的数据。 ksqlDB 建立在 Kafka 的 Streams API 之上，它也首次 class 支持 Streams 和 Tables。
what is the difference between Consumer API and Streams API?
Kafka 的 Streams 库 (https://kafka.apache.org/documentation/streams/) 构建在 Kafka 生产者和消费者客户端之上。 Kafka Streams 比普通客户端更强大，也更具表现力。
使用 Kafka Streams 编写真实世界的应用程序比使用普通消费者更简单、更快捷。
以下是 Kafka Streams 的一些特性 API，其中大部分特性不受消费者客户端的支持（需要您自己实现缺少的特性，本质上是重新实现 Kafka Streams） .
- 通过 Kafka 事务支持一次性处理语义 (what EOS means)
- 支持容错有状态（当然还有无状态）处理，包括流joins, aggregations, and windowing。换句话说，它支持开箱即用地管理应用程序的处理状态。
- 支持event-time processing as well as processing based on processing-time and ingestion-time. It also seamlessly processes out-of-order data。
- 首先-class 支持两者 streams and tables，这是流处理与数据库的结合；实际上，大多数流处理应用程序都需要流和表来实现它们各自的用例，因此如果流处理技术缺少这两种抽象中的任何一种（例如，不支持表），您要么陷入困境，要么必须自己手动实现此功能（祝你好运...）
- 支持interactive queries（也称为'queryable state'）通过请求-响应API将最新的处理结果暴露给其他应用程序和服务。这对于只能进行请求-响应而不能进行流式处理的传统应用程序特别有用。
- 更具表现力：它附带 (1) 函数式编程风格 DSL with operations such as
map, filter, reduce as well as (2) an imperative style Processor API，例如进行复杂事件处理 (CEP)，以及 (3) 您甚至可以组合 DSL 和处理器 API.
- 有自己的 testing kit 用于单元和集成测试。
有关 Kafka Streams 的更详细但仍然是高级的介绍，请参阅 http://docs.confluent.io/current/streams/introduction.html API，这也应该有助于您了解与较低级别的 Kafka 消费者客户端的区别。
除了 Kafka Streams，您还可以使用流式数据库 ksqlDB 在 Kafka 中处理您的数据。 ksqlDB 将其存储层 (Kafka) 与其计算层（ksqlDB 本身；它在这里使用 Kafka Streams 来实现其大部分功能）分开。它支持与 Kafka Streams 基本相同的功能，但是您编写流式 SQL 语句而不是 Java 或 Scala 代码。您可以通过 UI、CLI 和 REST API 与 ksqlDB 交互；如果您不想使用 REST，它还有一个本机 Java 客户端。最后，如果您不想自行管理您的基础架构，ksqlDB 在 Confluent Cloud 中可作为完全托管服务使用。
So how is the Kafka Streams API different as this also consumes from or produce messages to Kafka?
是的，Kafka Streams API 既可以读取数据也可以将数据写入 Kafka。它支持 Kafka 交易，所以你可以，例如从一个或多个主题读取一条或多条消息，如果需要，可选择更新处理状态，然后将一条或多条输出消息写入一个或多个主题——所有这些都是一个原子操作。
and why is it needed as we can write our own consumer application using Consumer API and process them as needed or send them to Spark from the consumer application?
是的，您可以编写自己的消费者应用程序——正如我提到的，Kafka Streams API 使用 Kafka 消费者客户端（加上生产者客户端）本身——但您必须手动实施Streams API 提供的所有独特功能。请参阅上面的列表，了解您“免费”获得的所有内容。因此，很少有用户会选择普通的消费者客户端而不是更强大的 Kafka Streams 库。
内置Kafka Stream组件支持ETL类型的消息转换。意思是从主题输入流，转换并输出到其他主题。
支持实时处理，同时支持聚合、windowing、join等高级分析特性
“Kafka Streams 通过构建在 Kafka 生产者和消费者库上并利用 Kafka 的本机功能来提供数据并行性、分布式协调、容错和操作简单性，从而简化了应用程序开发。”
以下是 Kafka Stream 的主要架构特性。请参考here
- 流分区和任务：Kafka Streams 使用分区和任务的概念作为其基于 Kafka 主题分区的并行模型的逻辑单元。
- 线程模型： Kafka Streams 允许用户配置库可用于在应用程序实例中并行处理的线程数。
- Local State Stores：Kafka Streams提供了所谓的状态存储，流处理应用程序可以使用它来存储和查询数据，这是实现有状态时的重要能力操作
- 容错： Kafka Streams 建立在 Kafka 中原生集成的容错功能之上。 Kafka 分区是高可用和可复制的，因此当流数据持久化到 Kafka 时，即使应用程序失败并需要重新处理它也是可用的。
根据我的理解，以下是主要差异，如果遗漏或误导任何一点，我愿意更新
在哪里使用消费者-生产者：
- 如果是单消费者，消费消息进程，不溢出到其他topic
- 作为第 1 点，如果只有生产者生产消息，我们不需要 Kafka Stream。
- 如果消费者消息来自一个 Kafka 集群，但发布到不同的 Kafka 集群主题。在这种情况下，即使您可以使用 Kafka Stream，但您必须使用单独的 Producer 将消息发布到不同的集群。或者干脆使用Kafka Consumer - Producer机制。
- 批处理 - 如果需要收集消息或进行某种批处理，则最好使用普通的传统方式。
在哪里使用Kafka Stream：
- 如果您使用来自一个主题的消息，转换并发布到其他主题，Kafka Stream 最适合。
- 实时处理、实时分析和机器学习。
- 聚合、连接等状态转换window等
- 计划使用本地状态存储或挂载状态存储，例如 Portworx 等
- 完全实现一种处理语义和自动定义的容错。
Streams 建立在消费者和生产者 API 之上，因此在更高的层次上工作，这意味着
- Streams 更易于用于 read-from-topic/process/write-to-topic 风格的任务
- Producer/Consumer 允许更多控制，并且可以在 Streams 无法处理的某些情况下使用
例如，Streams 会自动处理事务提交，这意味着您无法控制提交的确切时间点（无论您是使用 Streams DSL 还是 Processer API）。相比之下，Consumer/Producer API 为您提供了这种控制权。
我最近开始学习Kafka，最后遇到了这些问题。
Consumer 和 Stream 有什么区别？对我来说，if any tool/application consumer messages from Kafka 就是 Kafka 世界中的消费者。
Stream 有何不同，因为它也从 Kafka 消费消息或向 Kafka 产生消息？为什么需要它，因为我们可以编写自己的消费者 使用 Consumer API 的应用程序并根据需要处理它们或将它们从消费者应用程序发送到 Spark?
我对此做了 Google，但没有得到任何好的答案。对不起，如果这个问题太琐碎了。
2021 年 1 月更新： 我写了一篇 four-part blog series on Kafka fundamentals that I'd recommend to read for questions like these. For this question in particular, take a look at part 3 on processing fundamentals.
2018 年 4 月更新：现在您还可以使用 Kafka 的事件流数据库 ksqlDB 来处理 Kafka 中的数据。 ksqlDB 建立在 Kafka 的 Streams API 之上，它也首次 class 支持 Streams 和 Tables。
what is the difference between Consumer API and Streams API?
Kafka 的 Streams 库 (https://kafka.apache.org/documentation/streams/) 构建在 Kafka 生产者和消费者客户端之上。 Kafka Streams 比普通客户端更强大，也更具表现力。
使用 Kafka Streams 编写真实世界的应用程序比使用普通消费者更简单、更快捷。
以下是 Kafka Streams 的一些特性 API，其中大部分特性不受消费者客户端的支持（需要您自己实现缺少的特性，本质上是重新实现 Kafka Streams） .
- 通过 Kafka 事务支持一次性处理语义 (what EOS means)
- 支持容错有状态（当然还有无状态）处理，包括流joins, aggregations, and windowing。换句话说，它支持开箱即用地管理应用程序的处理状态。
- 支持event-time processing as well as processing based on processing-time and ingestion-time. It also seamlessly processes out-of-order data。
- 首先-class 支持两者 streams and tables，这是流处理与数据库的结合；实际上，大多数流处理应用程序都需要流和表来实现它们各自的用例，因此如果流处理技术缺少这两种抽象中的任何一种（例如，不支持表），您要么陷入困境，要么必须自己手动实现此功能（祝你好运...）
- 支持interactive queries（也称为'queryable state'）通过请求-响应API将最新的处理结果暴露给其他应用程序和服务。这对于只能进行请求-响应而不能进行流式处理的传统应用程序特别有用。
- 更具表现力：它附带 (1) 函数式编程风格 DSL with operations such as
map,filter,reduceas well as (2) an imperative style Processor API，例如进行复杂事件处理 (CEP)，以及 (3) 您甚至可以组合 DSL 和处理器 API. - 有自己的 testing kit 用于单元和集成测试。
有关 Kafka Streams 的更详细但仍然是高级的介绍，请参阅 http://docs.confluent.io/current/streams/introduction.html API，这也应该有助于您了解与较低级别的 Kafka 消费者客户端的区别。
除了 Kafka Streams，您还可以使用流式数据库 ksqlDB 在 Kafka 中处理您的数据。 ksqlDB 将其存储层 (Kafka) 与其计算层（ksqlDB 本身；它在这里使用 Kafka Streams 来实现其大部分功能）分开。它支持与 Kafka Streams 基本相同的功能，但是您编写流式 SQL 语句而不是 Java 或 Scala 代码。您可以通过 UI、CLI 和 REST API 与 ksqlDB 交互；如果您不想使用 REST，它还有一个本机 Java 客户端。最后，如果您不想自行管理您的基础架构，ksqlDB 在 Confluent Cloud 中可作为完全托管服务使用。
So how is the Kafka Streams API different as this also consumes from or produce messages to Kafka?
是的，Kafka Streams API 既可以读取数据也可以将数据写入 Kafka。它支持 Kafka 交易，所以你可以，例如从一个或多个主题读取一条或多条消息，如果需要，可选择更新处理状态，然后将一条或多条输出消息写入一个或多个主题——所有这些都是一个原子操作。
and why is it needed as we can write our own consumer application using Consumer API and process them as needed or send them to Spark from the consumer application?
是的，您可以编写自己的消费者应用程序——正如我提到的，Kafka Streams API 使用 Kafka 消费者客户端（加上生产者客户端）本身——但您必须手动实施Streams API 提供的所有独特功能。请参阅上面的列表，了解您“免费”获得的所有内容。因此，很少有用户会选择普通的消费者客户端而不是更强大的 Kafka Streams 库。
内置Kafka Stream组件支持ETL类型的消息转换。意思是从主题输入流，转换并输出到其他主题。 支持实时处理，同时支持聚合、windowing、join等高级分析特性
“Kafka Streams 通过构建在 Kafka 生产者和消费者库上并利用 Kafka 的本机功能来提供数据并行性、分布式协调、容错和操作简单性，从而简化了应用程序开发。”
以下是 Kafka Stream 的主要架构特性。请参考here
- 流分区和任务：Kafka Streams 使用分区和任务的概念作为其基于 Kafka 主题分区的并行模型的逻辑单元。
- 线程模型： Kafka Streams 允许用户配置库可用于在应用程序实例中并行处理的线程数。
- Local State Stores：Kafka Streams提供了所谓的状态存储，流处理应用程序可以使用它来存储和查询数据，这是实现有状态时的重要能力操作
- 容错： Kafka Streams 建立在 Kafka 中原生集成的容错功能之上。 Kafka 分区是高可用和可复制的，因此当流数据持久化到 Kafka 时，即使应用程序失败并需要重新处理它也是可用的。
根据我的理解，以下是主要差异，如果遗漏或误导任何一点，我愿意更新
在哪里使用消费者-生产者：
- 如果是单消费者，消费消息进程，不溢出到其他topic
- 作为第 1 点，如果只有生产者生产消息，我们不需要 Kafka Stream。
- 如果消费者消息来自一个 Kafka 集群，但发布到不同的 Kafka 集群主题。在这种情况下，即使您可以使用 Kafka Stream，但您必须使用单独的 Producer 将消息发布到不同的集群。或者干脆使用Kafka Consumer - Producer机制。
- 批处理 - 如果需要收集消息或进行某种批处理，则最好使用普通的传统方式。
在哪里使用Kafka Stream：
- 如果您使用来自一个主题的消息，转换并发布到其他主题，Kafka Stream 最适合。
- 实时处理、实时分析和机器学习。
- 聚合、连接等状态转换window等
- 计划使用本地状态存储或挂载状态存储，例如 Portworx 等
- 完全实现一种处理语义和自动定义的容错。
Streams 建立在消费者和生产者 API 之上，因此在更高的层次上工作，这意味着
- Streams 更易于用于 read-from-topic/process/write-to-topic 风格的任务
- Producer/Consumer 允许更多控制，并且可以在 Streams 无法处理的某些情况下使用
例如，Streams 会自动处理事务提交，这意味着您无法控制提交的确切时间点（无论您是使用 Streams DSL 还是 Processer API）。相比之下，Consumer/Producer API 为您提供了这种控制权。