Kafka 连接或 Kafka 客户端

Posted 2023-03-10

【中文标题】Kafka 连接或 Kafka 客户端

【英文标题】：Kafka connect or Kafka Client

【发布时间】：2017-04-03 19:49:54

【问题描述】：

我需要从 Kafka 主题中获取消息并通过基于 HTTP 的 API 通知其他系统。也就是说，从主题获取消息，映射到第 3 方 API 并调用它们。我打算为此编写一个 Kafka Sink 连接器。

对于这个用例，Kafka Connect 是正确的选择还是我应该使用 Kafka Client。

【参考方案1】：

Kafka Connect 可以很好地实现此目的，但这也是一个非常简单的消费者应用程序，因为消费者还具有容错/可扩展性的好处，在这种情况下，您可能只是在做简单的消息传递-每个消费者实例中的一次处理。您也可以轻松地为此应用程序使用enable.auto.commit，这样您就不会遇到直接使用消费者的棘手部分。与在这种情况下使用消费者相比，使用 Kafka Connect 给您的主要好处是，连接器可以针对不同的输入格式进行通用化，但对于自定义连接器而言，这对您来说可能并不重要。

【参考方案2】：

当您完全控制您的代码并且您是专家级开发人员时，您希望将应用程序连接到 Kafka 并可以修改应用程序的代码。

push data into Kafka

pull data from Kafka.

https://cwiki.apache.org/confluence/display/KAFKA/Clients

---

当您无法控制 Kafka 中的新第三方代码并且您必须将 Kafka 连接到无法修改代码的数据存储时，Kafka Connect。

Kafka Connect 的范围很窄：它只专注于将流数据复制到 Kafka 和从 Kafka 复制，不处理其他任务。

http://docs.confluent.io/2.0.0/connect/

---

我在其他博客中添加了几行来解释差异

想要采用 Kafka 的公司会编写一堆代码来发布他们的数据流。我们从经验中学到的是，正确地做到这一点比看起来要复杂得多。特别是，每个连接器都必须解决一系列问题：

• 模式管理：数据管道在可用的地方携带模式信息的能力。如果没有此功能，您最终不得不在下游重新创建它。此外，如果同一数据有多个消费者，则每个消费者都必须重新创建它。我们将在以后的博文中介绍数据管道模式管理的各种细微差别。

• 容错：运行一个进程的多个实例并对故障具有弹性

• 并行性：水平扩展以处理大规模数据集

• 延迟：实时摄取、传输和处理数据，从而摆脱每天一次的数据转储。

• 交付语义：在机器出现故障或进程崩溃时提供强有力的保证

• 运营和监控：以一致的方式监控每个数据集成过程的运行状况和进度

这些问题本身就是非常困难的问题，在每个连接器中单独解决它们是不可行的。相反，您需要一个单一的基础设施平台，连接器可以在此基础上以一致的方式解决这些问题。

直到最近，采用 Kafka 进行数据集成还需要大量的开发人员专业知识；开发 Kafka 连接器需要在客户端 API 上构建。

https://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines/

【参考方案3】：

当您使用 kafka 连接源为特定主题生成消息时，您应该使用 kafka 连接接收器。

例如当您使用文件源时，您应该使用文件接收器来使用已生成的源。或者当您使用 jdbc-source 时，您应该使用 jdbc-sink 来消耗您所生成的内容。

因为生产者和接收器消费者的模式应该是兼容的，所以你应该在双方都使用兼容的源和接收器。

如果在某些情况下模式不兼容，您可以使用自 kafka 10.2 版起添加的 SMT（简单消息转换）功能，您将能够编写消息转换器以在不兼容的生产者和消费者之间传输消息。

注意：如果你想更快地传输消息，我建议你使用 avro 和 schema registry 来更有效地传输消息。

如果您可以使用 java 编码，则可以使用 java kafka 流、Spring-Kafka 项目或流处理来实现您想要的。

【参考方案4】：

在名为Kafka In Action的书中解释如下：

Kafka Connect 的目的是帮助将数据移入或移出 Kafka 而无需处理编写我们自己的生产者和客户端。 Connect 是一个框架已经是 Kafka 的一部分，它确实可以让您轻松使用已经构建的片段来开始您的流媒体之旅。

As for your problem，首先，应该问的最简单的问题之一是是否可以修改需要数据交互的系统的应用程序代码。

其次，如果你会编写具有深入了解能力的自定义连接器并且此连接器将被其他人使用，那是值得的。因为它可以帮助其他可能不是这些系统专家的人。不然这个kafka连接器是自己用的，我觉得你应该写Kafka连接器。这样您可以获得更大的灵活性，并且可以更轻松地编写实现。