2024年数据流景观

研究公司Forrester在新的一篇Forrester Wave中将数据流平台定义为一个新的软件类别。Apache Kafka是被超过100,000家组织采用的事实标准。许多供应商提供Kafka平台和云服务。许多相关的开源流处理框架，比如Apache Flink和相关的云服务，已经出现。竞争性技术，比如Pulsar、Redpanda或WarpStream，试图通过利用Kafka协议获取市场份额。本博文探讨了2024年的数据流景观，以总结现有解决方案和市场趋势。文章的结尾展望了2025年可能出现的新进入者。

通过订阅我的通讯，加入数据流社区，了解最新博文。

数据流是一个新的软件类别

实时数据胜过慢速数据。这对任何行业的几乎所有用例都是正确的。由数据流驱动的应用是新宠。这种方法通过增加收入、降低成本、减少风险或提高客户体验来增加业务价值。

有许多软件类别和相关数据平台可用于处理和分析数据：

• 数据库：存储和执行事务工作负载。
• 数据仓库：处理结构化历史数据，以创建重复报告和独特见解。
• 数据湖：使用批处理处理结构化和半结构化或非结构化大数据集，以创建重复报告和独特见解。
• 湖仓一体：数据仓库和数据湖的结合，可在一个平台上处理所有数据。
• 数据流：不断处理运动中的数据，并在通信范式（如实时、批处理和请求-响应）之间提供数据一致性，而不仅仅在静息状态存储和分析数据。

当然，这些数据平台通常有一些重合。我做了一整套博文，探讨它们的用例以及它们如何相辅相成。

1. 数据仓库 vs. 数据湖 vs. 数据流—朋友、敌人、朋友敌？
2. 数据流用于将数据摄入到数据仓库和数据湖
3. 数据仓库现代化：从传统本地部署向云原生基础设施转型
4. 案例研究：云原生数据流用于数据仓库现代化
5. 构建云原生数据仓库的经验教训

Forrester Wave™：流式数据平台，2023年第4季度

Forrester是一家领先的研究和咨询公司，为组织提供有关技术、业务和市场趋势的洞察和分析。

该公司以其深入分析、市场研究报告和框架而闻名，帮助组织应对技术和业务快速变化的​​形势。企业和IT领导人经常使用Forrester的研究来了解市场趋势、评估技术解决方案，并制定战略，以在各自的行业中保持竞争力。

在2023年12月，该研究公司发布了“Forrester Wave™：流式数据平台，2023年第4季度”。可以在此处免费获取报告。领先者分别是微软、谷歌和Confluent，其后是甲骨文、亚马逊、Cloudera和其他几家公司。

你可能同意或不同意特定供应商关于其产品或策略强度的位置。但是，这一新浪潮的出现证明了数据流是一个新的软件类别；不再仅仅是另一种炒作或下一代ETL/ESB/iPaaS工具。

数据流用例的业务价值

新的软件类别为所有行业开启了用例，并增加了业务价值：

增加业务价值对于任何企业来说都至关重要。由于存在如此多的潜在用例，因此毫不奇怪，越来越多的软件供应商为其产品增加了Kafka支持。在我的博客中搜索你最喜欢的行业，找到大量的案例研究和架构。或阅读Apache Kafka在各行业中的用例以开始了解。

2024年的数据流景观

数据流是数据平台的一个独立软件类别。许多软件供应商围绕此类别构建了他们的整个业务。数据流景观显示，大多数供应商使用Kafka或实施其协议，因为Apache Kafka已成为数据流的事实标准。

在过去几年中，这一类别出现了许多新的软件公司。在数据市场中，一些成熟的参与者为其平台或云服务生态系统增加了数据流支持。大多数软件供应商使用Kafka作为其数据流平台。不过，除了Kafka以外，还有更多选择。有些供应商仅使用Kafka协议（Azure事件中心），或使用完全不同的API（比如亚马逊Kinesis）。

