MySQL数据实时同步到Hive, Confluent环境搭建

最新推荐文章于 2022-11-06 21:52:54 发布

雾岛与鲸

最新推荐文章于 2022-11-06 21:52:54 发布

阅读量1.4k

点赞数

本文链接：https://blog.csdn.net/qq_36039236/article/details/107709234

版权

hive 同时被 2 个专栏收录

64 篇文章 15 订阅

订阅专栏

kafka

8 篇文章 1 订阅

订阅专栏

1．背景

最近研究了mysql 数据库实时转移 hive 的方案，目的是要把数据库中某些表的指定数据实时的转移到 hive 数据库中。

在调研的过程中了解到Confluent平台可以很好的实现这个功能，于是开始逐步深入探究其使用方法和工作原理。

2．Confluent初探

Confluent 官网资料很多，本章主要对一些必要的概念或者是和本实验有关的东西进行重点讲解。

2.1. Confluent Platform功能

Confluent是用来管理和组织不同数据源的流媒体平台，可以实时地把不同源和位置的数据集成到一个中心的事件流平台。而且还强调了这个平台很可靠、性能很高，总之就是很好用，很强大。

下面的图形象说明了Confluent可以实现的功能。
confluent功能

2.2 Confluent Platform组成

Confluent目前提供了社区版和商业版两个版本，社区版永久免费，商业版面向企业收费。

社区版提供了Connectors、REST Proxy、KSQL、Schema-Registry等基础服务。

商业版为企业提供了控制面板、负载均衡，跨中心数据备份、安全防护等高级特性。

2.3 社区版功能介绍

通过对两个版本功能的比对，发现社区版已经能满足我们的要求，因此本文后面都以社区版来进行研究。

下载链接：https://www.confluent.io/download/

2.4 confluent命令

Confluent提供了多种命令来对confluent平台进行管理监控，命令列表及描述如下：
这里主要提一下我们最可能最常用到confluent local start ，confluent local stop 两个命令，这两个命令分别用来启动和停止相应的服务以及依赖的所有服务项。

start命令如果不带参数会把相关服务按顺序启动，stop会逆序把各服务停止。

执行start命令：

confluent local start

结果如下，[UP]表示该服务启动成功：

    The local commands are intended for a single-node development environment
    only, NOT for production usage. https://docs.confluent.io/current/cli/index.html

Using CONFLUENT_CURRENT: /var/folders/l1/8mjrry9j5r936_j36b6shvwr0000gn/T/confluent.Qoqz4E15
Starting zookeeper
zookeeper is [UP]
Starting kafka
kafka is [UP]
Starting schema-registry
schema-registry is [UP]
Starting kafka-rest
kafka-rest is [UP]
Starting connect
connect is [UP]
Starting ksql-server
ksql-server is [UP]
Starting control-center
control-center is [UP]

执行stop命令：

confluent local stop

结果如下，[DOWN]表示该服务停止成功：

    The local commands are intended for a single-node development environment
    only, NOT for production usage. https://docs.confluent.io/current/cli/index.html

Using CONFLUENT_CURRENT: /var/folders/l1/8mjrry9j5r936_j36b6shvwr0000gn/T/confluent.Qoqz4E15
Stopping control-center
control-center is [DOWN]
Stopping ksql-server
ksql-server is [DOWN]
Stopping connect
connect is [DOWN]
Stopping kafka-rest
kafka-rest is [DOWN]
Stopping schema-registry
schema-registry is [DOWN]
Stopping kafka
kafka is [DOWN]
Stopping zookeeper
zookeeper is [DOWN]

从上面命令可以看到服务的启动关闭都有一定的顺序性，不能随意颠倒。

jps查看启动的进程如下:

➜  ~ git:(master) ✗ jps
1072 KsqlServerMain
753 KafkaRestMain
99842 QuorumPeerMain
295
584 SchemaRegistryMain
922 ConnectDistributed
1387 Jps
1179 ControlCenter
287 SupportedKafka

3. 服务功能介绍

3.1 Zookeeper

Zookeeper是一个开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop、Hbase、Storm的重要组件。

Zookeeper主要功能包含：维护配置信息、命名、提供分布式同步、组管理等集中式服务。

