Twitter 的 Kafka 迁移历程

2018-12-08    来源:raincent

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

Twitter 的实时性特点为 Twitter 的工程团队带来了独特而具有挑战性的问题。我们需要快速发布突发新闻,向用户提供相关广告,并解决很多其他实时性问题。Twitter 的 Pub/Sub 系统为 Twitter 团队提供了处理这些工作负载的基础设施。

Twitter 的 Messaging 团队过去几年一直在运行一个内部 Pub/Sub 系统,叫作 EventBus(建立在 Apache DistributedLog 之上),但我们最近决定转向 Apache Kafka,不仅针对已有的用例,还包括新增的用例。在这篇文章中,我们将介绍为什么我们选择采用 Kafka 作为 Twitter 的 Pub/Sub 系统,以及我们在迁移过程中遇到的各种挑战。

Kafka 是什么?

Apache Kafka 是一个开源的分布式流式处理平台,可以高吞吐和低延迟地传输数据。Kafka 最初是在 LinkedIn 诞生,并于 2011 年开源,从那时起开始被社区广泛采用,包括很多其他公司在内,使其成为业界首选的事实上的实时消息系统。

Kafka 的核心就是一个基于分布式提交日志构建的 Pub/Sub 系统,提供了很多非常好的特性,例如水平可伸缩性和容错性。从那以后,Kafka 已经从消息系统发展成为一个成熟的流式处理平台。

为什么要迁移?

你可能想知道为什么 Twitter 需要自己构建内部的消息传递系统。几年前,Twitter 也曾经使用过 Kafka(0.7 版本),但我们发现在某些方面它无法满足我们的要求——主要是在读取期间进行的 I/O 操作数量,而且缺乏持久化特性和复制机制。然而,随着时间推移,硬件和 Kafka 都已经走过了漫长的道路,这些问题现在都已经得到了解决。硬件的改进已经使 SSD 的价格足够便宜,这解决了我们之前在 HDD 上看到的随机读取的 I/O 问题,而且服务器 NIC 具有更多的带宽,就没有那么必要分离服务和存储层(EventBus 会这么做)。此外,较新版本的 Kafka 现在支持数据复制,提供了我们想要的持久性保证。

将 Twitter 的所有 Pub/Sub 用例迁移到一个全新的系统将是一个非常耗费成本的过程。所以,迁移到 Kafka 的决定绝对不是自然发生的,而是经过精心策划的,并且是由数据驱动的。迁移到 Kafka 的动机可归纳为两个方面:成本和社区。

成本

在向整个公司宣布迁移到 Kafka 之前,我们的团队花了几个月时间评估了 Kafka 在与 EventBus 类似的工作负载下的表现——持久写入、尾部读取、追赶读取和高扇出读取,以及一些灰色故障情况(例如减慢集群中的特定 Kafka 代理)。

在性能方面,我们看到 Kafka 的延迟显著降低,无论是根据消息创建时间戳来衡量吞吐量,还是根据消费者读取消息时间戳来衡量吞吐量。

 

 

不同吞吐量下 EventBus 和 Kafka 之间的 P99 延迟比较

这可以归因于几个因素,可能包括但不限于:

在 EventBus 中,服务层和存储层是分离的,这引入了额外的跳转(网络时间和通过 JVM 代理层的时间),而在 Kafka 中只有一个进程处理存储和请求服务(参见下图)。

EventBus 在通过 fsync() 调用进行写入时会阻塞,而 Kafka 在后台依赖操作系统进行 fsync()。

Kafka 使用零拷贝。

 

 

EventBus(左)和 Kafka(右)之间的架构比较

从成本的角度来看,EventBus 需要服务层(针对高网络吞吐量进行了优化)和存储层(针对磁盘进行了优化)的硬件,而 Kafka 使用单台主机就可以提供这两者。因此,EventBus 需要更多的机器来提供与 Kafka 相同的工作负载。对于单个消费者,我们节省了 68%的资源,对于拥有多个消费者的案例,我们节省了 75%的资源。但有一个问题是,对于严重依赖带宽的工作负载(非常高的扇出读取),EventBus 理论上可能更有效,因为我们可以独立地扩展服务层。但是,我们在实践中发现,我们的扇出没有那么极端,分离服务层是不值得的。

社区

如上所述,Kafka 已经得到了广泛采用。我们可以利用数百名开发人员为 Kafka 项目所做出的贡献,他们修复错误、改进和添加新功能,这比 EventBus/DistributedLog 的八名工程师所做的要好得多。此外,Twitter 内部用户在 EventBus 中想要的很多功能已经在 Kafka 中提供了,例如流式处理库、至少一次 HDFS 管道,以及恰好一次性处理。

此外,当我们遇到客户端或服务器问题时,我们可以通过搜索网络轻松快速地找到解决方案,因为很可能其他人之前也遇到了同样的问题。另外,相比不太受欢迎的项目,受欢迎的项目的文档通常更加详尽。

采用 Kafka 等热门项目,并向这些项目回馈我们的贡献,这样做的另一个重要原因是为了招聘。一方面,通过向 Kafka 社区回馈贡献,可以让人们了解 Twitter 的工程。另一方面,由于新工程师已经熟悉了这些技术,因此为团队招聘工程师要容易得多。

挑战

尽管迁移到 Kafka 看起来非常棒,但过程并不是一帆风顺的。我们在这个过程中遇到了很多技术挑战和适应性挑战。

从技术角度来看,我们遇到的一些挑战包括配置调优和 Kafka Streams 库。与很多分布式系统一样,为了支持 Twitter 的实时性用例,需要对大量配置进行微调。在运行 Kafka Streams 时,我们发现 Kafka Streams 库中的元数据大小存在一些问题,这些问题是由于老版本的客户端在关闭后仍然保留元数据造成的。

另一方面,Kafka 与 EventBus 存在架构差异,我们不得不以不同的方式配置系统和调试问题。例如,如何在 EventBus(仲裁写入)和 Kafka(主从复制)中完成复制。写请求在 EventBus 中并行发送,而 Kafka 要求从节点仅在主节点收到写请求后才复制写请求。此外,两个系统之间的持久性模型是非常不同的—— EventBus 仅在数据持久化到磁盘时确认写入成功,而 Kafka 复制本身就具有持久性保证,并在将数据持久存储在磁盘上之前确认写入请求。我们不得不重新考虑我们对数据持久性的定义:数据的所有三个副本同时失败是不太可能的,因此没有必要在每个副本中同步数据来提供我们想要的持久性保证。

前行

在接下来的几个月里,我们计划将我们的用户从 EventBus 迁移到 Kafka,这将有助于降低运营 Twitter Pub/Sub 系统的成本,并使我们的用户能够使用 Kafka 提供的其他功能。我们将持续关注生态系统中的不同消息传递和流式处理系统,并确保我们的团队为我们的用户和 Twitter 做出正确的决策,即使这些决策很艰难。

英文原文:

https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story.html

标签: ssd 服务器 搜索 网络

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:谷歌开源 TF-Ranking:一个可扩展的排名学习 TensorFlow 库

下一篇:公民数据科学家的时代已经到来