以下是2024年的数据流景观，总结了相关产品和云服务的当前状况。

请注意：这并不是一个完整的框架、云服务或供应商清单。这也不是一个官方的研究景观。没有统计证据。如果你喜欢的技术在这个图表中没有出现，那是因为在我与客户、潜在客户、合作伙伴、分析师或更广泛的数据流社区的交谈中我没有看到它。

同时，请注意，我关注的是通用的数据流基础设施。对于特定场景的使用和分析流数据，比如时间序列数据库、机器学习引擎或可观察性平台，也存在出色的解决方案。这些解决方案通常与数据流集群自动连接并可互补使用。

部署模型：自管理 vs. 完全托管

关于部署模型，存在不同的数据流类别：

• 自管理：使用你喜欢的脚本和工具自行操作Kafka Broker、Kafka Connect和Schema Registry节点。可以是你的VPC中的自建环境或公共云中的环境。
• 部分托管：通过云原生平台（通常是Kubernetes）和相关的操作工具减少运维负担，自动执行操作任务，如滚动升级或重新平衡Kafka分区。可以是你的VPC中的自建环境或供应商的VPC中的环境。
• 完全托管：利用（真正）完全托管的SaaS解决方案，实现100%的运维操作，并提供重要的SLA和支持，以便专注于集成和业务逻辑。

自带云环境（BYOC）是什么？

一些供应商提供了第四种部署模型：自带云环境（BYOC），这是一种在你的环境中为你运行集群的方法。BYOC这种部署模型介于SaaS云服务和自管理部署之间。

我不认同这种方法，因为在BYOC中存在太多关于安全性、支持和SLA的问题和挑战，特别是P1和P2的问题和停机时间。因此，我将其归为自管理的范畴。无论如何，尽管供应商触及你的基础设施，但最终风险在你，因为你必须并且也希望控制自己的环境。

Jack Vanlightly撰写了一篇卓越的文章 "关于云服务和BYOC的未来." Jack探讨了以下迷思：

• 迷思1：BYOC通过保留数据在你的账户中实现更好的安全性。
• 迷思2：BYOC更便宜，具有更低的总体拥有成本（TCO）。

我用这两幅图表概括了这个故事，并强烈推荐阅读Jack关于BYOC及其权衡的详细文章：

来源：Jack Vanlightly

这是Jack的结论："客户曾远离自己搭建硬件而转向云，尝试BYOC的客户同样会因其简便性、可靠性、可扩展性和成本效益而迁移至SaaS。" 我完全同意。

流式处理类别：原生Kafka vs. 协议兼容性 vs. 流处理

Apache Kafka成为了数据流领域的事实标准，就像Amazon S3成为了对象存储领域的事实标准一样：

在探索数据流领域时，不可不看的是Apache Kafka生态系统。

数据流景观涵盖了三个流式处理类别：

• 本地Apache Kafka： 该产品或云服务利用开源框架进行实时消息传递和事件存储。Kafka API 符合100%。不包括Kafka Streams和Kafka Connect；很多供应商都排除了这些Kafka功能。
• Kafka协议： 产品或云服务实现自己的代码，但支持Kafka API。这些产品通常并不符合100%的要求。通常情况下，Kafka Connect和Kafka Streams 并不是产品的组成部分。
• 流处理： 框架和云服务以无状态或有状态的方式关联数据。解决方案要么是Kafka原生的，要么与Kafka协议一起工作，或者完全独立运行。

定义这几个类别其实非常困难。例如，我可以添加另一部分关于Kafka Connect，或者更一般地说，是数据集成。另一个争论是如何澄清一个供应商是否支持完整的Kafka API（是否包括Kafka Connect或Kafka Streams）。但我不想有一个无穷无尽的解决方案清单。因此，重点是在Kafka协议（作为消息传递和存储的事实标准）以及Kafka相关的流处理和非Kafka技术。

从2023到2024年的数据流景观变化

