写点什么

Kafka 权威指南(三):Kafka 起源故事

  • 2020-03-31
  • 本文字数:1950 字

    阅读完需:约 6 分钟

Kafka权威指南(三):Kafka起源故事

编者按:本文节选自图灵程序设计丛书 《Kafka 权威指南》一书中的部分章节。

起源故事

Kafka 是为了解决 LinkedIn 数据管道问题应运而生的。它的设计目的是提供一个高性能的消息系统,可以处理多种数据类型,并能够实时提供纯净且结构化的用户活动数据和系统度量指标。


数据为我们所做的每一件事提供了动力。

——Jeff Weiner,LinkedIn CEO

LinkedIn 的问题

本章开头提到过,LinkedIn 有一个数据收集系统和应用程序指标,它使用自定义的收集器和一些开源工具来保存和展示内部数据。除了跟踪 CPU 使用率和应用性能这些一般性指标外,LinkedIn 还有一个比较复杂的用户请求跟踪功能。它使用了监控系统,可以跟踪单个用户的请求是如何在内部应用间传播的。不过监控系统存在很多不足。它使用的是轮询拉取度量指标的方式,指标之间的时间间隔较长,而且没有自助服务能力。它使用起来不太方便,很多简单的任务需要人工介入才能完成,而且一致性较差,同一个度量指标的名字在不同系统里的叫法不一样。


与此同时,我们还创建了另一个用于收集用户活动信息的系统。这是一个 HTTP 服务,前端的服务器会定期连接进来,在上面发布一些消息(XML 格式)。这些消息文件被转移到线下进行解析和校对。同样,这个系统也存在很多不足。XML 文件的格式无法保持一致,而且解析 XML 文件非常耗费计算资源。要想更改所创建的活动类型,需要在前端应用和离线处理程序之间做大量的协调工作。即使是这样,在更改数据结构时,仍然经常出现系统崩溃现象。而且批处理时间以小时计算,无法用它完成实时的任务。


监控和用户活动跟踪无法使用同一个后端服务。监控服务太过笨重,数据格式不适用于活动跟踪,而且无法在活动跟踪中使用轮询拉取模型。另一方面,把跟踪服务用在度量指标上也过于脆弱,批处理模型不适用于实时的监控和告警。不过,好在数据间存在很多共性,信息(比如特定类型的用户活动对应用程序性能的影响)之间的关联度还是很高的。特定类型用户活动数量的下降说明相关应用程序存在问题,不过批处理的长时间延迟意味着无法对这类问题作出及时的反馈。


最开始,我们调研了一些现成的开源解决方案,希望能够找到一个系统,可以实时访问数据,并通过横向扩展来处理大量的消息。我们使用 ActiveMQ 创建了一个原型系统,但它当时还无法满足横向扩展的需求。LinkedIn 不得不使用这种脆弱的解决方案,虽然 ActiveMQ 有很多缺陷会导致 broker 暂停服务。客户端的连接因此被阻塞,处理用户请求的能力也受到影响。于是我们最后决定构建自己的基础设施。

Kafka 的诞生

LinkedIn 的开发团队由 Jay Kreps 领导。Jay Kreps 是 LinkedIn 的首席工程师,之前负责分布式键值存储系统 Voldemort 的开发。初建团队成员还包括 Neha Narkhede,不久之后, Jun Rao 也加入了进来。他们一起着手创建一个消息系统,可以同时满足上述的两种需求,并且可以在未来进行横向扩展。他们的主要目标如下:


  • 使用推送和拉取模型解耦生产者和消费者;

  • 为消息传递系统中的消息提供数据持久化,以便支持多个消费者;

  • 通过系统优化实现高吞吐量;

  • 系统可以随着数据流的增长进行横向扩展。


最后我们看到的这个发布与订阅消息系统具有典型的消息系统接口,但从存储层来看,它更像是一个日志聚合系统。Kafka 使用 Avro 作为消息序列化框架,每天高效地处理数十亿级别的度量指标和用户活动跟踪信息。LinkedIn 已经拥有超过万亿级别的消息使用量(截止到 2015 年 8 月),而且每天仍然需要处理超过千万亿字节的数据。

走向开源

