一转眼来到了2022年年底。作为一个2021年年初正式开始的项目，RisingWave即将步入第三个年头。she当然，所谓魔幻并不是在说我们经历了多少起起伏伏，而在说我们自身发展的速度远超预期，并不断对RisingWave这个项目自身以及整个数据系统行业的认知不断更新，使得我们不得不多次调整我们自己的步伐。借着年底的一些空闲时光，我就来复盘一下即将过去的2022年，并对未来做一些展望。
我从2021年年初正式从AWS Redshift离职，全职投身做RisingWave这个项目，目标是打造全新的下一代云原生流式数据库。说来有意思，也许是当时数据仓库领域新贵Snowflake的IPO震撼了整个科技行业，当我跟投资人聊起我们这个项目的时候，大家总是认为RisingWave是想做下一个Snowflake或是Redshift。于是我只好一遍一遍的解释流处理系统是多么不同于Snowflake或是Redshift这种批处理系统，以及在现有批处理系统上再去构建流处理系统的难度所在。我在Redshift的工作经历主要集中在了SIMD向量化引擎以及存算分离架构的开发，并且参与了物化视图实时更新的项目（没错，流处理在数据库当中的表达形态就是物化视图）。加之早年（主要是2012-2015年期间）对流处理的研究与参与Apache Flink（当年叫Stratosphere）的最初版流计算架构的开发，让我对流处理这个领域有着自己的认知。我相信，流处理技术的设计与工程原理已经成熟，但从实践角度，当前的流处理系统，无论是早年的Storm和Samza，还是现在的Flink和Spark Streaming，都有着很高的使用门槛，而这一门槛使得流处理技术很难在广大技术实力没那么强的公司中得到普及。为了让流处理这一技术变得像诸如Snowflake、Redshift、Clickhouse等批处理系统一样被更加广泛的使用，我们需要重新打造一款让大多数人都能够轻易上手且成本低廉的流处理系统。为了实现这一理念，我们的方法是：让用户使用跟Postgres（几乎）一样的方式来去进行流数据处理，并通过当今流行的存算分离架构来去提升资源利用效率，并使之更易在云上进行弹性伸缩。
想要创新，必定会面对质疑。在创业之初（哪怕到现在），我们面对的最多的问题便是RisingWave跟Flink等现有流处理系统是什么对比。我觉得用一幅图就可以说清楚了：Flink就是流处理版Spark，Flink SQL就是流处理版Spark SQL， 而RisingWave就是流处理版Snowflake。Snowflake通过简洁的接口以及全新的架构开辟了批处理的新范式，而RisingWave也希望用同样的方式开辟流处理的新范式。同时，RisingWave的目标并不是取代Flink，而是在市场中寻找到自己合适的用户画像。这点也是跟目前Snowflake与Spark SQL（其实说AWS EMR更加恰当）共存的关系一样：Snowflake与EMR都通过SQL这种方式来去触达广大用户，而EMR自带的底层基于Java（或其它语言）的编程框架可以更好的服务于业务逻辑相对复杂、需要更强编程能力的企业或团队，而Snowflake作为基于SQL的数据平台（其实这两年推出的Snowpark项目也开始提供Java、Scala、Python等编程接口），会更好的服务于业务逻辑相对简单、需要快速迭代产品的企业或团队。当然，还有不少人会问，为什么我们选择从零开始开发RisingWave，而不是基于现有的一些系统。这个问题我觉得还是单独开一篇文章讨论吧。
批处理与流处理系统对比
在时代的大潮中，创业公司必须不断的在不确定中寻找确定性。寻找确定性的最佳方式便是判断历史的发展方向。而我们所寻找的几个确定性总结下来便是这么几个关键词：开源、云、易用、低成本。相比之下，我们对性能等方面的考量优先级要低很多。这并不意味着我们不在乎性能，相反，我们认为性能是必须要素，而非差异化卖点。在云时代，系统的性能往往可以通过暴力使用资源而获得几乎线性的提升，而如何通过利用最少的资源达到用户需要的性能才是关键问题。在未来，性能将与稳定性一样，成为基础软件必须提供的能力：几乎没有专业用户会用不稳定的产品，在未来也几乎没有专业用户会用低性能的产品。
在2022年，RisingWave团队全身心的投入了以下几件事情：
1. 将RisingWave以Apache 2.0协议开源。
开源在系统领域应该已经是常态了。硅谷著名风投A16Z的创始合伙人Marc Andreessen说，软件正在吞噬世界（software is eating the world）。而如今我们看到，开源吞噬软件的速度甚至快于软件吞噬世界的速度（https://www.coss.community/cossc/open-source-is-eating-software-faster-than-software-is-eating-the-world-3b01）。开源生态对现代软件公司所带来的好处相信大家已经再清楚不过了：病毒式的口碑传播，更早更广泛的获得种子用户，通过社区制定调整路线图，增强与用户之间的信任等等。我是忠实的开源信仰者。开源很显然大大加速了RisingWave的发展。从2022年4月8日开源至今，RisingWave的Github上已经获得了3.6K的star，并有100多位贡献者参与了开发。有点出乎意外的是，作为一个开源的Rust项目，RisingWave在Rust社区内获得了广泛关注。这应该是主要得益于我们在今年5月的一篇文章: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (https://www.risingwave-labs.com/blog/building-a-cloud-database-from-scratch-why-we-moved-from-cpp-to-rust/)。这篇文章在工程师圈内被广泛讨论，以至于我与很多人聊天的时候，对方都会说：“我之前读过你们那篇Rust文章！”听到这样的话，总是能让我感受到开源社区的魔力。
开源带给了我们不少好处，但说一下带给我们的一些“坏处”吧。目前主要感觉到两方面的问题。一方面是开源社区的维护。坦白说，从公司层面来讲，公司对RisingWave社区的投入是不够的，目前社区属于纯自发状态。我们除了在新加坡办过几次meetup之外，并没有任何社区活动，甚至都没有人全职负责社区活动的运营。客观原因还是有的：疫情还是在世界各地蔓延，在诸多地区线下活动尚未完全放开；人手紧张，工程师都忙于了解需求开发产品等等。当然这些客观原因并不能成为我们的借口。寄希望于社区实现“无为而治”只是美好的幻想，而长期无治理的社区最终只会走向衰败。因此，我们会在新的一年中在社区方面加大投入。第二个问题是社区版本与商业化版本的潜在开发优先级冲突问题。RisingWave是个开源项目，但同时，我们公司又有RisingWave Cloud这一商业化产品。由于用户画像与产品定位并不完全相同（下面会讲），RisingWave拥有与RisingWave Cloud对系统功能的优先级并不完全一致。这也就造成了开发上的一些额外负担：我们是先满足商业化用户的需求还是先满足开源社区的需求？我们现在的做法很简单：找到最大相交子集，并全力开发子集内的功能。尽管有着这样的问题，但我们还保持了内核100%完全开源，并在可预见的未来，会一直保持这一做法。我坚信，对于云服务软件公司来说，卖的并不是软件，而是服务。在开源渗透整个世界的今天，寄希望于通过源代码闭源来去构建技术壁垒已经变得越来越艰难，而真正的壁垒将是面向开源软件所提供的服务。RisingWave Labs是一家云服务公司，而不是一家软件公司。
2. 强化稳定性与性能测试。
稳定性是软件的根本。设计理念再前卫的产品，如果不够稳定，就无法被市场广泛采用。当我们向潜在用户推销RisingWave的时候，往往对方的前几个问题就会问：“RisingWave经历过实战考验（battle-tested）吗？”这其实是绝大多数创业公司/新项目需要面临的“先有鸡还是先有蛋”的难题：没有经历过实战考验就无法获得用户，而无法获得用户就无法经历实战考验。我们解决这个难题的方法很简单、很传统、也很有效，就是构建高强度的测试框架。我们在很早的时候就构建了内部专职的稳定性与性能团队，并引入了各种测试手段对RisingWave进行长期的、大规模的测试。同时，我们也在自己内部的一些服务中首先用起RisingWave。目前，RisingWave已经在内部的网站、云服务资源监控等方面落地。我们也把使用RisingWave监控RisingWave指标的用例写成了教程，供大家参考: https://www.risingwave.dev/docs/current/use-risingwave-to-monitor-risingwave-metrics/。
正如文章之前所提到的，RisingWave的设计理念是将性能看成基本要素，而非核心卖点。性能应该与稳定性一样，是基础软件默认提供的能力：任何基础软件默认应该都是高性能的。毕竟现在的硬件水平并不是十多年前的Hadoop时代所能比拟的：在云时代，无论从机器的规模、机器的CPU数量、CPU的运算能力等各个方面都已经远超MapReduce引领出的大数据时代，加之工程师的水平稳固提升以及开源项目的兴起，高性能计算已经不再是秘密。尽管RisingWave从第一天起，目标并不是想成为一个性能高于Flink十倍或百倍的流处理系统，但在没有进行大规模系统性的性能优化的情况下，RisingWave在无状态计算中已经小幅优于Flink，而在带状态计算中，性能已经比Flink高出50%甚至数倍。也许有人质疑：Flink已经经过多年优化，为什么RisingWave在这么短的时间内就能超越Flink的性能？这并非我们刻意去挑选对于RisingWave有利的场景进行测试。实际上，这种性能提升哪怕从实现语言（RisingWave用Rust，而Flink用Java）角度就已经能够解释了：在柏林工业大学，Flink的最初创始人Volker Markl教授带领学生用C++重写的类Flink系统NebulaStream已经达到了Flink十倍甚至百倍的性能（论文：https://www.nebula.stream/paper/zeuch_cidr20.pdf）。目前RisingWave相比于Flink在性能方面领先的幅度相比于NebulaStream来说还是相对较小的，而我们也会选择在合适的时间点进行系统性的性能优化来进一步提升RisingWave性能。当然，RisingWave从来就不是Rust版的Flink：它不仅从产品形态上不一样（是流式数据库而非流式计算框架），也在具体实现上也具有明显的差异。尽管同样提供SQL接口，Flink SQL采用了自底向上的实现方式，即先有了一个通用计算框架，再在这个计算框架上搭一层SQL接口。相反，RisingWave采用了自顶向下的实现方式，即先有SQL层，再去为每个算子进行特化实现。显然，实现越特化，性能就越可能被提升。RisingWave充分利用了这种根本性的区别做了大量的特化，这也为RisingWave的性能优势提供了保障。
3. 将RisingWave落地于第一批用户。
创业从来不能闭门造车。好的技术也一定需要被市场所认可。自从RisingWave稳定性与性能在内部得到验证之后，我们便开始了寻找种子用户的历程。以各种理由（诸如没有流处理需求、已经使用了其他服务、内部太忙等等）被拒绝已经成了常态。而在寻找种子用户的过程中，我们也体会到了全球经济的萧条。例如，一个有意向的用户在准备落地RisingWave的前夕告诉我们，由于团队需要进行大裁员，计划好的落地将被搁置；另一个用户临时告知我们过两周再联系，而在两周之后我们在新闻上看到这个用户所在的公司已经被收购；等等。诸如此类的事情并没有让我们停止寻找种子用户的步伐。经过我们不懈的努力，RisingWave已经成功在第一批用户中落地，所覆盖的场景涵盖了互联网、金融、娱乐等等。在真实场景中的落地让我们感觉到了做产品的难点：用户的需求多种多样，可能是需要对某些特定语法的支持，可能是需要对某些系统的集成，也可能是对系统运维或是安全方面的一些特别要求。批量支持用户对我们路线图的设计提出了很高的要求。如何在及时响应各类用户需求的基础上仍然快速迭代产品，将成为我们未来需要思考的问题。
4. 发布了RisingWave Cloud的alpha版本。
RisingWave是开源项目，而非商业化产品。我们真正的产品是RisingWave Cloud，一款云上的流数据分析平台。如果说RisingWave提供的是软件，那么RisingWave Cloud提供的就是服务。所谓服务，并不是说要把RisingWave Cloud做成RisingWave as a Service，而是要基于RisingWave作为内核，做Stream Processing as a Service。毕竟，一款好的产品重要的是帮用户解决问题，而不是简简单单提供技术支持。再强大的发动机，也必须封装到经过精心设计的跑车中才能够发挥最大的价值。RisingWave Cloud已经开发了半年多时间，尽管我们已经发布了alpha版本并进行了内测，但是离想象中的形态还有不少差距。而在功能方面，云服务所涉及的安全以及合规等问题同样让我们反复修改设计。细节在这里就不多说了，但其中的心酸估计只有真真切切认真做过云服务才能够体会到吧。
RisingWave的发展速度是远超预期的。记得去年早些时候，当有人问我对RisingWave有什么规划的时候，我的回答是：在2022年年底开源，在2023年上半年获取早期用户，并同步开发云产品。当去年年底内部提出考虑在2022年4月开源的时候，我是认为步子有点迈得过大的：偏于保守的我比较期望等到万事俱备时再去考虑开源。而如今，当我们把整个进度，无论是开源还是用户落地还是云产品，都提前了至少半年以上的时候，我们会发现，很多事情实际上都没有我们想象的难，而真正的难点事实上并没有被我们细致的考虑过。总结下来主要是两方面吧：1）做产品与做技术的不同；2）做商业化与做产品的不同。
先说说产品与技术的不同吧。尽管我是学术圈+工程师出身，但我自认为是个非常务实的人，从一开始就非常明白技术与产品的区别。然而，道理大家都懂，但实际体会下来还是很不一样的。我们就把今年6月份写的RisingWave路线图（https://www.risingwave-labs.com/blog/on-the-way-to-democratized-stream-processing-risingwaves-roadmap/）拿出来讨论一下吧。当时我们路线图的设计主要是通过对比自身与现有成熟系统（如Postgres，Flink等）所做出的。可以看出，总体的路线图尽管在大方向上没有太多问题，但实际上低估了在稳定性与性能方面所花费的时间，并且没有充分的捕捉到用户对系统使用方面的需求。举个例子来说，在6月份的路线图中，我们认为系统的性能测试能够在三个月内完成。而从实际来说我们发现直到今天我们都没有系统性的完成性能测试。要知道，我们是有个全职测试团队以及一位产品经理全职在做这件事情的。那为什么我们还没有做完性能测试呢？主要原因是要进行完整的测试，需要考虑各种维度，如数据集与查询基准，机器规格，参数等等。更重要的是，每次进行性能测试，就意味着我们可能需要工程师修复bug或者性能瓶颈。庆幸的是，通过团队的努力，我们已经完成了大部分工作，预计很快就能够发布性能测试报告。除了性能测试这个例子之外，还有个例子是我们低估了系统集成的复杂度。所谓集成，并不是简简单单写几个不同系统的连接器就完事了，而是要考虑到用户在生产环境中所使用的工具，如调试工具、运维工具等等。这类工具的不成熟直接导致了我们的系统在一些场景下无法快速落地，并需要我们给出快速的解决方案。
2022年6月写的3个月内的规划
2022年6月写的6个月内的规划
前一阵子回顾了乔布斯的一番话，让我体会颇深。总的来说就是：不要拿着技术去找客户，而是要了解客户需求而去反推技术。这些话说出来大家都懂，但要不是真的自己踩一遍坑，真的是没有那种深刻的体会。要我在这里念首诗的话，便是“纸上得来终觉浅，绝知此事要躬行”。唉也许是我文笔不好，我发现自己还是没法写出这种感觉，还是等着各位自己去踩坑之后细品吧。
乔布斯的话
我再来说说商业化跟产品的区别吧。如果正在读这篇文章的你是一位工程师的话，也许没有太多机会能够去体会到，但如果真正自己去卖个产品的话，想必在被拒绝n多次之后就能体会到。我们有再好的产品，哪怕是用户急需的产品，也并不意味着能够顺利的把产品卖出去。谁是客户？客户为什么要买这个产品？客户付多少钱？怎么付？如何维护跟客户之间的关系？客户公司内部的办公室政治是怎样的？卖给客户之后如何处理用户的请求？等等。这里的问题实在是太多了，就不一一展开了。总的来说，想要卖东西，产品自身过硬最多只是必要条件，但并不是充分条件。很多事情并不是靠堆工程师或是堆销售就能够解决的，而是要通过理解客户的习惯、喜好、性格等等才能够做成。硅谷顶级VC之一Sutter hill Ventures的董事总经理Mike Speiser（也就是Snowflake的最早期投资者及CEO）有一套成熟的销售方法论。销售方面的很多策略在他那里都变成了公式。不少工程师可能会对销售策略等嗤之以鼻，并认为硅谷一众公司成功的主要原因是因为工程师文化。作为工程师出身的我自然理解工程师文化的重要性，并认同一些“有毒文化”的危害，但当我们真实的去运营一家商业化公司时，我们很有可能会感慨：“我要是能够学会这套公式与技巧该多好！“
最后再来说说对于RisingWave（以及公司）在2023年的展望。从我的角度，我们会往以下几个方向上下功夫。
首先是社区。RisingWave是一个开源项目。目前的“躺着”做社区的状态并不是我们想要的。RisingWave在新的一年会大力发展社区。我们会在社区中更加频繁、更加深入的推广流处理、云原生等技术，并分享RisingWave的设计理念。随着全球疫情的逐步好转，RisingWave社区会推出更多的线下活动，通过面对面的方式进一步拉近与技术爱好者的距离。
其次是用户推广与支持。帮助用户成功，才能实现RisingWave的成功。我们在新的一年中会更加积极的扩大RisingWave的影响力，扩张RisingWave的用户群体，并通过用户的反馈来更加及时的调整RisingWave的开发路线图。
最后是云产品与商业化。我们会在云产品方面更加努力。剧透一下，RisingWave Cloud的beta版本也即将发布，希望各位关注。在商业化方面，我们会认真接受客户的批评，“客户虐我千百遍，我待客户如初恋”便是我们的态度。
就写到这里吧。预祝各位2023年越来越好，也希望RisingWave在新的一年越来越成功！
如果你希望了解RisingWave，可以访问我们的Github主页: https://github.com/risingwavelabs/risingwave。
最近我们也开通了中文社区。微信用户可以添加微信小助手来加入我们的中文社区微信群，小助手微信号：risingwave_assistant
谢谢各位捧场！
