深入理解 RisingWave 流处理引擎（一）：总览
｜作者：师天硕 RisingWave Labs 内核开发工程师
关于本系列
在《深入理解 RisingWave 流处理引擎》系列，我们希望通过一系列文章自顶向下，由浅入深地分享 RisingWave 中流处理引擎的方方面面，聊聊我们在从零开始设计这个流处理引擎时的设计理念，进一步去深入各个模块的技术原理以及实现细节。
流处理还是一个相对年轻的领域，很多设计和工程上的最佳实践没有形成公论。我们非常希望能和对流处理感兴趣的爱好者，研究者和使用者进行更深入的交流，欢迎大家在评论区和其他渠道进行讨论，共同探讨流处理技术的未来。
那么让我们开始吧！
01
RisingWave 的流处理引擎在做什么？
简而言之，RisingWave 的流处理引擎上支持运行 long-running 的分布式计算任务，对于由源关系表上用 SQL 定义的目标关系表，它源源不断地从原关系表中的变更流增量的计算得到目标关系表的变更流。
这样有些抽象，下面用一个例子来进行说明。
在如下的 SQL 中，我们定义了一个文章表 Stories 来维护文章的详细信息，用户的点赞事件形成了一张 append-only 的表 Votes。
CREATE TABLE Stories (id int, author int, title text, url text, PRIMARY KEY id);CREATE TABLE Votes (user int, story_id int);在这两张表的基础上，我们可以使用 SQL 语句定义物化视图（Materialized View，以下简称MView）。例如以下的 MView StoriesWithVC 维护了每篇文章的点赞数量。
CREATE MATERIALIZED VIEW StoriesWithVC ASSELECT id, author, title, url, vcountFROM storiesJOIN ( SELECT story_id, COUNT(DISTINCT user_id) AS vcount FROM votes GROUP BY story_id) VoteCountWHERE VoteCount.story_id = stories.id;进一步的，我们可以在 MView StoriesWithVC 上定义新的 MView。
CREATE MATERIALIZED VIEW Top10VotedStories AS SELECT * FROM StoriesWithVC ORDER BY vcount DESC LIMIT 10在这个例子中，RisingWave 需要高效的维护 MView 当中的内容，同时由于支持级联的建立 MView on MView，还需要能够计算出 MView 本身的变更。通过 MView 的变更维护 MView 的实时结果是容易的，因此 RisingWave 流处理引擎只需要通过上游表的变更流，计算出下游表的对应变更。如下图，当源表 stories 和 votes 发生变更时，流处理引擎就会计算出下游 MView StoriesWithVC 的变更，继而计算出 Mview Top10VotedStories 的变更。
02
设计理念
SQL-native 的计算模型
可以看出，RisingWave 整个流处理引擎的输入和输出都相当于关系表上的数据变更，有着明确定义的结构（schema），事实上在内部的算子也是基于关系表的变更作为输入和输出，这是由 RisingWave 作为流数据库的定位导致的。RisingWave 用标准的SQL接口来支持用户创建流处理作业，可以说 RisingWave 的流处理从 day1 就是针对 SQL 查询和关系型数据的计算负载进行设计。这与其他一些从大数据时代走来的流处理系统的发展不同，它们往往是先实现通用的流计算框架，再在这个计算框架上搭建 SQL 引擎，提供 SQL 接口。
通用到特化的设计理念
SQL-native 的计算模型可以让我们借助关系代数很好的定义 RisingWave 在流处理上的问题边界，让我们在架构上能够自顶向下的构建整个流处理引擎。在 SQL feature 的设计中，通常从最通用的 SQL 算子开始设计。而后针对不同的场景进行特化和优化，来达到特定负载下的极致性能。这种设计理念使得我们能保证流处理模型通用性的同时，对各种常用的特定场景能够达到不俗的性能。
值得一提的是，在开发中我们发现，这种特化可以分布在不同的层面上。
•执行器在运行时的自适应：我们在算子中实现了 LRU-based 的 state cache，确保在状态较小，内存充足的时候所有状态可以全量存在内存中。•优化器在生成plan期间特定算子优化：例如针对 append-only stream 特化算子，大幅优化性能。•配置项参数：例如用户针对数据新鲜度（Freshness）和执行开销（Cost）的权衡，我们将其收敛到 barrier_interval 等几个配置项上。
03
核心特性
除此之外，一些核心特性贯穿了设计始终，我们将这些特性视作 RisingWave 流处理引擎的一等公民，在每一处的设计和实现上都一致地保证这些特性。
分布式并行的执行引擎
RisingWave 是一个分布式系统，能够大规模并行处理数据。RisingWave 流处理引擎能够充分利用多节点和多核的计算资源，同时生成的执行计划尽可能避免单点计算，将计算分布或下推在多个节点上，减少系统中潜在的单点瓶颈。
灵活弹性的云原生调度
RisingWave 作为云原生流数据库，在并行处理的基础上支持了动态扩缩容的能力。由于流处理任务是 long-running 的，要使集群的动态扩缩容起到作用，流处理引擎必须支持任务的在线调度和迁移，这给状态存储，数据分区等设计抽象带来了极大的挑战。RisingWave 流处理引擎向外暴露了调度和迁移接口，使得外部管控组件可以方便的迁移和调度计算任务。
快速高效的容错与恢复
容错是现代流处理系统必须的基本能力。流处理系统通常采用 checkpoint 机制持久化计算状态，在系统内部达到 exactly-once 的语义，以此实现容错与恢复。同时需要尽量避免或减少 checkpoint 过程抢占资源，影响前台流处理任务。RisingWave 自己实现状态存储引擎，实现了 checkpoint 全链路异步化，使得 checkpoint 过程对前台任务几乎无影响。
快照隔离的流计算结果
RisingWave 作为一个流数据库，内部的 MView、Table 等对象之间需要保证计算结果的一致。更具体的说用户在同一时刻查询到不同 MView 的结果是基于源表的同一版本，这要求在上游表中的变更和下游表中对应引发的变更需要原子地在同一个纯写事务中提交。
这就要求每一个流算子在计算时不能轻易的延迟数据和对数据进行攒批，在收到上游数据时就要即时将对下游地更改下发。熟悉流计算的读者可能都知道，流算子可以通过攒批提供更好的性能。我们针对此做了两个优化：一是引入 epoch 的概念，一个 epoch 内可以对应多条源表上的变更，相当于扩大前文所说的写事务的大小，算子可以在该事务中进行攒批；二是针对流计算常见的 watermark 攒批设计了 EMIT ON WINDOW CLOSE 的查询语义（RFC: The Semantics of EMIT ON WINDOW CLOSE by fuyufjh · Pull Request #30 · risingwavelabs/rfcs (github.com)[1]），让用户能够声明他所希望的 MView 与上游的一致性语义。
04
整体架构
整体架构如下图所示。最左侧 Frontend 节点通过 pgwire 和用户连接，负责把 DDL SQL 语句转化成流处理执行计划，并在优化器中对计划进行优化，将执行计划发送注册到中心的 Meta 节点上。Meta 节点会将执行计划持久化在全局强一致高可用的 MetaStore 中，并根据执行计划向计算节点发送计算任务。在 streaming job 的整个生命进程中，meta 节点可以通过RPC向计算节点发送控制指令，实现对计算任务的迁移调度，checkpoint 和 failover。外部系统或用户也可以通过 Meta 节点暴露的接口直接控制和调度计算节点上的计算负载。
05
总结
本文从实际场景出发，介绍了 RisingWave 流处理引擎的使用场景，描述了其在架构设计中所依赖的设计理念和核心特性，在最后给出了整个流处理引擎的整体架构。
References
[1] RFC: The Semantics of EMIT ON WINDOW CLOSE by fuyufjh · Pull Request #30 · risingwavelabs/rfcs (github.com): https://github.com/risingwavelabs/rfcs/pull/30