深入理解Kafka系列（六）--Kafka数据管道

系列文章目录

Kakfa权威指南系列文章

前言

本系列是我通读《Kafka权威指南》这本书做的笔录和思考。

正文

Kafka其实就像一个数据管道，基本上他的定位是作为一个中间件，我们数据流入到Kafka，让Kafka管理，然后数据从Kafka当中流出到需要的地方。那么Kafka作为数据管道各个数据段之间的大型缓冲区，可以有效地解耦管道数据的生产者和消费者。接下来就来讲一下Kafka Connect以及一些案例。

Kafka Connect

Connect是Kafka的一部分，他为在Kafka和外部数据存储系统之间移动数据提供了一种可靠且可伸缩的方式。

1. Connect以worker进程集群的方式来运行，我们基于worker进程安装连接器插件。
2. 然后使用Rest API来管理和配置connector，这些worker进程会成为长时间持续运行的作业。
3. 连接器启动额外的task，有效利用工作节点的资源，以并行的方式移动大量的数据。
4. 数据源的连接器负责从源系统读取数据，并把数据对象提供给worker进程。
5. 数据池的连接器负责从worker进程获取数据，并把他们写入目标系统。

运行Connect

第一步：修改配置文件(进入kafka/config目录)

vi connect-distributed.properties 

一般Connect进程有3个比较重要的配置参数（在这里我们只需要修改bootstrap.server即可）

1. bootstrap.server

该参数列出了将要与Connect协同工作的broker服务器，连接器将会向这些broker写入数据或者从他们那里读取数据。

2. group.id

具有相同group.id的worker属于同一个Connect集群。

3. key.converter和value.converter

Connect可以处理存储在kafka里面不同格式的数据，这俩参数分别指定了消息的键和值所使用的转换器。默认使用Kafka提供的JSONConverter。

第二步：后台启动Connector（单机即可）

 ./bin/connect-distributed.sh config/connect-distributed.properties &

第三步：验证是否启动成功

1.验证端口是否打开：

netstat -nlp | grep :8083

2.通过REST API验证是否运行正常：

curl http://192.168.237.130:8083/
curl http://192.168.237.130:8083/connector-plugins

如果正常，会返回当前Connect的版本号等信息。

---

Connect Demo1：文件数据源和文件数据池

确保上述zookeeper和Kafka以及Connector开启后，我们来开始案例的操作。

1.第一步：开始启动一个文件数据源，为了方便，直接让他读取kafka的配置文件----把kafka的配置文件内容发送到主题上。

echo '{"name":"load-kafka-config","config":{"connector.class":"FileStreamSource","file":"config/server.properties","topic":"kafka-config-topic"}}' | curl -X POST -d @- http://192.168.237.130:8083/connectors --header "content-Type:application/json"

这个JSON片段包含了连接器的名字：load-kafka-config，连接器的配置信息（包含连接器的雷鸣，需要加载的文件名和主题名称）

2.第二步：通过Kafka控制台消费者来验证配置文件是否加载到主题上。

 ./bin/kafka-console-consumer.sh --bootstrap-server=192.168.237.130:9092 --topic kafka-config-topic --from-beginning

结果：若出现以下结果，则代表成功。

1.以上结果输出的是config/server.properties的内容，这些内容被一行一行的转成了JSON记录，并被连接器发送到kafka-config-topic的主题上面。
2.默认情况下，JSON转换器会在每个记录里面附带上schema，这里的schema非常简单，只有一个payload列，代表字符串类型，并且包含了文件里的一行内容。

3.第三步：使用文件数据池的转换器把主题里面的内容导入到文件里。

echo '{"name":"dump-kafka-config1","config":{"connector.class":"FileStreamSink","file":"copyServerProperties","topics":"kafka-config-topic"}}' | curl -X POST -d @- http://192.168.237.130:8083/connectors --header "content-Type:application/json"

结果：出现以下字样代表成功

1.首先这次的配置发生了变化，类名FileStreamSink代替了FileStreamSource。文件的属性指向了目标文件而不是原文件。指定了topics而不是topic，则可以使用数据池将多个主题写入一个文件，而一个数据源只被允许写入一个主题。
2.如果一切正常， 你会得到一个叫copyServerProperties的文件，内容和server.properties完全一样。

如果再次调用命令你会发现报错，报错信息：连接器已经存在。

删除连接器：

curl -X DELETE http://192.168.237.130:8083/connectors/dump-kafka-config1

查看连接器：

curl -X GET http://192.168.237.130:8083/connectors/

到这里，我们完成了用Kafka自带的连接器，把文件内容写入主题，再把数据从主题中写入到目标数据源当中。

注意：写入只能写入单主题（一对多）。写出可以多对一

---

Connect Demo2：从Mysql到Kafka

第一步：获取相关的jar包（我都是自己maven打包的，太麻烦了，直接给你们线程的）
俺的百度云 密码: 6eq9

---

第二步：将jar包上传到kafka/libs目录下，然后重新启动connect。

 ./bin/connect-distributed.sh config/connect-distributed.properties &

验证插件：

curl http://192.168.237.130:8083/connector-plugins

结果：

---

第三步：在Mysql中创建一张表（启动和安装mysql就不用我说了吧）

create database test;
use test;
create table login(username varchar(30),login_time datetime);
insert into login values('test1',now());
insert into login values('test2',now()); 
commit;

