阿帕奇卡夫卡可以而且应该取代数据库吗？我可以在卡夫卡存储数据多长时间？如何在卡夫卡查询和处理数据？这些是越来越多的常见问题。短的答案，如”是”或”它取决于”是不够好，你？那么这个读物是给你的！这个博客文章解释了数据库背后的想法和不同的功能，如存储，查询和事务，以评估Kafka何时是一个很好的适合，当它不是。
杰伊·克雷普斯，阿帕奇卡夫卡和康弗林的联合创始人，已经在2017年解释了为什么”可以存储数据在阿帕奇卡夫卡“。但是，许多方面已经改进，并且在过去三年中添加了新的组件和功能。本2020年更新从数据库的角度涵盖了卡夫卡的核心概念。
它包括 Kafka 本机加载项，如分层存储，用于长期经济高效的存储，ksqlDB 作为事件流数据库。卡夫卡和其他数据库之间的关系和权衡是相互补充的，而不是考虑更换。此讨论包括拉取和基于推送的双向集成的不同选项。
什么是数据库？甲骨文？Nosql？Hadoop？
让我们在非常高的层次上考虑术语”数据库”。根据维基百科，
数据库是有组织的数据收集，通常从计算机系统以电子方式存储和访问。
数据库管理系统 （DBMS） 是一种与最终用户、应用程序和数据库本身交互以捕获和分析数据的软件。DBMS 软件还包括为管理数据库提供的核心功能。数据库、DBMS 和相关应用程序的总和可称为”数据库系统”。通常，”数据库”一词也用于松散地引用任何 DBMS、数据库系统或与数据库关联的应用程序。
计算机科学家可以根据他们支持的数据库模型对数据库管理系统进行分类。关系数据库在20世纪80年代占据主导地位。这些模型数据作为一系列表中的行和列，绝大多数使用 SQL 写入和查询数据。在 2000 年代，非关系数据库变得流行，称为 NoSQL，因为它们使用不同的查询语言。
基于这个定义，我们知道市场上有许多数据库。甲骨文。Mysql。后。Hadoop。Mongodb。弹性搜索。AWS S3.InfluxDB。卡 夫 卡。
坚持。卡 夫 卡？是的，确实如此。让我们详细探讨一下…
存储、事务、处理和查询数据
数据库基础结构用于存储、查询和处理数据，通常具有特定的交付和持久性保证（也称为事务）。
不只是一个数据库，因为我们都应该从市场上的NoSQL和大数据产品中知道。对于每个用例，您（应该）选择正确的数据库。这取决于您的要求。存储数据多长时间？数据应该具有什么结构？您是否需要复杂的查询或仅通过键和值检索数据？需要 ACID 事务、一次语义或”仅”至少一次交付保证？
在决定是否需要像 MySQL 或 Postgres 这样的关系数据库、像 Hadoop 这样的大数据批处理平台、像 MongoDB 这样的文档存储、键值存储（如 RocksDB）、时间序列数据库（如 InfluxDB、像 Memcached 这样的内存缓存）之前，必须回答这些问题。
每个数据库都有不同的特点。因此，当您问自己是否可以用 Kafka 替换数据库时，您谈论的是哪个数据库以及您谈论什么要求？
什么是阿帕奇卡夫卡？
显然，了解卡夫卡是什么才能决定卡夫卡是否可以取代你的数据库也是至关重要的。否则，很难继续此评估…
卡夫卡是一个事件流平台@>消息！流处理！数据库！集成！
首先，Kafka 不仅仅是一个从A 到 B 发送数据的酒吧/子消息系统。当一些不知情的人认为卡夫卡是下一个IBM MQ或RabitMQ时，他们通常会回答这样的问题。不。卡夫卡不是一个消息系统。与其他消息传递解决方案的比较是 Apple 到橙色的比较（但何时选择 Kafka 或消息传递系统仍然有效）。
卡夫卡是一个事件流平台。来自不同行业的公司提供了数百个用例，他们成功地使用 Kafka 进行不仅仅是消息传送。只需查看卡夫卡峰会的所有会谈（包括免费幻灯片和录像）。
Apache Kafka 成为这么多不同用例的实际标准的主要原因之一是它结合了四个强大的概念：
- 发布和订阅事件流，类似于消息队列或企业消息系统。
- 根据需要将事件流存储在容错存储中（小时、天、月、永远）
分离、可扩展、高度可用的流式微服务
通过这四个支柱构建到一个分布式事件流平台中，您可以以可靠、可扩展和容错的方式分离各种应用程序（即生产者和使用者）。
正如您所看到的，存储是卡夫卡的关键原则之一。因此，根据您的要求和定义，Kafka 可用作数据库。
“卡夫卡核心”是一个数据库与ACID保证？
我不涉及关于”Kafka Core”（即Kafka经纪人及其概念（如分布式提交日志、复制、分区、保证排序等）如何适应数据库的ACID（原子性、一致性、隔离性、耐久性）事务属性的整个讨论。马丁·克莱普曼在2018年旧金山卡夫卡峰会上已经讨论过这个问题（”卡夫卡是数据库吗？ less technically by Tim Berglund
TL;DR：卡夫卡是一个数据库，并提供ACID保证。但是，它的工作方式与其他数据库不同。卡夫卡也没有取代其他数据库。相反，它是工具集中的补充工具。
卡夫卡的客户侧
在消息传递系统中，客户端 API 为生产者和使用者提供发送和读取消息。所有其他逻辑都使用低级编程或其他框架实现。
在数据库中，客户端 API 提供一种查询语言来创建数据结构，并使客户端能够存储和检索数据。所有其他逻辑都是使用低级编程或其他框架实现的。
在事件流式处理平台中，客户端 API 用于发送和使用数据，如在消息系统中。但是，与消息传递和数据库相反，客户端 API 提供了更多的功能。
借助 Kafka API，可以构建独立、可扩展、可靠的组件应用程序。因此，Kafka 客户端应用程序是一个分布式系统，用于查询、处理和存储连续的数据流
卡夫卡生态系统 – 卡夫卡溪流、卡夫DB、春卡夫卡和更多…
卡夫卡生态系统提供各种组件来实现应用。
Kafka本身包括Java 和 Scala 客户端 API（用于使用 Java 进行流处理的Kafka 流，Kafka Connect与不同的源和接收器集成，无需编码）。
存在许多其他 Kafka 本机客户端 API 和框架。下面是一些示例：
- 利布卡夫卡：阿帕奇卡夫卡协议的C库实现，提供生产者、消费者和管理员客户端。其设计考虑到了消息传递的可靠性和高性能。当前数字超过 100 万毫秒/秒的生产者和消费者的 300 万毫秒/秒。除了 C 库之外，它通常用作包装器，从其他编程语言（如C++、Golang、Python 和 JavaScript）提供 Kafka 客户端。
- REST 代理：为卡夫卡群集提供 RESTful 接口。它便于生成和使用消息、查看群集的状态以及执行管理操作，而无需使用本机 Kafka 协议或客户端。
- ksqlDB： Apache Kafka 的事件流数据库，使您能够利用对关系数据库的熟悉程度构建事件流应用程序。
- 卡夫卡的春天：将核心弹簧概念应用于基于卡夫卡的消息和流媒体解决方案的开发。它提供了一个”模板”作为用于发送消息的高级抽象。包括对卡夫卡流的一流支持。其他春季框架（如春云流和春云数据流）也为 Kafka 的事件流提供本机支持。
- 浮士德：用于在Python 中构建流式处理应用程序的库，类似于原始的 Kafka Streams 库（但功能有限且不太成熟）。
- TensorFlow I/O = 卡夫卡插件：用于流式机器学习的 TensorFlow 的本机集成（即直接从卡夫卡使用模型训练和模型评分模型，而不是使用其他数据湖）
..
域驱动设计 （DDD）、哑巴管道、智能端点
Kafka 客户端的重要性对于讨论可能取代数据库至关重要，因为Kafka 应用程序可以是无状态的或有状态的;后者在应用程序中保留状态，而不是使用外部数据库。下面的存储部分包含有关客户端应用程序如何长期存储数据且高度可用的更多详细信息。
有了这个，你明白卡夫卡有一个强大的服务器和客户端。许多人在评估 Kafka 与其他消息传递解决方案或存储系统时都没有意识到这一点。
有了这一点，结合利用Kafka的基础存储在生产者和消费者之间进行真正脱钩的能力，阿帕奇卡夫卡成为微服务架构的实际标准和骨干——不仅取代了其他传统的中间件，还利用域驱动设计（DDD）构建客户端应用程序，用于分离应用程序、哑管和智能端点：
同样，为什么围绕 Kafka 是数据库的讨论很重要：对于您创建的每个新的微服务，您都应该问自己：我的微服务中真的需要一个”真实数据库”后端吗？开发、测试、操作、监控的复杂性和成本？
当然，答案通常是肯定的。但我看到越来越多的应用程序，保持状态直接在Kafka应用程序更好，更容易，或两者兼而有之。
存储 – 可在卡夫卡存储数据多长时间？什么是胡德下的数据库？
简短的回答是：只要您想要，数据就可以存储在卡夫卡。卡夫卡甚至提供了使用 -1 保留时间的选项。这意味着”永远”。
较长的答案要复杂得多。你需要考虑卡夫卡经纪人的成本和可扩展性。应该使用 HDD 还是 SDD？或者甚至是基于闪存的技术？纯存储写了一个很好的例子，利用闪存存储每秒写入 500 万条消息，其中有三个生成器和 3 倍复制。这取决于您需要存储的数据量以及访问数据和从故障中恢复的速度。
卡夫卡用于存储纽约时报发表的所有文章，并取代基于API的方法。Streams API 用于实时向各种应用程序和系统提供已发布内容，以便读者使用它。
到目前为止，我们只是谈论最常用的 Kafka 功能：基于日志的存储，保留时间和磁盘附加到代理。但是，您还需要考虑 Kafka的其他功能，以便全面讨论 Kafka 基础结构中的长期存储：压缩主题、分层存储和客户端存储。所有这些功能都能快速改变您对 Kafka、其用例及其体系结构的看法。
压缩主题 – 日志压缩和”事件更新”
日志压缩可确保 Kafka 始终在单个主题分区的数据日志中保留每个消息键的最后一个已知值。它解决用例和方案，例如在应用程序崩溃后还原状态、系统故障或在操作维护期间应用程序重新启动后重新加载缓存。因此，log 压缩没有保留时间。
显然，最大的权衡是日志压缩不会保留所有事件和更改的完整顺序。为此，您需要使用具有特定保留时间的正常 Kafka 主题。
或者，您可以使用 -1 永久存储所有数据。这里最大的权衡是磁盘成本高，操作和可扩展性更加复杂。
分层存储 – 阿帕奇卡夫卡的长期存储
创建 KIP 405（Kafka改进建议）是为了标准化 Kafka 分层存储的接口，以便不同贡献者和供应商提供不同的实现。KIP 尚未实现，来自不同公司的贡献者仍在讨论该接口。
Kafka 的分层存储降低了成本（由于对象存储成本更低），提高了可扩展性（由于存储和处理之间的分离），并简化了操作（由于简化和更快的再平衡）。
下面是一些用于长期在 Kafka 中存储完整日志的示例（而不是利用压缩的主题）：
- 新的消费者，例如一个全新的微服务或替换现有应用程序
g. 在出错时重新处理数据，以修复错误并再次处理事件。
最后一个示例在这里进行了更详细的讨论：使用分层存储进行流式机器学习（无需数据湖）。
客户端数据库 – 有状态的卡夫卡客户端应用程序和微服务
如上所述，卡夫卡不仅仅是服务器端。您可以在Kafka 客户端上构建高度可用且可扩展的实时应用程序。
岩石DB为状态卡夫卡应用
通常，这些卡夫卡客户端应用程序（必须）跟踪状态。Kafka 流和 ksqlDB 利用RocksDB进行此（您也可以仅使用内存中存储或将 RocksDB 替换为其他存储;然而，我在现实世界中从未见过后一种选择）。RocksDB是运行任务关键工作负载的关键值存储。它针对快速、低延迟存储进行了优化。
在Kafka Streams 应用程序中，解决了抽象对本地稳定存储的访问而不是使用外部数据库的问题。每次处理事件时，使用外部数据库都需要外部通信/RPC。事件流体系结构中清晰的反模式。
RocksDB 使软件工程师能够专注于系统其他领域的设计和实施，并放心地依靠 RocksDB 访问稳定存储。它在几个硅谷公司进行了战斗测试，并在阿帕奇卡桑德拉、蟑螂开发银行或MySQL（MyRocks）等许多著名数据库的引擎盖下使用。RocksDB 正在蚕食数据库世界，更详细地介绍了历史和用例。
ksqlDB 作为事件流数据库
卡夫卡流和ksqlDB – Kafka的事件流数据库 – 允许构建有状态的流应用程序;包括强大的概念，如联接、滑动窗口和状态的交互式查询。下面的示例演示如何构建有状态的付款应用程序：
客户端应用程序将数据保存在自己的应用程序中，以便进行实时联接和其他数据关联。它结合了 STREAM（不可更改事件）和 TABLE（更新的信息（如关系数据库中）的概念。
请记住，此应用程序具有高度可扩展性。它通常不只是单个实例。相反，它是一个分布式的客户端实例群集，用于提供高可用性和并行化数据处理。即使某些内容出现故障（VM、容器、磁盘、网络），整个系统也不会丢失数据并继续全天候运行。
正如您所看到的，许多问题必须回答，并且必须考虑各种功能，以便对要在 Kafka 中存储数据的时间和位置做出正确的决定。
长期在 Kafka 存储数据的一个很好的原因是能够在以后的时间点使用数据进行处理、关联或分析。
查询和处理 – 您能否使用和分析 Kafka 存储？
卡夫卡提供了不同的选项来使用和查询数据。
Kafka 中的查询可以是PUSH（即连续处理和转发事件）或PULL（即客户端请求您从您喜爱的 SQL 数据库中知道的事件）。
将在以下部分中向您展示不同的选项。
使用者应用程序拉动事件
卡夫卡客户从经纪人那里提取数据。这分离了生产者、经纪人和消费者，使基础设施具有可扩展性和可靠性。
卡夫卡本身包括一个Java和Scala客户端来使用数据。但是，Kafka 客户端几乎可用于任何其他编程语言，包括广泛语言，如 C、C++、Python、JavaScript 或 Golang 和异国情调的语言（如 RUST）。此外，Confluent 提供了 REST 代理。这允许使用来自支持此标准的任何语言或工具的 HTTP（S） 的事件。
应用程序具有不同的选项来使用来自 Kafka 代理的事件：
- 持续消耗最新事件（实时或批量）。
- 只是特定的时间框架或分区。
- 从开始的所有数据。
流处理应用程序/微服务拉动和推送事件
Kafka Streams 和 ksqlDB 从代理中提取事件，处理数据，然后将结果推回另一个 Kafka 主题强大的查询是可能的;包括 JOIN 和有状态聚合。
这些功能用于大规模流式传输 ETL和实时分析。它们还可用于构建任务关键型业务应用程序和微服务。
此讨论需要更详细的内容，不能在本文中介绍侧重于数据库透视。开始，例如，我的介绍事件流与ksqlDB从大数据西班牙在马德里涵盖用例和更多的技术细节。”集成开发人员“是开始构建事件流应用程序的另一个要点。该网站提供了大量的教程，视频，演示，和更多的阿帕奇卡夫卡。
功能”交互式查询“允许从客户端应用程序的状态存储查询值（通常在引擎盖下使用 RocksDB 实现）。事件通过 REST / HTTP 等技术进行拉取，或通过 WebSocket 代理等中介推送。卡夫卡流提供核心功能。交互式查询界面必须由自己在上面实现。专业：灵活性。Con： 未提供开箱即用。
卡夫卡作为查询引擎及其局限性
上述 Kafka 查询功能均不如您喜爱的 Oracle 数据库或弹性搜索强大！
因此，卡夫卡不会替换其他数据库。它是互补的。Kafka 背后的主要思想是持续处理流数据;附加选项来查询存储的数据。
Kafka 作为某些用例的数据库足够好。但是，Kafka 的查询功能对于其他用例来说不够好。
然后，Kafka经常用作中央流媒体平台，其中一个或多个数据库（和其他应用程序）利用自己的技术构建自己的具体实时视图。
该原理通常被称为”将数据库从内向翻出“。此设计模式允许使用正确的数据库解决正确的问题。卡夫卡用于以下方案：
- 作为数据集成的可扩展事件流平台。
- 用于不同生产者和消费者之间的脱钩。
- 处理背压。
- 持续处理和关联传入事件。
- 用于启用在其他数据库中创建和更新具体化视图。
- 允许直接对 Kafka 进行交互式查询（具体取决于用例和已使用的技术）。
卡夫卡作为真理和领导系统的单一来源？
对于许多方案，如果中心事件流平台是事实的核心单一来源，则这是一个很好的结果然而，在现实世界中，像 ERP 系统这样的系统通常会保持领先的系统，即使它通过 Kafka 将数据推送到企业的其他部分。
那完全没问题！卡夫卡是中央流媒体平台并不强迫你使它在每一个事件的领先系统。对于一些应用程序和数据库，在与卡夫卡集成后，现有的真相来源仍然是真相的来源。
这里的关键点是，您的单一真实来源不应是存储数据处于静止处的数据库，例如，在 Hadoop 或 AWS S3 等数据湖中。这样，您的中央存储是一个缓慢的批处理系统。您不能简单地将实时使用者连接到它。另一方面，如果事件流平台是您的中心层，则可以将其引入到数据湖中进行休息数据处理，但您也可以轻松地添加另一个实时使用者。
本机 ANSI SQL 查询层以拉取事件？Tableau、Qlik、Power BI 等用于分析卡夫卡？
通过 Kafka 访问大量事件流数据激发了对交互式实时仪表板和分析的浓厚兴趣，其想法类似于使用 Tableau、Qlik 或 Power BI 等传统数据库构建的数据库，以及使用 Impala、Presto 或 BigQuery 的 Hadoop 等批处理框架：用户希望提出问题并快速获得答案。
利用Rockset，一个基于 RocksDB 的可扩展 SQL 搜索和分析引擎，并结合 BI 和分析工具（如 Tableau），您可以直接查询 Kafka 日志。与 ANSI SQL。没有限制。规模。实时。现在是质疑数据湖策略的好时机，不是吗？:-)
交易 – 卡夫卡的交付和加工担保
TL;DR：Kafka 提供端到端处理保证、耐用性和高可用性，以构建最关键的业务应用程序。我见过许多在卡夫卡上建立的关键任务基础设施，这些基础设施包括银行、电信、保险、零售、汽车等。
我想将交付保证和正确性作为邮件系统和数据库的关键特征。许多应用程序中都需要事务来保证不丢失数据并保证行为。
数据库中的事务处理是信息处理，分为单个、不可分割的操作，称为事务。每个事务都必须作为一个完整的单位成功或失败;它永远不能只部分完成
因此，许多分布式系统只提供”至少一次语义”。
卡夫卡的一次性语义 （EOS）
卡夫卡是一个分布式系统，提供各种保证交付。不同的配置选项允许至少一次、最多一次和完全一次的语义 （EOS）。
一次的语义是人们与数据库事务相比的。这个想法是相似的：你需要保证每个生成的信息被消耗和处理一次。许多人认为，这是不可能实现与Kafka，因为个别的，不可分割的操作可能会失败在分布式系统中！在卡夫卡的世界里，许多人提到著名的黑客新闻讨论”你不能有一次准确交付“和类似的Twitter对话。
在2017年中期，”难以置信的事情”发生了：阿帕奇卡夫卡0.11增加了对精确一次语义（EOS）的支持。请注意，它不包括”交易”一词故意。因为它不是事务。因为在分布式系统中不可能发生事务。但是，结果相同：每个使用者只消耗每个生成的消息一次。”一次语义是可能的：下面是卡夫卡如何做它”涵盖了实现的细节。简而言之，EOS 包括三个功能：
- 阳萎：每个分区的语义顺序一次。
- 事务： 跨多个分区的原子写入。
- 阿帕奇卡夫卡的一次性流处理。
马蒂亚斯·萨克斯在2018年伦敦卡夫卡峰会上出色地解释了EOS。幻灯片和视频录制是免费的。
EOS 的工作方式与数据库中的事务不同，但最终提供了相同的结果。它可以通过配置打开。顺便说一下，与至少一次语义相比，性能损失并不大——通常端到端处理速度要慢 10% 到 25%。
卡夫卡生态系统中的一次性语义（卡夫卡连接、卡夫卡流、ksqlDB、非Java客户端）
EOS不仅仅是卡夫卡核心和相关Java/Scala客户端的一部分。大多数 Kafka 组件支持一次交付保证，包括：
- 某些（但不是全部）卡夫卡连接连接器。例如 AWS S3 和弹性搜索。
- Kafka 流和 ksqlDB可完全处理一次数据，用于流式处理 ETL 或业务应用程序中
利布斯卡夫卡是许多卡夫卡客户在各种编程语言中的核心基础，最近增加了对EOS的支持。
卡夫卡会取代您的现有数据库吗？
一般来说，不！但是你应该总是问自己：除了卡夫卡，你还需要另一个数据存储吗？有时是，有时没有。我们讨论了数据库的特征以及卡夫卡何时足够。
每个数据库都有特定的功能、保证和查询选项。使用 MongoDB 作为文档存储，弹性搜索文本搜索，Oracle 或 MySQL 用于传统关系用例，或者使用 Hadoop 为大数据湖运行报表的地图/减少作业。
这个博客文章希望帮助你为您的下一个项目做出正确的决定。
但是，请坚持：问题并不总是”卡夫卡 vs 数据库 XYZ”。通常，卡夫卡和数据库是互补的！让我们在下面的一节中讨论这个问题…
卡夫卡连接 – 卡夫卡和其他数据库之间的集成
阿帕奇卡夫卡包括卡夫卡连接：连接卡夫卡与外部系统，如数据库，键值存储，搜索索引和文件系统的f rame工作。使用 Kafka Connect，您可以将现有连接器实现用于常见数据源和接收器，将数据移入和移出卡夫卡：
这包括许多连接器到各种数据库。要从源系统查询数据，可以拉取事件（例如，使用JDBC 连接器），也可以通过机会数据捕获（CDC，例如使用Debezium 连接器）推送。Kafka Connect 还可以写入任何接收器数据存储，包括各种关系、NoSQL 和大数据基础架构，如 Oracle、MongoDB、Hadoop HDFS 或 AWS S3。
阿帕奇卡夫卡是一个数据库与ACID保证，但补充其他数据库！
阿帕奇卡夫卡是一个数据库。它提供 ACID 保证，并用于数百家公司的任务关键型部署。然而，在许多情况下，卡夫卡没有竞争力，其他数据库。Kafka 是一个事件流平台，用于实时进行消息传送、存储、处理和集成，实现零停机时间和零数据丢失具体化视图可以由其他数据库为其特定用例构建，例如实时、时间序列分析、近乎实时地引入文本搜索基础结构或数据湖中的长期存储。
总之，如果您被问到 Kafka 是否可以替换数据库，则下面是不同的答案：
- Kafka 可以以持久且高可用的方式永久存储数据，从而提供 ACID 保证。
- Kafka 中提供了用于查询历史数据的不同选项。
- 卡夫卡原生加载项，如ksqlDB或分层存储，使卡夫卡比以往任何时候都更强大数据处理和基于事件的长期存储。
- 可以利用Kafka 客户端（微服务、业务应用程序）构建有状态的应用程序，而无需另一个外部数据库。
- 不能替代现有数据库，如 MySQL、MongoDB、弹性搜索或 Hadoop。
- 其他数据库和卡夫卡相辅相成;必须为问题选择正确的解决方案;通常，从基于中心事件的基础结构实时创建和更新专门构建的实化视图。
- Kafka 和数据库之间的双向拉取和推送集成提供了不同的选项，以相互补充。
你觉得怎么样？阿帕奇卡夫卡是数据库吗？对于某些用例）？
我知道这是一个有争议的讨论：-）你有什么想法？如上所述，我不建议替换现有的数据库。但有时卡夫卡一个人就足够了，不是吗？
请连接，让我知道：
contact@kai-waehner.de
@KaiWaehner
LinkedIn （https://www.linkedin.com/in/megachucky/）