Kafka 是如何建模数据的？

Kafka 是一个高度可扩展的消息系统，具有优秀的水平可扩展性和高吞吐率的特点，因而被许多公司所青睐并得到广泛的使用。本文首先介绍 Kafka 诞生的时代背景以及诞生之初的设计目标，随后回答 Kafka 作为一个消息系统是如何建模数据的，最后讲解 Kafka 作为一个软件系统的架构，为有志于深入了解的 Kafka 的同学做一个简单的框架梳理。

Kafka 诞生的时代背景与设计目标

大数据时代，为了分析数据背后的价值，组织所有服务和系统所产生的数据在权限允许的范围内对所有服务和系统都应该是可用的。从原始数据的收集到数据的使用，自底向上是一个金字塔形的结构，即底部以某种统一的方式采集数据，以统一的方式对数据建模，通过统一的方式对上层服务和应用提供访问和处理接口。

现实世界里，企业的每个应用程序都会产生数据，包括日志信息、监控指标、用户行为和请求响应等等。这些数据的产生源头不尽相同，可能散落在不同业务团队的逻辑代码当中。在传统的软件开发世界里，这些数据的持久化位置也不尽相同，日志文件可能存储在服务运行的机器的文件系统上，监控指标可能在监控系统拥有的数据库里，用户行为可能落到了数据仓库中，请求响应甚至没有被合理的持久化。

我们再从数据消费一端来观察这个过程，现在一个商业智能分析系统想要从不同业务的监控指标里聚合出统一的指标页面以供运营方快速决策应该采取什么行动来提升公司的盈利。最糟糕的情况莫过于该系统发现不同业务拥有不同的存放指标的方式，因此你要为接入每个系统的指标上报实现完全不同的逻辑，每来一个新的业务，就需要对接一个新的指标上报流程。对于一个新的分析系统来说，在它冷启动的时候，就要对接所有产生数据的业务方。这将成为所有开发人员的噩梦。

软件开发的一个重要技能就是观察出系统中存在的重复逻辑并抽出通用的模块以提升复用率和开发效率。注意到上面的数据对接流程涉及到数据的生产方和消费方，每对生产消费组合都要确定一个数据对接的方案。但是，数据的对接之所以会要求不同的方案，是因为数据的存储和模式是异构的。自然而然的，我们会想到定义一种统一的、足够通用以支持覆盖各种场景的数据交互模式，在数据的生产方和消费方之间引入一个中间层来解耦相互了解的负担。可以看到，原先有 N 个生产方和 M 个消费方，对接的要求次数是 N x M 次，而引入一个统一的数据交互中间层，消费方和生产方只需要分别对接这一中间层，对接的要求是 N + M 次。数据协同的复杂度被大大降低了。

这样的中间层解耦思路就是所谓的发布订阅系统。不同于数据的消费方与生产方