【问题标题】:Kafka: Consumer API vs Streams APIKafka:消费者 API 与流 API
【发布时间】:2017-10-16 07:59:40
【问题描述】:

我最近开始学习 Kafka,最后遇到了这些问题。

  1. Consumer 和 Stream 有什么区别?对我来说,如果任何工具/应用程序使用来自 Kafka 的消息,那么它就是 Kafka 世界中的消费者。

  2. Stream 有何不同,因为它也从 Kafka 消费或向 Kafka 生产消息?以及为什么需要它,因为我们可以编写自己的消费者 应用程序使用消费者 API 并根据需要处理它们,还是从消费者应用程序将它们发送到 Spark?

我对此进行了谷歌搜索,但没有得到任何好的答案。对不起,如果这个问题太琐碎了。

【问题讨论】:

    标签: apache-kafka kafka-consumer-api apache-kafka-streams


    【解决方案1】:

    2021 年 1 月更新:我写了一封 four-part blog series on Kafka fundamentals,建议您阅读这些问题。特别是对于这个问题,请查看part 3 on processing fundamentals

    2018 年 4 月更新:现在您还可以使用 Kafka 的事件流数据库 ksqlDB 在 Kafka 中处理您的数据。 ksqlDB 建立在 Kafka 的 Streams API 之上,它还提供对 Streams 和 Tables 的一流支持。

    Consumer API 和 Streams API 有什么区别?

    Kafka 的 Streams 库 (https://kafka.apache.org/documentation/streams/) 构建在 Kafka 生产者和消费者客户端之上。 Kafka Streams 比普通客户端更强大,也更具表现力。

    使用 Kafka Streams 从头到尾编写一个实际应用程序比使用普通消费者更简单、更快捷。

    以下是 Kafka Streams API 的一些特性,其中大部分不受消费者客户端支持(需要您自己实现缺少的特性,本质上是重新实现 Kafka Streams)。

    • 通过 Kafka 事务支持一次性处理语义 (what EOS means)
    • 支持容错有状态(当然还有无状态)处理,包括流式处理joinsaggregationswindowing。换句话说,它支持开箱即用地管理应用程序的处理状态。
    • 支持event-time processing以及基于processing-timeingestion-time的处理。它还可以无缝处理out-of-order data
    • streams and tables都有一流的支持,这是流处理与数据库的结合;在实践中,大多数流处理应用程序都需要流和表来实现它们各自的用例,因此如果流处理技术缺少这两种抽象中的任何一种(例如,不支持表),您要么陷入困境,要么必须自己手动实现此功能(祝你好运……)
    • 支持interactive queries(也称为“可查询状态”)通过请求-响应 API 向其他应用程序和服务公开最新的处理结果。这对于只能进行请求-响应而不是流式处理的传统应用程序特别有用。
    • 更具表现力:它附带 (1) 函数式编程风格 DSL 以及 mapfilterreduce 等操作以及 (2) 命令式 Processor API,例如进行复杂事件处理 (CEP),并且 (3) 您甚至可以将 DSL 和处理器 API 结合起来。
    • 有自己的testing kit 用于单元和集成测试。

    请参阅http://docs.confluent.io/current/streams/introduction.html,了解更详细但仍然是高级别的 Kafka Streams API 介绍,这也应该有助于您了解与较低级别的 Kafka 消费者客户端的区别。

    除了 Kafka Streams,您还可以使用流式数据库 ksqlDB 在 Kafka 中处理您的数据。 ksqlDB 将其存储层(Kafka)与计算层(ksqlDB 本身;它使用 Kafka Streams 来实现其大部分功能)分开。它支持与 Kafka Streams 基本相同的功能,但您编写流式 SQL 语句而不是 Java 或 Scala 代码。您可以通过 UI、CLI 和 REST API 与 ksqlDB 进行交互;如果您不想使用 REST,它还有一个本机 Java 客户端。最后,如果您不想自行管理基础架构,请使用 Confluent Cloud 中的ksqlDB is available as a fully managed service

    那么 Kafka Streams API 有什么不同,因为它也从 Kafka 消费或向 Kafka 生成消息?

    是的,Kafka Streams API 既可以读取数据,也可以将数据写入 Kafka。它支持 Kafka 事务,因此您可以例如从一个或多个主题读取一条或多条消息,如果需要,可以选择更新处理状态,然后将一条或多条输出消息写入一个或多个主题——所有这些都作为一个原子操作。

    为什么需要它,因为我们可以使用消费者 API 编写自己的消费者应用程序并根据需要处理它们或将它们从消费者应用程序发送到 Spark?

    是的,您可以编写自己的消费者应用程序——正如我所提到的,Kafka Streams API 使用 Kafka 消费者客户端(加上生产者客户端)本身——但你必须手动实现所有独特的功能Streams API 提供。请参阅上面的列表,了解您“免费”获得的一切。因此,用户会选择普通的消费者客户端而不是更强大的 Kafka Streams 库的情况很少见。

    【讨论】:

    • 在什么情况下应用程序会使用 Kafka Consumer API 而不是 Kafka Streams API?
    • 主要在您需要直接访问 Kafka Consumer API 的低级方法的情况下。现在 Kafka Streams 可用,这通常用于相当定制的、专门的应用程序和用例。这是一个类比:想象一下 Kafka Streams 是一辆汽车——大多数人只想驾驶它,但不想成为汽车修理工。但是有些人可能出于某种原因想要打开和调整汽车的引擎,此时您可能想要直接使用 Consumer API。 (话虽如此,Kafka Streams 也有用于定制需求的处理器 API。)
    • 我认为区分它们的主要因素是访问商店的能力。一旦你了解了在流中使用 store 的力量,你就会明白 kafka 流的力量。
    【解决方案2】:

    为支持 ETL 类型的消息转换而构建的 Kafka Stream 组件。表示从主题输入流,转换并输出到其他主题。 它支持实时处理,同时支持聚合、窗口化、连接等高级分析功能。

    “Kafka Streams 通过构建 Kafka 生产者和消费者库并利用 Kafka 的原生功能来提供数据并行性、分布式协调、容错和操作简单性,从而简化了应用程序开发。”

    以下是 Kafka Stream 的主要架构特性。请参考here

    1. 流分区和任务:Kafka Streams 使用分区和任务的概念作为其基于 Kafka 主题分区的并行模型的逻辑单元。
    2. 线程模型: Kafka Streams 允许用户配置库可用于并行处理应用程序实例中的线程数。
    3. 本地状态存储:Kafka Streams 提供了所谓的状态存储,流处理应用程序可以使用它来存储和查询数据,这是实现有状态操作时的重要能力
    4. 容错: Kafka Streams 建立在 Kafka 原生集成的容错功能之上。 Kafka 分区具有高可用性和可复制性,因此当流数据持久保存到 Kafka 时,即使应用程序出现故障并需要重新处理它,它仍然可用。

    根据我的理解,如果遗漏或误导任何一点,我愿意更新以下主要差异

    在哪里使用消费者 - 生产者:

    1. 如果有单个消费者,则消费消息进程,但不要溢出到其他主题。
    2. 作为第 1 点,如果只有生产者生成消息,我们不需要 Kafka Stream。
    3. 如果消费者消息来自一个 Kafka 集群,但发布到不同的 Kafka 集群主题。在这种情况下,即使您可以使用 Kafka Stream,但您必须使用单独的 Producer 将消息发布到不同的集群。或者干脆使用 Kafka Consumer - Producer 机制。
    4. 批处理 - 如果需要收集消息或某种批处理,最好使用常规的传统方式。

    在哪里使用 Kafka Stream:

    1. 如果您使用来自一个主题的消息,则转换并发布到其他主题最适合 Kafka Stream。
    2. 实时处理、实时分析和机器学习。
    3. 聚合、连接窗口等状态转换
    4. 计划使用本地州立商店或已安装的州立商店,例如 Portworx 等。
    5. 实现完全一种处理语义和自动定义的容错。

    【讨论】:

    • 太棒了,真的很有帮助,但是有一个重大错误,在 Consumer 和 Streams api 中只有一次语义可用,而且 EOS 只是较低级别的消费者/生产者的一堆设置,这样设置组连同它们的特定值保证了 EOS 的行为。目前我使用 EOS 和 Consumer api 没有问题。
    • 是的,我们可以通过设置属性在 Kafka Stream 中定义 Exactly once 语义,但是对于简单的生产者和消费者,我们需要定义幂等和事务以支持作为一个单元事务
    • 根据建议更改了措辞
    • @sun007,对于不需要实时功能的简单应用程序来说,哪个更快?而且,使用流媒体是否会像任何其他高级工具一样在 kafka 原生功能之上增加“额外”转换开销?
    • @uptoyou:“而且 EOS 只是低级消费者/生产者的一堆设置”这不是真的。 Kafka Streams 中的 EOS 功能有几个重要的特性,这些特性在普通的 Kafka 消费者/生产者中不可用。可以使用消费者/生产者自己(DIY)实现这一点,这正是 Kafka 开发人员为 Kafka Streams 所做的,但这并不容易。详情confluent.io/blog/enabling-exactly-once-kafka-streams
    【解决方案3】:

    Streams 建立在 Consumer 和 Producer API 之上,因此可以在更高级别上运行,这意味着

    • Streams 更易于用于读取主题/进程/写入主题样式的任务
    • Producer/Consumer 允许更多控制,并且可以在 Streams 无法处理的某些情况下使用

    例如,Streams 会自动处理事务提交,这意味着您无法控制提交的确切时间点(无论您使用 Streams DSL 还是 Processer API)。相比之下,Consumer/Producer API 为您提供了这种控制权。

    【讨论】:

      猜你喜欢
      • 2017-05-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-12-30
      • 2016-10-31
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多