Apache Kafka是否可以并且应该替换数据库？我可以并且应该在Kafka中存储数据多长时间？如何在Kafka中查询和处理数据？这些是越来越多的常见问题。诸如“是”或“取决于”的简短答案对您来说还不够好？这篇博客文章解释了数据库和各种功能（如存储，查询和事务）背后的思想，以评估何时和何时不适合使用Kafka。

Apache Kafka和Confluent的共同创始人Jay Kreps在2017年已经解释了为什么“ 可以在Apache Kafka中存储数据 ”。但是，在过去三年中，许多事情已经得到改善，并且增加了新的组件和功能。此2020更新从数据库角度涵盖了Kafka的核心概念。

它包括Kafka本地附加组件，例如用于长期经济高效存储的分层存储，以及作为事件流数据库的ksqlDB。探索Kafka与其他数据库之间的关系和权衡以补充彼此，而不是考虑替换。该讨论包括基于拉和推的双向集成的不同选项。

什么是数据库？甲骨文？NoSQL？Hadoop？

让我们从一个很高的角度考虑一下“数据库”一词。根据维基百科，

“数据库是有组织的数据集合，通常从计算机系统以电子方式存储和访问。

数据库管理系统（DBMS）是与最终用户，应用程序以及数据库本身进行交互以捕获和分析数据的软件。DBMS软件还包含为管理数据库而提供的核心功能。数据库，DBMS和关联的应用程序的总和可以称为“数据库系统”。通常，术语“数据库”还用于宽松地指代任何DBMS，数据库系统或与数据库关联的应用程序。

计算机科学家可以根据他们支持的数据库模型对数据库管理系统进行分类。关系数据库在1980年代占主导地位。这些模型数据是一系列表中的行和列，并且绝大多数使用SQL来编写和查询数据。在2000年代，非关系数据库开始流行，被称为NoSQL，因为它们使用不同的查询语言。”

基于此定义，我们知道市场上有许多数据库。甲骨文 MySQL的、Postgres、Hadoop、MongoDB、Elasticsearch、AWS S3、InfluxDB、kafka

kafka？确实是的。让我们详细探讨一下...

存储，交易，处理和查询数据

一个数据库基础设施用于存储，查询和数据的处理，往往与具体的业务处理有关并提供持久性保证。

从市场上所有NoSQL和大数据产品中我们不仅应该知道一个数据库。对于每个用例，您（应该）选择正确的数据库。这取决于您的要求。存储数据多长时间？数据应具有什么结构？您需要复杂的查询还是仅通过键和值检索数据？是否需要ACID交易，一次准确的语义，或者至少一次保证交付“公正”？

在决定是否需要关系数据库（如MySQL或Postgres），大数据批处理平台（如Hadoop），文档存储（如MongoDB），键值存储（如RocksDB），时间序列数据库之前，必须回答这些问题以及更多的问题。例如InfluxDB，内存缓存（例如Memcached/Redis）或其他东西。

每个数据库都有不同的特征。因此，当您问自己是否可以用Kafka替换数据库时，您在谈论哪个数据库以及什么要求？

什么是Apache Kafka？

显然，了解什么是Kafka以确定Kafka是否可以替换您的数据库也很重要。否则，真的很难进行此评估…:-)

Kafka是一个事件流平台=>消息传递！流处理！数据库！

首先，Kafka不仅仅是一个将数据从A发送到B 的发布/订阅消息系统。这是一些不知道的人通常会在认为Kafka是下一个IBM MQ或RabbitMQ时回答此问题的方法。不。Kafka不是消息系统。

Kafka是一个事件流平台。来自各个行业的公司展示了数百个用例，它们成功地使用了Kafka，而不仅仅是消息传递。

Apache Kafka成为许多不同用例的事实标准的主要原因之一是它结合了四个强大的概念：

• 发布和订阅事件流，类似于消息队列或企业消息传递系统。
• 存储在容错存储事件流，只要你想要的（小时，天，月，永远）。
• 发生时实时处理事件流。
• 集成不同的源和接收器（无论是实时，批处理还是请求响应）。

解耦，可扩展，高可用性的流微服务

