作者序： 首先祝大家春节快乐，龙年大吉，新年第一篇文章，这篇文章的缘由主要是我个人最近拓展了解了下 RisingWave 的一些感悟和思考。 当然也是吃了不少的瓜， 想着也和大家分享下。

注： 本文仅代表作者个人观点。资料，图片均来自互联网公开资料。

吃瓜篇

"比 Flink 快十倍”的流式处理数据库 RisingWave

RisingWave 创始人 吴英骏

博士毕业于新加坡国立大学计算机系，为前 Amazon Redshift 工程师和前 IBM Research Almaden 研究员，且常年担任数据库三大顶会 SIGMOD/VLDB/ICDE 的评审委员会成员。来源：36氪首发 | 「Singularity Data」获云启资本近千万美元种子轮融资，开发下一代云原生流式数据库

这背景太硬，只能膜拜，大佬大佬 ~~~。 21 年创业成立 RisingWave ，定义为分布式 SQL 流处理数据库。官网介绍图如下：

具体瓜是，大佬在 2023 年 7 月 4 日 知乎上发布了 RisingWave 与 Flink 项目的性能对比。大家感兴趣的欢迎阅读下，具体文章如下：

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

Apache Flink与RisingWave：流处理性能报告公开预览版

省流版，直接摘录文章中的一张图片：

为模拟真实场景，我们使用 Kafka 不断产生数据，并在下游分别接上 Flink 与 RisingWave 进行对比。我们专注于吞吐量，而非延迟。对于 Flink 与 RisingWave，我们均要求保证 exactly once 语义。

基于基准测试，整体上 RisingWave 大多数情况下明显优于 Flink 引擎。

Flink 官方人员回应

可能是上面的推广文章在圈内传播的挺广，2023 年 7 月 14 日 阿里的 **伍翀（云邪）**在个人公众号上回应了一篇文章。

远离虚假营销，还原真实的 Flink 和 RisingWave 评测

质疑上面 RisingWave 发布的测评报告，主要集中的几点如下：

1. RisingWave 声称使用 Nexmark 做基准测试，然而却不使用 Nexmark 中开箱即用的 Flink 配置，转而改了一系列非常古怪的 Flink 参数，这是 Flink 性能差异的主要原因。

2. Nexmark 官方推荐使用多机分布式环境测试，然而却被改成了单机单进程测试。让人不禁怀疑这是在评测分布式系统么？

3. RisingWave 声称使用 Nexmark 做基准测试，但却修改了 query 和数据，并且并未对齐 RisingWave 和 Flink 的 query，从而支撑了其某种论述。

在修复了这些问题后，我们发现 RisingWave 有两成的 query 无法支持，在性能上 Flink 全面大幅领先 RisingWave，整体性能快 60%，部分 stateful query 有 20 倍的性能优势！

这里有必要介绍下 伍翀 何许人也：

伍翀，花名云邪，Apache Flink PMC member & Committer，Flink CDC 创作者。目前就职于阿里云开源大数据平台，Flink SQL 团队负责人。长期以来一直专注于分布式处理和实时计算，热爱开源，热爱分享。

来源：Flink 学习网

2009 - 2015，就读于北京理工大学。

2015 年进入阿里巴巴中间件实时计算团队，JStorm 研发。

2017 年加入阿里云计算平台，Blink/Flink 研发。

2022 年阿里云 Flink SQL 负责人。

来源： 个人博客

我对这位大佬最深刻的印象就是推出了 Flink CDC 这套数据集成工具，可以说抓住了大数据用户的痛点，基于 Flink 提供了一套合适的数据同步解决方案。2020 年 8 月推出的第一版，基本核心是基于Debezium 作为捕获数据变更的引擎，上层封装多套 flink connectors 支持不同数据库的全量和增量数据接入。 当然随着 Flink CDC 3.0 的发布，当前整体功能越来越完善。

官方资料：

Flink CDC 3.0 正式发布，详细解读新一代实时数据集成框架

Flink Forward Global 2020：Change Data Capture and Processing with Flink SQL

RisingWave 官方人员回应

