2026 RisingWave 与 Materialize 服务器租用配置手册：状态后端落在内存还是对象存储 + 检查点账怎么算 + 避坑全解

2026 RisingWave 与 Materialize 服务器租用配置手册：状态后端落在内存还是对象存储 + 检查点账怎么算 + 避坑全解

状态放哪儿，先于 CPU 和内存的那一笔账

给流式增量视图配服务器，第一个要定的不是 CPU 核数，也不是内存插到多大，而是「状态放哪儿」。Materialize 把索引与物化视图的活跃状态留在计算副本的内存里，RisingWave 用 Hummock 把状态写成对象存储上的 LSM 树，计算节点对持久化而言是无状态的。这一条分叉一旦选定，后面四笔账会被连带改写：内存账从「硬约束」变成「缓存预算」，本地盘从「可有可无」变成「读放大的缓冲器」，网络上行从「只跑查询结果」变成「状态本身的搬运工」，恢复时间从「重新水化要多久」变成「挂载文件有多快」。

据 RisingWave 官方 FAQ 口径，RisingWave 有内置状态存储，不需要额外部署和管理 RocksDB，且 streaming、serving、compactor 三类节点可以独立扩缩；据 Materialize 官方文档口径，副本在处理期间把索引与物化视图的活跃状态放在内存里，持久化由 Persist 层（blob 存储加 consensus）提供。两种说法都成立，差别在于它们各自把成本压在了不同的资源上：前者把成本推给对象存储的容量、请求次数与上行带宽，后者把成本压给副本内存。

所以正确的选型顺序是先算状态规模，再定一致性要求，最后才回到机型。反过来做——先挑一台高核数大内存的机器然后问能不能跑——十有八九会配错，而且错的地方往往不在 CPU 上。本篇只围绕流式增量视图这一套负载展开，讲清楚「状态后端落在内存还是对象存储」之后派生出来的每一笔账，不涉及安装步骤，也不做与 Flink、Kafka Streams、ksqlDB 的横评。

内存态副本的读写路径：arrangement 常驻内存，Persist 只兜底

Materialize 构建在 Timely Dataflow 与 Differential Dataflow 之上（Rust 实现），计算副本（cluster replica）在处理期间把索引与物化视图的活跃状态放在内存里。这个「放在内存里」的具体形态，是 Differential Dataflow 中的 arrangement——一组按 key 排序、带时间戳的物化集合。索引是 arrangement，物化视图的中间结果也是 arrangement，查询直接在这些内存结构上做查找，不需要回落到磁盘。

写路径上，输入变更进入数据流后先更新内存中的 arrangement，再由 Persist 层把变更写入 blob 存储，并借助 consensus 保证写入顺序。这里要分清两件事：Persist 提供的是持久化与恢复兜底，不是读路径的支撑。正常服务期间，查询命中的是内存里的 arrangement，blob 存储只在副本重启、扩副本或故障恢复时才被大量读取。据第三方汇总给出的量级描述，arrangement 查找是亚毫秒级，视图维护在个位数毫秒级；这两个数字不是厂商公布口径，实际值受数据规模、查询复杂度与机型影响，需以自身压测为准。

这条路径的直接后果是：内存就是工作集上限。状态规模超过副本内存，作业跑不起来或者被 OOM 打断，解法只有三种——换更大规格的副本、拆分成多个小集群、或者把状态本身做小。磁盘在这套架构里不参与查询，本地盘的容量压力相对小，这也意味着把预算堆在大容量磁盘上边际收益很低。

另一个容易被忽略的点是 Materialize 的 PostgreSQL 兼容边界。它支持 PostgreSQL 线协议与相当一部分 SQL 能力，包括 SELECT、物化视图与索引、窗口函数、CTE、jsonb 等，并提供 SUBSCRIBE 输出变更流；但不支持存储过程、触发器与部分 PostgreSQL 专有函数。如果你的应用层大量依赖存储过程或触发器，迁移到这类流式增量视图之前，这部分逻辑要另找落点，不能指望数据库侧照搬。

对象存储态的读写路径：mem-table、SSTable 与 compactor 三件套

RisingWave 的状态引擎 Hummock 是写在对象存储（S3、GCS、Azure Blob）上的 LSM 树。写路径分三步：状态变更先在流节点的内存 mem-table 里缓冲；flush 被触发时（触发条件是内存压力或 checkpoint barrier），mem-table 被序列化成不可变的排序 SSTable 上传到 S3；后台的 compactor 节点负责合并 SSTable、清理墓碑条目、优化读性能。