通过将这四个支柱构建到一个分布式事件流平台中，您可以以可靠，可扩展且容错的方式分离各种应用程序（即生产者和使用者）。

如您所见，存储是Kafka的关键原则之一。因此，根据您的要求和定义，Kafka可以用作数据库。

“ Kafka Core”是具有ACID保证的数据库吗？

TL; DR：Kafka是一个数据库，并提供ACID保证。但是，它的工作方式不同于其他数据库。Kafka也不替换其他数据库。而是，它是工具集中的补充工具。

Kafka的客户端

在消息传递系统中，客户端API提供给生产者和使用者以发送和阅读消息。所有其他逻辑都是使用编程或其他框架实现的。

在数据库中，客户端API提供了一种查询语言来创建数据结构，并使客户端能够存储和检索数据。所有其他逻辑都是使用编程或其他框架来实现的。

在事件流平台中，客户端API用于发送和使用数据，就像在消息传递系统中一样。但是，与消息传递和数据库相反，客户端API提供了更多功能。

可以使用Kafka API构建独立，可扩展，可靠的组件应用程序。因此，Kafka客户端应用程序是一种分布式系统，可以查询，处理和存储连续的数据流。无需其他附加框架即可构建许多应用程序。

Kafka生态系统-Kafka Streams、ksqlDB、Spring Kafka、SparkStreaming、Flink以及更多...

Kafka生态系统提供了各种组件来实现应用程序。

Kafka本身包括Java和Scala客户端API （用于通过Java处理流的Kafka Streams，以及无需编码即可与不同的源和接收器集成的Kafka Connect）。

存在许多其他的Kafka本机客户端API和框架。这里有些例子：

• librdkafka：Apache Kafka协议的C库实现，提供了Producer，Consumer和Admin客户端。它的设计考虑了消息传递的可靠性和高性能。对于生产者来说，目前的数字超过了每秒一百万毫秒，对于消费者来说，则超过了三百万毫秒。除C库外，它通常用作包装器，以提供来自其他编程语言（例如C ++，Golang，Python和JavaScript）的Kafka客户端。
• REST代理：为Kafka集群提供RESTful接口。无需使用本机Kafka协议或客户端，即可轻松生成和使用消息，查看集群状态以及执行管理操作。
• ksqlDB：Apache Kafka的事件流数据库，使您能够利用对关系数据库的熟悉程度来构建事件流应用程序。
• Kafka的Spring：将Spring的核心概念应用于基于Kafka的消息传递和流解决方案的开发。它提供了一个“模板”作为发送消息的高级抽象。包括对Kafka Streams的一流支持。其他Spring框架（例如Spring Cloud Stream和Spring Cloud Data Flow）也提供了对Kafka事件流的本地支持。
• Faust：一个用于在Python中构建流应用程序的库，类似于原始的Kafka Streams库（但功能有限且较不成熟）。
• TensorFlow I / O + Kafka插件：TensorFlow的本机集成，用于流机器学习（即直接使用Kafka的模型进行模型训练和模型评分，而不是使用另一个数据湖）。
• 还有大数据计算框架的支持，比如spark和flink

对于讨论可能替换数据库的问题，Kafka客户端的重要性至关重要，因为Kafka应用程序可以是无状态的，也可以是有状态的。后者在应用程序中保持状态，而不是使用外部数据库。下面的存储部分包含有关客户端应用程序如何长期存储数据和高可用性的更多详细信息。

有了这个，您就会知道Kafka拥有强大的服务器和客户端。当评估Kafka与其他消息传递解决方案或存储系统时，许多人并没有意识到这一点。

借助此功能，再加上利用Kafka的底层存储在生产者和消费者之间进行真正的解耦的能力，为什么Apache Kafka成为了微服务架构的事实上的标准–不仅取代了其他传统的中间件，而且构建了使用域驱动设计（DDD）的客户端应用程序用于解耦的应用程序。

同样，对于围绕Kafka作为数据库的讨论来说，为什么这很重要：对于您创建的每个新微服务，您都应该问自己：微服务中是否真的需要“真实数据库”后端？在开发，测试，运营，监控方面，它具有所有复杂性和成本吗？

当然，答案通常是肯定的。但是，我看到越来越多的应用程序更好，更轻松地将状态直接保存在Kafka应用程序中，或两者兼而有之。

