在上一篇推文中，已经为大家分享了 RisingWave 相关核心概念和术语。本文将在此基础上为大家介绍 RisingWave 的架构、容错以及数据持久化。
1架构
RisingWave 的架构如下图所示。它由三个主要部分组成：Meta 节点、Compute 节点和 Compactor 节点。
Meta 节点负责管理 Compute 节点和 Compactor 节点的元数据，并协调整个系统的操作符。
Compute 节点负责从上游系统获取数据，解析和运行 SQL 查询，并将数据传送到下游系统。
Compactor 节点处理数据存储和从对象存储中检索数据。它们还执行数据压缩，以优化存储效率。
RisingWave Architecture
2容错
RisingWave 是一种容错的分布式流处理系统。让我们通过以下三个方面对其是如何处理故障的做整体了解：
RisingWave 如何从故障中恢复？ 发生故障时，RisingWave 如何确保数据的正确性和一致性？ RisingWave 的故障恢复对计算有何影响？
RisingWave 采用 Chandy-Lamport 算法[1]创建检查点。检查点是代表整个系统在特定时间点的一致状态的全局快照。在 RisingWave 中，检查点被持久化到一个持久且高度可用的远程存储中。
读取查询时，RisingWave 总是从上一个检查点获取数据。这确保了数据的正确性和一致性。
如果发生故障，只有未保存到下一个检查点的状态才会丢失。RisingWave 所有内部有状态的算子都将从上一个检查点获取状态。这种方法避免了全部重新计算，因此不会造成长时间延迟。检查点间隔可以配置，默认为 10 秒。这意味着故障造成的延迟不应超过 10 秒。
例如，假设 RisingWave 集群已摄取 Kafka 数据 24 小时，在 1:00:25 出现故障，而最后一次检查点是在 1:00:20。在这种情况下，RisingWave 不会重新计算一天前的数据，而是从 1:00:20 的检查点开始重新计算。
为了尽量减少对计算的影响并提高效率，检查点是增量创建的。自上次检查点之后生成的状态会增量持久化到远程存储中。RisingWave 会在后台运行远程压缩任务来压缩检查点中的状态。这样可以回收空间，并提高读取性能。
3数据持久化
RisingWave 在创建检查点时，流算子和输出结果的增量状态会被持久保存在高可用的远程存储中，默认的检查点间隔为 10 秒。
在 RisingWave 中，Compute 节点在创建检查点之前会在内存中缓冲脏状态（脏状态指的是自上次检查点以来未保存的状态），从而执行写批处理。
当内存缓冲区超过某个内存阈值（可配置）或创建检查点时，脏状态将被刷新并持久保存在远程存储中。
RisingWave 并不要求所有数据都保存在内存中才能运行。数据可以持久化至：
S3 或与 S3 兼容的对象存储 谷歌云存储，或 HDFS/WebHDFS（通过 Apache OpenDAL[2] 实现支持）
如果有更多的内存资源，通常可以实现更好的缓存，从而提高性能，特别是对于要求很高的工作负载来说。不过，也可以通过分配有限的内存资源，实现中小型工作负载中等性能，从而节省一些成本。
Chandy-Lamport 算法: https://en.wikipedia.org/wiki/Chandy%E2%80%93Lamport_algorithm
[2]Apache OpenDAL: https://en.wikipedia.org/wiki/Chandy%E2%80%93Lamport_algorithm
关于 RisingWave
往期推荐
技术内幕