读路径是三级缓存：流节点与服务节点的内存 block cache 在最前，本地 NVMe SSD 缓存居中，S3 在最后。大部分点查应当命中前两级，穿透到 S3 的那部分决定了尾延迟与请求成本。整个集群由 meta 节点协调——它管理 Hummock 的元数据、编排 checkpoint、处理作业生命周期。meta 节点本身的规格通常不是性能瓶颈，但它的可用性就是整个集群的可用性，不能只部署单点而不做高可用设计。

这套设计里最关键的一句是「计算节点对持久化而言是无状态的」。节点掉了不丢状态，换一台机器挂载对象存储上的既有文件就能接着跑。代价是状态的每一次变更都要走一趟网络，而且这趟网络是持续的、与查询量无关的——查询量为零时，只要状态变更还在发生，上行流量就还在跑。

内存账怎么算：从基数与窗口长度折算副本内存压力

内存态方案的内存预算等于「活跃 arrangement 工作集」乘以安全系数，注意它既不是源数据量，也不是磁盘上表的大小。折算方法按四步走，每一步都要把假设条件写清楚。

第一步，列出所有索引与物化视图，逐个估计条目数。聚合类视图的条目数与 group key 去重后的基数同量级：按 user_id 聚合，条目数上界就是活跃 user_id 数；按 device_id 聚合，就是活跃 device_id 数。这一步的假设是「每个键至少占一个条目」，高基数字段会让这个数字迅速膨胀，也是内存超预期最常见的原因。

第二步，把窗口长度乘进去。滚动窗口保留窗口内全部输入，条目数约等于「窗口时长 × 每秒事件数 × 每个事件产生的平均条目数」；滑动窗口因为窗口重叠，还要再乘以同时存活的窗口个数。假设每秒 1 万条事件、窗口 5 分钟，仅原始输入就是 300 万条量级，若再叠加多个窗口重叠与中间 arrangement，数量还要继续往上走。这条推算的前提是事件速率稳定，如果业务有明显的波峰，要按峰值而不是均值来算。

第三步，考虑多版本与撤回。Differential Dataflow 维护的是带时间戳的差异集合，同一个键的多次更新在被 compaction 之前会留存多个版本；更新越热的键，累积的版本越多。源库是 CDC 且 UPDATE 频繁时，这一项的占比可能高于静态估算，静态算出来的数字会偏乐观。

第四步，加开销与安全系数。内存中的数据结构带有索引指针与分配器开销，实际占用高于序列化后的裸字节数；并发查询与峰值写入也需要 headroom。安全系数取多少没有通用值，通常要先按稳态占用留出足够余量，再留出一条能快速加内存的扩容通道。

验证这件事只有一个可靠办法：用生产流量样本在压测副本上跑，观察 arrangement 的增长曲线是否收敛。曲线持续上升不收敛，说明存在无界窗口、未撤回的更新，或者基数假设错了——这三种情况的解法完全不同，但表现都是「内存慢慢涨满」。把内存直接加到涨不动为止，是最贵也最容易掩盖真实问题的做法。

compactor 与后台角色：最容易被漏配的那一台

对象存储态方案里，mem-table、SSTable、compactor 三者吃掉的资源各不相同。mem-table 吃流节点的内存，缓冲尚未 flush 的状态变更，它的水位由内存压力与 barrier 频率共同决定；SSTable 吃对象存储的容量、PUT 请求次数与上行带宽，是不可变文件，只能整体替换不能原地修改；compactor 吃 CPU（排序与合并）、内存（合并时的读缓冲），以及对象存储的 GET 与 PUT（读回旧 SSTable、写回合并后的新 SSTable）。

compactor 之所以最容易被漏配，是因为它不在查询链路上。压测时把查询 QPS 打满，compactor 未必满载，于是看起来一切正常；但状态持续增长几周之后，SSTable 层数堆积、读放大上升、block cache 命中率下降、点查穿透到 S3 的比例变高、延迟上升，反压传导回流节点，mem-table 水位被迫抬高，最终整条链的性能一起退化。这是一个慢性的、跨周甚至跨月才暴露的问题，没有对应监控就查不到根因，最后往往被误判成「对象存储变慢了」。

