研究公司 Forrester 将数据流平台定义为新 Forrester Wave 中的一个新软件类别。 Apache Kafka 是超过 100,000 个组织使用的事实上的标准。许多供应商提供 Kafka 平台和云服务。许多互补的开源流处理框架（例如 Apache Flink 和相关云产品）出现了。 Pulsar、Redpanda 或 WarpStream 等竞争技术试图通过利用 Kafka 协议来获得市场份额。这篇博文探讨了 2024 年的数据流格局，总结现有解决方案和市场趋势。文章最后对 2025 年潜在新进入者进行了展望。
加入数据流社区并通过订阅我的新闻通讯随时了解新博客文章.
数据流是一个新的软件类别
实时数据胜过慢速数据。对于任何行业的几乎所有用例都是如此。由数据流驱动的事件驱动应用程序是新的黑色。这种方法通过增加收入、降低成本、降低风险或改善客户体验来提高业务价值作为总体目标。
存在大量的软件类别和相关数据平台来处理和分析数据：
- 数据库：存储和执行事务工作负载。
- 数据仓库：处理结构化历史数据以创建重复报告和独特见解。
- 数据湖：通过批处理处理结构化和半结构化或非结构化大数据集，以创建重复报告和独特见解。
- Lakehouse：数据仓库和数据湖的混合体，用于在一个平台上处理所有数据。
- 数据流：持续处理动态数据并提供跨通信范式（例如实时、批量和请求响应）的数据一致性，而不是仅存储和分析静态数据。
当然，这些数据平台通常会有一些重叠。我制作了一个完整的博客系列，探索用例以及它们如何相互补充。
- 数据仓库、数据湖、数据流——是朋友、敌人还是亦敌亦友？
- 用于将数据引入数据仓库和数据湖的数据流
- 数据仓库现代化：从传统开始-云原生基础设施的前提
- 案例研究：用于数据仓库现代化的云原生数据流
- 经验教训来自构建云原生数据仓库
Forrester Wave™：流数据平台，2023 年第 4 季度
Forrester 是一家领先的研究和咨询公司，提供有关技术、业务和市场趋势各个方面的见解和分析。
该公司以其深入分析、市场研究报告和框架而闻名，可帮助组织应对快速变化的技术和业务格局。企业和 IT 领导者经常利用 Forrester 的研究来了解市场趋势、评估技术解决方案并制定战略以保持各自行业的竞争力。
2023 年 12 月，该研究公司发布了“Forrester Wave™：流数据平台，2023 年第 4 季度”。 在此处免费访问该报告。领先者是 Microsoft、Google 和 Confluence，其次是 Oracle、Amazon、Cloudera 和其他一些公司。
您可能同意或不同意特定供应商关于其产品或策略优势的立场。但这一新浪潮的出现证明了数据流是一个新的软件类别；不仅仅是另一个炒作或下一代 ETL / ESB / iPaaS 工具。
按业务价值划分的数据流用例
新的软件类别打开了用例并增加了所有行业的业务价值：
增加业务价值对于任何企业都至关重要。有了如此多的潜在用例，越来越多的软件供应商在他们的产品中添加 Kafka 支持也就不足为奇了。在我的博客中搜索您最喜欢的行业，找到大量案例研究和架构。或者阅读Apache Kafka 跨行业用例开始使用。
2024 年的数据流格局
数据流是数据平台的一个单独的软件类别。许多软件供应商围绕这一类别构建了他们的整个业务。数据流领域显示，大多数供应商都使用 Kafka 或实现其协议，因为 Apache Kafka 已成为数据流事实上的标准。
过去几年，这一类别中出现了新的软件公司。数据市场中的一些成熟参与者在其平台或云服务生态系统中增加了对数据流的支持。大多数软件供应商都使用 Kafka 作为他们的数据流平台。然而，不仅仅是卡夫卡。一些供应商仅使用 Kafka 协议（Azure 事件中心）或完全不同的 API（例如 Amazon Kinesis）。
以下《2024 年数据流格局》总结了相关产品和云服务的现状。
论云服务和 BYOC 的未来。”杰克探索了以下神话：
- 误区 1：BYOC 通过将数据保留在您的帐户中来提高安全性。
- 误区 2：BYOC 更便宜，总拥有成本 (TCO) 也更低。
我用这两张图总结了这个故事，并强烈建议阅读 Jack 关于 BYOC 及其权衡的详细文章：
来源：Jack Vanlightly
以下是 Jack 的结论：“正如客户从架设自己的硬件转向云一样，那些尝试 BYOC 的客户也会因为其简单性、可靠性、可扩展性和成本效益而迁移到 SaaS .”我完全同意。
流媒体类别：原生 Kafka、协议兼容性与流处理
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 等核心消息传递解决方案。
- 红帽：IBM 的战略转变（再次）。红帽关闭了其云产品“Red Hat OpenShift Streams for Apache Kafka”，并将对话转向 IBM 产品。我用 IBM 替换了徽标，IBM 仍然提供 Kafka 云产品。但需要明确的是：红帽 AMQ Streams（即自我管理的 Kafka + Strimzi Kubernetes 运算符）仍然是一款畅销产品。
已添加
- WarpStream：使用 Kafka 协议的完全托管云服务的新进入者。
- Confluence：通过 Kafka Streams、ksqlDB 和 Apache Flink（通过收购 Immerok）添加到流处理类别中。
- Ververica：多年来一直提供 Flink 平台。老实说，不知道为什么我去年错过了他们。
- 适用于 Apache Flink (MSF) 的 Amazon 托管服务。以前称为 Amazon Kinesis Data Analytics (KDA)。添加到部分托管流处理。
- Google DataFlow：添加到完全托管的流处理中。
已删除
这是一个有争议的部分。因此，我再次强调，这只是我在该领域所看到的，而不是统计研究或调查。
- Google Pub/Sub：专注于数据流，而不是消息代理。
- TIBCO：不用于数据流（除了金融服务市场中用于低延迟交易的 TIBCO StreamBase）。
- DataStax：我不太了解开源 Apache Pulsar。而且我根本没有看到 DataStax 的 Pulsar 提供 Luna Streaming 来获得市场上的任何吸引力。此外，供应商似乎又进行了一次战略转变，现在更加关注向量数据库和生成人工智能 (GenAI)。
- 镜头 + 导体：我移除它们的原因并不是因为它们没有被使用。这些都是很棒的工具。但这种格局侧重于数据流平台，而不是补充管理、监控或代理工具。围绕 Kafka 同时存在如此多的工具 – 这值得有自己的景观或比较文章。
- Pravega：2023 年我在该领域还没有看到过这项技术。
- Immerok：被 Confluence 收购。
- Hazelcast：我没有在现实世界中的数据流场景中看到它。该技术以内存数据网格而闻名，但不适用于流处理。
正如我在上面提到的 Forrester Wave，您可能会意识到我并没有包括报告中的所有“表现出色”。例如，TIBCO、SAS 或 Hazelcast。因为在我关于事件驱动架构和流处理的对话中，我没有看到这些供应商有任何吸引力。这不是统计证据，也不是试图让其他工具变得糟糕。
数据流平台的评估标准
我经常建议使用以下四个方面来查看不同的框架、平台和云服务，以评估适合您的业务项目或企业架构策略的技术：
- 云原生：解决方案是否具有弹性扩展和缩减？它是完全托管/无服务器，还是只是托管在云中的一堆服务器实例？您能否使用 DevOps、GitOps、测试驱动开发和类似原则来自动化开发、运营和测试流程？
- 完整：该解决方案是否提供所有必需的功能？数据流需要的不仅仅是消息传递或数据摄取。那么，它是否提供连接器、数据处理、治理、安全性、自助服务、开放 API 等？
- 任何地方：您可以在哪里使用该解决方案？仅云？是否支持所有必需的云服务提供商？是否可以选择在数据中心甚至边缘（即数据中心外部）部署，例如工厂、手机信号塔或零售店？如何在区域、云或数据中心之间共享数据？它支持哪些用例（例如聚合、灾难恢复、混合集成、迁移等）？
- 支持：该解决方案是否成熟并经过实战检验？公共案例研究是否适用于您的用例或行业？供应商是否完全支持该产品？ SLA 是什么？商业企业支持是否排除了特定功能？一些供应商提供数据流云服务（例如托管 Kafka 服务），并在条款和条件中排除支持（遗憾的是，许多人在公共云服务中不会阅读这些条款和条件）。
让我们更深入地了解不同的数据流类别，并从领先的技术开始：本机 Apache Kafka…
用于数据流的原生 Apache Kafka
从领先的数据流技术、Apache Kafka 以及相关供应商和 SaaS 产品开始。
过去几年 Apache Kafka 社区的发展令人印象深刻。以下是 Jay Kreps 去年在德克萨斯州奥斯汀举行的数据流会议“当前 – 下一代 Kafka 峰会”上介绍的一些统计数据：
- >100,000 个组织使用 Apache Kafka
- >41,000 名 Kafka 聚会参与者
- >32,000 个 Stack Overflow 问题
- >12,000 个适用于 Apache Kafka 的 Jiras
- >31,000 个空缺职位列表需要 Kafka 技能
并查看使用 Maven 下载 Kafka Java 客户端库的每月活跃唯一用户数量的增加：
来源：Sonatype
Apache Kafka 供应商：自我管理与云产品
新软件公司专注于数据流。甚至IBM、甲骨文等老牌公司在过去几年也紧随潮流。在顶层 – 为了简单起见 – Apache Kafka 存在三种产品：
我做了详细的使用汽车类比对本地 Kafka 供应商和云服务进行比较。在编写此比较时，只有 Amazon MSK Serverless（即完全托管的服务，而不是部分托管的 MSK）不可用。因此，另请阅读 Confluence 云与 Amazon MSK 无服务器。
以下是对每种技术的一些注释作为摘要。
- Apache Kafka：数据流事实上的标准。开源并拥有庞大的社区。此列表中的所有供应商都依赖此项目（部分）。
- Confluence：通过 Confluence Platform（自我管理）和 Confluence 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 云区域可用；不适用于前哨站、本地区域、波长等。
- 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 事件中心：成熟、完全托管的云服务。该服务做了一件事，而且做得非常好：通过 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”更名为“当前 – 下一代 Kafka Summit”。为什么？因为数据流不仅仅是 Kafka。许多互补和竞争的技术都出现了，包括供应商、展位、演示和客户案例研究。对于全球社区和企业来说，这是数据流的一次显着发展！
Apache Flink 正在成为流处理的事实上的标准。 Flink 的崛起看起来与几年前 Kafka 的采用非常相似：
但不要低估 Kafka Streams 的 Kafka 原生流处理的能力和用例。由于 Kafka Streams 易于使用，因此采用率很高。它是 Apache Kafka 的一部分。
一些流处理产品与 Kafka 是互补的
每个流处理框架或云服务都有权衡。虽然 Flink 受到了很大的关注，但还有其他一些。没有适合所有用例的单一尺寸。以下是一些可以补充 Apache Kafka 的成熟和新兴技术。
开源流处理框架
- Kafka Streams：开源 Apache Kafka 的一部分。因此，如果您从 Apache 网站下载 Kafka，它始终包含该库。您应该始终问自己除了 Kafka Streams 之外是否还需要另一个框架来进行流处理。显着优势：一种技术、一种供应商、一种基础设施。
- ksqlDB（通常称为 KSQL，即使在更名后也是如此）：Kafka Streams 之上的抽象层，用于通过流式 SQL 提供流处理。因此，也是卡夫卡原生的。它附带 Confluence 社区许可证，并且可以免费使用。最佳点：流式 ETL。
- Apache Flink：领先的开源流处理框架。高级功能包括强大的可扩展计算引擎（与 Kafka 分离）、开发人员可以在 ANSI SQL、Java 和 Python 之间自由选择、用于复杂事件处理 (CEP) 的 API 以及用于流和批处理工作负载的统一 API。
- Spark Streaming：开源大数据处理框架 Apache Spark 的流处理部分。我仍然没有百分百相信。 Kafka Streams 和 Apache Flink 是流处理的更好选择。然而，企业中 Spark 集群的庞大安装基础扩大了采用范围。
流处理供应商和云服务
- Ververica：知名的 Flink 公司。 2019 年被中国巨头阿里巴巴收购。在欧洲和美国吸引力不大，但在亚洲绝对是 Flink 的专家。就我个人而言，我从未见过该供应商在亚洲以外的地区使用过。
- 可解码：新的云服务。非常早期的阶段。我仍然添加了它，因为我认为在 Apache Flink 之上构建数据流云服务是一个非常好的战略举措。如果与企业现有的 Kafka 基础设施相结合，潜力巨大。而且还为非 Kafka 系统提供预构建的连接器。
- Amazon Managed Service for Apache Flink (MSF)：AWS 提供的（几乎）完全托管服务，允许客户使用 Apache Flink 实时转换和分析流数据。它仍然为自动扩展提供了一些（成本高昂的）差距，并且并不是真正的无服务器。支持所有 Flink 接口，即 SQL、Java 和 Python。还有非 Kafka 连接器。仅在 AWS 上可用。
- 融合云：真正的无服务器 Flink 产品，具有弹性，如果不使用，可以扩展到零。一开始只支持SQL。 Java 和 Python 支持将于 2024 年推出。首先在 AWS 上提供，但预计将于 2024 年初在 GCP 和 Azure 上提供。与完全托管的 Kafka、架构注册表、连接器、数据治理和 Confluence 的其他功能深度集成。为数据流管道提供无缝的端到端开发人员体验。
- Databricks：是 Apache Spark 背后的领先供应商。如今，没有人再谈论 Spark（即使它是 Databricks 云平台的关键技术部分）。尝试更多地涉足实时数据业务。我喜欢这个用于分析、报告和人工智能/机器学习的平台。但我并不相信“在一个大数据湖内完成所有事情”的数据湖屋故事。
这些服务中的大多数都可以与其他供应商的解决方案配合良好。例如，Databricks 可以轻松地与任何 Kafka 环境集成，或者 Amazon MSF 直接连接到 Confluence 的 Kafka。
Apache Flink（或 Spark Streaming）没有 Kafka？
大多数流处理技术都是 Apache Kafka 的补充。但像 Flink 这样的流处理框架或像 Databricks 这样的云服务不需要 Kafka 作为摄取层。还有其他选择…
Flink、Spark 等。可以使用来自其他流媒体平台或直接来自文件或数据库等数据存储的数据。小心后者：如果您使用 Flink 或 Spark Streaming 进行流处理，那就没问题。但如果首先要做的是从 S3 对象存储中读取数据，那么，这就是静态数据。
但是：数据流市场的一个常见趋势是在事件流平台内长期存储（某些）事件。特别是，引入 Kafka 分层存储改变了功能和用例。一些供应商通过 S3 接口对对象存储的支持可能会彻底改变游戏规则，用于使用 Kafka 协议或其他分析引擎和数据库以近实时或批量方式实时存储和处理事件。 Apache Iceberg 可能是我们谈论的 2025 年流媒体领域的下一个趋势。
并了解流处理应用程序也可以保留状态： Kafka Streams 或 Flink 应用程序的后端可以为您的任务（例如丰富目的）存储状态。流处理应用程序不仅仅涉及实时数据源。它还将这些实时源与（已摄取的）历史数据相关联。对于更新频率较低的元数据或业务数据（例如来自 SAP ERP 系统），这是一种常见方法。
一些流处理产品与 Kafka 具有竞争力
在某些情况下，您必须评估 Apache Kafka 或其他技术是否是正确的选择。以下是一些开源和云竞争对手：
- Amazon Kinesis：将数据提取到 AWS 数据存储中。针对特定问题的成熟产品。仅在 AWS 上可用。
- Google Cloud DataFlow：完全托管的服务，用于在 Google Cloud Platform 生态系统中执行 Apache Beam 管道。针对特定问题的成熟产品。仅在 GCP 上可用。
- 在 Kafka 和 Flink 世界之外，围绕流处理出现了许多有竞争力的初创公司。让我们看看其中一些是否会在 2024 年受到关注。
如果您“只是”想将数据提取到特定的云存储中，Amazon Kinesis 和 Google Cloud DataFlow 都是出色的云服务。如果没有其他用例，这些工具可能是正确的选择（如果大规模定价和其他限制适合您）。
Apache Kafka 是一个更加灵活且更具战略性的数据流平台。许多项目仍然从数据摄取开始并构建第一个管道。但是，向任何其他数据接收器提供对相同事件流的访问或使用 Kafka Streams 或 Apache Flink 等工具进行强大的流处理是一个显着的优势。
2025 年数据流格局的潜力
数据流是一个旅程。事件流平台和云服务的发展也是如此。一些成熟的软件和云供应商可能会因其数据流产品而获得更多关注。一些初创公司可能会显着增长。以下显示了一些可能在 2024 年发展并得到广泛采用的技术：
- 数字海洋或 Oracle 云基础设施 (OCI) 流等其他 Kafka 云服务可能会获得更多关注。我还没有在现场看到过这些。但例如，对于某些用例，某些组织可能会对将 Oracle GoldenGate 与 OCI Streaming 相结合感兴趣。
- Hazelcast 进行了重大品牌重塑，并成为 Forrester 流数据浪潮的一部分。通过本地部署和无服务器云产品，该技术可能会吸引数据流，并在明年回到我的领域。
- 像 Materialise 或 RisingWave 这样的流数据库可能会成为自己的类别。我的感觉：炒作周期的超级早期阶段。我们将在 2024 年看到这项技术是否、在哪里得到更广泛的采用，以及用例是什么。很难回答这些将如何与 Apache Druid、Apache Pinot、ClickHouse、Rockset、Timeplus 等新兴实时分析数据库竞争。我知道存在差异，但更广泛的社区和公司需要 a) 了解这些差异并 b) 为其找到业务问题。
- Quix 和 Bytewax（均使用 Python 进行流处理）、DeltaStream（由 Apache Flink 提供支持）等 SaaS 初创公司已经出现。让我们看看哪一个凭借创新的产品和商业模式在市场上受到关注。
- 现有的多产品企业通过单独的 Flink 服务围绕 Kafka 扩展其产品。例如，Aiven 同时已经推出了 Flink 产品，可能会像 Kafka 产品一样受到关注。
- MongoDB 或 Snowflake 等传统数据管理供应商试图更深入地涉足数据流业务。我仍然支持关注点分离；因此，我认为这些应该保持其最佳位置，并且（仅）提供流式摄取和 CDC 作为用例，但不（尝试）与数据流供应商竞争。
有趣的事实：几乎所有新兴初创公司的商业模式都是完全托管的云服务，而不是销售本地部署的许可证。许多基于开源或开放核心，而另一些则仅提供专有实现。
数据流之旅是漫长的……
数据流不是一场竞赛，而是一段旅程！ Apache Kafka 或 Apache Flink 等事件驱动架构和技术需要在架构、开发、部署和监控应用程序方面进行思维转变。传统集成、云原生微服务以及跨混合和多云设置的数据共享是常态，而不是例外。
2024 年的数据流格局展示了新软件类别的兴起。我们仍处于早期阶段。创建一个新的软件类别需要时间。在与客户、合作伙伴和社区的大多数对话中，我听到这样的说法：“我们看到了价值，但我们还没有实现——我们现在开始构建第一个数据流管道，并制定了未来几年添加更多数据流管道的路线图。高级流处理。”
