Kafka数据迁移

1.概述

Kafka的使用场景非常广泛,一些实时流数据业务场景,均依赖Kafka来做数据分流。而在分布式应用场景中,数据迁移是一个比较常见的问题。关于Kafka集群数据如何迁移,今天笔者将为大家详细介绍。

2.内容

本篇博客为大家介绍两种迁移场景,分别是同集群数据迁移、跨集群数据迁移。如下图所示:

2.1 同集群迁移

同集群之间数据迁移,比如在已有的集群中新增了一个Broker节点,此时需要将原来集群中已有的Topic的数据迁移部分到新的集群中,缓解集群压力。

将新的节点添加到Kafka集群很简单,只需为它们分配一个唯一的Broker ID,并在新服务器上启动Kafka。但是,这些新服务器节点不会自动分配任何数据分区,因此除非将分区移动到新增的节点,否则在创建新Topic之前新节点不会执行任何操作。因此,通常在将新服务器节点添加到Kafka集群时,需要将一些现有数据迁移到这些新的节点。

迁移数据的过程是手动启动的,执行过程是完全自动化的。在Kafka后台服务中,Kafka将添加新服务器作为其正在迁移的分区的Follower,并允许新增节点完全复制该分区中的现有数据。当新服务器节点完全复制此分区的内容并加入同步副本(ISR)时,其中一个现有副本将删除其分区的数据。

Kafka系统提供了一个分区重新分配工具(kafka-reassign-partitions.sh),该工具可用于在Broker之间迁移分区。理想情况下,将确保所有Broker的数据和分区均匀分配。分区重新分配工具无法自动分析Kafka群集中的数据分布并迁移分区以实现均匀的负载均衡。因此,管理员在操作的时候,必须弄清楚应该迁移哪些Topic或分区。

分区重新分配工具可以在3种互斥模式下运行:

  • --generate:在此模式下,给定Topic列表和Broker列表,该工具会生成候选重新​​分配,以将指定Topic的所有分区迁移到新Broker中。此选项仅提供了一种方便的方法,可在给定Topic和目标Broker列表的情况下生成分区重新分配计划。
  • --execute:在此模式下,该工具将根据用户提供的重新分配计划启动分区的重新分配。 (使用--reassignment-json-file选项)。由管理员手动制定自定义重新分配计划,也可以使用--generate选项提供。
  • --verify:在此模式下,该工具将验证最后一次--execute期间列出的所有分区的重新分配状态。状态可以有成功、失败或正在进行等状态。

2.1.1 迁移过程实现

分区重新分配工具可用于将一些Topic从当前的Broker节点中迁移到新添加的Broker中。这在扩展现有集群时通常很有用,因为将整个Topic移动到新的Broker变得更容易,而不是一次移动一个分区。当执行此操作时,用户需要提供已有的Broker节点的Topic列表,以及到新节点的Broker列表(源Broker到新Broker的映射关系)。然后,该工具在新的Broker中均匀分配给指定Topic列表的所有分区。在迁移过程中,Topic的复制因子保持不变。

现有如下实例,将Topic为ke01,ke02的所有分区从Broker1中移动到新增的Broker2和Broker3中。由于该工具接受Topic的输入列表作为JSON文件,因此需要明确迁移的Topic并创建json文件,如下所示:

> cat topic-to-move.json
{"topics": [{"topic": "ke01"},
            {"topic": "ke02"}],
"version":1
}

准备好JSON文件,然后使用分区重新分配工具生成候选分配,命令如下:

> bin/kafka-reassign-partitions.sh --zookeeper dn1:2181 --topics-to-move-json-file topics-to-move.json --broker-list "1,2" --generate

执行命名之前,Topic(ke01、ke02)的分区如下图所示:

 

执行完成命令之后,控制台出现如下信息:

该工具生成一个候选分配,将所有分区从Topic ke01,ke02移动到Broker1和Broker2。需求注意的是,此时分区移动尚未开始,它只是告诉你当前的分配和建议。保存当前分配,以防你想要回滚它。新的赋值应保存在JSON文件(例如expand-cluster-reassignment.json)中,以使用--execute选项执行。JSON文件如下:

{"version":1,"partitions":[{"topic":"ke02","partition":0,"replicas":[2]},{"topic":"ke02","partition":1,"replicas":[1]},{"topic":"ke02","partition":2,"replicas":[2]},{"topic":"ke01","partition":0,"replicas":[2]},{"topic":"ke01","partition":1,"replicas":[1]},{"topic":"ke01","partition":2,"replicas":[2]}]}

执行命令如下所示:

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --execute

最后,--verify选项可与该工具一起使用,以检查分区重新分配的状态。需要注意的是,相同的expand-cluster-reassignment.json(与--execute选项一起使用)应与--verify选项一起使用,执行命令如下:

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --verify

执行结果如下图所示:

 

 同时,我们可以通过Kafka Eagle工具来查看Topic的分区情况。

2.2 跨集群迁移

这里跨集群迁移,我们指的是在Kafka多个集群之间复制数据“镜像”的过程,以避免与单个集群中的节点之间发生的复制混淆。 Kafka附带了一个用于在Kafka集群之间镜像数据的工具。该工具从源集群使用并生成到目标集群。这种镜像的一个常见用例是在另一个数据中心提供副本。

另外,你可以运行许多此类镜像进程以提高吞吐量和容错(如果一个进程终止,其他进程将占用额外负载)。将从源集群中的Topic读取数据,并将其写入目标集群中具有相同名称的主题。事实上,“镜像”数据只不过是一个Kafka将消费者和生产者联系在了一起。

源集群和目标集群是完全独立的实体,它们可以具有不同数量的分区,并且偏移量将不相同。出于这个原因,镜像集群并不是真正意图作为容错机制(因为消费者的位置会有所不同);为此,建议使用正常的集群内复制。但是,镜像进程将保留并使用消息Key进行分区,因此可以按Key保留顺序。

下面是一个跨集群的单Topic实例,命令如下:

> ./kafka-mirror-maker.sh --consumer.config consumer.properties --producer.config producer.properties --whitelist ke03

需要注意的是,consumer.properties文件配置源Kafka集群Broker地址,producer.properties文件配置目标Kafka集群地址。如果需要迁移多个Topic,可以使用 --whitelist 'A|B',如果需要迁移所有的Topic,可以使用 --whitelist '*'。

3.结果预览

执行跨集群迁移命令后,目标集群中使用Kafka Eagle中查看Topic Size大小看是否与源集群的Topic Size大小相等,或者使用SQL语句,验证是否有数据迁移过来,结果如下图所示:

 

4.总结

跨集群迁移数据的本质是,Kafka启动了消费者读取源集群数据,并将消费后的数据写入到目标集群,在迁移的过程中,可以启动多个实例,提供迁出的吞吐量。

5.结束语

这篇博客就和大家分享到这里,如果大家在研究学习的过程当中有什么问题,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉!

另外,博主出书了《Kafka并不难学》,喜欢的朋友或同学, 可以在公告栏那里点击购买链接购买博主的书进行学习,在此感谢大家的支持。

posted @ 2019-03-18 11:28 哥不是小萝莉 阅读(...) 评论(...) 编辑 收藏