摘要

  • RIPE NCC 在 2026 年第三季度 RIS 计划中说，RIS/RIPEstat 数据迁往租用裸金属服务器的工作已经完成；同一条计划又把数据处理监测、技术债清理以及降低 HBase 依赖的存储架构研究标为进行中。
  • Kafka 机器更换和版本升级是另一项进行中的工作，此前因资源有限而推迟。它没有证明数据迁移失败，公开资料也没有显示数据丢失、损坏或服务中断。
  • RIPEstat 的历史计划记录了迁移期间它与后端系统之间出现额外延迟。团队研究过并行查询等隐藏延迟的方法并持续监测影响，但资料没有给出延迟数值，也没有声称服务目标被突破。
  • 最合适的公共凭证是一张分组件迁移收据：明确数据范围、技术代际、切换窗口、重放或回填决定、MRT、RIS Live 与 RIPEstat 的独立检查、已知例外、验收角色和观察期。

“完成”的宾语不能丢

RIS 2026 年第三季度计划里最值得保留的不是一个绿色状态，而是句子的完整宾语。RIPE NCC 写的是：把 RIS/RIPEstat 数据迁移到租用裸金属服务器的工作已经完成。

紧接着，计划把后续任务拆开。数据处理的监测要改善，部分技术债要清理；团队还在研究其他存储架构，以降低对 HBase 的依赖。这一项仍是进行中。下一项则是更换 Kafka 机器并升级 Kafka 版本，曾因资源有限而推迟，现在同样处于进行中。

这不是自相矛盾。数据搬迁、消息运输、处理程序、存储选择和消费者体验本来就可能在不同时间收尾。把仍在进行的工作当作迁移失败的证据，会抹掉计划里已经做出的范围区分。反过来，把“数据迁移完成”扩写成“整套 RIS 已全部更新并验证”，同样超出了资料。

需要治理的不是哪个动词更好听，而是这个动词能承担多大范围的证明责任。后来发生一次查询变慢、一个文件迟到或一次 Kafka 切换时，人们需要知道它属于哪一项工作，而不是笼统地回到“那次迁移”。

一条 BGP 消息经过多少只手

RIPE NCC 对 Routing Information Service 的介绍，从志愿网络与远程路由收集器之间的 BGP 会话开始。RRC 通常设在互联网交换中心，接收对等方发来的更新和撤回。RIPE NCC 保存并公开这些数据，让运营者和研究人员观察路由系统。

这条链上没有哪个环节能够代表全部事实。对等方决定展示哪一份视图；收集器记录自己收到的内容；传输系统把消息送往处理层；处理任务生成文件、索引或查询结果；存储系统保留不同代际的数据；公开接口再按各自的节奏交付给用户。

因此，迁移期间的一条结果至少有四个时间问题：它在切换前还是切换后被采集？由哪个处理版本生成？存入哪个代际的存储？如果队列被重放，它的公开时间和原始观察时间是否被分别保存？这些问题并不是怀疑数据真实性，而是在保护它作为证据的用途。

如果一项路由研究跨过切换窗口，却无法判断样本来自旧链、新链还是回放链，今日的“服务正常”无法替代当时缺失的谱系。迁移收据的价值就在这里：给每一段历史留下可复核的生产边界。

RIPEstat 把消费者边界暴露出来

RIPEstat 归档计划公开了一项不应被夸大、也不应被忽略的影响。文件称，RIS 团队把与 RIPEstat 有关的大数据迁往租用裸金属服务器，这导致 RIPEstat 与后端系统之间出现额外延迟。RIPEstat 团队支持迁移，研究过包括并行查询在内的隐藏延迟方法，并仔细监测迁移影响。该支持事项在 2026 年第三季度完成。

资料没有给出毫秒数、百分位或受影响查询清单，也没有说某个服务承诺失守。“研究过”不能自动变成“已在所有路径部署”。所以这不是一篇故障报道。

它证明的是另一件更重要的事：底层数据完成搬迁之后，消费者仍然有自己的验收对象。存储吞吐、后端距离、查询并发和最终响应不是同一个指标。一条成功返回的请求只能说明那次请求，不能替整段分布或所有查询类型签字。