然后创建和配置JDBC连接器：相关的官方配置文档以及案例点我

echo '{"name":"mysql-login-connector","config":{"connector.class":"JdbcSourceConnector","connection.url":"jdbc:mysql://localhost:3306/test?user=root&useSSL=true","connection.password":"ljj000","mode":"timestamp","table.whitelist":"login","validate.non.null":false,"timestamp.column.name":"login_time","topic.prefix":"mysql."}}' | curl -X POST -d @- http://192.168.237.130:8083/connectors --header "content-Type:application/json"

参数：

1. table.whitelist：相当于表的白名单，表示要监听的表。
2. topic.prefix：topic的前缀，和前面的参数结合成最终的topic。
3. connector.class：使用的连接器的类型。
4. connection.url：连接地址。
5. timestamp.column.name：使用时间戳字段的名称。

我这里踩了很大的坑，这里让大家排下雷。

1. Mysql的版本是否和mysql-connector-java.jar包的版本对应。（我一开始用的是虚机上mysql8以上的版本，后来换成了本地localhost有个5.7版本的，我的jar包是5.1.37，肯定不能和8版本的mysql用）
2. 是否在kafka/libs下导入相关的jar包。

如果出现以下字样代表成功：

使用Kafka消费者验证：

./bin/kafka-console-consumer.sh --bootstrap-server=192.168.237.130:9092 --topic mysql.login --from-beginning

到这里，我们成功的把Mysql中的数据导入到Kafka的topic当中。

---

深入理解Connect

要理解Connect的工作原理，我们首先要知道几个基本概念，以及他们之间是如何进行交互的。

连接器和任务

连接器：负责3个事情

1. 决定需要运行多少个任务。
2. 按照任务来拆分数据复制。
3. 从worker进程获取任务配置并把它传递下去。

例：
1.JDBC连接器会连接到数据库，统计需要复制的表，并确定需要执行多少个任务。
2.然后在配置参数max.tasks和实际数据量之间选择数值最小的那个值作为任务数量。
3.确定任务数后，连接器为每个任务生成一个配置，配置里面包含了连接器的配置项，例如connection.url以及每个任务所需要复制的表。
4.由taskConfigs（）方法返回一个映射列表，worker进程负责启动和配置任务，每个任务只复制配置项里指定的数据表。

任务：

1. 负责将数据移入或者移出kafka。

1.任务在初始化的时候会得到由worker进程分配的一个上下文。源系统上下文（Source Context）包含一个对象，可以将源系统记录的偏移量保存在上下文中（如数据表的主键ID）。
2.当然，源系统有上下文，目标系统也会有个上下文，他会提供一些方法，连接器用他们操作kafka中拿到的数据。
3.任务完成初始化化后，开始按照连接器指定的配置启动工作。
4.源系统任务对外部系统进行轮询，并返回一些记录，worker进程将这些记录发送到kafka。
5.数据池任务通过worker进程接收来自Kafka的记录，并把他们写入到外部系统。

worker进程

1. 作为连接器和任务的容器，负责处理http请求。
2. 这些请求用于定义连接器和连接器之间的配置，还负责保存配置、启动连接器之间的任务。

可以这么理解：连接器和任务负责数据的移动，而worker进程负责REST API、配置管理、可靠性和高可用、负载均衡等工作。

转化器和Connect的数据模型

Connect提供了一组数据API，包含了数据对象和用于描述数据的schema。

例：
1.JDBC连接器从数据库读取了一个字段，并基于该字段的数据类型创建了一个Connect Schema对象。
2.使用这个Schema对象创建了一个包含所有数据库字段的Struct
3.源连接器就是从源系统中读取事件，并为每个事件生成schema和值（值就是数据对象本身）。
4.而目标连接器则获取schema和值，使用schema来解析值，并写入目标系统。

转化器就是用于数据流入或者流出kafka时需要经过的步骤，例如，对象转JSON数据。

稍微做个小总结就是：

1. 连接器负责传递数据、获取任务的配置，把数据导入和导出kafka。
2. 连接器生成任务，任务启动后，数据开始传输。
3. 数据传输的过程中会经过转化器的转换，比如转String啊，JSON类型啊等等，方便存储。

偏移量管理

worker进程除了提供REST API服务，还提供偏移量的管理服务，让连接器直到哪些数据是已经被处理过的。

1. 源连接器返回的记录中其实还包含了源系统的分区和偏移量，worker会将这些记录发送给Kafka。（结合上文任务中讲的上下文）

例如：
1.对于文件源来说，分区可以是一个文件，偏移量可以是文件里面的一个行号或者字符号。
2.对于JDBC源来说，分区可以使一个数据表，偏移量可以使一条记录的主键。

2. 如果Kafka确认记录保存成功，worker进程就会把偏移量保存下来，一般通过主题来保存。

3. 而目标连接器则相反，他们会从Kafka当中读取包含了主题、分区和偏移量信息的记录，然后调用连接器的put（）方法，该方法会把记录保存到目标系统当中。

4. 如果保存成功，连接器会通过消费者客户端将偏移量保存到kafka上。

---

总结

本文大概讲了这么几个点：

1. Kafka自带的Connect连接器。
2. 讲了两个Demo，源文件-Kafka-目的文件，Mysql-Kafka。
3. 细说了Connect中：worker进程、连接器、转化器、任务的相关概念以及关系。

下一篇准备从管理Kafka方面来讲解。