我需要从 Kafka 主题中获取消息并通过基于 HTTP 的 API 通知其他系统。也就是说,从主题获取消息,映射到第 3 方 API 并调用它们。我打算为此编写一个 Kafka Sink Connector。
对于这个用例,Kafka Connect 是正确的选择,还是我应该使用 Kafka Client。
我需要从 Kafka 主题中获取消息并通过基于 HTTP 的 API 通知其他系统。也就是说,从主题获取消息,映射到第 3 方 API 并调用它们。我打算为此编写一个 Kafka Sink Connector。
对于这个用例,Kafka Connect 是正确的选择,还是我应该使用 Kafka Client。
Kafka Connect 可以很好地实现此目的,但这也是一个非常简单的消费者应用程序,因为消费者还具有容错/可扩展性的好处,在这种情况下,您可能只是一次处理简单的消息在每个消费者实例中进行处理。您也可以轻松地使用enable.auto.commit
此应用程序,因此您不会遇到直接使用消费者的棘手部分。与在这种情况下使用消费者相比,使用 Kafka Connect 给您的主要好处是连接器可以针对不同的输入格式进行通用化,但这对于自定义连接器可能并不重要。
Kafka 客户端当您完全控制您的代码并且您是专家开发人员时,您希望将应用程序连接到 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 上构建。
在被称为的书中Kafka In Action
解释如下:
Kafka Connect的目的是帮助将数据移入或移出 Kafka ,而无需编写我们自己的生产者和客户端。Connect 是一个框架,它已经是 Kafka 的一部分,它确实可以让使用已经构建好的片段来开始你的流媒体之旅变得简单。
As for your problem
, 首先,应该问的最简单的问题之一是您是否可以修改需要数据交互的系统的应用程序代码。
其次,如果您编写具有深入了解能力的自定义连接器并且该连接器将被其他人使用,那是值得的。因为它可以帮助其他可能不是这些系统专家的人。不然这个kafka连接器是自己用的,我觉得你应该写Kafka连接器。这样您可以获得更大的灵活性并且可以更轻松地编写实现。
当您使用 kafka 连接源为特定主题生成消息时,您应该使用 kafka 连接接收器。
例如,当您使用文件源时,您应该使用文件接收器来使用已生成的源。或者当您使用 jdbc-source 时,您应该使用 jdbc-sink 来消耗您所生成的内容。
因为生产者和接收器消费者的模式应该兼容,所以你应该在双方都使用兼容的源和接收器。
如果在某些情况下模式不兼容,您可以使用自 kafka 10.2 版起添加的 SMT(简单消息转换)功能,您将能够编写消息转换器以在不兼容的生产者和消费者之间传输消息。
注意:如果您想更快地传输消息,我建议您使用 avro 和模式注册表来更有效地传输消息。
如果您可以使用 java 编码,则可以使用 java kafka 流、Spring-Kafka 项目或流处理来实现您想要的。