公共收据可以用聚合数据表达这个边界。它不必暴露用户请求或内部地址，只需说明测了哪些查询类型、切换前后各测多久、看的是中位数还是尾部延迟、并行查询或其他缓解是否适用。

MRT、RIS Live 和 RIPEstat 要各自作证

MRT 文档给出了一套可以外部复核的节奏。RIS 按收集器存放文件。bview 是某个时点的路由状态，update 文件记录一个时间段内的变化。当前文档写明，dump 每八小时生成一次，update 每五分钟生成一次。

这使用户能够为每个 RRC 列出预期时间槽。但文件名出现并不等于内容、代际和其他输出全部正确。验收仍要记录大小或哈希、处理版本、抽样结果、缺口、例外，以及是否执行过重放或回填。此前关于某个已生成却未发布的 bview 的文章处理的是一次特定事件；本文不声称现在存在缺失文件。

RIS Live是另一种证据面。RIPE NCC 把它描述为接近实时的 BGP 消息流。流在此刻新鲜，不证明历史 MRT 档案完整；MRT 槽位齐全，也不证明 RIPEstat 查询没有额外后端延迟。现有一手资料没有授权我们假设三者走同一条内部路径。

所以迁移验收不能用一个绿灯覆盖三张表。MRT 看每个 RRC 的时间槽和内容边界，RIS Live 看自身的新鲜度，RIPEstat 看查询类别与延迟分布。它们可以互相参照，但不能互相代替。

历史计划提醒我们保留代际

RIS 归档计划记录，RIPE NCC 在 2023 年更换了生成公共 MRT dump 的管线，延迟明显减少，同时 MRT 文件结构有一些变化。这说明两段都有效的历史数据，也可能由不同生产代际生成。

2025 年计划还提到一个已经解决的数据不一致：某个被移除的 IPv6 对等方，其数据曾继续出现在数据集中。RIPE NCC 计划公开记录这一项和其他较小的数据伪影，但文档工作后来推迟。这里必须保持时态准确——不一致已经解决，推迟的是公开说明；它不能被写成仍在持续的错误。

2024 年的外部 Kafka 数据分发和 RIS Live 开源计划则被降低优先级。它们是产品史，不是当前架构图。过去的公共 Kafka 原型与今天计划中待更换的 Kafka 机器也不能未经证据就画上等号。

这些记录共同说明，好的迁移凭证既要写适用关系，也要写“不适用”。后者能阻止旧项目名、旧原型和新硬件在日后被错误拼接。

一张不泄露拓扑的收据

收据第一栏应是范围：哪些数据集、收集器、时间段和面向用户的产品被纳入，哪些明确排除。第二栏是谱系：适用的采集代际、传输代际、处理部署和存储代际。若某条路径不使用这批 Kafka，就应写明不适用，而不是为了表格完整强行关联。

第三栏是切换序列。抽取旧数据、向新系统初次灌入、双轨观察、切换写入、切换读取和退役旧环境不是同一个时间点。RIPE 88 技术更新文字记录在更广泛的数据平台讨论中把抽取、建集群、开始接收新数据、切生产和日后退役分开叙述。它只能提供历史上的程序启示，不能被当作 2026 年 RIS 当前拓扑。

第四栏是验收。选择切换前后等价的 RRC 与时间段，检查五分钟 update 和八小时 dump；另行测量 RIS Live 新鲜度；按查询类型记录 RIPEstat 延迟百分位。注明容差、观察期和责任角色。重放或回填应有明确状态：无需、计划中、部分完成或完成，并绑定具体范围。

最后是一份已知伪影和排除项清单。公开内容可以是时间段、构建编号、哈希、计数和聚合指标，不需要主机名、凭证、内部地址或原始日志。

这种收据不会否定 RIPE NCC 已完成的数据迁移，恰恰会保护这个结论。它允许 Kafka 更换按自己的节奏完成，允许 HBase 替代方案在选定前仍是研究，允许处理监测继续收集证据，也允许 RIPEstat 单独说明消费者影响。每个状态都保持真实，整条链才不会被一个项目标签压扁。

来源