存储-您可以在Kafka中存储多长时间？什么是后台数据库？

简短的答案：可以根据需要将数据存储在Kafka中。Kafka甚至提供了使用-1保留时间的选项。这意味着“永远”。

更长的答案要复杂得多。您需要考虑Kafka成本和可伸缩性。您应该使用HDD还是SDD？甚至是基于Flash的技术？Pure Storage编写了一个很好的示例，利用闪存以三个生产者和3倍复制速度每秒写入500万条消息。这取决于您需要存储多少数据以及访问数据以及从故障中恢复所需的速度。

到目前为止，我们只是在谈论最常用的Kafka功能：基于日志的存储，其中包含保留时间和连接到代理的磁盘。但是，您还需要考虑 Kafka的其他功能，以全面讨论Kafka基础架构中的长期存储：压缩主题，分层存储和客户端存储。所有这些功能都可以迅速改变您对Kafka，其用例和体系结构的看法。

压缩主题-日志压缩和“事件更新”

日志压缩可确保Kafka将始终为单个主题分区的数据日志中的每个消息密钥至少保留最后一个已知值。它解决了用例和方案，例如在应用程序崩溃后恢复状态，系统故障或在操作维护期间重新启动应用程序后重新加载缓存。

显然，最大的折衷是日志压缩不能保留所有事件和更改的全部顺序。为此，您需要使用具有特定保留时间的常规Kafka主题。

或者，您可以使用-1永久存储所有数据。这里最大的折衷是磁盘的高成本以及更复杂的操作和可伸缩性。

分层存储-Apache Kafka中的长期存储

Kafka的分层存储可降低成本（由于对象存储便宜），可扩展性（由于存储和处理之间的分离）和简化操作（由于简化且重新平衡快得多）。

以下是一些将完整日志长期存储在Kafka中的示例（而不是利用压缩的主题）：

• 新消费者，例如完整的新微服务或现有应用程序的替换。
• 错误处理，例如在发生错误的情况下重新处理数据以修复错误并再次处理事件。
• 合规/法规处理：出于法律原因对已处理的数据进行重新处理；可能是非常古老的数据。
• 查询和分析现有事件：不需要另一个数据存储/数据湖；ksqlDB（位置第一，但知道各种限制）；Kafka原生分析工具（例如具有Kafka连接器的Rockset和对Tableau等的完整SQL支持）
• 机器学习和模型训练：不同的一个机器学习框架和不同的超参数或不同的机器学习框架来进行模型训练的事件

客户端数据库-有状态的Kafka客户端应用程序和微服务

如上所述，Kafka不仅仅是服务器端。您可以在Kafka客户端上构建高度可用且可扩展的实时应用程序。

适用于有状态Kafka应用程序的RocksDB

通常，这些Kafka客户端应用程序（必须）跟踪状态。Kafka Streams和ksqlDB 为此使用了

RocksDB（您也可以只使用内存中的存储或用另一个存储替换RocksDB；不过，我在现实世界中从未见过后者的选择）。RocksDB是用于运行关键任务工作负载的键值存储。它针对快速，低延迟的存储进行了优化。

在Kafka Streams应用程序中，解决了抽象访问本地稳定存储而不是使用外部数据库的问题。 每次处理事件时，使用外部数据库都需要进行外部通信/ RPC。事件流体系结构中的明确反模式。

RocksDB允许软件工程师将精力集中在系统其他区域的设计和实现上，而不必担心依靠RocksDB来访问稳定的存储。它已在多家硅谷公司进行了实战测试，并在许多著名数据库（例如Apache Cassandra，CockroachDB或MySQL（MyRocks））的框架下使用。RocksDB正在“吃数据库”中详细介绍了历史和用例。

ksqlDB作为事件流数据库

Kafka Streams和ksqlDB-Kafka的事件流数据库-允许构建有状态的流应用程序；包括强大的概念，如联接，滑动窗口和状态的交互式查询。以下示例显示了如何构建有状态支付应用程序：

客户端应用程序将数据保留在其自己的应用程序中，以进行实时联接和其他数据关联。它结合了STREAM（不可更改的事件）和TABLE（如关系数据库中的更新信息）的概念。