我的目标不是一个增长迅速的方案清单，其中有成千上万的供应商和云服务。已经有很多这样的图片。相反，我注重的是一些真实实践中广泛使用的技术、供应商和服务器提供，以及受到更广泛的开源和云社区的关注。因此，与一年前发布的2023年数据流景观相比进行了以下变化：

替换

• 类别：我将“非Kafka”改为“流处理”，以便更好地专注于数据流处理，而不包括像Google Pub/Sub或Amazon Kinesis这样的核心消息解决方案。
• Red Hat：IBM的战略转变（再次）。Red Hat关闭了它的云服务“Red Hat OpenShift Streams for Apache Kafka”，并且将对话转移到IBM产品。我用IBM替换了它的标志，而IBM仍然提供Kafka云产品。但需要明确的是：Red Hat AMQ Streams（即，自管理的Kafka + Strimzi Kubernetes operator）仍然是一个有市场的产品。

添加

• WarpStream： 一个新的完全托管的云服务入场者，使用Kafka协议。
• Confluent： 添加到流处理类别，具有Kafka Streams，ksqlDB和Apache Flink（通过其Immerok收购）。
• Ververica： 多年来提供Flink平台。老实说，我不确定为什么去年错过了他们。
• Amazon Manage Service for Apache Flink（MSF）。曾被称为Amazon Kinesis Data Analytics（KDA）。添加到部分托管的流处理。
• Google DataFlow： 添加到完全托管的流处理。

已删除

这是一个有争议的部分。因此，我再次强调，这只是我在实践中看到的，不是作为统计研究或调查。

• Google Pub/Sub： 关注数据流处理，而不是消息代理。
• TIBCO：在数据流处理方面并不常见（超出金融服务市场上的TIBCO StreamBase用于低延迟交易）。
• DataStax：我没有看到开源的Apache Pulsar很多，也没有看到DataStax的Pulsar产品Luna Streaming在市场上取得任何进展。此外，看起来该供应商进行了另一次战略转变，现在更加专注于矢量数据库和生成AI（GenAI）。
• Lenses + Conduktor：我删除它们的原因不是因为它们没有被使用。这些都是很棒的工具。但这个景观着重于数据流处理平台，而不是辅助的管理、监控或代理工具。目前在Kafka周围存在很多工具 - 这值得有一个自己的景观或比较文章。
• Pravega：我在2023年没有一次在现场看到这种技术。
• Immerok：被Confluent公司收购。
• Hazelcast：我在实际场景并没有看到它用于数据流处理。该技术以内存数据网格而闻名，但不是用于流处理。

如上所述，我提到了Forrester Wave，你可能会意识到我并没有在报告中包含每一个“强大的表现者”。例如，TIBCO、SAS或Hazelcast。因为我在关于事件驱动体系结构和流处理的讨论中没有看到这些供应商的任何发展。这不是统计证据，也不是试图贬低其他工具。

数据流平台的评估标准

我经常建议使用以下四个方面来评估不同的框架、平台和云服务，以评估一项技术是否适合您的业务项目或企业架构战略：

• 云原生：解决方案是弹性的，可以自动扩展吗？它是完全托管/无服务器的，还是仅仅是一堆托管在云中的服务器实例？您可以使用DevOps、GitOps、测试驱动开发等原则自动化开发、运营和测试流程吗？
• 完整：解决方案是否提供所有必需的功能？数据流处理需要的不仅是消息传递或数据摄入。因此，它是否提供连接器、数据处理、治理、安全性、自助服务、开放API等等？
• 到处都有：您可以在哪里使用该解决方案？仅限于云？所有必需的云服务提供商都受支持吗？有没有部署在数据中心甚至边缘（即，数据中心之外）的选择，比如工厂、基站或零售商店？您如何在区域、云端或数据中心之间共享数据？它支持哪些用例（例如，聚合、灾难恢复、混合集成、迁移等）？
• 支持：解决方案是否成熟并且经受过实战测试？是否有您用例或行业的公开案例研究？供应商是否充分支持产品？SLA是什么？商业企业支持中是否排除了特定功能？某些供应商提供数据流处理云服务（如托管的Kafka服务），并在条款和条件中排除了公共云服务中许多人不愿意阅读的支持。

