flume连接kafka_kafka-connect 出现的原因

简介

kafka connect 是 Apache Kafka 的开源组件，作为Kafka跟外部系统的连接器，例如数据库，kv 存储，查询索引，文件系统等。kafka connect 提供一套可靠，高性能的插件，使 Kafka 生产消费数据变得很简单。

虽然在 Apache Kafka 中也有 connector 组件，但是开源的插件太少。开源大户还是国外的 confluent 公司，就是那个围绕 Kafka 建设一系列周边，创建的商业公司。confluent-platform 平台社区版提供很多组件。

---

动机：为什么要重新构建一个框架

简单来说，已有的解决方案不能很好的将事件驱动产生的原生数据集成到以Kafka为中心的流数据平台。为什么已有的框架不能适配于特殊的使用场景，按照使用场景和功能分类如下。

日志监控收集、处理、聚合

Flume、LogStash、Fluentd、Heka

这些系统主要从应用和框架服务中收集和处理大量日志和监控数据。相同的设计是在每个数据节点安装代理服务，但可能会因为缓存造成数据丢失，因为数据处理过后才会继续从代理服务抓取。通过编码/解码/过滤功能使得数据满足目的端要求。 面对大数据量，这些服务部署起来比较复杂。收集日志需要在每个节点部署一个代理服务，在水平扩展的时候，需要手动管理每个服务，分配相应的任务，重启服务等。因为它们没有标准的存储层。过度依赖外界，就代表了自身的不稳定性。

数据仓库ETl

Gobblin、Chukwa、Suro、Morphlines、HIHO

这些系统尝试构建不同系统到数据仓库的桥梁，使得每一种系统都可以以相同的数据格式写入到数据仓库。最明显的问题是：批量。小批量就意味着没办法做到低延迟。
共有的特点就是灵活、可插拔的数据处理管道。在ETl场景下，如果数据在写入数据仓库之前需要格式转换、满足存储、查询的需求，这个特性是很有必要的。但是，这些工具用起来也比较复杂，需要用户学习如何使用ETL框架处理数据。
最后，这些系统只能应用于特定的使用场景，支持于 HDFS 等类似的文件系统中。支持特定领域是它们流行的原因，但也限制了其他类型的数据复制作业。

数据管道管理

NiFi

NiFi 尝试构建一个尽可能简单的数据管道。不仅仅专注于可配置和系统间的数据拷贝，而是通过GUI提供整个管道的操作视图。核心是，提供一些任务的基础组件，而不是一些视图。
系统默认的所有数据管道作为一个整体。如果不同部门控制不同管道段，那不会有太好的表现。因为一个大的组织肯定会有很多小的管道而不是一个大的管道。全局的视图，更容易监控和观测到哪个环节出现错误。
此外，允许用户任意连接不同组件来构建一个完成的数据处理管道，这样提供了灵活性，但是也造成了有限的保障性和容错性。

Kafka-connect

在以上框架的优点和缺点下，Kafka-concept 设计，有以下关键点：

• Broad copying by default

快速定义用于在系统之间复制大量数据的连接器，以将配置成本降至最低。

• Streaming and batch

支持拷贝数据到流系统和批系统。

• Scales to application

降低单个处理连接器开发、测试的生产环境要求。提高服务支持多范围数据系统。

• Focus on copying data only

专注可靠、可扩展的数据拷贝。将数据的转换，丰富和其他修改留给专注于该功能的框架完成。相应的 Kafka connect 必须能很好的的集成到流处理框架。

• Parallel

核心抽象包含并行，为框架的自动扩展提供清晰的路径

• Accessible connector API

必须很简单就可以开发一个新的连接器。实现新连接器的API 和运行模型必须可以简单快捷的从两个系统间获取数据。