Kafka使用ZooKeeper对集群元数据进行持久化存储，是Confluent平台部署的关键组件。

如果ZooKeeper丢失了Kafka数据，集群的副本映射关系以及topic等配置信息都会丢失，最终导致Kafka集群不再正常工作，造成数据丢失的后果。

想要了解更多Zookeeper信息，可以查看官方链接：https://zookeeper.apache.org/

3.2 Kafka

Kafka是一个分布式流处理平台，最初由Linkedin公司开发，是一个基于zookeeper协调并支持分区和多副本的分布式消息系统。

Kafka最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎、web/nginx日志、访问日志、消息服务等等。

Kafka用Java和Scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

Kafka工作原理是一种高吞吐量的分布式发布订阅消息系统，消息队列中间件，主要功能是负责消息传输，Confluent就是依赖Kafka来进行消息传输。

3.3 Kafka-rest

Confluent提供的Kafka RESTful接口服务组件。

可以通过Restful接口而不是本机Kafka协议或客户端的情况下，很容易的生成和使用消息,而且还可以查看集群状态以及执行管理操作。

3.4 Schema-Registry

Schema-Registry是为元数据管理提供的服务，同样提供了RESTful接口用来存储和获取schemas，它能够保存数据格式变化的所有版本，并可以做到向下兼容。

Schema-Registry还为Kafka提供了Avro格式的序列化插件来传输消息。

Confluent主要用Schema-Registry来对数据schema进行管理和序列化操作。

3.5 Connect

Kafka Connect是 Kafka的一个开源组件，是用来将Kafka与数据库、key-value存储系统、搜索系统、文件系统等外部系统连接起来的基础框架。

通过使用Kafka Connect框架以及现有的连接器可以实现从源数据读入消息到Kafka，再从Kafka读出消息到目的地的功能。

Confluent 在Kafka connect基础上实现了多种常用系统的connector免费让大家使用，提供的列表如下：

Kafka Connect ActiveMQ Connector
Kafka FileStream Connectors
Kafka Connect HDFS
Kafka Connect JDBC Connector
Confluent Kafka Replicator
Kafka Connect S3
Kafka Connect Elasticsearch Connector
Kafka Connect IBM MQ Connector
Kafka Connect JMS Connector

这些connector都可以拿来免费使用，而且Confluent 在GitHub上提供了源码，可以根据自身业务需求进行修改。

3.6 ksql-server

KSQL是使用SQL语句对Apache Kafka执行流处理任务的流式SQL引擎。

Confluent 使用KSQL对Kafka的数据提供查询服务.

4. 系统架构

为了保证系统可靠性，真实生产环境中都会以集群的方式搭建，以避免单机宕机造成的影响。本文以3台机器，MySQL作为源/目的数据库来进行数据库的转移实验。

整个系统的整体结构如下图所示，因为每个组件都是独立提供服务且都能以集群的方式进行工作，因此本实验把每个服务都分别部署到3台机器来模拟集群环境。本系统主要用了Zookeeper、Kafka、Kafka-Connect、Schema-Registry 4种服务，整体架构如下：
confluent 平台架构
整个系统工作流程是Source Connector集群从源MySQL DB中不断实时读取变动数据(增/删/改)再经过Schema-Registry序列化后插入到Kafka消息队列中，Sink Connector会不断从Kafka消息队列中获取数据再经过反序列化插入到目的MySQL DB中。

5. Confluent 安装

以mac为实验环境
confluent 版本: confluent-5.5.1-2.12.tar.gz
debezium 版本: debezium-connector-mysql-1.1.2.Final-plugin.tar.gz

5.1 安装JDK1.8

5.2 Confluent 安装

下载Confluent Community版，下载链接为https://www.confluent.io/download/，解压到安装目录，添加环境变量。