让我们深入了解不同的数据流类别，并从领先技术Native Apache Kafka开始...

用于数据流的本地Apache Kafka

从领先的数据流技术Apache Kafka开始，以及相关的供应商和SaaS产品。

过去几年中Apache Kafka社区的增长令人印象深刻。以下是Jay Kreps去年在奥斯汀得克萨斯州举办的数据流会议“Current - The Next Generation of Kafka Summit”上提出的一些统计数据：

• >100,000家机构使用Apache Kafka
• >41,000名Kafka meetup参与者
• >32,000个Stack Overflow问题
• >12,000个Apache Kafka的Jiras
• >31,000个带Kafka技能的工作列表

再看看使用Maven下载Kafka Java客户端库的活跃月度独立用户数量的增加：

来源：Sonatype

Apache Kafka供应商：自主托管与云服务

新的软件公司专注于数据流。甚至像IBM和Oracle这样的历史悠久的公司在过去几年也追随了这一趋势。在最高层次上——简言之——Apache Kafka存在三种提供方式：

我使用了一个汽车类比来做详细的本地Kafka供应商和云服务的比较。但在进行这项比较时，Amazon MSK Serverless（即，完全托管的服务，而不是部分托管的MSK）尚不可用。因此，也请阅读Confluent Cloud与Amazon MSK Serverless的比较。

以下是对每种技术的一些注解。

• Apache Kafka：数据流的事实标准。拥有广泛的开源社区。此列表中的所有供应商都依赖于（部分）这个项目。
• Confluent：通过Confluent平台（自主托管）和Confluent Cloud（完全托管，并可在所有主要云提供商上使用）实现全球范围内的数据流。
• Cloudera：提供以自我托管的形式的Kafka。专注于将许多数据技术（如Kafka、Hadoop、Spark、Flink、NiFi等）组合在一起。
• IBM：提供Kafka作为部分托管的云服务，以及通过OpenShift（通过Red Hat）在Kubernetes上进行自我托管的Kafka。Kafka是包括Apache Camel等其他开源框架的一体化产品组合的一部分。
• AWS：提供两个独立的产品，即Amazon MSK（部分托管）和Amazon MSK Serverless（完全托管）。这两种产品具有非常不同的功能和限制。这两种MSK产品不包括Kafka支持（请阅读条款和条件）。AWS拥有数百个云服务，而Kafka是其中广泛谱的一部分。只能在公共AWS云区域中使用；不能在Outposts、Local Zones、Wavelength等中使用。
• Instaclustr和Aiven：跨多个云提供商提供部分托管的Kafka云产品。产品组合提供各种托管的开源技术服务。Instaclustr还为本地基础设施提供（半）托管服务。
• Microsoft Azure HDInsight：Azure的Hadoop基础设施的一部分。不适用于其他用例。只能在公共Azure云区域中使用。

这不是一个比较。只是列举了一些注解。自行评估您喜欢的供应商。检查您需要什么：云原生？完整？全球？受支持？

请记住，许多供应商不包括或不专注于Kafka Streams和Kafka Connect，并仅提供不完整的Kafka；他们希望销售自己的集成和处理产品。不要拿苹果和橙子来比较！

使用Kafka协议的开源框架和SaaS

一些供应商并不依赖于开源Apache Kafka，而是基于Kafka协议构建了自己的实现，原因各异。

市场不会告诉您，但Kafka协议的兼容性是有限的。这可能在操作现有Kafka工作负载时构成风险，并且在操作和执行方面有所不同（有利也有弊）。

以下是对每种技术的一些注解：

