从“云原生”到“比 Flink 快十倍”：RisingWave 的寻找自我认知之旅

2023-06-29
北京
本文字数：3573 字
阅读完需：约 12 分钟

RisingWave 作为一个从 2021 年初开始开发的流计算系统，一直将自己定位于帮助用户简单高效的构建实时分析应用。自从 2022 年 4 月正式以 Apache 2.0 协议在 GitHub 开源后，RisingWave 这一开源项目不断迭代，目前已经在数十家不同规模企业中实现落地，并且每日的开源部署（Kubernetes 方式）量一直保持在数百。

RisingWave在2023年6月的Kubernetes部署情况。

尽管我们的产品一直按照我们自己预计的方向不断发展，我们的宣传口径却在过去的一年多时间中经历了多达 5 次的修改，可以说是每两三个月便会更改一次我们的宣传标语。以下便是我们所用过的宣传标语：

第一版：

RisingWave: a cloud-native streaming database.

第二版：

RisingWave: a streaming database in the cloud.

第三版：

RisingWave: a distributed SQL streaming database in the cloud.

第四版：

RisingWave: a distributed SQL database for stream processing.

第五版：

SQL stream processing with Postgres-like experience; more than a modern alternative to Apache Flink.

第六版：

SQL stream processing with Postgres-like experience; 10X faster and more cost-efficient than Apache Flink.

从公司角度来讲，其实并不愿意频繁改动宣传标语，因为这意味着需要不断重新制作宣传材料，并调整宣传方式。然而宣传标语的改动也意味着我们对自身产品定位的不断更新。毕竟，一个新项目的诞生与发展，总是免不了重新认识自我，寻找自己的位置。在本文中，我就来讲讲我们在进行这些改动背后的心路历程。

第一次改动：从“云原生”到“云上”

RisingWave 最初的宣传标语是“a cloud-native streaming database"。这个标语伴随了 RisingWave 的整个 2021 年。那个时候并没有人关注 RisingWave，也没有人关心 RisingWave 到底是什么。而当我们逐步对外介绍 RisingWave 的时候，便发现了一个问题：不少人对什么是 cloud-native，也就是云原生，并不清楚。毕竟，云原生蕴含了太多的含义：是否意味着 RisingWave 只在云上卖？还是使用了云上的基础设施服务？还是说可以用 Kubernetes 方式部署？还是使用了针对云更加友好的设计？当听众对一个关键词产生各种各样的猜想的时候，作为讲者就非常艰难了：毕竟多数听众并不希望花时间了解一个自己并不关心的产品。

基于此，我们做出了第一次改变：删除“云原生”这一个关键词，并直接描述成“云上”的流数据库。这样的标语简明易懂：RisingWave 是面向云所设计的产品。至于架构是什么，部署方式是什么，等等问题，就留给感兴趣的听众进一步摸索吧 :-)

第二次改动：从“流数据库”到“分布式 SQL 流数据库”

将 RisingWave 的标语改成“云上”的流数据库之后，我们不再需要纠结如何解释“云原生”这个关键词了。但继续向更多听众解释什么是 RisingWave 的时候，我们便发现了一个问题：什么是“流数据库”？流数据库怎么用？那时候的我们还是非常坚持的使用“流数据库”这个名词（并且一直使用到现在），但的确非常想传递给用户使用 RisingWave 的方法。毕竟，作为一个流处理系统，使用 SQL 的方式进行交互可以大幅降低用户的使用门槛，的确是个不错的卖点。

根据这些，我们决定将“SQL”这个关键词加上，并且提及分布式，让大家都知道 RisingWave 并非一个单机系统。这一小小的改变直接写明了 RisingWave 的用法，让我们在与听众沟通时的门槛降低了不少。

第三次改动：从“流数据库”到“用于流处理的数据库”

在宣传标语中放弃“流数据库”这个关键词是我们在团队内部做出的一个相对比较大的决定。这个决定是在 2022 年年底做出的。在使用了“流数据库”这个名词一年多的时间之后，选择直接放弃，还是经过了不少挣扎的。然而，选择放弃“流数据库”的原因也是显而易见的：要解释清楚什么是“流数据库”真不容易！在 2022 年 10 月，我们已经开始从闭门造车走向了逐步对外落地，而在拜访用户的过程中，我们往往发现“流数据库”这个词给潜在用户造成了不少的困扰。“流”往往意味着实时，而“流数据库”听起来给人感觉像是“实时数据库”，也就是大家所熟知的 ClickHouse、Apache Doris、StarRocks 等实时分析数据库。然而，RisingWave 的定位与这些数据库截然不同，并且，RisingWave 在使用场景中与这些数据库更属于互补的关系。而如果我们将“流数据库”解释成“既是流处理系统又是数据库”的话，又给人造成了不小的疑惑：这个系统到底是流处理系统还是数据库？