export PATH=<path-to-confluent>/bin:${PATH};
export CLASSPATH=<path-to-confluent>/share/java/*:${CLASSPATH}

执行source~/.bashrc 使之生效。

6. 服务配置

5.1 Zookeeper 配置

编辑/etc/kafka/zookeeper.properites文件，修改以下配置信息。

完整配置信息可以参看链接：

https://docs.confluent.io/current/zookeeper/deployment.html

tickTime=2000                                      # 时间单元，毫秒单位
dataDir=/var/lib/zookeeper/                  # 数据存储路径
clientPort=2181                                    # zookeeper 客户端监听端口 
initLimit=5                                            # followers 初始化时间
syncLimit=2                                         # followers 同步时间
maxClientCnxns=0                              # 最大client连接数，值为0的时候没有上限
server.< myid >=< hostname >:< leaderport >:< electionport > 集群配置
server.1=< IP1>:2888:3888 #server1 地址，修改为自身地址
server.2=< IP2>:2888:3888 #server2 地址
server.3=< IP3>:2888:3888 #server3 地址
autopurge.snapRetainCount=3           # 最近的快照保存数目
autopurge.purgeInterval=24                # 快照自动清除时间间隔

修改好配置文件后，需要在每台Zookeeper Server的dataDir目录下创建myid文件来在集群中作为

唯一标示。

例如：

server1:  echo 1 > myid
server2:  echo 2 > myid
server3:  echo 3 > myid

集群中所有配置信息需保持一致，每次修改配置文件，都必须重启相应机器的服务才能生效。

5.2 kafka配置

编辑/etc/kafka/server.properites文件，修改以下配置信息。

完整配置信息可以参看链接：

https://docs.confluent.io/current/kafka/operations.html

集群地址，修改为自己地址

zookeeper.connect=xxx.xxx.xxx.xxx:2181，xxx.xxx.xxx.xxx:2181，xxx.xxx.xxx.xxx:2181
broker.id=[1,2,3]                                                       # 节点标识，每台机器依次改为1，2，3….依次递增 
log.dirs=/xxx/log/kafka                                              # 日志目录,修改为自身log目录 
listeners=PLAINTEXT://0.0.0.0:9092                        # 监听地址 
advertised.listeners=PLAINTEXT://0.0.0.0:9092      # 发布到zookeeper供客户端连接的地址
num.partitions=3                  # 分区数设置，分区间数据无序，分区内数据有序。若需要保证有序，此处设置为1
default.replication.factor=3  # 消息备份数目默认1不做复制。此处改为2，备份一份。
port=9092                            # 服务端口，默认9092

集群中除broker.id外所有配置信息需保持一致，每次修改配置文件，都必须重启相应机器的服务才能生效。

5.3 Schema Registry 配置

编辑/etc/schema-registry/schema-registry.properites 文件，修改以下配置信息。

完整配置信息可以参看链接

https://docs.confluent.io/current/schema-registry/docs/index.html

listeners=http://0.0.0.0:8081                        # 监听地址
host.name=172.21.101.186                        # 主机地址,改为机器本身地址 
port                                                             # 端口号，默认8081
kafkastore.connection.url=xxx.xxx.xxx.xxx: 2181,xxx.xxx.xxx.xxx: 2181，xxx.xxx.xxx.xxx:2181 # 集群列表，改为机器相应地址

集群中除host.name设置为本身ip外，所有配置信息均需保持一致，每次修改配置文件，都必须重启相应机器的服务才能生效。

5.4 Kafka-Connect

4.4.1 Connect 配置
编辑/etc/schema-registry/connect-avro-distributed.properties.properites 文件，修改以下配置信息。

完整参数参考链接：

https://docs.confluent.io/current/connect/index.html

group.id=connect-cluster # Connect集群组标示，集群中此处所有配置必须相同。
kafka节点列表,host1:port1,host2:port2,...修改为相应机器地址 
bootstrap.servers=xxx.xxx.xxx.xxx:2181，xxx.xxx.xxx.xxx:2181，xxx.xxx.xxx.xxx:2181
key.converter=io.confluent.connect.avro.AvroConverter                # 使用Avro为key转化类
key.converter.schema.registry.url=http:// xxx.xxx.xxx.xxx:8081      # key的schema 访问URL 
value.converter= io.confluent.connect.avro.AvroConverter            # 使用Avro为value 转化类
value.Converter.schema.registry.url=http:// xxx.xxx.xxx.xxx:8081  # value的schema 访问URL
config.storage.replication.factor=3                  # config信息备份因子，不超过集群数目 
offset.storage.replication.factor=3                   # 偏移量备份因子，不超过集群数目 
status.storage.replication.factor=3                  # 任务状态备份因子，不超过集群数目

集群中除schema.registry.url设置为本身ip外,集群中所有配置信息均需保持一致，每次修改配置文件，都必须重启相应机器的服务才能生效。

5.5 安装kafka-connect-hdfs

执行:

confluent-hub install confluentinc/kafka-connect-hdfs:latest

5.6 安装debezium

在http://debezium.io 下载
解压缩到指定的文件夹
在connect-distributed.properties的plugins属性指定插件对应的目录即可

6. Connector REST API

在集群环境下，Connector参数只能通过RESTful接口进行参数配置，通过RESTful接口可以给任意一个服务器发送配置参数，Connector参数信息会自动转发给集群中的其它机器。使用RESTful接口配置参数后，Connector服务无需重启，即可生效。

下面详细描述Connector RESTful接口的配置参数。

6.1 RESTful Header

目前 REST接口只支持Json格式参数,因此请求头应该如下设置。

Accept: application/json
Content-Type: application/json

6.2 RESTful URL

connect接口列表

7. mysql to hive 同步

确定mysql 已经开启binlog

7.1 创建并启动 MySql Source Connector

MySql Source Connector
配置描述:

{
  "name": "inventory-connector",                              # connector名称
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector", 
    "database.hostname": "127.0.0.1",                     
    "database.port": "3307", 
    "database.user": "root", 
    "database.password": "123456", 
    "database.server.id": "184054",                           # 保证唯一
    "database.server.name": "fullfillment",                 # 命名自定义
    "database.whitelist": "test_binlog",                       # 要监控的mysql库
    "database.history.kafka.bootstrap.servers": "127.0.0.1:9092",       # kafka地址
    "database.history.kafka.topic": "dbhistory.fullfillment",                    # topic名称
    "include.schema.changes": "true" 
  }
}

查看任务启动状态:
mysql connector启动状态
操作mysql的test_binlog库下的students数据表
操作mysql数据表
查看kafka Topic列表, 发现出现如下Topic:

./bin/kafka-topics --zookeeper localhost:2181 --list

dbhistory.fullfillment
fullfillment
fullfillment.test_binlog.students

7.2 创建并启动 HDFS Sink Connector

hdfs sink任务配置
配置信息描述:

{
    "name":"dev_hdfs-sink",                    # connector名称
    "config":{
        "connector.class":"io.confluent.connect.hdfs.HdfsSinkConnector",
        "tasks.max":"1",                            # task任务并行度
        "topics":"fullfillment.test_binlog.students",      # 消费的 topic 名称
        "hdfs.url":"hdfs://127.0.0.1:8020",                   # hdfs地址
        "flush.size":"3",    
        "hive.integration":true,
        "hive.database":"test",                                    # 要写入的hive库
        "hive.metastore.uris":"thrift://127.0.0.1:9083",      # hive metastore地址（hive需要配置远程连接）
        "schema.compatibility":"BACKWARD"
    }
}

任务启动，hive中的数据表会自动创建。
查看对应的hive库:
hive对应库表
查看自动创建的表结构:
hive对应表结构
查看hive表中对应的导入数据:
hive表对应数据

8. 小结

通过实验所有数据都能实时进行转移并没有遗漏。

在破坏性测试中如杀掉服务进程、下线集群中的某台机器等异常测试中，集群都能正常的进行转移工作。

即使把集群中所有机器的服务都停止，当服务重启后，Confluent会把宕机期间的数据转移过来。可以看出Confluent确实如官方宣传所言，是一个高性能，高可靠的系统。

到此，本文也基本结束，希望此教程能帮助所有需要的人。

雾岛与鲸

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
打赏
1
评论
MySQL数据实时同步到Hive, Confluent环境搭建

1．背景最近研究了mysql 数据库实时转移 hive 的方案，目的是要把数据库中某些表的指定数据实时的转移到 hive 数据库中。在调研的过程中了解到Confluent平台可以很好的实现这个功能，于是开始逐步深入探究其使用方法和工作原理。2．Confluent初探Confluent 官网资料很多，本章主要对一些必要的概念或者是和本实验有关的东西进行重点讲解。2.1. Confluent Platform功能Confluent是用来管理和组织不同数据源的流媒体平台，可以实时地把不同源和位置的数据
复制链接

扫一扫