uReplicator: Uber工程公司的健壮Apache Kafka Replicator

0
uReplicator: Uber工程公司的健壮Apache Kafka Replicator

优步的分析管道

在优步,我们使用Apache卡夫卡作为连接生态系统不同部分的消息总线。我们从骑手和司机应用程序中收集系统和应用程序日志以及事件数据。然后我们通过Kafka将这些数据提供给各种下游消费者。

数据通过Kafka管道为优步的许多分析用例提供支持。
数据通过Kafka管道为优步的许多分析用例提供支持。

Kafka中的数据同时提供实时管道和批处理管道。前者的数据用于计算业务指标、调试、警报和仪表板等活动。批处理流水线数据更具有探索性,如ETL导入Apache Hadoop而且惠普Vertica

在本文中,我们将描述优步的开源解决方案uReplicator用于以健壮和可靠的方式复制Apache Kafka数据。该系统扩展了Kafka的MirrorMaker的原始设计,专注于极高的可靠性,零数据丢失的保证,以及易于操作。uReplicator自2015年11月开始投入生产,是Uber多数据中心基础设施的关键部分。

什么是镜子制造机,我们为什么需要它?

考虑到Kafka在Uber内部的大规模使用,我们最终在不同的数据中心使用多个集群。对于各种用例,我们需要查看此数据的全局视图。例如,为了计算与旅行相关的业务指标,我们需要从所有数据中心收集信息并在一个地方进行分析。为了实现这一点,我们一直使用开源技术MirrorMaker工具随Kafka包一起发布,以跨数据中心复制数据,如下所示。

Uber的数据管道反映了多个数据中心的数据。
Uber的数据管道反映了多个数据中心的数据。

MirrorMaker(作为Kafka 0.8.2的一部分)本身非常简单。它使用高级Kafka消费者从源集群获取数据,然后将数据提供给Kafka生产者,将其转储到目标集群。

卡夫卡的镜子制造商在优步的限制

尽管我们最初的MirrorMaker设置一开始就足够了,但我们很快就遇到了可伸缩性问题。随着主题数量和数据速率(字节/秒)的增长,我们开始看到数据交付延迟或进入聚合集群的数据完全丢失,从而导致生产问题和数据质量下降。以下列出了现有MirrorMaker工具(截至0.8.2)在Uber特定用例中的一些主要问题:

  • 昂贵的重新平衡。如前所述,每个MirrorMaker工作者使用一个高级消费者。这些消费者通常会经历一个重新平衡的过程。他们之间协商决定谁拥有哪个主题分区(通过Apache管理员).这个过程可能需要很长时间;我们观察到在某些情况下大约5-10分钟不活动。这是一个问题,因为它违反了我们的端到端延迟保证。此外,消费者可能会在32次重新平衡尝试后放弃,并永远陷入困境。不幸的是,我们亲眼看到这种情况发生过几次。每次尝试重新平衡后,我们都会看到类似的流量模式:
Kafka MirrorMaker产生不活跃的问题时,消费者试图重新平衡。
Kafka MirrorMaker产生不活跃的问题时,消费者试图重新平衡。

在重新平衡期间的不活跃之后,MirrorMaker有大量的积压数据,它必须赶上。这导致目标集群上的流量激增,随后所有下游消费者都受到影响,导致生产中断和端到端延迟增加。

  • 难以添加主题。在Uber,我们必须在镜像工具中指定一个主题白名单,以控制有多少数据流经链接。使用Kafka MirrorMaker,这个白名单是完全静态的,我们需要重新启动MirrorMaker集群来添加新的主题。重新启动是昂贵的,因为它迫使高级消费者重新平衡。这成了一场操作上的噩梦!
  • 数据可能丢失。旧的MirrorMaker有一个问题——似乎在最新版本中得到了修复——自动偏移提交可能会导致数据丢失。高级使用者自动提交所取消息的偏移量。如果在MirrorMaker能够验证是否确实将消息写入了目标集群之前发生了故障,那么这些消息将会丢失。
  • 元数据同步问题。我们还遇到了配置更新方式的操作问题。为了从白名单中添加或删除主题,我们在一个配置文件中列出了所有最终的主题名称,该配置文件在MirrorMaker初始化期间读取。有时在某个节点上更新配置失败。这导致整个集群崩溃,因为不同的MirrorMaker工作人员对要复制的主题列表没有达成一致。

为什么要开发uReplicator

我们考虑了以下方案来解决上述问题:

A.分成多个MirrorMaker集群。上面列出的大多数问题都是由高层消费者重新平衡过程引起的。减少其影响的一种方法是限制由一个MirrorMaker集群复制的主题分区的数量。因此,我们最终会得到几个MirrorMaker集群,每个集群复制要聚合的主题的一个子集。

优点:

-添加新主题很容易。只需创建一个新的集群。

—MirrorMaker集群快速重启。

缺点:

-这是另一个操作噩梦:我们必须部署和维护多个集群。

B.使用Apache Samza进行复制。由于问题出在高级使用者身上(从0.8.2开始),一种解决方案是使用KafkaSimpleConsumer并补充了领导人选举和分区分配的缺失部分。Apache Samza(一个流处理框架)已经静态地将分区分配给工人。然后,我们可以简单地使用Samza作业将数据复制并聚合到目的地。