RisingWave 员工做出的回应：

审视“真实的” RisingWave 和 Flink 评测 —— 有多少傲慢与偏见假借“还原真相”之名？

结合上面 Flink 相关回应，做了十个回应，可以说也是有来有回，具体孰是孰非，不做评价，各位看官可以自己衡量，个人只把这篇文章的总结放在下面，详细内容可以去阅读下原文。

总结

事实上，我们都知道，该文的作者们作为 Flink committer 不可能不会测 Flink、不会分析瓶颈、不会查阅文档。让他们犯下这些荒谬错误的，是他们的傲慢与偏见。他们固执地认为一个从零到一的新项目不可能在短短的两年内做出超越他们的成果；固执地认为我们一定是花了整整一年半 all in 跟他们性能竞赛；固执地认为我们一定在性能测试中出了花招。抱着这种傲慢的心态，他们急切地完成了一份充满错误，毫无参考价值的报告。

作者在文章最后提到“欢迎更多社区共同建设流计算”，我们希望作者能够放下傲慢与偏见，以诚信、尊重的态度对待其他社区；也希望作者能够真的把精力集中在解决用户痛点上，而不是花费无用功在恶意诋毁其他社区。技术的进步不应该被单一公司垄断，我们很愿意与 Flink 以及其他社区一同良性竞争，为用户提供更加可靠，更加易用，更加具有性价比的流处理解决方案。

剧终

最后 **吴英骏 （RisingWave 创始人）**在年底的时候 发布了一篇万字长文年终总结，也算为这次事件画上了句号。

与Flink干了一架的那位创始人，写了份万字长文年终总结！

关于 RisingWave 与 Flink 的性能讨论

RisingWave 是一个为流计算所设计的数据库。提到流计算，不得不提 Apache Flink 这一知名开源项目。RisingWave 被很多人知道，除了是因为我们不断发表高质量技术文章之外，很重要的一件事情是与阿里 Flink 团队的朋友们关于 RisingWave 与 Flink 性能对比的讨论。这事因我而起，我就在这里与大家毫无保留的分享事情的来龙去脉。

RisingWave 自始至终的定位一直是流处理数据库，而非流计算引擎，因此从本质上来讲，与 Flink 有竞争，但并非纯粹替代关系。实际上，在创立之初，不管是对内还是对外，我也很少去提 Flink。那为什么会开始提 Flink 呢？原因在于，“流处理数据库”这个词在当时还是太小众，教育用户会耗费我们巨量的时间。而不少潜在用户听完我们的推销之后，往往会去主动提及 Flink，并希望理解 RisingWave 与 Flink 的区别。对于做产品，”你认为你是什么不重要，别人认为你是什么才是最重要的“ (it doesn’t matter what you think of yourself; it only matters what others think of you)。既然用户都把 RisingWave 当作 Flink 的竞品，那为什么我们不干脆直接在宣传上直接把自己当成 Flink 竞品呢？我们的确也是这么做了，而事实也证明是奏效的。我认为，在早期（或者也许可能是在任何时期），千万不要幻想着教育用户，而是站在用户的立场上，为用户解决问题。既然 RisingWave 与 Flink 的对比是用户反复提出的问题，那我们自然需要帮用户理解。顺着这一思路，我们也在早期让用户将 RisingWave 当作 Flink 在测试环境下的替代品，正如我在本文前面提到的。

我们再来谈谈 RisingWave 与 Flink 的性能对比一事。如果从早期便开始关注 RisingWave 的朋友们应该知道，RisingWave 使用的口号一直是“让流计算平民化”，也就是大幅降低流计算门槛，提升流计算性价比。我作为 Redshift 工程师背景、拥有数据库方向 PhD 学位的创始人，自然非常明白 性能对于用户来讲从来不是首要考虑项。那我们为什么还提性能？原因还是同样的：因为用户希望看到。我相信不少工程师背景的用户都认同”性能并非最重要的“这一事实，但实际上，公司的工程团队在向上级领导层提议引入一个产品时，几乎肯定需要向领导呈现不同产品间的对比：领导永远不希望看到只有一个可选项。而为了做对比，所谓”更易用”几乎很难打动领导，尤其是在经济下行周期中。领导需要看到一个可量化的指标，而 最简单的可被量化的指标便是性能。我们最早做的性能报告便是为了几个大企业中的工程团队向上级汇报所准备的。而我们当时公开发表性能报告也并没有预料到后续发生的一些事情。