请记住，此应用程序具有高度可扩展性。它通常不仅仅是一个实例。相反，它是客户端实例的分布式集群，用于提供高可用性和并行化数据处理。即使出现故障（VM，容器，磁盘，网络），整个系统也不会丢失数据并继续24/7运行。

如您所见，必须回答许多问题，并且必须考虑各种功能才能正确决定在Kafka中存储数据的时间和位置。

在Kafka中长期存储数据的一个很好的理由是能够在以后的某个时间点使用该数据进行处理，关联或分析。

查询和处理-您可以使用和分析Kafka存储吗？

Kafka提供了不同的选项来使用和查询数据。

Kafka中的查询可以是PUSH（即，连续处理和转发事件）或PULL（即，客户端 从您喜欢的SQL数据库中请求类似您所知道的事件）。

在以下各节中，我将向您显示不同的选项。

消费者应用程序拉动事件

Kafka客户从代理那里获取数据。这使生产者和消费者脱钩，并使基础架构具有可扩展性和可靠性。

Kafka本身包括一个Java和Scala客户端来使用数据。但是，Kafka客户端几乎可用于任何其他编程语言，包括广泛的语言（如C，C ++，Python，JavaScript或Golang）以及奇异的语言（如RUST）。此外，Confluent提供了REST代理。这允许通过支持该标准的任何语言或工具通过HTTP（S）使用事件。

应用程序具有不同的选项来使用来自Kafka代理的事件：

• 持续消耗最新事件（实时或批量）。
• 只是特定的时间范围或分区。
• 所有数据都从一开始。

流处理应用程序/微服务拉和推事件

Kafka Streams和ksqlDB从代理中提取事件，处理数据，然后将结果推回到另一个Kafka主题。这些查询正在连续运行。强大的查询是可能的；包括JOIN和状态聚合。

这些功能用于大规模流式传输ETL和实时分析。它们还可以用于构建关键任务业务应用程序和微服务。

“ 交互式查询 ”功能允许从客户端应用程序的状态存储中查询值（通常在后台使用RocksDB实现）。这些事件是通过诸如REST / HTTP之类的技术来提取的，或者是通过诸如WebSockets代理之类的中介来推送的。Kafka Streams提供了核心功能。交互式查询界面必须首先由您自己实现。优点：灵活性。缺点：未提供现成的。

Kafka作为查询引擎及其局限性

上面描述的Kafka查询功能都没有您所钟爱的Oracle数据库或Elasticsearch强大！

因此，Kafka将不会替换其他数据库。它是互补的。Kafka的主要思想是连续处理流数据。带有查询存储数据的附加选项。

Kafka足以作为某些用例的数据库。但是，Kafka的查询功能不足以用于其他一些用例。

然后，Kafka通常被用作中央流平台，在该平台上，一个或多个数据库（和其他应用程序）利用自己的技术构建自己的物化实时视图。

该原理通常称为“ 将数据库由内向外 ”。这种设计模式允许针对正确的问题使用正确的数据库。在以下情况下使用Kafka：

• 作为可扩展的事件流平台，用于数据集成。
• 用于不同生产者和消费者之间的脱钩。
• 处理背压。
• 连续处理和关联传入事件。
• 用于在其他数据库中创建和更新实例化视图。
• 允许直接向Kafka进行交互式查询（取决于用例和使用的技术）。

卡夫卡精确语义（EOS）

Kafka是一个分布式系统，可提供各种保证交付。不同的配置选项允许至少一次，最多一次和完全一次语义（EOS）。

人们仅将一次语义与数据库事务进行比较。这个想法是相似的：您需要保证每个产生的信息被消耗和处理一次。许多人争辩说，这不可能用Kafka来实现，因为单个，不可分割的操作可能会在分布式系统中失败！在卡夫卡世界中，许多人都提到了著名的Hacker News讨论“ 您不能立即发送 ”和类似的Twitter对话。

