当前位置：首页 > news >正文

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

news 2025/5/9 7:24:42

2022 年 4 月 8 日，我们开源了 RisingWave，一款专为流处理设计的分布式 SQL 数据库。两年间，RisingWave 取得了飞速发展：社区方面， GitHub上收获近 7000 颗星，Slack 社区拥有超过 2000 名成员，全球各行业（如金融、制造业、电商、娱乐等）部署达到数千次。产品方面，我们保持每月发布新版本，最新的 1.10 版本已于 2024 年 7 月发布。

1. 我们取得了哪些成就？

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

1.1 用户选择 RisingWave 的三大理由：

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

1.2 用户最喜爱的十大功能：

PostgreSQL 协议兼容（PostgreSQL wire compatibility）
丰富的 Source 和 Sink 集成（Source and sink integrations）
高性能流式 Join （High-performance streaming joins）
动态扩缩容（Dynamic scaling）
即时故障恢复（Instant failure recovery）
无服务器数据回填（Serverless backfilling）
支持 UDF、UDAF 和 UDTF（Support for UDF, UDAF, and UDTF）
自动化模式更改（Automatic schema changes）
全面支持流式 SQL：包括水印、时间窗口和时间过滤等（Full-fledged streaming SQL）
时间旅行功能（Time travel capabilities）

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

2. 流批一体

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

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

2.1 持续监控和分析

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

2.2 特征工程和时间序列分析

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

2.3 指标和事件存储

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

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

3. RisingWave 2.0 的主要关注点

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

3.1 流、批处理的数据摄取

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

3.2 流、批处理的执行

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

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

3.3 数据湖集成

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