我即将为我的组织实施基于Kafka和Spark的流式基础架构。但是，当我在Kafka中摄取数据时，我很难解决最佳方法。
该任务确实可以使用许多解决方案
- Spark本身可用于从外部源读取并写入Kafka。我不想用那条路。
- Kafka Connect
- Kafka客户端API（制作人和消费者）
- Akka-Stream Kafka（据我所知，可能是Reactive Kafka客户，但我不确定）
为了做出我的选择，当然我可以继续自己尝试一切，但是，我想知道是否有人已经通过了这个障碍。
我倾向于（4）。因此，对于那些最终完成任务框架的人来说，我想知道他是否可以与我分享经验。
特别是，我想知道使用（4）和（2）之间观察到的利弊。是什么让Kafka Connect成为摄取的更好选择。是否真的需要更多的工作（4）。 是Kafka Connect，反应性吗？ Kafka连接是否处理背压？
答案 0 :(得分：1)
将Kafka之外的数据转换为Kafka主题的一种方法是编写自己的服务或应用程序。它将使用普通的Kafka生产者，除了与托管数据的外部系统交谈之外，您的服务或应用程序还必须跟踪它已处理的数据，以便在重新启动时知道从哪里开始。它还必须跟踪该信息，可能将信息分解为多个并行任务，在多个进程之间分配任务等。
Akka Streams Kafka框架实际上只是普通生产者/消费者API的反应性变体。你仍然需要完成上面提到的所有相同的事情。
Kafka Connect是一个框架，用于将外部系统中的数据移动到Kafka到Kafka，或者用于将Kafka中的数据移动到外部系统中。 Kafka Connect完成上述大部分工作，同时委托连接器进行与外部系统交谈和使用的逻辑。 Kafka Connect定义了源连接器和接收器连接器，每个连接器都有一组略有不同的职责和功能。两者都比较容易写。
Kafka Connect的一大优势是适用于各种现有系统的可用连接器数量。如果连接器适合，只需安装在Kafka Connect工作人员上，配置连接器以与外部系统通信，然后监视和管理Kafka Connect工作人员。没有任何编写代码。例如，除了从外部系统复制数据的连接器之外，其他连接器还会监视外部系统的更改并捕获新的/更改/删除的数据。有时，这些连接器可能只监视文件系统的更改，而其他连接器则是正确的 Change Data Capture 连接器，用于监视插入，更新和删除的行/对象/文档的数据库管理系统。这些连接器永远运行，不断监视任何新的或更改的信息，并将其传递到适当的Kafka主题中。
如果您的数据存在于没有连接器的系统中，您可以编写源连接器，也可以编写一个正常的生产者应用程序来完成大部分工作。
在之前对你的问题的评论中，你谈过Kafka和Kafka Connect并不是被动的。它们不是，但这并不限制连接器与外部系统的对话方式。有连接器建立与外部系统的连接，外部系统将信息推送到连接器中的客户端。其他连接器实现轮询（或更常见的是长轮询）外部系统。它只取决于你与外部系统的对话方式。
现在，源连接器的Kafka Connect API确实使用拉模型，但基本上是因为Kafka Connect工作人员轮询连接器以获取“源记录”，将这些记录写入Kafka，然后重复该过程。每个连接器的任务都在一个单独的线程中运行，因此这个常量循环将与连接器生成数据一样快，Kafka Connect可以将其写入Kafka。请注意，当时没有源记录时，您的连接器通常会阻塞，然后当没有数据时，工作人员不会简单地旋转。
从开发人员的角度来看，这个API非常容易实现。系统会询问您的连接器任务是否有源记录，然后将其返回。 Kafka Connect负责其他一切事务。 Kafka Connect框架由Kafka开发人员使用最佳实践和已经更高性能的Kafka生成器库编写。
在容错方面，Kafka Connect工作群集将自动在群集中分发连接器和任务。如果任何工作程序失败或无法与群集的其余部分（例如，网络分区）通信，则群集将自动重新平衡其余工作程序上的连接器任务。由于Kafka Connect会自动管理/保留连接器的偏移（每个消息来自源中），重新启动的任务将从其他人停止的地方开始，确保至少一次在外部源系统中传递数据。