因此，一般来说，只要从Kafka读取记录并将其发送到其他服务中，功能上应该没有太大的区别。
kafka connect在标准任务中可能更容易实现，因为它提供了各种现成的连接器，因此它很可能减少编写任何代码的需要。因此，如果您只想将一堆记录从kafka复制到hdfs或hive，那么使用kafka connect可能会更容易、更快。
记住这一点，当你需要做一些非标准的事情时，spark streaming会大行其道，例如，如果你想对记录执行一些聚合或计算并将它们写入hive，那么你可能应该从一开始就使用spark streaming。
一般来说，我发现用kafka connect做一些不符合标准的事情，例如将一条消息拆分为多条消息（假设它是json数组）非常麻烦，而且通常需要比spark中更多的工作。
至于kafka connect容错，正如文档中所描述的，这是通过用相同的方法运行多个分布式worker来实现的 group.id ，如果其中一个任务和连接器失败，工人将重新分配任务和连接器。

在哪些情况下，我更喜欢连接器而不是Spark流解决方案。
“视情况而定”：-）
kafkaconnect是apachekafka的一部分，因此在安全性、交付语义等方面与apachekafka有更紧密的集成。
如果您不想编写任何代码，kafka connect会更容易，因为它只需要json来配置和运行
如果您还没有使用spark，那么kafka connect可以说更易于部署（运行jvm，传递配置）
作为一个框架，kafka connect更具可移植性，因为概念是相同的，每次只需为要集成的技术插入适当的连接器
kafka connect为您处理所有棘手的事情，如模式、偏移、重新启动、扩展等
kafka connect支持单个消息转换，以便在数据通过管道时对其进行更改（屏蔽字段、删除字段、更改数据类型等）。对于更高级的处理，您可以使用kafka streams或ksqldb之类的东西。
如果您使用的是spark，而且它工作得很好，那么使用kafka connect来撕碎它并不一定明智：）
还有，Kafka连接器解决方案有多宽容…如何使用kafka连接器实现容错（如果可能的话）？
kafka connect可以在分布式模式下运行，在这种模式下，跨节点有一个或多个工作进程。如果一个工人失败了，kafka connect会在剩下的任务之间重新平衡任务。如果在中添加一个worker，kafka connect将重新平衡以确保工作负载分布。这在ApacheKafka2.3（kip-415）中得到了极大的改进
kafka connect使用kafka consumer api并跟踪传递到kafka自身中目标系统的记录的偏移量。如果任务或辅助进程失败，您可以确保它将从正确的点重新启动。许多连接器也支持一次交付（例如hdfs、elasticsearch等）
如果你想了解更多关于Kafka的信息，请看这里的文档和我的演讲。请在此处查看连接器列表，并在此处查看教程视频。
免责声明：我为confluent工作，也是Kafka的忠实粉丝：-）