在过去的文章里面经常会提到云原生大数据、存算分离架构、传统大数据的转型和迭代还有对于数据仓库相关的技术，对于流计算相关的好像涉及的非常少，但不得不说，流计算是目前以及未来大数据发展的主要趋势，无论是AI时代需要实时的数据流交互，还是在实际的处理业务场景中对于实时性的要求都会越来越高。

架构的简单化

为什么大数据技术这些年发展的会那么快，基本上每年都会有一些新的技术诞生，也或许是一个新的数据处理手段出现，原因并不是现在技术不能满足业务需求，而是使用成本和复杂度越来越高，在软件开发领域有一个“3-5年法则”，也就是说一套系统性的程序，再经过3-5年的时间之后，就会有一个新的重构版本出现，要么是这个系统废弃了，要么是这个系统得到了系统性的升级改造，在大数据领域来说，最近的十多年基本上没一两年就出现一些重大的技术组件更新，从hadoop、kafka、spark、storm、flink、doris、elasticserach、hudi、iceberg再到现在的一些向量化能力支持等等，从时间轴上来看，大约在3-5年的时间。

那回到架构简单化，回想对于大数据组件升级有多少是因为现在的组件不能够满足业务需求而升级的？ 我认为这种情况是少部分，而大部分来说，是因为现在的组件维护成本太高，一套业务实现下来，可能需要7，8个甚至更多的大数据组件来支撑，那这里面每个环节都需要来运维维护，从可靠性、稳定性、冗灾能力等等方便都要考虑，所以，从近些年云原生大数据、数据湖技术开始，整个技术组件生态都是简单化去演变。

其实近几年对于计算引擎的迭代来说，大家会发现大多数的计算引擎都设计了自己的数据湖引擎，例如：Flink推出了Fluss和Paimono来实现其流场景的服务能力，Databricks的Delta Live Tables 来支持基于Spark Streaming的场景，为什么所有这些流处理系统都在向整合存储和服务的方向发展？答案还是在于简化架构。传统上，流处理系统被设计来处理数据，而存储和服务层由独立的系统管理。然而，为单个应用程序维护多个系统会引入显著的操作开销，增加复杂性和成本。通过将摄取、处理和服务层整合到一个系统中，流处理平台可以实现更流畅的数据流动，减轻维护负担。

流计算的存算分离设计

从数据仓库到数据湖，从分布式文件存储到对象存储，从分布式计算和存储的一体化部署到计算和存储的分开部署，计算保持弹性、灵活的能力，存储支撑海量、可扩展、低成本的能力，这些在过去几年发展基本都比较成熟了，无论是国内外都有相关的成熟产品可以供参考和使用，但是，貌似对于流计算来说，存算分离架构设计一直还没有大的改进。

流计算里面最核心的就是状态维护，需要通过不断记录内部信息来进行增量计算，而现在状态维护基本都是在引擎本身去维护的，一般都是在本地内存或者磁盘中保存，而采用存储和计算分离的架构模式，则可以将状态保存到对象存储中，对象存储相比于本地来说，成本更加的低廉、扩展性也更好，当在流计算处理大型状态（有时候比较大的状态信息，会导致计算Task进程OOM）操作时，

当然，这里还有一个很关键的问题，就是S3这种对象存储引擎他们的数据查询延迟是比较大的，如果不是一个精准的Key来查看，而是模糊匹配的话，那么它会通过scan的方式来全局扫描，这可比我们过去所使用的文件系统类的操作要慢好多，所以，对于流处理的来说这目前依旧是一个关键突破点。

不过，在技术领域中有一个非常好的氛围，对于工程师来说，遇到问题就会想办法去解决问题，那么对象存储的问题来说，也会有对应的一些开源解决方案，例如JuiceFS可以直接挂在S3、OSS等等的对象存储，可以实现像访问本地文件系统来访问对象存储的数据，这里面还支持分布式缓存能力，在某种程度上也算是解决了一些问题，但是在流计算的场景中，这些依旧无法彻底满足。

另一个解决方案是Alluxio，它是位于计算和存储之间的一个分布式服务，可以简单理解为在我们计算引擎和对象存储服务之间，有一个Alluxio的分布式服务，我们不直接操作对象存储服务，而是通过它来操作，Aullxio借助自身的分布式缓存、元数据管理、透明加速能力，可以让我们像访问HDFS一样访问对象存储服务，这种场景在对于大数据开发来说非常友好。

在2025年，流计算在基于S3这种对象存储服务的作为基础架构的应用场景会越来越多，对应的流计算技术的支撑能力也会越来越强，例如：在Flink2.0版本中就引入了存储计算分离的计划，这里对于混合存储、分布式缓存系统以及更多的缓存策略有很多特性的演进，如果没有这些缓存策略，在实际生产环境中很难能够支撑大数据量、高负载的处理效率。

然而，数据流和数据湖的融合不仅仅是关于数据摄取。随着 Databricks 的 Delta Live Tables 功能，对数据湖上增量计算的需求日益增长。由于 Iceberg 还没有完全支持 CDC（变更数据捕获），所以在iceberg中还无法提供对于增量数据的计算能力，但是在icerberg V3的版本设计中，已经有了关于这方面的提案设计。

所以，从Lakehouse到StreamHouse的时刻某种意义上即将到来，在数据湖的这个短短几年的发展中，将迎来新的里程碑。

Kafka作为流处理必然绕不过去的

既然在聊流计算技术的方向，那么Kafka是其中的核心话题之一，在这么多年的流计算领域里，kafka已经是作为数据流传输的既定标准，然而，Kafka 并非是唯一能够促进数据传输的工具，在流计算系统中也支持对于数据源的数据集成能力，例如Flink、Spark Streaming这样的系统可以直接支持从上游的Postgres、Mysql和MongoDB中消费CDC（变更数据捕获）数据，所以，这也对整个流处理架构进行了优化。

但是，不得不说Kafka依旧是大数据生态中的核心主导位置，而且其本身也支持了Kafka Stream和ksqlDb的能力，但是在大规模复杂的数据场景中，这些还是过于耦合了，只能说作为一个单点集成能力在进行使用，目前还没见过在真实的业务场景中，直接使用Kafka的stream和sql来对接线上能力的。

而Apache Pulsar作为最近几年非常活跃的基于存算分离的消息队列引擎，新的架构模式、新的性能吞吐量以及和周边生态的集成能力的快速迭代，也得到了越来越多的认可，我们目前就有很多业务在大规模的使用pulsar在进行数据类的传输。

从未来几年来看，流计算系统不太可能取代kafka来作为数据流的平台，Kafka作为虽然是一个消息流系统，但是也充当着对于数据容错、故障转移、数据顺序性等等角色，应用的场景非常的广泛，这些在流处理系统中是无法直接满足的，所以，这些也确保Kafka在整个大数据生态系统的位置是很难以撼动的。

最后

人工智能现在已经是全社会都在讨论的话题，那在大数据技术领域中，计算引擎系统也在面临着更快速的迭代，来适配人工智能相关的需求，例如过去OLAP引擎相关都不具备向量化能力，现在StarRocks、Click house、TiDB已经支持使用向量化数据库能力来进行向量搜索了，这是在大数据领域中非常重要的一个趋势，后面可以结合计算引擎的CDC的能力（和消息队列系统）来进行实时进行数据采集，计算引擎基于数据特征进行数据处理和标注，最后将数据保存在向量化数据库中，在实际业务中进行实时的问答以及结合智能BI分析能力，来展示实时的智能分析能力。