Kafka的API那么多，到底该怎么选？
本文介绍了各种 Kafka API 的应用场景。
更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）Kafka 是一头值得研究的野兽。尽管随着时间的推移，Kafka 的内核已经相当稳定，但围绕 Kafka 的框架却在迅速发展。
几年前，Kafka 很容易理解：Producer 和 Consumer。现在，我们还有 Kafka Connect、Kafka Streams 和 KSQL。它们是要取代 Producer 或 Consumer API，还是对它们的补充？本文将详细说明。
一个简单的示意图
我把 Apache Kafka 中的工作负载归纳成 5 类，在我看来， 每一种对应一种特定的 API：
- Kafka Producer API：应用程序直接生成数据（如点击流、日志、物联网）；
- Kafka Connect Source API：应用程序连接我们无法控制的数据存储和 Kafka（如 CDC、Postgres、MongoDB、Twitter、REST API）；
- Kafka Streams API / KSQL：从 Kafka 消费并把生成的数据传回 Kafka 的应用程序，也称为流处理。如果你认为你只需要编写类似 SQL 的实时任务，则可以使用 KSQL；如果你认为你需要编写复杂的任务逻辑，则可以使用 Kafka Streams API。
- Kafka Consumer API： 读取流并以此为依据实时执行动作（如发送电子邮件）；
- Kafka Connect Sink API： 读取流，并将其保存到目标存储（如 Kafka 到 S3、Kafka 到 HDFS、Kafka 到 PostgreSQL、Kafka 到 MongoDB 等）。
你可能想做一些和上面说的都不一样的事情，Kafka 也支持你这么做。例如，如果你想要根据自己的需求编写大量定制化代码，Kafka Consumer 和 Kafka Connect Sink API 是可以互换的。
总的来说，上面的指导原则应该可以帮助你以最少的代码和挫折来实现最高效的工作流。
Kafka Producer API 使用起来非常简单：发送数据，这是异步的，会有一个回调。这非常适合直接发送数据流的应用程序，比如日志、点击流、物联网。
这种 API 经常和代理一起使用。
Kafka Producer API 可以扩展，你可以以此为基础做更多的事情，但是，这需要工程师编写大量的附加逻辑。我发现，人们犯的最大错误是试图使用 Producer API 在数据库和 Kafka 之间执行 ETL。以下是一些不容易做到的事情：
- 如何跟踪源偏移？（即如果 Producer 停止了，该如何恰当恢复）
- 如何在多个 Producer 之间分配 ETL 工作负载？为此，我们最好使用 Kafka Connect Source API。
Kafka Connect Source API 优点
Kafka Connect Source API 是一个构建在 Producer API 之上的完整框架。它主要是为了让开发人员能够有一个更好的 API：1）用于 Producer 任务分发以进行并行处理，2）提供 Producer 恢复的简单机制。最后一个好处是提供了各种各样的连接器，你现在可以利用它们从大多数源传输数据，而无需编写一行代码。
如果你未能为自己的源找到一个可用的源连接器，原因是在你的的环境中使用了一个专有的系统，那么你将不得不编写自己的源连接器。编写自己的源连接器实际上还算轻松，但调试它就不那么令人愉快了。
Kafka Consumer API 非常简单，它使用 Consumer 群组，所以主题可以并行消费。尽管你需要小心处理一些事情，比如偏移管理和提交，以及重新平衡和幂等约束，但是它们非常容易编写。对于任何无状态的工作负载，它们都是完美的选择。
当你执行某种 ETL 时，Kafka Connect Sink 更适合，因为它们使你不必针对外部数据源编写一些复杂的逻辑。
与 Kafka Connect Source API 类似，Kafka Connect Sink API 允许你利用现有的 Kafka 连接器生态系统来执行流 ETL，而无需编写一行代码。Kafka Connect Sink API 是构建在 Consumer API 之上的，但是看起来和它没有什么不同。
如果你要编写的数据接收器还没有可用的连接器，则必须编写 Kafka Connect Sink（如果你愿意，也可以是消费者），调试过程可能会稍微复杂一些。
如果你想要进入流处理的世界，即实时读取来自 Kafka 的数据，并在处理之后将其写回 Kafka，那么，如果你把 Kafka Consumer API 和 Kafka Producer API 链接在一起使用的话，你很可能陷入麻烦之中。值得庆幸的是，Kafka 项目现在提供了 Kafka Streams API （可用于 Java 和 Scala），让你可以编写高级 DSL（类似于函数式编程 / Apache Spark 类型的程序）或低级 API（和 Apache Storm 更为相似）。使用 Kafka Streams API 确实需要编写代码，但完全隐藏了维护生产者和消费者的复杂性，使你可以专注于流处理器的逻辑。它还具有连接、聚合和只执行一次处理的特性。
你将不得不编写一些代码，这可能会变得非常混乱和复杂。直到最近，还很难对 Kafka Streams 应用程序进行单元测试，但现在可以使用 test-utils 库来实现。最后，尽管 Kafka Streams 看起来很简单，但它实际上是后台的一头野兽，它会创建状态存储，很可能是以 Kafka 主题为基础。这意味着，虽然作为额外的好处，你将拥有“无状态”和完全弹性的应用程序，但基于拓扑的复杂性，Kafka 集群可能不得不开始处理更多的消息。
KSQL 不是 Kafka API 的直接组成部分，而是 Kafka Streams 的包装器。在这里仍然值得一提。尽管 Kafka Streams 使你可以编写一些复杂的拓扑，但那需要一些丰富的编程知识，而且可能难以阅读，尤其是对于新手来说。KSQL 希望通过提供一个 SQL 语义（非 ANSI）来抽象这种复杂性，该语义与你今天已经了解的内容非常接近。我不得不承认，它非常具有吸引力，使你可以轻松编写流处理器。记住，这不是批处理 SQL，而是流 SQL，因此会出现一些警告。
如果你想要进行复杂的转换、分解数组或需要一个尚未可用的特性，有时你必须回到 Kafka Streams。这个库的发展非常迅速，所以我预计功能缺口可以很快被填补。
我希望本文能够帮助你理解哪种 Kafka API 适合你的场景，以及为什么。
查看英文原文：
https://medium.com/@stephane.maarek/the-kafka-api-battle-producer-vs-consumer-vs-kafka-connect-vs-kafka-streams-vs-ksql-ef584274c1e
如果你喜欢这篇文章，或希望看到更多类似优质报道，记得给我留言和点赞哦！
阅读原文 最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。