• Apache Pulsar: 一个与Apache Kafka竞争的产品。故事和使用案例类似，但架构不同。Kafka是一个单一的分布式集群 - 在2022年移除了对ZooKeeper的依赖后。Pulsar是三个（！）分布式集群：Pulsar代理、ZooKeeper和BookKeeper。现在要想获得更多的市场份额已经太晚了。而且Kafka正在迎头赶上一些缺失的功能，比如Kafka的队列。
• StreamNative: Apache Pulsar背后的主要供应商。提供自管理和全面管理的解决方案。StreamNative Cloud for Kafka目前还处于非常早期的成熟阶段，不确定是否会加强。毫不奇怪，现在你也可以选择BYOC。
• Redpanda: 数据流市场的一个相对较新的新参与者，提供自管理和全面管理的产品。用C ++实现Kafka协议的有趣方法。如果他们能找到适当的用例和差异化，可能会占据一些市场份额。但是今天，我不认为Redpanda是Kafka原生方案的替代品，因为它在成熟度曲线上处于早期阶段，与Apache Kafka相比，对解决业务问题没有增加价值，反而增加了风险。
• Azure Event Hubs: 一个成熟的全面管理云服务。该服务只做一件事，而且做得非常出色：通过Kafka协议进行数据摄入。因此，它不是一个完整的流处理平台，而更类似于Amazon Kinesis或Google Cloud PubSub。只在公共Azure云区域可用。我经常听到的两个阻碍是，与Kafka协议的兼容性有限，以及服务的高昂成本。
• WarpStream: 数据流市场的一个新参与者。这个云服务是一个建立在S3之上的Kafka兼容数据流平台。对于一些Kafka使用案例来说，较差的延迟可能还可以接受。但是只有未来才能证明这种不同的架构在其他Kafka云服务采用Kafka的KIP-405进行分层存储（自Kafka 3.6起提供早期访问）后是否能起到关键作用。

要小心那些重新实现Kafka协议的供应商的说法。这些供应商中，大多数都会夸大Kafka协议的兼容性。此外，“基准营销”（即，在你的竞争对手表现更好的甜蜜点或利基场景）是“证明”与真正的Apache Kafka不同的最喜欢的营销技术之一。

流处理技术

尽管Apache Kafka是消息和事件存储的事实标准，但许多相辅相成和竞争性的技术存在于流处理中：

由于这个软件类别在全球和所有行业的增长，最近出现了更多的技术，这是个很好的消息。数据流是来留下并增长的。

作为数据流景观的一部分，探索情况是具有挑战性的，因为一些产品是与Apache Kafka生态系统相辅相成和竞争的。

Apache Flink的采用和增长

有趣的事实：领先的Kafka会议在2022年从“Kafka Summit”重新品牌为“Current - The Next Generation of Kafka Summit”。为什么？因为数据流不仅仅是Kafka。许多相辅相成和竞争的技术都会出现，包括供应商、展位、演示和客户案例研究。这对于全球社区和企业来说，是数据流的显著进化！

Apache Flink正在成为流处理的事实标准。Flink的崛起看起来非常类似于几年前Kafka的采用情况：

但不要低估与Kafka本地流处理及Kafka Streams的力量和使用案例。采用率是巨大的，因为Kafka Streams易于使用，并且它是Apache Kafka的一部分。

一些流处理产品与Kafka相辅相成

每个流处理框架或云服务都有各种折衷。虽然Flink受到了很多关注，但也有其他的流处理技术。并没有适合所有用例的单一大小。下面是一些成熟和新兴技术，它们是与Apache Kafka相辅相成的：

开源流处理框架