判断 compactor 够不够，要看两个指标而不是看 CPU 使用率：一是 SSTable 的生成速率，也就是每分钟新产生的文件数与字节数；二是待合并字节的 backlog 是否收敛。backlog 只涨不落，就是规格不够或者并发度不够。所幸据官方 FAQ 口径，streaming、serving、compactor 三类节点可以独立扩缩容，compactor 是可以被单独加的那一环——前提是你确实在监控它，并且为它预留了独立的机型而不是塞在流节点上共用。

本地 NVMe 在这一架构里的位置：它是缓存不是持久层

在 RisingWave 的读路径里，本地 NVMe SSD 处在 block cache 与 S3 之间，是二级缓存。它不承担持久化职责，掉盘不会丢状态——状态本体在对象存储上，计算节点对持久化是无状态的。掉盘之后真正会发生的是另一件事：缓存失效，原本命中本地盘的读请求穿透到 S3，延迟上升、GET 请求次数上升、对象存储的请求计费上升，直到缓存重新热起来为止。

这个退化窗口有多长，取决于缓存重建速度与穿透后的 S3 带宽。换机、滚动重启、扩容新节点都会经历一次空缓存阶段，所以「新节点上线后先观察一段时间再切流量」应当写进运维流程，而不是直接全量切入。同理，缓存盘的容量规划不能只看「够不够放热点」，还要看「穿透率能否接受」，因为穿透率直接换算成对象存储的请求费用。

内存态方案里本地盘的地位恰好相反：主存是副本内存，本地盘更多承担 Persist 落盘与暂存，容量压力相对小，把预算堆在大容量磁盘上的边际收益很低。于是采购判断就很直接——对象存储态方案值得把预算放在更大的 NVMe 缓存盘和更高的耐久度上，用缓存容量换穿透率与请求次数；内存态方案则应该把预算全部压在内存容量上。另外，缓存盘的淘汰策略与水位线必须配置并监控，写满之后的行为是报错、阻塞还是绕开缓存，要提前在文档里确认清楚。

检查点账：每秒一次 barrier 换来什么，代价是什么

RisingWave 的一致性来自 barrier-based checkpointing：barrier 周期性流过整个 DAG（默认每秒一次），每个 barrier 标记一个一致快照；物化视图的结果在一个 barrier 间隔内保持新鲜，正常工况下是亚秒级新鲜度。这句官方描述里藏着三笔成本。

第一笔是写入放大的下限。即使没有任何内存压力，状态变更最多缓冲一个 barrier 间隔就要 flush 成 SSTable 上传——新鲜度要求把 flush 频率锁死了。同一个键在一秒内被更新十次，最终只有最后一个版本有意义，但在 compaction 回收之前，对象存储上躺着的是放大后的数据。barrier 越密，每次 flush 携带的重复版本越少但 flush 次数越多；barrier 越稀，单次 flush 的数据量更大、重复更新合并更充分，代价是新鲜度变差和 mem-table 内存占用上升。这是一个可以调的权衡，不是固定值，调之前要先明确业务能接受多长的新鲜度延迟。

第二笔是请求次数。SSTable 上传即 PUT 请求，每次 PUT 都计入对象存储的请求计费；compaction 又要 GET 旧文件、PUT 新文件。文件越碎小，请求次数越多，容量单价上省下来的钱可能被请求费吃掉。这正是「S3 约 $0.023/GB/月、EBS gp3 约 $0.08/GB/月」（厂商博客引用的 AWS 区域公开单价，须以官网实时价为准）这组对比没有覆盖的部分：容量单价便宜，不代表总账单便宜。

把这两笔账合起来可以做一次粗算：假设某作业的活跃状态为 500 GiB，按上述 S3 单价推算，对象存储侧的月容量成本约在 11 至 12 美元量级；同容量若用 EBS gp3 承载，按 $0.08/GB/月 推算约 40 美元量级。两者相差三倍多，但这只是容量一项，没有计入 PUT/GET 请求费、上行流量费与 compactor 的重复读写。反过来讲，内存态方案把 500 GiB 状态放进副本内存，需要的是数百 GiB 级的内存机型，这部分硬件成本要按整机摊销来算，不能只和对象存储的容量单价做对比。以上是按给定单价做的算术推算，假设条件是状态规模与单价均取给定值，实际账单以云厂商官网实时报价为准。

