文：吴梦麟（韩述）
Why
2023年作为“生成式人工智能（AI）元年”，开启了一个恢弘浩大的AI时代。生成式人工智能正深刻地改变着千行百业。数据分析（Data Analysis）领域也不例外——AI赋予了各类应用更高的智能性与更强的自动化能力。数据的产生方式，正从过去以人工触发为主（如购物下单、金融交易、页面访问等），逐步过渡到以AI智能行为为主（如智能推荐、自动交易、Agent代理访问），这也自然催生了数据的大爆炸，以及数据分析和挖掘频率的急剧上升，甚至轻松跨越多个数量级。简单来说：
- 数据的产生变多了
- 数据的访问变多了
- 多了好几个数量级
随着数据量以跨数量级的方式增长，数据访问和处理的范式也在发生转变。传统的全量计算方式，由于数据产生侧（即计算所涉及的数据量）和数据访问频率（即计算执行的次数）都发生了数量级层面的质变，其运行效率问题被成倍放大。相比之下，增量计算因其计算开销与数据总量和计算次数不呈线性关系的特性，正日益凸显出显著优势。顺应这一趋势，阿里云AnalyticDB团队近期在VLDB 2025上发表了关于增量计算的最新研究成果——论文《Streaming View: An Efficient Data Processing Engine for Modern Real-time Data Warehouse of Alibaba Cloud》。本文将对该工作进行简要介绍。
What
增量计算 VS 全量计算
如下图所示全量计算是一种相对简单且直观的计算范式。每当发生查询需求时，系统都会对全部数据进行一次完整的计算，其优势在于逻辑清晰、易于理解，并且能够支持几乎所有的SQL语法。
然而，其缺点在于计算开销与数据量大小以及查询次数呈线性关系，且这两个维度是相乘的——通常可表示为：
全量计算开销 = 数据的总量大小 × 查询计算次数
在AI时代，数据生成日益自动化，查询的触发方式也从人工操作逐步转向由智能体自动发起，导致数据量和查询频次双双呈现数量级的增长。在此背景下，全量计算所带来的性能压力和资源消耗问题愈发突出，其局限性也随之显著显现。相对而言，增量计算的优势则愈发凸显，因为其开销与数据的总量和查询次数无关，仅与数据的增量大小有关：
增量计算开销 = 数据的增量大小
如下图所示增量计算在首次执行时会进行一次全量计算，生成一份基线数据；后续的计算则基于这份基线，结合数据的变更进行渐进式更新。
不过增量计算的挑战是显而易见的：无论是在实现难度还是使用门槛上，都显著高于全量计算。从实现角度看，每一种语法和算子都需要专门支持增量语义，其实现复杂度远超传统的全量计算。同时，由于增量计算是一种递进式的计算过程，数据一致性的维护也更加困难。此外，增量计算使用门槛也更高。由于计算范式的转变，数据模型的设计、业务逻辑的构建，都需要围绕渐进式计算进行重构和适配，对开发和运维提出了更高的要求。
现实中增量计算与全量计算的关系，非常类似于最近的热点新闻中常被提及的 LNG 船运（对应全量计算）与管道天然气（对应增量计算）之间的关系。LNG 船运灵活便捷，无需前期大规模建设，能够快速调配运力，按需输送天然气——这正如全量计算，启动简单、无需预处理，每次查询独立执行。而管道天然气则不同，前期建设成本高昂，正如增量计算需要预先完成基线数据的构建，以及对业务模型和数据架构进行改造以适配增量范式。但一旦管道建成并稳定运行，后续的天然气输送成本就极低，且可持续、高效地供应。
流计算引擎 VS 传统IVM VS StreamingView
▶︎ 流计算引擎
传统上，以 Flink、Spark Streaming、Storm 等为代表的独立实时计算引擎，是增量计算领域的标杆，在生产业务中被广泛部署和长期使用。这类系统专门设计了一套流计算范式——可视为增量计算的一种变体。通过引入水位线（Watermark）、窗口（Window）等核心机制，有效降低了在无界数据流上实现渐进计算与状态管理的复杂度。
然而，这种简化并非没有代价：本质上仍是以牺牲部分计算精度或延迟可控性为前提。因此，在实际应用中，业务往往需要做出较大适配，例如对时间语义的重新建模、对乱序数据的容忍，以及在数据一致性方面接受“近似正确”而非严格一致的结果。
此外，独立流计算引擎还存在一个显著痛点：数据与数据流转链路的冗余。尤其在数仓分层架构中，数据需在 OLAP 数仓（如 ClickHouse、Doris、Greenplum 等）与流计算引擎之间反复流转，导致大量重复存储与传输，消耗可观的计算和网络资源。同时，开发链路割裂、运维复杂度高，无论是在资源成本还是人力维护成本上都居高不下，这也使得“流计算很贵”成为业界普遍的认知。
▶︎ 传统IVM
与独立流计算引擎在工业界被广泛应用相对应的，是传统数据库领域中的物化视图（IVM, Incremental View Maintenance）。尽管 IVM 在理论界早已被广泛而深入地研究，但在工业级实现和落地应用方面，其进展长期滞后于流计算引擎。
这一现象的背后原因有多方面。首先，一个完善的增量计算范式本身具有较高的复杂性，而流计算引擎之所以能在生产中快速普及，很大程度上正是通过对增量计算范式进行了简化——例如引入窗口、水位线等抽象，降低状态管理与一致性处理的难度。但这种简化本质上是一种权衡，以牺牲部分语义严谨性或计算精度为代价，换取系统可实现性与工程可行性。
另一方面，传统的 IVM 技术更多聚焦于查询加速这一目标，其设计初衷是在读多写少的场景下。因此，系统往往偏向“轻写重读”的假设，面对当前大数据环境下高吞吐、持续更新的现实需求，传统 IVM 的架构和机制显得力不从心。正因如此，尽管 IVM 发展多年，并已有若干工业级实现（如 Oracle、SQL Server 中的物化视图），但真正用于支撑大规模、高频率、实时性强的增量计算生产场景的案例仍然有限。
▶︎ StreamingView
StreamingView 作为阿里云在 AnalyticDB（ADB）数仓内部设计与开发的增量计算引擎，其核心实现原理在一定程度上借鉴了传统 IVM（物化视图增量维护）的技术思路，但在目标定位和工程实现上实现了重要突破。
其主要目的，是为了解决传统独立流计算引擎所带来的数据反复出入仓的问题——避免在 OLAP 数仓与外部流引擎之间频繁流转数据，从而消除由此带来的存储冗余、传输开销和链路复杂性，显著简化数仓分层架构，降低整体资源与运维成本。
在此基础上，StreamingView 深度融合了 IVM 的增量计算理论，构建了一套完备的原生增量计算范式。用户无需关心传统流计算中复杂的水位线（Watermark）、窗口（Window）、状态管理等概念，即可实现持续更新的实时计算，大幅降低了使用门槛。
同时，StreamingView 并未局限于传统 IVM 常见的“轻写重读”查询加速场景。相反，它采用最终一致性模型，并针对流式数据的高吞吐特性，集成了多项面向增量数据处理的深度优化技术，在数据摄入能力、处理性能和语法支持完备性方面，甚至超越了部分传统流计算引擎。
此外，StreamingView 还集成了生产实践中大量针对增量计算的细节优化，使得在大规模生产环境中增量计算的性能和稳定性大幅提高。更详细的 StreamingView 技术细节介绍可以具体参考论文原文。
由此，StreamingView 实现了在数仓内部即可高效、低成本且持续稳定地完成大规模增量计算的能力。如今，这一能力已在阿里云多个大型生产环境中广泛落地应用，支撑了实时数仓、近实时分析、持续聚合等多种典型场景，成为 ADB 构建一体化实时数据处理体系的核心组件之一。
Result
在实验部分，论文对比了当前最流行的流计算引擎及主流商业数据库。无论从增量计算的吞吐量（如下图，相同硬件资源下的吞吐能力，StreamingView有2～7倍以上的优势）、性能表现，还是增量计算所覆盖的语法场景等多个维度来看，StreamingView均展现出显著优势。
更为重要的是，StreamingView已作为云服务集成于阿里云AnalyticDB PostgreSQL产品中，面向客户开放使用。截至目前，已有大量客户在生产环境中大规模采用StreamingView构建复杂的增量计算链路。例如，论文中展示了一个真实的线上案例：某电商客户在拥有数十个节点的AnalyticDB PostgreSQL集群上，管理着数百TB的数据，基于这些数据构建了数十个StreamingView，形成了复杂的增量计算流程。其中相当一部分计算涉及10张表以上的复杂SQL，写入端每秒处理数万至数十万行的数据增量更新。StreamingView能够稳定提供秒级的增量计算延迟；在大促等峰值时段，延迟仅有小幅上升，随后迅速恢复。这充分体现了其能够广泛适应复杂场景，并且对高吞吐、低延迟以及负载波动的良好自适应能力。
总结
生成式人工智能（AI）的快速发展驱动数据量与数据访问频率双双迅猛增长，推动数据分析领域从全量计算时代逐步迈向增量计算时代。阿里云顺应这一趋势，于VLDB 2025发表了论文《Streaming View: An Efficient Data Processing Engine for Modern Real-time Data Warehouse of Alibaba Cloud》，系统介绍了阿里云AnalyticDB PostgreSQL中内置的StreamingView（实时物化视图）功能。该产品提供了一条高性能、低成本的演进路径，帮助用户实现从传统全量计算范式向增量计算范式的平滑过渡。依托云计算的便捷性，用户可轻松在云端获取这一能力。欢迎更多有需求的业务通过云服务体验并使用云原生数据仓库 AnalyticDB PostgreSQL 版的 StreamingView 能力。
👉欢迎 钉钉搜索群号：11700737 入群交流