• Kafka Streams: 开源Apache Kafka的一部分。因此，如果你从Apache网站下载Kafka，它总是包含这个库。你应该问自己，除了Kafka Streams以外，你是否还需要另一个框架进行流处理。重要的好处是：一种技术，一个供应商，一个基础设施。
• ksqlDB（通常被称为KSQL，即使在重新品牌后仍然如此）: 位于Kafka Streams之上的抽象层，提供流处理和实时SQL。因此，它也是Kafka原生的。它附带Confluent Community许可证，并可免费使用。优势：流式ETL。
• Apache Flink: 领先的开源流处理框架。先进特性包括强大的可扩展计算引擎（与Kafka分离）、开发者在ANSI SQL、Java和Python之间的自由选择、复杂事件处理（CEP）的API，以及流和批处理工作负载的统一API。
• Spark Streaming: Apache Spark开源大数据处理框架的流处理部分。我还不是100%确信。Kafka Streams和Apache Flink对流处理来说是更好的选择。然而，企业中Spark集群的庞大安装基数扩大了采用率。

流处理供应商和云服务

• Ververica：著名的Flink公司。2019年被中国巨头阿里巴巴收购。在欧美市场知名度不高，但在亚洲地区绝对是Flink的专家。我个人从未见过这家供应商在亚洲以外的地方被使用。
• Decodable：一项新的云服务。目前仍处于早期阶段。我仍然添加它，因为我认为在Apache Flink之上构建数据流云服务是一个非常明智的战略举措。如果与企业现有的Kafka基础设施结合，巨大的潜力。但也提供了预先构建的非Kafka系统连接器。
• Amazon Managed Service for Apache Flink (MSF)：由AWS提供的（几乎）完全托管的服务，允许客户实时转换和分析流式数据。它仍然存在一些（昂贵的）自动扩展空白，并非真正的无服务器。支持所有Flink接口，即SQL，Java和Python。还支持非Kafka连接器。仅在AWS上可用。
• Confluent Cloud：一种真正无服务器的Flink产品，具有弹性并且如果未被使用则会自动缩减为零。起初仅支持SQL，Java和Python支持将于2024年推出。最初在AWS上启动，但预计将在2024年初在GCP和Azure上推出。与Confluent的完全托管Kafka，模式注册表，连接器，数据治理和其他功能深度集成。为数据流水线提供无缝的端到端开发者体验。
• Databricks：过去是Apache Spark背后的领先供应商。如今，没人再谈论Spark了（即使它是Databricks云平台的关键技术组成部分）。试图更多地涉足实时数据业务。我喜欢该平台用于分析，报告和人工智能/机器学习。但我对“在一个大数据湖中执行所有操作”的数据湖式存储故事并不信服。

这些服务中的大多数与其他供应商的解决方案配合良好。例如，Databricks与任何Kafka环境轻松集成，或者Amazon MSF直接连接到Confluent的Kafka。

没有Kafka的Apache Flink（或Spark Streaming）？

大多数流处理技术都是用来补充Apache Kafka的。但像Flink或Databricks这样的流处理框架并不需要Kafka作为摄取层。还有其他选择……

Flink，Spark等可以从其他流式平台或直接从文件或数据库中消耗数据。但对于后者，需要注意：如果您使用Flink或Spark Streaming进行流处理，那很好。但如果首要任务是从S3对象存储中读取数据，那么这其实属于静态数据。

但是：数据流市场的一个常见趋势是在事件流平台中的长期存储（某些）事件。特别是通过S3接口，一些供应商对对象存储的支持可以成为在Kafka协议或其他分析引擎和数据库中实时存储和处理事件的整个游戏规则变化。而Apache Iceberg可能是我们在2025年谈论的下一个趋势。

还要了解，流处理应用也可以保持状态：Kafka Streams或Flink应用程序的后端可以为像数据丰富这样的目的存储任务状态。流处理应用程序不仅仅是关于实时数据反馈。它还将这些实时数据反馈与（已经摄取的）历史数据相关联。这是元数据或较不经常更新的业务数据的常见处理方式（如来自SAP ERP系统的数据）。

一些数据流处理产品对Kafka构成竞争