与阿里 Flink 团队的小伙伴关于性能对比的讨论完全是意料之外。当阿里 Flink 小伙伴公开对我们的报告作出反驳时，我当时想的只是：这是一个千载难逢的机会。实际上，如果大家回顾之前任何两个产品在网络上的公开对比，如 Snowflake 与 Databricks，如 Iceberg 与 Hudi，就不难发现，公众在短期内可能对结果产生浓厚兴趣，但在长期来讲，没有人还记得结果，只记得了这两个产品进行过对比。因此，这场 RisingWave 与 Flink 关于性能的讨论的结局，从一开始就已经确定了，那就是 强化了公众对两个产品关联度的印象。至于性能到底如何，只不过是一个短期的技术性讨论罢了。“All you need is attention”。这是一个云厂商高管在这事情发生之后对我说的话。是的，all I get is attention。

当然，进行公开讨论，也是有后果的。后果其实在一开始也是可以被预估的，那就是，被动了利益蛋糕的人或多或少会产生不满。正如我的一位 advisor 所说的，我们毕竟是 “poke the bear”，面对的是机遇与挑战，需要做好周全的准备。在此之后，我的确感受到了个别个人（并非阿里 Flink 的朋友）对我产生的误解甚至是敌意，并在一些场合做出了一些不友善的举动。我对此全盘接受。平心而论，任何人从潜意识上都会去保护自己的利益。当自己的利益被他人所触碰时，几乎不可避免的会产生抵触情绪。而这一情绪所导致的举动因人而异。我们没有办法去改变他人，只能从他人角度理解他人，并为自己的行为负责。

我在这里不得不去赞扬阿里 Flink 团队小伙伴的专业素养。我们不提性能对比结果，但从性能报告本身来讲，是具有足够专业度的。我们也通过性能对比，更加全面的了解了 Flink，为 RisingWave 自身进一步性能提升提供了非常好的参考。与此同时，不管是我个人，还是 RisingWave 团队的工程师们，都与阿里 Flink 团队的小伙伴们保持着非常好的关系，并不断探究在工程、市场等方面合作的可能性。我在这里真诚感谢阿里 Flink 小伙伴们的付出。

学习篇

瓜就吃到这里，作为一名数据工程师，个人还是比较好奇 RisingWave 这个 21 年才成立的公司，技术上是有哪些创新来对垒 Flink（虽然公司成立年头不长，但是稍微了解下创始人背景，前 Amazon Redshift 工程师和前 IBM Research Almaden 研究员，且常年担任数据库三大顶会 SIGMOD/VLDB/ICDE 的评审委员会成员。硬实力还是摆在那里的）。

扒了一扒官网的介绍以及一些公开的技术资料，我们从产品定位，使用差异和底层技术 三个方面来看看 RisingWave 的特点。

产品定位

RisingWave 是一个分布式架构的 SQL 流式数据库，能简单、高效、可靠地处理流数据。

Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。

RisingWave 官网把自己定位为 SQL 流式数据库，这个名称我也是第一次听过，这个和 Flink 就有明显差异了，众所周知 Flink 是定位为分布式计算框架，一个是数据库一个是计算框架，初始给人的影响是有点不太相关，甚至我刚开始看到这句话，偏向于把 RisingWave 理解为了类似 ClickHouse，Doris 等 OLAP 引擎类别。官网的这张图片，更方便我们理解这个定位：

个人理解：RisingWave 相当于是通过提供 SQL 方式开发方式，屏蔽了实时处理底层需要遇到的一些技术细节（状态存储，数据一致性，分布式集群扩展等），供应用方快速的开发实时数据流，进行流式 ETL，可以应用在一些数据看版，监控，实时指标等场景。

使用差异