与其为了坚持使用一个名词而增添大量不必要的解释工作，还不如回归第一性原理，使用最简单的方式给出最直白的解释。因此，我们选择了直接将 RisingWave 定位于“数据库”，并且是一个“用于流处理的数据库”。这样一来，我们再也不需要为解释“流数据库”与“实时分析数据库”之间的区别而烦恼，并可以专注在布道“流处理”这一概念上了。

第四次改动：从“数据库”到“PostgreSQL 与 Flink”

第四次改动发生在 2023 年的 4 月。当 RisingWave 开源一周年之后，我们已经积累了一定的早期用户，开始寻找如何面向更大的潜在用户群体布道 RisingWave。从一对一向听众布道，转向直接面向群体普及，需要经历一个巨大的转变：当一对一与人沟通时，我们常常有机会细致的解释 RisingWave，并针对用户的具体场景给出解决方案。而当面向群体普及时，我们便不再可能进行这种私下交流了。更重要的是，绝大多数个人并没有足够大的动力去了解新兴事物：每个人会更加自然的关心自身熟悉的内容，并从自己的角度出发去理解外部的世界。

这一客观事实让我们对宣传 RisingWave 的方式做出了彻底的转变：与其解释 RisingWave 是什么，还不如解释 RisingWave 在用户的世界中处于怎样的位置。很显然，对于绝大多数数据平台工程师来说，PostgreSQL 与 Apache Flink 是两个相当熟悉的系统：PostgreSQL 是数据库的代名词，而 Flink 是流处理的代名词。RisingWave 的使用方式几乎与 PostgreSQL 一致，而其使用场景与 Flink 高度相似。既然如此，将 RisingWave 描述成“SQL stream processing with Postgres-like experience; more than a modern alternative to Apache Flink.”便显得非常浅显易懂了。

当然，作为一个拥有十多年历史的老牌流处理产品，Flink 在不少用户心中还是有着一种象征意味的：正如当年 Hadoop 象征着由 MapReduce 开创的大数据时代一样。尽管所有人都知道，那个年代所打造的产品终究无法在云时代继续引领潮流，但作为后来者，在没有足够数据支撑的情况下，我们更倾向于用柔和的方式来描述与先驱者的关系。这也是第四次改动将 RisingWave 的描述止于“more than a modern alternative”的原因。

第五次改动：从“Flink 替换”到“比 Flink 快 10 倍”

在进行第四次改动后的两个月，我们选择再一次对宣传标语进行改动。而这一次，我们选择了更加激进的策略：直接指出“RisingWave 比 Flink 快 10 倍”的这一结果。进行这一改动出于两个原因：第一，RisingWave 终于在这个月（2023 年 6 月）发布稳定版 - RisingWave 1.0 版本；第二，在经过数月的大量性能测试之后，我们终于可以非常自信的给出“比 Flink 快 10 倍”这一结论。

当然，只要是对性能评测有所了解的工程师们都应该知道，一切评测都是相对的：几乎没有系统能够实现在同等环境下比其竞品实现 10 倍性能提升。然而，经过反复的实验，我们得出了非常一致的结论：

RisingWave 在简单 stateless 计算中比 Flink 实现性能提升 10-30%；
RisingWave 在复杂 stateful 计算中比 Flink 实现性能提升 10-100 倍。

考虑应该使用更加保守的宣传口径，我们选择了“10 倍”这一数字。

事实上，RisingWave 并非第一个实现比 Flink 快 10-100 倍的流处理系统。早在 3 年前，Flink 的原创团队 TU Berlin 数据库组便抛弃 Flink 从头开发了新一代流处理引擎 NebulaStream，并实现了 10-100 倍的提升（论文：https://nebula.stream/paper/zeuch_cidr20.pdf）。类似于 NebulaStream，RisingWave 相比于 Flink 实现了巨大性能优势的原因也是非常显然的：