日志就像是分布式文件系统中的一个文件，在这个系统里，日志被复制到多台机器上，被持久化到磁盘，并支持高吞吐的线性读取和写入。当然，日志也像是一个消息系统，支持高吞吐的并发写入和低延迟的多消费者。
从实现方面来看，日志非常适合用来作为数据存储。Kafka本身就是使用复制日志作为存储，所以你也不例外！在Kafka内部，偏移量被保存在一个压缩主题上，Kafka Streams API使用压缩主题来记录应用程序的处理状态。
当然，把Kafka作为存储系统来用并不会给你带来新的门槛。存储系统包揽了正确性、运行时间和数据完整性等方面的工作。如果一个系统成为数据的标准来源，人们就会对它的正确性和运维标准提出很高的要求。我们花了大量的精力在提升Kafka的正确性上，我们每天在数百台机器上运行数个小时的分布式测试以及数千个常规性的单元测试，但我们觉得还有很多事情要做。除了测试之外，我们还需要知道如何做好运维工作，以及了解系统的局限性。
有时候，人们也会问我，这是不是就意味着Kafka可以取代其他存储引擎。答案当然是否定的。
首先，数据库提供大量的查询，而Kafka并不打算在日志上增加随机访问的特性。Kafka保存数据可以被复制到其他数据库、缓存、流式处理器、搜索引擎、图存储引擎和数据胡（data lake）上，这些存储引擎都各自的优缺点，我们也无法做出一个可以打败其他所有引擎的系统。
如果说Kafka并不想取代这些系统，那它存在的意义是什么？你可以把数据中心看成是一个大型的数据库，Kafka是这个系统里的提交日志，而其他存储引擎则是索引或视图。Kafka是构建数据库的基础，至于查询方面的工作可以交给索引和视图。
Kafka Streams API提供了交互式的查询功能。基于Kafka Streams开发的应用就是一个Kafka消费者，只不过它们可以维护计算状态，而且这些状态可以直接保存到外部的存储系统，这种物化视图让Kafka具备了低延迟的查询能力。Kafka集群保存日志，Streams API保存物化视图并处理查询请求。后来我们引入了KSQL——Kafka的流式SQL引擎。有了KSQL，用户可以直接使用SQL语句从Kafka上获得物化视图。
我们不打算为Kafka提供查询API的另一个原因是因为我们有其他更重要的事情要做。我们希望流式处理成为主流的开发模式，让流式平台成为现代数字业务的中心系统。我们希望能够达成这个让人激动不已的目标，而不只是创建一种新的数据库系统。我们相信，在现代企业里，流式平台将会成为移动和处理数据的黑马。要实现这个目标，我们还有很多事情要做。
下面关于Kafka的文章您也可能喜欢，不妨参考下：
CentOS 7.2部署Elasticsearch+Kibana+Zookeeper+Kafka