优点:

-高度稳定可靠。

-易于维护。我们可以用一个作业复制很多主题。

—重启作业对复制流量的影响很小。

缺点:

-它仍然是静止的。我们需要重新启动作业来添加和/或删除主题。

我们需要重新启动工作来增加更多的工人(从Samza 0.9开始)。

—主题扩展需要明确处理。

C.使用基于Apache helix的Kafka消费者。最终,我们决定使用基于helix的Kafka消费者。在本例中,我们使用Apache Helix为工作者分配分区,每个工作者使用SimpleConsumer复制数据。

优点:

-添加和删除主题非常简单。

—在MirrorMaker集群中添加和删除节点非常简单。

我们从不需要因为操作原因重新启动集群(只是为了升级)。

-高度可靠和稳定。

缺点:

-这引入了对Helix的依赖。(这很好,因为Helix本身非常稳定,我们可以将一个Helix集群用于多个MirrorMaker集群。)

uReplicator概述

Kafka MirrorMaker产生不活跃的问题时,消费者试图重新平衡。

uReplicator的各个组件以不同的方式实现可靠性和稳定性:

1.Helix uReplicator控制器实际上是一个节点集群,它有几个职责:

  • 将主题分区分配给每个工作进程
  • 处理添加/删除主题/分区
  • 处理uReplicator worker的添加/删除
  • 检测节点故障并重新分配这些特定的主题分区

控制器使用Zookeeper来完成所有这些任务。它还公开了一个简单的REST API,以便添加/删除/修改要镜像的主题。

2.一个uReplicator工人,类似于Kafka镜像特性中的工作进程,将一组特定的主题分区从源集群复制到目标集群。而不是一个rebalance进程,uReplicator控制器决定uReplicator的分配。此外,我们使用一个简化版本DynamicKafkaConsumer,而不是使用Kafka的高级消费者。

3.一个螺旋代理对于每个uReplicator worker,无论何时有更改(添加/删除主题分区)都会得到通知。然后,它通知DynamicKafkaConsumer添加/删除主题分区。

4.一个DynamicKafkaConsumer实例,它是高级使用者的一个修改,存在于每个uReplicator工作者上。它删除了重新平衡部分,并添加了一种动态添加/删除主题分区的机制。

例如,假设我们想向现有的uReplicator集群添加一个新主题。事件流程如下:

  • Kafka admin使用以下命令将新主题添加到控制器:

image05

  • uReplicator控制器计算出分区的数量testTopic并将主题分区映射到活跃的工作者。然后更新Zookeeper元数据以反映这个映射。
  • 每个相应的Helix代理都会收到一个回调,通知添加了这些主题分区。方法调用addFetcherForPartitions的函数DynamicKafkaConsumer
  • DynamicKafkaConsumer随后,注册这些新分区,找到相应的领导代理,并将它们添加到获取线程以启动数据镜像。

有关实施的详情,请参阅uReplicator设计维基

对整体稳定性的影响

自从8个月前uReplicator首次在优步投入生产以来,我们还没有看到它出现过任何问题(相比之下,在它实施之前几乎每周都会出现某种程度的停机)。下图描述了在生产环境中向镜像工具白名单中添加新主题的场景。第一个图显示了每个uReplicator工作者拥有的总的主题分区。每添加一个新主题,这个计数就会增加。

img3

第二个图显示了流向目标集群的相应的uReplicator流量。没有一段时间的不活动或负载峰值,与旧的Kafka MirrorMaker:

uReplicator在发生变化时保持稳定的运行。

总的来说,uReplicator的好处包括:

  • 稳定重新平衡现在只在启动和添加或删除节点时发生。此外,它只影响主题分区的一个子集,而不是像以前那样导致完全不活动。
  • 简单的可伸缩性:现在向现有集群中添加新节点要简单得多。由于分区分配现在是静态的,我们可以智能地将分区的一个子集移动到新节点。其他主题分区不受影响。
  • 更容易操作: Uber新镜像工具支持动态白名单。现在我们在添加/删除/扩展Kafka主题时不需要重新启动集群。
  • 零数据丢失: uReplicator保证零数据丢失,因为它只在数据持久化到目标集群之后才提交检查点。

自成立以来,uReplicator一直是流媒体平台团队的一个有价值的补充,该团队的使命是通过消息传递和发布-订阅模型将Uber工程生态系统的不同部分连接在一起。使用卡夫卡).作为这一使命的一部分,我们正在构建一个新的分析平台,用于在流数据之上计算业务指标。听起来有趣吗?看到我们的实时数据基础设施开放Uber招聘页面如果你有兴趣参与这个故事的下一章。

Chinmay Soman是公司核心基础设施组的流媒体平台软件工程师超级工程并与流媒体平台工程师宁元池、傅翔和徐宏亮共同撰写了这篇文章。

图片来源:纳米比亚埃托沙国家公园Conor Myhrvold拍摄的斑马水坑反射。

编者按:2016年9月30日:Uber的uReplicator工具以前被称为uMirrorMaker。——康纳·梅尔沃德

评论