在某些情况下，您必须评估Apache Kafka或另一项技术是否是正确选择。以下是一些开源和云竞争对手：

• Amazon Kinesis：将数据摄取到AWS数据存储中。对于特定问题的成熟产品。仅在AWS上可用。
• Google Cloud DataFlow：在谷歌云平台生态系统中执行Apache Beam流水线的完全托管服务。对于特定问题的成熟产品。仅在GCP上可用。
• 许多竞争性初创公司涌现在Kafka和Flink领域之外的流处理周围。让我们看看其中一些是否在2024年获得了成功。

Amazon Kinesis和Google Cloud DataFlow是出色的云服务，如果您“只”想将数据摄取到特定的云存储中。如果没有其他用例，这些工具可能是正确的选择（如果规模价格和其他限制符合您的要求）。

Apache Kafka是一个更加灵活和战略性的数据流平台。许多项目仍然从数据摄取开始并构建首个流水线。但提供对相同事件流的访问权限，供任何其他数据接收器使用或使用强大的流处理工具，比如Kafka Streams或Apache Flink，是一个重要的优势。

数据流领域的潜力 2025 年

数据流是一段旅程。事件流平台和云服务的发展也是如此。一些已建立的软件和云供应商可能会获得更多的关注。并且一些初创公司可能会显著增长。以下是一些可能在2024年演进并获得更多采用的技术：

• 像Digital Ocean或Oracle Cloud Infrastructure（OCI）Streaming这样的额外Kafka云服务可能会更受关注。我还没有在现场看到这些。但是例如，将Oracle GoldenGate与OCI Streaming结合可能对某些组织的某些用例很有趣。
• Hazelcast重新品牌，并成为Forrester的流式数据浪潮的一部分。凭借本地部署和无服务器云服务两者的优势，这种技术可能在数据流处理方面受到关注，并可能在明年再次出现在我的视野中。
• 像Materialize或RisingWave这样的流式数据库可能会成为独立的类别。我的感觉是：这仍处于炒作周期的早期阶段。我们将在2024年看到这项技术是否得到更广泛的应用以及用例是什么。很难回答这些技术将如何与新兴的实时分析数据库（如Apache Druid、Apache Pinot、ClickHouse、Rockset、Timeplus等）竞争。我知道存在差异，但更广泛的社区和企业需要a）理解这些差异，b）为其找到商业问题。
• 像Quix和Bytewax（均采用Python进行流处理）以及DeltaStream（由Apache Flink提供支持）等SaaS初创公司已经出现。让我们看看其中哪些在市场上获得了创新产品和商业模式方面的支持。
• 现有的多产品企业围绕Kafka扩展其Flink服务。例如，Aiven目前已经有了一个可能会受到关注的Flink产品，就像其Kafka产品一样。
• 像MongoDB或Snowflake这样的传统数据管理供应商试图更深入地涉足数据流处理业务。我仍然支持关注点分离；因此我认为这些公司应该保持其优势领域，并（仅）提供用于流式摄入和CDC的用例，而不是（试图）与数据流处理供应商竞争。

有趣的事实：几乎所有新兴初创公司的商业模式都是完全托管的云服务，而不是销售本地部署的许可证。许多基于开源或开源核心，而另一些则仅提供专有实现。

数据流处理的旅程漫长...

数据流处理不是一场竞赛，而是一次旅程！事件驱动的架构和技术，如Apache Kafka或Apache Flink，需要在架构、开发、部署和监控应用程序方面进行思维转变。遗留集成、云原生微服务和在混合和多云设置中进行数据共享已成为常态，而非例外。

2024年的数据流处理景观显示了一个新的软件类别的出现。我们还处于早期阶段。一个新的软件类别需要时间来孵化。在与客户、合作伙伴和社区的大多数对话中，我听到类似的声明："我们看到了价值，但我们还没有准备好——我们现在开始构建第一个数据流处理管道，并且有未来几年增加更高级流处理的路线图。