我只是好奇，使用 Kafka Consumer API 编写自己的代码从 Kafka 读取并使用 AWS 开发工具包写入 S3 是否不简单？是否有很多不明显的并发症需要处理？
我问是因为 Kafka Connect 似乎是从 Kafka 写入 S3 的最建议方式。
你可能已经看到它作为一个类比，所以我也会在这里使用它：你可能会认为 Connect 是 Kafka 生产者和消费者的高级框架，旨在使用源和接收器(Connect 中生产者和消费者的高级等价物)将您的数据与 Kafka 集成。各种这样的源和接收器，简要的连接器，已经可用。
具体来说，关于从 Kafka 到 Amazon S3 的数据导出，已经有一些连接器可用，由于我部分负责最新的连接器，请允许我提及使用它的一些优势。(希望这将回答您的问题，即从头开始实现所有这些功能是或多还是少简单)。
与直接基于消费者编写程序相比，我将把我的论点大致分为两类：
连接框架提供的优点
- 在集群上透明且可扩展的执行。
- 容错执行，与 Kafka 使用者组相同(优点是无需编写代码即可获得容错)
- 用于启动和停止连接器的 REST 接口。
- 一小组指标(将很快扩展到一整套性能和操作指标)。
- 总体而言，定义简单直观的流数据流，其中包括源、数据的简单转换 (SMT) 和接收器。
S3 连接器提供的优点
- 多个格式化程序(当前导出二进制 .avro 文件和文本 .json 文件)
- 支持结构化或非结构化数据，前者的模式演变模式。
分区程序- 的范围：基于大小、时间或字段，您可以将其用作基类来构建自己的自定义分区程序 您的用例，如果他们没有完全按照您想要的开箱即用方式进行操作。
对于- 上述分区程序的大多数用例，精确一次语义(这意味着，如果您重新处理数据，或者从 失败，您将不会在 S3 中看到重复的记录)。
- 易于配置。
- 来自社区的积极支持(如果您开源它们，您的类最终也可能获得支持)。
总的来说，您不必从头开始编写和维护许多其他人(如您)想要使用的代码。此外，如果您发现缺少一个或多个功能，则可以在开源 S3 连接器中贡献这些功能。
有几个优点：
- 连接可以以分布式方式部署，从而扩展
- 连接具有容错能力
- 您只需配置连接器并使用它(无需编码)
- 如果更新，则无需更新任何代码(未编写任何代码)
当然，您可以编写自己的消费者应用程序来写入 S3，但为什么要重新发明轮子呢？