什么时候 Kafka 连接器比 Spark 流解决方案更受欢迎？

Question

使用 Spark 流，我可以读取 Kafka 消息并将数据写入不同类型的表，例如 HBase、Hive 和 Kudu。但这也可以通过对这些表使用 Kafka 连接器来完成。我的问题是，在哪些情况下我应该更喜欢连接器而不是 Spark 流解决方案。

Kafka 连接器解决方案的容忍度如何？我们知道通过 Spark 流，我们可以使用在多个节点上运行的检查点和执行器进行容错执行，但是 Kafka 连接器如何实现容错（如果可能）？通过在多个节点上运行连接器？

Answer 1

\n

在哪些情况下我应该更喜欢连接器而不是 Spark 流解决方案。

\n

\n\n

“这取决于” ：-）

\n\n

\n
1. Kafka Connect 是 Apache Kafka 的一部分，因此在安全性、交付语义等方面与 Apache Kafka 集成更紧密。
\n
2. 如果您不想编写任何代码，Kafka Connect 更容易，因为它只需配置和运行 JSON
\n
3. 如果您尚未使用 Spark，那么 Kafka Connect 可以说更易于部署（运行 JVM，传入配置）
\n
4. 作为一个框架，Kafka Connect 更具可移植性，因为概念是相同的，您只需为每次要集成的技术插入适当的连接器
\n
5. Kafka Connect 为您处理所有棘手的事情，例如模式、偏移、重新启动、横向扩展等
\n
6. Kafka Connect 支持单消息转换，以便在数据通过管道时对数据进行更改（屏蔽字段、删除字段、更改数据类型等）。对于更高级的处理，您可以使用 Kafka Streams 或 ksqlDB 之类的东西。
\n
7. 如果您正在使用 Spark，并且它工作得很好，那么将其拆掉并使用 Kafka Connect 来代替并不一定是明智的做法:)
\n

\n\n

\n

Kafka 连接器解决方案的容忍度如何？\xe2\x80\xa6 Kafka 连接器如何实现容错（如果可能）？

\n

\n\n

\n
1. Kafka Connect 可以在分布式模式下运行，在这种模式下，您可以跨节点拥有一个或多个工作进程。如果某个工作线程发生故障，Kafka Connect 会在剩余任务之间重新平衡任务。如果添加工作人员，Kafka Connect 将重新平衡以确保工作负载分配。这在 Apache Kafka 2.3 ( KIP-415 )中得到了极大的改进
\n
2. Kafka Connect 使用 Kafka 消费者 API 并跟踪传送到 Kafka 本身目标系统的记录的偏移量。如果任务或工作人员失败，您可以确保它将从正确的点重新启动。许多连接器也支持一次性交付（例如 HDFS、Elasticsearch 等）
\n

\n\n

如果您想了解有关 Kafka Connect 的更多信息，请参阅此处的文档和我的演讲。请在此处查看连接器列表，并在此处查看教程视频。

\n\n\n\n

免责声明：我在 Confluence 工作，并且是 Kafka Connect 的忠实粉丝:-)

\n

Answer 2

因此，一般来说，简单地从 Kafka 读取记录并将它们发送到其他服务时，功能应该没有太大区别。

Kafka Connect 在标准任务方面可能更容易，因为它提供了各种开箱即用的连接器，因此它很可能会减少编写任何代码的需要。因此，如果您只想将一堆记录从 Kafka 复制到 HDFS 或 Hive，那么使用 Kafka 连接可能会更容易、更快。

考虑到这一点，当您需要做一些不标准的事情时，Spark Streaming 会彻底接管，即如果您想对记录执行一些聚合或计算并将它们写入 Hive，那么您可能应该从一开始就使用 Spark Streaming。

总的来说，我发现使用 Kafka connect 做一些不合标准的事情，例如将一条消息拆分为多条消息（假设它是例如 JSON 数组）非常麻烦，并且通常需要比在 Spark 中做更多的工作。

至于 Kafka Connect 容错，正如文档中所描述的，这是通过运行多个具有相同的分布式工作人员来实现的group.id，如果其中一个失败，工作人员会重新分配任务和连接器。