在2017年中，发生了“令人难以置信的事情”：Apache Kafka 0.11添加了对Exactly-Once Semantics（EOS）的支持。注意，它没有故意包括术语“交易”。因为这不是交易。因为在分布式系统中不可能进行交易。但是，结果是相同的：每个使用者只消费一次所产生的消息。“ 可能只有一次语义：这是Kafka做到的方式 ”，涵盖了实现的细节。简而言之，EOS包括三个功能：

• 幂等性：每个分区的语义顺序恰好一次。
• 事务：原子写入多个分区。
• Apache Kafka中的流处理一次。

EOS的工作原理与数据库中的事务不同，但最终提供相同的结果。可以通过配置将其打开。顺便说一下，与至少一次语义相比，性能损失并不大-通常，端到端处理的速度要慢10％到25％之间。

Kafka生态系统中的完全一次语义（Kafka Connect，Kafka Streams，ksqlDB，非Java客户端）

EOS不仅是Kafka核心以及相关的Java / Scala客户端的一部分。大多数Kafka组件均支持一次交付保证，包括：

• 一些（但不是全部）Kafka Connect连接器。例如，AWS S3和Elasticsearch。
• Kafka Streams和ksqlDB可以为流式ETL或在业务应用程序中仅处理一次数据。
• 非Java客户端。librdkafka是使用各种编程语言的许多Kafka客户端的核心基础，最近又增加了对EOS的支持。

Kafka会取代您现有的数据库吗？

一般来说，不！但是您应该始终问自己：除了Kafka之外，您还需要其他数据存储吗？有时是，有时不是。我们讨论了数据库的特征以及何时使用Kafka就足够了。

每个数据库都有特定的功能，保证和查询选项。将MongoDB用作文档存储，将Elasticsearch用于文本搜索，将Oracle或MySQL用于传统的关系用例，将Hadoop用作大数据湖，以运行地图/归约作业以生成报告。

希望这篇博客文章可以帮助您为下一个项目做出正确的决定。

但是，请保留：问题并不总是“ Kafka vs数据库XYZ”。通常，Kafka和数据库是互补的！让我们在以下部分中对此进行讨论...

Kafka Connect-Kafka与其他数据库之间的集成

Apache Kafka包括Kafka Connect：一种框架，用于将Kafka与外部系统（例如数据库，键值存储，搜索索引和文件系统）连接。使用Kafka Connect，您可以将现有的连接器实现用于通用数据源和接收器，以将数据移入和移出Kafka：

这包括许多连接各种数据库的连接器。从源系统查询数据，一个事件可以被拉出（例如，与JDBC连接器），或推 经由可能有-数据捕获（CDC，例如，与Debezium连接器）。Kafka Connect还可以写入任何接收器数据存储，包括各种关系，NoSQL和大数据基础架构，例如Oracle，MongoDB，Hadoop HDFS或AWS S3。

Apache Kafka是具有ACID保证的数据库，但与其他数据库互补！

Apache Kafka是一个数据库。它提供ACID保证，并且已在数百家公司中用于关键任务部署。但是，在许多情况下， Kafka不能与其他数据库竞争。Kafka是一个事件流平台，用于实时大规模地进行消息传递，存储，处理和集成，停机时间为零，数据丢失为零。

具有这些特性，Kafka通常被用作中央流集成层。可以通过其他数据库针对其特定用例（例如实时，时间序列分析，以近乎实时的方式提取到文本搜索基础结构中或在数据湖中长期存储）来构建实例化视图。

总而言之，如果您被问及Kafka是否可以替换数据库，那么以下是不同的答案：

• Kafka可以提供ACID保证，以持久和高可用性的方式永久存储 数据。
• Kafka提供了用于查询历史数据的 不同选项。
• 诸如ksqlDB或Tiered Storage之类的Kafka本机附加组件使Kafka在数据处理和基于事件的长期存储方面比以往任何时候都更加强大。
• 可以利用Kafka客户端（微服务，业务应用程序）构建有状态的应用程序，而无需其他外部数据库。
• 不能替代现有数据库，例如MySQL，MongoDB，Elasticsearch或Hadoop。
• 其他数据库和Kafka相辅相成 ; 必须为问题选择正确的解决方案；通常，从基于事件的中央基础结构中实时创建和更新专用的物化视图。
• 不同的选项可用于在Kafka和数据库之间基于双向拉和推的集成，以相互补充。