第三笔是尾延迟。据第三方汇总给出的量级，RisingWave 的端到端时延约 50–500 ms（含 barrier 对齐与状态 flush 到 S3），Materialize 是亚毫秒级查找加个位数毫秒视图维护。这组数字不是厂商公布口径，受部署形态、网络路径与数据规模影响很大，只能作为量级参考，不能当作 SLA 写进合同。如果业务对「读到的一定是最新」有硬要求，这 50 至 500 ms 的量级差异与快照一致性本身的取舍，比机型选择更值得先讨论清楚。

降低请求次数的手段也很明确：适当提高 mem-table 缓冲、减少碎小 SSTable、调整并行度与 flush 策略。但每一种都要拿新鲜度或内存占用去换，不存在白来的优化。把 barrier 间隔从每秒一次放宽到每十秒一次，请求次数会明显下降，代价是物化视图的新鲜度从亚秒级退到十秒级——这一步能不能接受，是业务问题不是技术问题。

资源对照表：两种状态后端在六个维度上的差异

一致性取舍：严格可串行化与快照一致性分别由谁买单

Materialize 提供严格可串行化（strict serializability）——查询结果等价于某个串行执行顺序，而且这个顺序与真实时间顺序一致；RisingWave 提供的是快照一致性（barrier-based），物化视图反映的是最近一个 barrier 的一致快照。两者不是高低之分，而是「错了能不能接受」之分。

第三方汇总指出了快照一致性在可变数据上的具体风险：RisingWave 对可变数据不提供全局逻辑时间，处理大 CDC 事务时可能让查询观察到源库中从未存在过的中间态，可变 CDC 场景需要显式去重与撤回逻辑。这句话要拆开读。「源库中从未存在过的中间态」意味着一份跨多行的业务事务，在源库里是原子提交的，但在流式视图里可能被读到只提交了一半的版本；如果这个视图下游是聚合计数，同一笔业务可能被重复计一次。

哪些业务必须为此接受内存态的代价？资金对账、财务凭证、订单状态机、结算归因——这些场景里错一次的结果是要人工冲账、要跟客户解释、可能要回退一批下游数据，成本远高于多买几条内存。把这类负载放在严格可串行化的引擎上，本质上是花钱买确定性。

哪些业务可以接受快照一致性？实时看板、 IoT 聚合、监控指标、趋势统计——一个 barrier 间隔（默认一秒量级）内的偏差对结论毫无影响，看板晚一秒刷新没人看得出来，趋势曲线的形状不会因此改变。这类负载放在对象存储态上，换来的是状态规模不再受单机内存约束，以及节点故障后秒级恢复的能力。

一个务实的判断句：一致性要求不是越高越好，而是看「错了之后回滚的代价有多大」。回滚代价高的，老老实实上内存态；回滚代价低的，用快照一致性换规模上限。中间还有第三条路——把状态做小，缩短窗口、提前预聚合、降低 group key 基数，让原本装不进内存的状态重新装得进去。这条路经常被跳过，但它往往是成本最低的。

网络账：上行带宽、请求速率与跨可用区流量

状态放在对象存储上时，流节点到对象存储的上行是持续、恒定、不可省的流量。它和查询量无关，只与状态变更速率、barrier 频率以及 compaction 策略有关。这一点和大多数数据库负载都不一样，习惯了按 QPS 估带宽的人很容易在这一项上算漏。

估算框架可以这样搭：上行字节速率约等于「每 barrier flush 出的 SSTable 字节数 × barrier 频率」加上「compaction 读回再写回的字节数」。注意 compaction 是读回再写回，同一份数据会被反复搬运，放大倍数取决于 SSTable 层数与合并策略，层数越多搬得越多。请求速率则是「PUT 次数与 SSTable 个数相关、GET 次数与读穿透加 compaction 相关」。这是一个推算框架，其中每个变量都要由实际作业的表数量、并行度与 flush 策略测出来，不能直接套用到别的负载上。

跨可用区流量是这一层里最容易被漏掉的隐藏成本。计算节点在 A 区、对象存储在 B 区时，每一 GB 都要双向计费；架构评审时这一项常常因为「反正都在同一个云里」而被忽略，等到月底账单出来才发现流量费超过了计算费。可行的处理办法是让计算节点与对象存储同区部署，并且确认对象存储的访问入口是否提供内网端点——走内网端点通常既能降低时延，也能避免公网出网流量计费，但具体是否计费、如何计费，要以所用云厂商的实时说明为准。

内存态方案的网络画像正好相反：常态网络压力小，只在 Persist 写入、副本重建、扩副本时才出现突发读取；但副本重建时会在短时间内拉满 blob 存储带宽，如果此时正好赶上业务高峰，恢复时间会被显著拉长。给内存态副本规划网络时，重点不是平均带宽，而是恢复窗口内的突发带宽是否够用。

