写点什么

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:002418

评论

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

中国DevOps平台市场,华为云再次位居领导者位置

华为云开发者联盟

云计算 华为云 企业号九月金秋榜

2022最新腾讯面经分享:Java 面试刷题 PDF(17 大专题 )

Java-fenn

Java 编程 程序员 面试 java面试

成为优秀程序员的8种方法

小小怪下士

Java 程序员 职业发展

老生常谈!数据库如何存储时间?你真的知道吗?

小小怪下士

Java 数据库 编程 程序员

元宇宙场景技术实践|虚拟直播间搭建教程

ZEGO即构

音视频开发 元宇宙 虚拟直播

2.69分钟完成BERT训练!新发CANN 5.0加持

华为云开发者联盟

人工智能 企业号九月金秋榜

开发者问第四期|统一扫码服务、机器学习服务等问题解答

HarmonyOS SDK

腾讯云,DevOps 领导者!

CODING DevOps

腾讯云 DevOps IDC CODING

Java 面试之技术框架

小小怪下士

Java spring 编程 程序员

前端面试哪些是必须要掌握的

loveX001

JavaScript 前端

EasyCV带你复现更好更快的自监督算法-FastConvMAE

阿里云大数据AI技术

深度学习 算法 计算机视觉

云图说丨DDoS防护解决方案:DDoS大流量攻击防得住

华为云开发者联盟

云计算 后端 华为云 企业号九月金秋榜

ESP32-C3入门教程 基础篇(八、NVS — 非易失性存储库的使用)

矜辰所致

ESP32-C3 9月月更 NVS

爆肝整理5000字!HTAP的关键技术有哪些?| StoneDB学术分享会#3

StoneDB

数据库 HTAP StoneDB 企业号九月金秋榜 9月月更

一个代码仓库(免费)与技术点 的故事

八点半的Bruce.D

GitHub Linux 网络服务 GitHub仓库

模块一

早安

极客时间架构训练营

为什么Java中有三种基础的类加载器?

小小怪下士

Java 编程 程序员 程序

Lua脚本在Redis事务中的应用实践

京东科技开发者

数据库 redis 事务 开发语言 Lua脚本

英特尔Wi-Fi 7速率提升5倍,为多应用场景带来改变

科技之家

数字化办公,企业OA软件技术该如何发力?

FinClip

【存疑】爬虫学习中decode问题

Sher10ck

存疑

2022年面试复盘大全500道:Redis+ZK+Nginx+数据库+分布式+微服务

小小怪下士

数据库 redis 分布式 微服务 java面试

长安链ca 容器部署(解决无法访问Mysql问题)

长安链

打破联接壁垒,华为云IoT到底强在哪?

华为云开发者联盟

云计算 后端 物联网 华为云 企业号九月金秋榜

基于云原生技术打造全球融合通信网关

阿里云视频云

云原生 网络 通信 通信云

智能电饭煲

OpenHarmony开发者

OpenHarmony

35岁程序员自荐:我所掌握的架构技术

小小怪下士

Java 程序员 中年危机

架构师成长之路——什么是架构师

小小怪下士

Java 程序员 架构 后端

高精度的“文件转换excel”背后藏着这些解题思路!

合合技术团队

人工智能 表格识别

这样Debug,排查问题效率大大提升...

程序知音

作为一个菜鸟前端开发,面了20+公司之后整理的面试题

beifeng1996

前端 React

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