上图中第一张图片，使我们平时做实时处理的常见的场景，Flink+Kafka 多流处理，聚合，计算，拉宽，然后发往下游目标端。这里可能涉及多个实时流，上下游需要有相应的数据血缘图谱，和离线血缘类似。

而 RisingWave 差异在于，利用物化视图这一特性，将多个处理阶段，放在一个 RisingWave instance 中，更方便管理和维护，中间不再使用 Kafka 这类消息队列组件，更利于维护。

开发模式上，目前 RisingWave 只提供 SQL 式开发模式，当然也是支持 UDF 定义开发，目前从官网了解支持的开发语言有 Python，Java。所以整体上这块和 Flink 是无法对比的，Flink 提供了更底层的 DataStream 相关接口，可编程开发，更好的接入公司内部既有系统。

周边生态，RisingWave 作为一个新产品，这块当下应该还更聚焦在核心产品功能上，周边生态是无法和 Flink 比拟的，Flink CDC， paimon 等扩展出来的生态，更好的助力 Flink 成为事实上的流式处理框架。

RisingWave 提供部署方式（容器化，基于 k8s 编排）更适应云原生，但是同时也舍弃了基于 Yarn 的调度（至少目前官方是没有提供），可能这也会劝退一大波还在用 Yarn 的用户，同时可能也是产品定位，这样更没有太多历史包袱。 同时 RisingWave 也提供了 Cloud 服务。可以理解成各家云厂商上提供的 Flink 专业版服务。

使用上 RisingWave 上手可能会更快，学习曲线不陡峭，本身产品更内聚，同时也代表它只能解决一些特定场景，无法做太多定制开发，以及接入一些公司内部系统，更偏向一个独立的产品。 Flink 本身是定位于计算框架，同时提供可编程接口，所以高度丰富的插件与周边生态，方便开发人员做定制化开发。RisingWave 官网也提供了一个和 Flink 差异对比文章。 RisingWave vs. Apache Flink：如何进行选择？

当然文章还是会多少偏向自家产品，各位看官自行权衡。

底层技术

通过 RisingWave 的一些公开技术资料，也可以窥探下它设计上有哪些值得借鉴的地方，相对于 Flink 来说，它是近两年才推出的产品，所以整体上设计上会有一些与时俱进的东西。

RisingWave 存算分离架构

比如它的状态管理，推荐阅读官方的这几篇文章：

RisingWave 中的高可用性与容错机制

深入理解 RisingWave 流处理引擎（一）：总览

RisingWave 中的状态管理机制

Hummock: 为流计算而生的存储引擎

个人理解 RisingWave 将状态管理对使用用户做了尽量透明，不再像 Flink 我们需要关注状态的保存，处理以及恢复的操作。 同时**存算分离，**状态放在了远端对象存储上，至于性能问题，它通过一些算法和本地缓存去解决，这个说起来容易，但是真的要实现上还是挑战很多，不然 Flink 当初也会这么设计了。

据我所知，Apache Flink 是第一个引入 Checkpoint 的流计算系统。Apache Flink 创新性地将 Chandy-Lamport 算法用于 checkpoint streaming jobs，我认为这一设计是它取得成功的重要原因之一。Chandy-Lamport 算法能够在分布式系统中取得全局一致的快照，这允许我们用它来恢复一个 job 而不丢失或重复任何事件（所谓的 exactly-once）。

在故障恢复这个主题上，本质上，无论是 Flink 还是 RisingWave 都遵循和 AGC 相同的原则：

• 在正常运行中，记录下可供恢复的 checkpoint，并保存在持久存储中

• 一旦系统发生不可继续的问题，从上一次 checkpoint 恢复并尝试继续

不过，RisingWave 的实现要轻量的多。

我们希望像 AGC 那样在一秒内完成重启，但是流计算的状态太大了！取决于 workload，它可能从几 GB 到几 TB 不等，即便用今天的硬件，也需要一段时间来恢复全部的状态。

