展望 RisingWave 2.0: 提供流批一体功能的 SQL 数据库

1我们取得了哪些成就？

我们对所构建的产品充满自豪，并坚信我们的技术具有颠覆行业的潜力。尽管市面上已有诸如 ksqlDB、Apache Spark Streaming 和 Apache Flink 等成功的流处理项目，许多人在面临流处理需求时依然选择或正在转向 RisingWave。最近，我们在社区进行了一项调查，以下是我们的发现。

用户选择 RisingWave 的三大理由：

1. 简单易用：大多数人更愿意专注于构建业务应用，而不是花费数周时间学习新工具。RisingWave 兼容 PostgreSQL，因此用户无需学习复杂的 Java/Scala API 或专用 SQL 方言。它还提供 UDF 和 API 等工具，便于与现有数据栈无缝集成。同时，它简化了内部复杂性，如状态管理，用户无需为处理大型工作负载配置存储引擎（如 RocksDB）。
2. 简化的数据栈：传统上，构建流处理应用程序需要整合多个组件，如消息队列（例如 Kafka）、流处理器和服务数据库。RisingWave 将数据摄取、计算和服务功能集成在一个系统中，使用户能够轻松构建和运行流处理应用程序。
3. 成本效益：许多数据驱动的企业需要处理涉及连续有状态计算的复杂业务逻辑，如连接（Join）、聚合（Aggregations）和时间窗口（Time windowing）。RisingWave 对这些复杂查询进行了高度优化，能够以极低的成本实现高效处理。

用户最喜爱的十大功能：

• PostgreSQL 协议兼容
• 丰富的 Source 和 Sink 集成
• 高性能流式 Join
• 动态扩缩容
• 即时故障恢复
• 无服务器数据回填
• 支持 UDF、UDAF 和 UDTF
• 自动化模式更改
• 全面支持流式 SQL（包括水印、时间窗口和时间过滤）
• 时间旅行功能

目前有数百家企业和初创公司信任 RisingWave。我们相信它已经成为顶尖的 SQL 流处理系统之一。过去两年，我们致力于降低流处理的学习和应用门槛，使其更易上手。随着 RisingWave 功能日益强大，我们的视野也在不断扩大，不仅关注流处理体验的优化，更在思考如何满足用户在数据栈中的深层次需求。为了将 RisingWave 推向更高的水平，我们正在构建全新功能。

2流批一体

经过数月的调研，我们得出结论：必须提供流批一体功能。当然，这并不意味着 RisingWave 将转向批处理系统。

实际上，越来越多的企业正迈向“流优先”的发展路径，它们需要处理实时数据以获取即时洞察。这种趋势不仅在对延迟敏感的行业（如金融）中显而易见，在制造和能源等传统行业中，实时数据同样在推动决策。然而，仅靠流处理并无法满足所有需求，很多场景中，企业仍需使用批处理来构建完整的应用程序。以下三大经典场景突显了流批一体系统的重要性：

持续监控和分析

在持续监控和分析场景中，用户通常需要将事件流（如来自 Kafka）与批表（如来自 S3 或 Postgres）进行 Join。比如，营销团队常常需要将实时点击流与用户档案或 CRM 数据进行实时结合。要支持这些场景，系统必须能够批量加载 S3 数据，持续摄取 Kafka 流数据，并实现事件流与批数据的实时连接。

特征工程和时间序列分析

在特征工程和时间序列分析场景中，用户希望批处理和流处理使用相同的代码。在两个不同系统中开发相同逻辑容易导致错误和不一致。例如，为了避免生产中性能下降，训练和推理的特征转换必须保持一致。理想情况下，系统应能够有效地同时转换批处理和流处理数据，并将其分别传送到离线存储（如 S3）用于训练和在线存储（如 Redis）用于实时推理，以确保一致的模型性能。

指标和事件存储

在处理指标和事件存储时，用户希望在分析新插入数据的同时，低成本地存储和分析历史数据。例如，在计费系统中，用户可能希望实时监控消费峰值，同时使用历史数据构建数据看板。

显然，流批一体系统有极大需求。基于此，我们展望未来，计划发布 RisingWave 2.0——提供流批一体功能的 SQL 数据库。

3RisingWave 2.0 的主要关注点