2010 年底,Kafka 作为开源项目在 GitHub 上发布。2011 年 7 月,因为倍受开源社区的关注,它成为 Apache 软件基金会的孵化器项目。2012 年 10 月,Kafka 从孵化器项目毕业。从那时起,来自 LinkedIn 内部的开发团队一直为 Kafka 提供大力支持,而且吸引了大批来自 LinkedIn 外部的贡献者和参与者。现在,Kafka 被很多组织用在一些大型的数据管道上。2014 年秋天,Jay Kreps、Neha Narkhede 和 Jun Rao 离开 LinkedIn,创办了 Confluent。 Confluent 是一个致力于为企业开发提供支持、为 Kafka 提供培训的公司。这两家公司连同来自开源社区持续增长的贡献力量,一直在开发和维护 Kafka,让 Kafka 成为大数据管道的不二之选。

命名

关于 Kafka 的历史,人们经常会问到的一个问题就是,Kafka 这个名字是怎么想出来的,以及这个名字和这个项目之间有着怎样的联系。对于这个问题,Jay Kreps 解释如下:


我想既然 Kafka 是为了写数据而产生的,那么用作家的名字来命名会显得更有意义。我在大学时期上过很多文学课程,很喜欢 Franz Kafka。况且,对于开源项目来说,这个名字听起来很酷。因此,名字和应用本身基本没有太多联系。


图书简介https://www.ituring.com.cn/book/2067



相关阅读


Kafka权威指南(一):初识Kafka


Kafka权威指南(二):为什么选择Kafka


2020-03-31 10:002374

评论

发布
暂无评论
发现更多内容

架构实战营 模块三

听闻

193篇文章暴揍Flink,这个合集你需要关注一下

王知无

JavaScript new 关键词解析及原生实现 new

zhoulujun

JavaScript new

总结

杰语

阿里“宝妈级”之作,这份Spring Security应用到源码手册,全是精华

Java spring 程序员 架构 计算机

没有银弹

escray

学习 极客时间 如何落地业务建模 8月日更

让我们一起开发【菜谱系统】吧,滚雪球学 Python 第三轮项目计划

梦想橡皮擦

8月日更

MinIO存储服务客户端使用指南(三)

liuzhen007

8月日更

架构实战训练营模块五作业

NewBranSTONE

#架构实战营

架构实战0期毕业设计---电商秒杀系统

谢博琛

现代分布式架构设计原则-伸缩性

余先生

可伸缩 伸缩 弹性扩容

序列化单例模式的实现————readResolve 源码解读

4ye

Java 源码 后端 序列化 8月日更

雷从九天临,暗由赤地生 - 你的对手只有时间

王知无

架构课程第4次作业

听闻

Android SDK 版本属性

Changing Lin

8月日更

在所有Spark模块中,我愿称SparkSQL为最强!

王知无

Flink CDC我吃定了耶稣也留不住他!| Flink CDC线上问题小盘点

王知无

QDS05 Prometheus

耳东@Erdong

Prometheus 8月日更

浏览器数据库 IndexedDB(一) 概述

编程三昧

数据库 大前端 indexedDB 8月日更

instanceof运算符的实质:Java继承链与JavaScript原型链

zhoulujun

JavaScript 继承 原型链 instanceof 继承链

架构设计总结

鲲哥

二叉查找树的迭代遍历

泽睿

二叉树

消息队列架构设计

thewangzl

架构训练营毕业总结

Geek_e0c25c

架构实战营

蚂蚁金服+拼多多+抖音+天猫Java面经合集,金九银十Java开发校招社招福音!

编程菌

Java 编程 程序员 面试 计算机

Github首次开放,一天遭狂转 50w 次!大厂内部不外传的 100 万字 Java 面试手册!

编程菌

Java 编程 程序员 面试 计算机

JDK的泛型如何工作的

卢卡多多

Java泛型 8月日更

5000字阐述云原生消息中间件Apache Pulsar的核心特性和设计概览

王知无

select、poll、epoll之间的区别

一个大红包

8月日更

老外为了在MacBook上玩原神,让M1支持了所有iOS应用 | Github每周精彩分享第一期

Zhendong

GitHub

秒杀架构设计

鲲哥

Kafka权威指南(三):Kafka起源故事_架构_Neha Narkhede_InfoQ精选文章