自建场景下，这几项都要向机房侧逐条确认：出口带宽是保障带宽还是共享带宽、上行是否单独限速、流量按 95 计费还是按固定带宽计费、到对象存储公网端点的路径质量与抖动情况。如果需要与既有数据库或上游系统做低时延互联，可以评估点到点线路或自有线路的方案，具体可行性与报价需实时询价。

恢复与扩缩容：加节点迁不迁状态，容错要不要双倍计算

加节点这件事在两种架构下的含义完全不同。RisingWave 的计算节点对持久化无状态，加节点不需要搬运既有状态文件，新节点挂载对象存储上的文件就能开始服务；但新节点的 block cache 与本地缓存是空的，需要一段预热期，预热期间的读穿透比例会偏高。Materialize 加副本则需要重新水化完整状态，所需时间与状态规模直接相关，状态越大等得越久。

恢复时间上，据 RisingWave 官方口径，从对象存储挂载既有文件恢复是秒级；据官方对比表口径，Materialize 的容错成本被描述为需要 2 倍以上计算资源（厂商口径），也就是说为了宕机时业务不中断，需要常备冗余副本，这部分冗余是计入常态成本的。做预算时要把「2 倍以上」这个口径翻译成具体机型数量，而不是记住一个倍数就完事。

扩缩容的维度也值得单独说。据官方 FAQ 口径，RisingWave 的 streaming、serving、compactor 三类节点可以独立扩缩——读压力大就加 serving，写入压力大就加 streaming，SSTable 堆积就加 compactor。这种拆分让资源配置有明确的着力点，不用为了一个瓶颈整体扩容。缩容时则要反过来检查两个风险：内存态缩容后剩余副本的内存是否仍能装下工作集；对象存储态缩容后 mem-table 与 block cache 的总量下降，穿透率是否还在可接受范围内。

版本升级与滚动重启也要算进维护窗口。内存态滚动重启意味着逐个副本重新水化，总耗时约等于副本数乘以单个副本水化时间，状态大时这可能是一个以小时计的窗口；对象存储态重启主要损失的是缓存，恢复后性能有个先低后高的爬坡过程。两种都需要先在预发环境跑一遍，把真实耗时测出来再排生产窗口。

还有一个版本边界要提前确认：RisingWave 社区版（CE）自托管有 24 GiB 上限的说法（厂商对比表口径）。选型时要确认这个上限具体指向哪种资源、适用于哪个版本与哪种部署形态，以官方实时说明为准——不要拿二手对比表里的数字直接做容量规划。

什么情况下不该自建流式增量视图节点

自建不是默认选项，下面几种情况建议直接放弃自建，改用托管服务或者换一个更简单的架构。

第一种是没有能看懂这套系统内部状态的人。至少要有人能读懂 barrier 的行为、能判断 compaction backlog 是否收敛、能看出 arrangement 增长曲线是否异常、能在反压发生时定位到是哪一环。如果团队里没有这样一个人，自建的结果是故障只能靠重启解决，而且重启也不一定有效。流系统的故障往往表现为「变慢」而不是「挂掉」，没有可观测性就等于没有运维能力。

第二种是状态规模大且增长不可预期。状态在几十 GiB 以内、增长曲线可预测时，内存态副本的成本是可控的；状态到了数百 GiB 乃至 TB 级还在持续增长时，内存态自建的成本曲线会明显变陡，要么持续升配，要么不得不拆分成多个小集群，后者又带来运维复杂度的上升。这时候对象存储态的架构优势才开始体现，但它换来的是一致性等级与端到端时延上的让步。

第三种是「要求严格可串行化且状态很大」这个组合。这是最贵的一种组合：既不能接受快照一致性，又要为巨大的工作集付内存成本。要么接受这个成本，要么先把状态做小——缩短窗口、预聚合、降低 group key 基数——把规模压回到内存能装下的范围。如果两条路都走不通，说明这个需求本身需要重新设计，而不是靠加机器解决。

第四种是想用二手价格做预算。Materialize Cloud 的按需价，有来源称 $1.50/compute credit/小时，也有来源称起价 $0.98/小时；RisingWave Cloud 有 $0.227/RWU/小时的口径。这几个数字来源不同、口径不一，彼此不能直接比较，更不能拿来推算自建成本。所有云端计费一律以官网实时报价为准，自建成本则以实际询价为准。

