早期的设计

最早的设计可以看: KIP-26 - Add Kafka Connect framework for data import/export,

通过kip, 可以发现, connect设计的目标是 导入和导出数据. 设计目标:

  • 只聚焦数据处理
  • 并行度的支持. 能够支持大量数据的拷贝
  • 尽可能提供 准确一次的分发.
  • 管理元数据
  • 设计良好的connector api. 易于扩展
  • 流式和批处理的支持
  • Strandalone 和 集群的支持

为什么是基于 kafka 构建一套connect, 而不是其他框架呢?

  • kafka 本身就有并行度的概念
  • kafka 本身良好的 容错能力, 使得编码简单
  • kafka 提供了 准确一次、最多一次、最少一次

除此之外, 其他的框架 本身也是从一个具体的case进行 泛化, 不能很好的利用kafka本身的优势。 学习成本和复杂度很高. 部分依赖于 yarn, 对于大集群是好处, 但是应该是 利用而不是依赖. 最后, 其他框架的技术栈 和 kafka 不匹配.

那么, 为什么 kafka-connect 和 kafka 放在一起呢?

  • 文档入口友好度
  • 生态化. 在使用kafka的时候, 不需要到处找其他框架的connector
  • 更好的集成kafka相关的接口

模块设计

设计上, kafka connect 主要有一下三个模块:

  1. 数据模型的定义. 和 kafka 使用byteArray 不一样. 数据模型将 序列化/反序列化作为可插拔的组件. 模型定义是 schema.
  2. 与外部系统交互的 connector 定义. connector负责切分数据(监听外部系统变化更新数据切分), task 负责生产和消费 records
  3. worker模型. connector执行模式、coordination、配置存储、offset 存储、offset commit 管理. 负责任务的负载均衡, 以及 rest 接口支持. Strandalone 和 分布式模式

关于数据存储:

主要存储的对象: 用户提供的connector配置、connector生产的task配置、offset数据. 目前主要是 本地文件 和 kafka/zk 两种实现方式, 对应 standalone 和 分布式模式.

kafka sink 直接复用 offset. kafka source 在 offset 数据上需要添加一些元信息.

分发保证:

kafka connect 支持 三种不同的分发模式. 至少一次、最多一次、准确一次.

  • 至少一次: source connector, producer 支持 flush; sink connector, consumer 本身支持 offset 提交
  • 最多一次: 机制和上面类似, 但是可以通过缓存一批数据 进行提交
  • 准确一次: source connector, 通过 幂等producer 实现; sink connector, 可以借助于 topic + partition + offset 实现

进程管理和集群资源管理

connect 框架不负责 进程的 开始/暂停/重启. 可以利用yarn/mesos/k8s, 或者不需要其他框架. 使用方式: - kafka connector 作为一个服务. 进程管理可以通过 Chef/Puppet/Ansible/Salt 实现, connecotor 通过 rest api 提交. - 资源管理 connector. 通过 mesos/yarn/k8s/Slider/Marathon 管理 - standalone 模式 - 嵌入式模式. 提供了嵌入式 api

例子

jdbc、hdfs、log 和 mirror make

接口

cli: standalone 和 cluster 模式分两种 rest api: embedded api:

反对方案

  1. kafka connect 是和 kafka 放在一起的. 接口更加一致, 管理更加方便
  2. 不使用第三方的流处理框架: kafka-connect 如果使用 流处理框架, 那么 流处理实现会很复杂, 涉及 source/sink. 而且, 流处理框架不会太关心 kafka-connect
  3. 不支持 push-based source connectors. 针对任务调度变得复杂,集成其他第三方数据源 也复杂.