一行代码极速部署：打造面向开发者的流计算平台

TL;DR.

在 2021 年初，我创立了 RisingWave，目标是推广流计算技术的普及。在过去的三年中，我不断地向市场布道 RisingWave，希望 RisingWave 能够在流计算这一市场中占有一席之地。经过坚持不懈的努力，如今，RisingWave 已被数百家企业采用，这些企业遍布多个领域，包括一些世界顶尖的金融交易、制造业、安全、航空航天等行业的公司。

为大型企业提供优质服务总是能够令人感到兴奋。然而，与此同时，我始终在思考一个问题：为什么总是大公司？为什么不是中小型企业或者个人？将流计算技术以开发者为中心来设计是否切实可行？换句话说，个人开发者或中小型企业是否能够真正利用流计算技术的强大功能？

1数据系统市场的平民化趋势

“让流计算技术平民化”产生这一想法，并不是单纯因为我喜欢开脑洞。如果我们看一下如今的数据系统市场的话，我们便会发现，云上的数据库服务已经呈现了很明显的向开发者市场下沉的趋势。正如其他任何先进技术的发展历程一样，各类数据库通常都是首先被顶尖科技公司等利用，然后随着时间的推移，逐渐被广大人民群众，尤其是个人开发者与中小型公司，所使用。

这一技术平民化的过程，需要有两大前提同时被满足：

• 从用户角度出发，开发者及中小型公司有足够的需求；

• 从产品角度出发，市场上有足够好用便宜的产品。

对于 OLTP 数据库这一领域来说，技术平民化已经实现了：小到搭建个人网站，大到构建大型服务，只要用户有需求存储数据，都可能会选择使用 OLTP 数据库。PostgreSQL、MySQL 这类成熟的数据库早已被无数公司部署在生产环境中，而云上 SaaS 产品如 Supabase、Neon 等将 PostgreSQL 带到云上，并提供了一系列工具，让开发者可以使用小几十美金一个月的价格来搭建应用。

在 OLTP 与 OLAP 数据库这两个赛道中，我们都看到了同样的情况。流计算已经经历了二十多年的发展。然而，在这发展历程中，我们似乎并没有看到任何一个流计算产品真正下沉到开发者市场中，在个人开发者与中小型公司内部普及。我们如果看一下几个常见的流计算产品，无论是 Spark Streaming 还 Flink，目前更多应用在了具有一定规模工程团队的科技公司中。对于个人或者小团队来说，部署使用这类大数据组件很显然门槛较高。可以想象一下，当一个小团队还在为构建产品雏形而加班加点的时候，几乎不可能有时间去考虑自己如何使用一套流计算框架。他们想要的仅仅是一个开箱即用的工具产品罢了。

思考到这里，我们不难发现，在流计算领域，面向企业的流计算系统已经日渐饱和，形成了竞争激烈的红海。相反，针对开发者的流计算系统似乎仍是一片未被充分开发的蓝海。我们不禁会想，在 2024 年这个时间点上，让流计算平民化的时机是否已经成熟？

2流计算的平民化：从用户角度分析

在当前的技术环境中，流计算的应用范围越来越广泛，但关键的问题在于：个人开发者和中小型企业是否真正需要流计算技术？从根本上来说，流计算适用的场景必须同时满足两个核心条件：首先，数据以流的形式不断被摄入系统；其次，用户需要对这些即时的数据流进行分析以提取信息。世界上的数据流的来源还是相对比较广泛的，包括但不限于：

• 网站上的用户行为日志（页面访问、点击等等）

• IoT 设备数据

• 社交媒体数据

• 金融交易数据

• 电商订单、支付数据

在这些领域中，如果有开发者希望开发新的产品，并且这些产品需要对数据进行及时的分析，那么就可能需要流计算技术。例如，如果我们希望从股票交易中监控某只股票的波动范围，或者从电子设备回传的数据中分析异常情况，那都是使用流计算技术的非常好的场景。

那么实时数据同步与实时 ETL 场景，是否也是可以被开发者所利用呢？虽然对开发者具有一定吸引力，但实际上门槛可能还是相对较高。这是因为实时数据同步或 ETL 通常涉及至少两个系统的协作，在引入流计算系统后，开发者需要同时维护三套系统。对于个人开发者或小型创业团队来说，这样的成本是相当高的，因此这可能并非一个理想的应用场景。

总的来说，我认为从用户角度分析，流计算平民化的前置条件是成立的。

3流计算的平民化：从产品角度分析