反过来，自建确实成立的边界也很清楚：数据需要留在自有网络内、跨境链路受限、需要与既有数据库同机房做低时延互联、负载长期稳态且能把硬件成本摊薄。这四条里至少满足两条，自建才谈得上划算。

状态落在内存还是对象存储，这道选择题该按什么定

把前面所有账收拢起来，这道选择题只需要按三个变量排序来定：状态规模、一致性要求、新鲜度要求。顺序不能颠倒。

先看状态规模。状态能装进单机内存且增长可预期，内存态就是合理选择，顺带拿到亚毫秒级的 arrangement 查找（第三方汇总口径）与严格可串行化；状态超过单机内存或增长不可控，对象存储态几乎是唯一解，状态规模的上限由对象存储容量决定，而不是由某台机器的内存插槽决定。大状态处理能力上的这个差异，是两种架构最本质的分工。

再看一致性要求。对账、财务、订单状态机这类错了要冲账的场景，必须选严格可串行化，这是内存态的主要理由，而且这个理由优先于成本；实时看板、IoT 聚合、监控指标这类刷新一次就能自愈的场景，快照一致性完全够用，没必要为它多付内存成本。如果源是可变 CDC，选对象存储态时务必把去重与撤回逻辑写进作业里，这是第三方汇总明确点出的风险点，不是可选项。

最后才看新鲜度要求。默认每秒一次的 barrier 换来亚秒级新鲜度，代价是固定的写入放大下限与持续的请求次数；能接受十秒级新鲜度的业务可以把 barrier 放宽，请求费与上行流量会明显下降。这一步的调整空间比换机型大得多，却最常被忽略。

一句话判断：内存态买的是确定性，对象存储态买的是上限。知道自己缺哪一个，配置单就写出来了。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。针对流式增量视图这类负载，我们在配置阶段会先按状态规模与一致性要求区分内存态副本与对象存储态节点，再分别匹配大内存机型、NVMe 缓存盘规格与上行带宽档位，避免把预算压在不会成为瓶颈的 CPU 上。

一万网络给流式增量视图节点的配置口径

落到具体配置单上，我们的口径是按角色拆机型，而不是给整个集群定一个统一规格。内存态副本节点优先保证内存容量与内存通道数，本地盘给到够用即可，把省下来的预算换更大的内存；对象存储态的流节点与服务节点优先保证内存（mem-table 与 block cache 共用）与 NVMe 缓存盘容量，CPU 核心数按并行度配置，不盲目堆核；compactor 与 meta 节点单独给机型，尤其是 compactor，必须为它留出独立的 CPU 与内存余量，不能和流节点共用一台机器。

网络侧的口径是优先确认上行而不是下行。对象存储态节点的上行流量是恒定的，需要明确保障带宽档位与计费方式；内存态节点则要确认恢复窗口内的突发带宽。跨可用区、跨地域的流量一定要在部署前算清楚，让计算节点与对象存储尽量落在同一区域，避免把成本花在来回搬运状态上。

关于连接器与生态，据第三方汇总与官方页面，RisingWave 支持 Kafka、Redpanda、Pulsar、Kinesis、NATS 作为源，支持 PostgreSQL CDC 与 MySQL CDC，并提供 Iceberg sink 与 S3 source；Materialize 支持 Kafka 与 Redpanda，对 Iceberg 支持有限。如果数据源落在上述清单之外，或者依赖 Iceberg 作为下游，选型阶段就要先确认连接器能力，别等到部署之后才发现要自己写。性能方面，RisingWave 官方公布的 Nexmark 口径数据为：简单投影约 893 k records/s，带过滤选择约 764 k records/s，滚动窗口 join 约 312 k records/s，多路 join 约 285 k records/s；Materialize 未用同一 Nexmark 方法发布可比数据，因此这组数字只能单侧参考，不能用于两者直接对比。

最后重申一遍价格纪律：本篇出现的所有单价与计费口径都来自厂商博客或第三方汇总，且不同来源之间存在不一致，实际选型请以各厂商官网实时报价为准；一万网络的具体机型、带宽与报价同样以官网实时信息或咨询确认为准，不提供未核验的价格承诺。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。流式增量视图节点的配置，我们会按状态后端类型分别给出内存、缓存盘、上行带宽与后台角色的建议档位，并配合你完成压测阶段的水位观测，确保扩容通道在真正需要的时候能用得上。