动机
既然可供选择的框架已经很多了，为什么还要构建另一个框架呢？为什么不简单的重用它们呢？
简而言之，这些解决方案中的大多数都没有与流数据平台进行最佳集成，在流数据平台中，基于事件的流数据时通用语言，Kafka是作为所有数据中的通用中介。要了解为什么现有框架不能很好地适应这个特定的用例，我们可以根据它们的预期用例和功能将它们分类为几个类别：
1.日志和度量收集、处理和聚合
代表产品：Flume、Logstash、Fluentd、Heka
这些系统的动机是需要从应用程序和基础设施服务器收集和处理大量日志或度量数据。这导致了一种常见设计，即在每个节点上使用一个agent来收集日志数据，可能对其进行缓冲以防出现故障，并将其转发到目标存储系统或一个用于聚合的agent，后者在再次转发数据之前进一步处理数据。为了将数据从源格式转换为适合目标的格式，这些系统具有解码、过滤和编码事件的框架。
这种模型非常适合于日志的初识收集，其中的数据必须分布在大量主机上，且只能由运行在每个主机上的agent访问。但是它们并没有很好的扩展到其他用例上。例如，这些系统不能很好的处理与诸如HDFS这样的批处理系统的集成，因为它们的设计是基于这样一种预期，即每个事件的处理都将得到及时处理，而大多数故障处理都留给用户。
对于大型数据管道，这些系统在操作上也很复杂。无论如何，每台服务器都需要一个agent来收集日志。然而，要将数据复制到Hadoop这样的系统中，需要跨多台服务器手动管理许多独立的agent进程，并在它们之间手动划分工作。此外，添加新任务可能还需要重新配置上游任务，因为没有标准化的存储层。
2.用于数据仓库的ETL
例子：Gobblin、Chukwa、Suro、Morphlines
这些系统试图从一组完全不同的系统抽取数据到数据仓库（最常见的是HDFS）。因为其关注点在数据仓库之上，所以导致这些系统出现一组常见的模式。最显著的是，它们主要关注批处理作业。在某些系统中，这些批处理可以做的非常小，但是它们的设计目的不是为了实现流处理应用程序所需的低延迟。在将数据加载到数据仓库时，这种设计是合理的，但它不能扩展到Stream Data platform中所需的各种数据复制作业。
另一个常见特性是灵活可插入的数据处理管道。在数据到达HDFS之前，必须将其转换为适合长期存储、查询和分析的形式。然而，这大大复杂化了这些工具——包括它们的使用和实现——并要求用户学习如何在ETL框架中处理数据，而不是使用他们可能已经熟悉的其他现有工具。
最后，这些系统通常只能应用于单一的sink（HDFS）或类似的sink（S3）。同样，给定特定的应用程序领域，这是一个合理的设计去权衡，但是限制了其他类型的数据复制作业。
3.数据管道管理
例子：NiFi
这些系统试图使构建数据管道尽可能容易。它们不关注在两个系统之间复制数据的各个作业的配置和执行，而是为用户提供整个管道的视图。本质上，它们需要相同的基本组件(单个复制任务、数据源和接收器、中间队列等)，但是这些系统的默认视图是整个管道。
因为这些系统作为一个整体“拥有”数据管道，所以它们可能无法在整个组织的范围内很好地工作，其中不同的团队可能需要控制管道的不同部分。大型组织可能在这样的工具中管理许多小型数据管道，而不是一个大型数据管道。但是，这种全局视图允许更好地全局处理错误，并支持对整个数据管道进行监控和度量。
此外，这些系统是围绕通用处理器组件设计的，这些组件可以任意连接以创建数据管道。这提供了很大的灵活性，但是对可靠性和交付语义提供的保证很少。
考虑到每一类相关系统的优缺点，Kafka Connect被设计为具有以下关键属性：
- Broad copying by defaul：快速定义在系统之间复制大量数据的connector，以将配置开销降到最低。默认的工作单元应该是整个数据库，即使也可以定义复制单个表的connector。
- 流和批：支持流系统和面向批处理系统之间的复制。
- 扩展方便：在开发、测试或小型生产环境中运行connector的单个进程，在大型生产环境中进行扩展。
- 只关注复制数据：专注于可靠、可伸缩的数据复制;将数据的转换和其他修改留给只关注该功能的框架。相应地，Kafka Connect复制的数据必须与流处理框架很好地集成。
- 并行：并行性应该包含在核心抽象中，为框架提供一个自动可伸缩性的途径。
- 简便的connector API：开发新的connector必须很容易。
架构
Kafka Connect在设计上有如下三个主要模型：
- Connector模型：connector的定义是通过指定connector类和配置选项来控制复制什么数据以及如何格式化数据。每个connector实例负责定义和更新一组实际复制数据的tasks。Kafka Connect管理tasks;connector只负责生成task集，并在需要更新任务集时指示框架。source和sink的connector和task在API中是不同的，以确保两者都使用最简单的API。
- Worker模型：Kafka Connect集群由一组worker进程组成，这些worker进程是执行connector和task的容器。workers自动相互协调以分配工作，并提供可伸缩性和容错性。worker将在任何可用的过程中分配工作，但不负责过程的管理。
- Data模型：connector将消息流从分区输入流复制到分区输出流，其中至少有一个输入或输出始终是Kafka。每个流都是一个有序集消息，其中每个消息都有一个相关的偏移量。connector定义了这些偏移量的格式和语义，以支持与各种系统的集成；然而，要在出现错误时实现特定的交付语义，需要偏移量在流中是惟一的，并且流可以寻求任意偏移量。消息内容由不依赖于序列化格式的connector表示，Kafka Connect支持可插入转换器，用于以各种序列化格式存储此数据。schema是内置的，允许通过复杂的数据管道传播关于消息格式的重要元数据。然而，当schema不可用时，也可以使用无schema数据。
connector模型解决了三个关键的用户需求。首先，Kafka Connect默认情况下执行广泛的复制，让用户在connector级别定义作业，然后将作业分解成更小的tasks。这种两级模式强烈鼓励connector使用复制大量数据的配置，因为它们应该有足够的输入来将作业分解为更小的任务。它还要求connector考虑如何将它们的工作分解为子任务，从而提供了并行性。最后，通过定制化sourcesink接口，Kafka Connect提供了一个可访问的connector API，使得为各种系统实现connector非常容易。
worker模型允许Kafka Connect扩展到应用程序。它可以以单进程运行，或者以集群模式运行，其中connector和task在worker上动态调度。这种架构允许向上和向下伸缩，但是Kafka Connect的实现还添加了一些实用程序来支持这两种模式。用于管理和监控作业的REST接口使Kafka Connect很容易作为一个为多用户运行作业的企业服务。
数据模型处理其余的需求。许多好处来自与kafka的紧密结合。Kafka作为流系统和批处理系统的天然缓冲区，消除了connector开发者关于管理数据和确保交付的大部分负担。此外，通过始终要求Kafka作为端点之一，更大的数据管道可以利用许多与Kafka集成良好的工具。这允许Kafka Connect只专注于复制数据，因为可以使用各种流处理工具来进一步处理数据，这使得Kafka Connect在概念上和实现上都很简单。最后，Kafka在其核心抽象中包含了partition，提供了并行性。