我们的目标不是构建一个全面的批处理系统——我们并不打算再创造一个 Spark、Snowflake 或 Redshift。我们清楚 RisingWave 的边界，也明白在数据基础设施领域没有万能的解决方案。与其追求不切实际的大项目，我们更专注于为用户提供真正有价值的实用解决方案。以下是我们的三个重要关注点：

流和批处理的数据摄取

• 无模式摄取：当前，当 RisingWave 用户从 Kafka 或 Postgres 等上游服务中消费数据时，通常需要手动指定模式决定要将哪些列或字段摄取到 RisingWave 中——除非用户使用了模式注册表。我们希望简化这一过程，用户不应该为定义模式而烦恼，只需将 RisingWave 指向源系统，RisingWave 就应自动提取模式。这将大大简化数据导入过程，使用户更轻松地将数据导入 RisingWave，专注于编写查询而不是纠结于数据摄取。
• 模式演变：数据库模式会经常变化。RisingWave 需要自动检测上游数据库的模式更改，并自动对应调整。一旦检测到模式变化，RisingWave 应重新计算物化视图并将更改传播至下游，用户无需为模式更改操心，只需专注于核心业务操作。
• 支持更多批处理数据源：目前，RisingWave 支持多种流数据源（如 Kafka、Pulsar、Redpanda 和 PostgreSQL CDC），并可以监控 S3 变化。但用户还有更多存储数据的地方，比如数据湖、数据仓库。我们计划扩展支持更多批处理数据源，让用户能够批量或以流方式导入数据。

流和批处理的执行

• 扩展即席查询的数据源：RisingWave 常用于从多个来源摄取数据并执行流处理。但许多用户也希望对这些数据源进行即席查询。虽然 RisingWave 已支持在 Kafka、S3 和 Iceberg 等系统上执行即席查询，但我们知道这还不够。我们计划提升这些查询的性能，并扩展更多数据源，如不同的数据库、消息队列和数据湖。
• 可调节的物化视图：目前，RisingWave 的物化视图是基于事件的，这意味着每个事件到来都会触发刷新。但用户并不总是需要如此高的实时性，可能每小时或每天更新一次就足够了。通过降低实时性要求，可以显著降低计算成本。RisingWave 计划引入可调节的物化视图，允许用户指定刷新频率，从而在系统实时性和计算资源使用之间找到平衡，满足特定需求。
• 时间序列支持：尽管并非所有流数据都以时间序列的形式存在，但相当一部分确实如此。RisingWave 的许多用户，尤其是在金融服务和物联网领域的用户，需要对时间序列数据进行专门的操作。RisingWave 将提供多种时间序列操作，包括但不限于：

1. AS-OF Join：根据最接近的前一个时间值有效地连接时间序列数据。
2. 降采样：通过聚合或选择数据点来减少时间序列数据的频率，以创建更易管理的数据集。
3. 重新采样：聚合或插值时间序列数据，以获得不同的时间频率。
4. 时间序列聚合：计算固定时间间隔内的聚合，例如每日、每周或每月的汇总。
5. 填补空隙：检测并使用插值或其他方法填补时间序列中的缺失数据点。
6. 基于时间的 Join：在时间维度是关键因素的情况下执行 Join，例如基于重叠时间间隔连接不同的时间序列。

数据湖集成

越来越多的公司将数据湖作为唯一数据来源，以整合所有数据，从而有效打破数据孤岛。我们充分意识到这一趋势，并希望 RisingWave 成为数据湖生态系统的一部分。在 RisingWave 2.0 中，我们将加强与数据湖的集成。我们已经支持从 Iceberg 读取并持续写入数据。未来，我们将继续支持 Iceberg，并扩展到其他数据湖，增加对主流数据湖目录的支持。这将帮助用户更好地管理模式信息，使 RisingWave 成为生态系统中更为重要的一部分。

4RisingWave 2.0 的愿景

截至目前，RisingWave 已开发三年半。在此期间，我们从零开始构建了系统，并在社区和商业领域取得了快速增长。我们对 RisingWave 和实时流处理的未来充满信心。RisingWave 将继续作为一个独立的、基于 Apache 2.0 协议的开源项目，专注于更好地服务用户。

对于那些对实时流处理有更高需求的用户，我们还提供了 RisingWave Cloud 和自托管版本，这些版本包含更多高级功能，使用户更容易利用强大且高性价比的流处理能力。

我们的目标是让流处理技术普及大众，为此我们致力于让它更加简单、实惠和易用，这是我们引以为豪的使命。