我们接着从产品角度来分析。无论是个人开发者还是小的开发团队，都是希望将精力专注于快速开发迭代产品，而非研究底层数据系统架构。数据系统的定位就是工具，而工具就是为了给人以更好更快解决问题的手段。

当我们要开发一个面向开发者的数据系统时，我相信需要满足以下特征：

• 能单机部署，不依赖于 Docker 或 Kubernetes 等容器，如果能够做到嵌入式那是更好；

• 能提供 all-in-one 解决方案，不要求所有能力做到最好，但是需要提供各种能力：用户永远希望简化架构，而不希望把很多系统堆叠起来；

• 简单易用，上手门槛极低；

• 与各种其他开发者工具打通。

如果按照这一标准来寻找流计算系统，很显然我们在市面上的可选项极其有限了。幸运的是，RisingWave 就是极个别能够满足所有选项的流计算系统。

4流计算与批计算

我们讨论了这么多，其实最后又不得不回到一个老生常谈的问题：为什么需要流计算？用批计算不好吗？市面上不少批计算系统（尤其是 OLAP 数据库）都已经支持实时写入数据，那么为什么不直接使用批系统呢？我认为至少从三个方面来说，流计算系统拥有独一无二的优势：

• 对于一些应用来说，低延迟结果更新的要求强烈。对于金融交易、欺诈检测等场景来说，用户需要的往往是秒级甚至毫秒级的系统响应时间。对于这类应用来说，流计算也许是唯一的解法。OLAP 数据库中带有的物化视图功能尽管能够解决部分功能，但面对带有大状态的复杂查询的时候，可能就力不从心了。

• 对于一些应用来说，增量计算带来的好处明显大于存量计算。流计算使用的是增量计算模型，不难想象，这种计算模型大大避免了不必要的重复计算，使得计算效率得到大幅提升。

• 对于一些应用来说，流计算的思考方式更加直观。对于 IoT、金融等对于计算顺序有着强烈需求的场景来说，使用流计算更加符合正常思维方式，而批计算的计算反而可能“反直觉”。例如，如果我们想要不断监控过去 10 分钟内某只股票的平均价格，显然流计算的方式会更加容易被人接受。

当一个用户的使用场景满足这三个方面之一或更多时，我相信用户就可能会更加倾向于使用流计算系统。

5RisingWave 本地版的设计理念

未来总是充满未知。但与其等待答案，不如自己寻找答案。在 RisingWave 最新的 1.7 版本中，我们推出了面向开发者的 RisingWave 本地版。我们希望这一版本能够让 RisingWave 能够触及到广大开发者，让开发者能够在自己本地便享受到流计算带来的价值。

RisingWave 本地版的设计理念很简单，便是“极简”。

安装部署简单

RisingWave 本地版的最大特色之一便是安装部署极其简单。开发者能够通过简单的一行命令就在他们的本地电脑上（Mac 或者 Ubuntu）安装 RisingWave：

用户也不需要使用 Kubernetes 或 Docker 等容器，真正实现了裸机安装。对于关心程序体积的用户，我们还提供了一些编译选项，可以将程序大小压缩到约140MB。如果对这一大小还感到不满意，也欢迎与我们联系，商量一下更小打包的方案。

All-in-one

与 Flink、Spark Streaming 等传统流计算系统不同，RisingWave 自带存储功能，也就是说，用户不再需要寻找一个所谓“下游数据库”来存储流计算结果。在支持流计算的同时，RisingWave 也支持对存储在自身内部的数据进行随机查询。对于用户来讲，RisingWave 实质实现了从计算到存储再到服务的所有功能。

上手门槛极低

RisingWave 兼容的是 PostgreSQL 语法。用户可以直接写 SQL 语句便进行流计算，完全不需要学习 Java/Scala 等语言的 API，更不需要了解如 Checkpoint、Savepoint 等系统内部细节。

丰富的系统集成

RisingWave 支持了数十种常用系统与管理工具的集成。对于开发者常用的MySQL、PostgreSQL、MongoDB 等数据库，RisingWave 可以一条语句直接连接，免除中间消息队列等组件。感谢 PostgreSQL 的生态，RisingWave 同样可以与 Grafana、Superset、DBeaver、dbt 等可视化、管理、建模等工具无缝集成，大幅提升用户体验。

6后记

RisingWave 本地版寄托着我们对流计算平民化的美好愿景，是我们对于流计算技术发展的一次探索。探索未知自然意味着风险与挑战。我们诚挚地希望读者们能够给予更多的支持，与我们携手共探未来的边界！