自从设计之初，我们就将计算节点看作几乎无状态的节点，具体地说，我们将计算节点内存以及磁盘中的数据看作缓存，有它能达到更好的性能，没有也不会影响 job 的运行。或者换一个说法，它在任务运行时 lazily 加载 checkpoint。该设计让 RisingWave 能够在毫秒级调度起新的任务而不用完整加载状态。

另一个容易被忽视的问题是 checkpoint 的新鲜度，或者说 checkpoint 频率。如果 AGC 重启后恢复到了更早的阶段，那么需要执行更多的步骤才能到达重启前的状态。流计算也是如此。例如，如果最后检查点在半小时前，那么，近半小时的输入就需要被重放，才能真正到达当前状态。

我们的解决方案是每隔 1s 进行一次 checkpoint，这听起来很频繁，不是吗？事实上，对于 S3 这样的对象存储，1 秒一次的 put_object 是小菜一碟。RisingWave 的存储是从头设计的，基于 LSM-Tree 结构，每次 checkpoint 仅会上传那些新的改动，这使得它能高效地进行高频率的 checkpoint。在基准测试中，在 1s、10s 或是 1min 的 checkpoint 间隔下，性能表现都差不多。

Flink 2.0 存算架构

同时 2023 年 Flink 社区喊出的 Flink 2.0 也是走上了存算分离架构，至少说明这个方向，大佬们都是认可的，这点 RisingWave 目前确实走在了前面。

可以看看 Flink 关于这方面的思考：

Flink 2.0 状态管理存算分离架构演进

Flink 2.0 状态存算分离改造实践

为此我们可以考虑换个思路来做这个事情，把 DFS 作为 Primary Storage，而把本地磁盘作为 Cache 并且是不强制需要的（Optional），DFS 的数据是 Source of truth。在这种形式下，状态数据直接持续写入 DFS，内存和本地盘作为 Cache，服务于上层的算子状态访问。这种架构的好处是：

• Checkpoint 被触发的时候，大部分状态文件已经在 DFS 上了, Checkpoint 可以速度很快；

• 状态文件在算子之间是可以共享的，一些场景下通过共享状态计算，存储资源可以大大减少；

• 状态查询可以基于远端 Checkpoint 文件实现，并提供文件级别 API；

• Compaction 和状态清理不再和 Task Manager 绑定，我们可以通过 remote compaction、load balancing 等手段来均衡 Cluster 整体资源的使用

总结篇

RisingWave 整体上架构上更适应当下的云原生，但是整体生态还很多空白的地方需要开拓。 基于容器编排，存算分离，可以说是它的亮点，商业化上从公众号上也确实有企业也在尝试使用，能够在一些特定场景下，满足用户需求。

但是整体使用用户体量还是无法比拟 Flink 用户，无论从商业化推广，社区运营，还是开源开发者的参与上，RisingWave 都属于刚刚萌芽的新产品，这种 to B 的流框架，技术是一方面同时背书以及广大开发者的认知也需要普及，道路漫漫，期待后面的表现。

回到 Flink，个人也是 Flink 的使用者，平时作为数据开发工程师以及平台工程师，对 Flink 以及周边生态的使用还是蛮多的。Flink 在国内已成为流式计算的事实标准，这个不容置疑。但是目前看来，国外的推广还是有点欠缺。 这两年 Flink 初创的那波人的出走，外面也有很多负面的声音。 但是还是会看到每年 Flink 的版本迭代以及架构演进，国内社区也十分活跃，当然这也是阿里每年投下去很多真金白银的结果。

后面也希望 Flink 能够更多争取国际的开发者，让在国外也同样知名。 目前个人 在 reddit ，medium，github 等社区上和 spark 的整体热度还是差距很大， 同时英文的官网整体上并没有像国内 Flink 学习网这样资料全面，这块有待加强推广。

好了，多啰嗦一些其他的事情， 今天的文章就在此告一段落， 假期的最后一天，赶着写的稿子（发出应该是上班的第一天了），可能思路有点乱，还望各位看官海涵，我们下期再见。

感兴趣的朋友，欢迎沟通交流。

如果觉得文章不错，欢迎大家点赞，留言，转发，收藏 谢谢大家，我们下篇文章再会~~~