分布式计算的十年：从资源解耦到最小必要分布

3.1 Hadoop 默认中心地位的消退#

2016 年的起点不是一片空白。Hadoop 时代已经形成一套完整的分布式计算体系：HDFS 以数据块和副本把数据放在集群节点，YARN 把容器映射到资源，MapReduce 通过任务尝试、数据交换（shuffle）和结果提交处理失败，Hive/HBase 等系统共享这套存储与控制基础，JVM 进程同时承担编程接口、对象表示、序列化和垃圾回收。它解决了廉价机器上的批量容错，却也把数据位置、执行生命周期、资源管理和文件提交绑定在一个需要长期运维的集群中。2016—2026 年所谓“大数据退潮”，首先是这套组合不再成为新系统的唯一默认，而非其中所有项目和机制同时消失。

JVM 也不是这次转折的单一原因。Spark 当前的 tuning guide(文档) 仍把 Java 对象额外开销、垃圾回收、序列化缓存和 Kryo 作为明确的工程边界；Tungsten、堆外二进制表示、RocksDB/ForSt 状态后端与容器资源感知的共同方向，是让 JVM 不再承担大规模数据对象的主要物理表示，而更多作为编程接口与控制层。旧运行时的机制被拆开后继续存在，只是不再必须共享一个进程模型和一个集群生命周期。

对象存储最能说明“替代”其实是责任迁移。Apache Hadoop 的 S3A Committers architecture(文档) 指出，HDFS 上具有原子性且成本近似恒定的重命名操作，在 S3 上会变成“复制后删除”，经典 FileOutputCommitter 因而失去原有的失败语义。2020 年 S3 强一致改善了对象可见性，却没有带回多对象重命名和表提交语义。后来的事务日志、清单与元数据目录不是凭空增加的云复杂性，而是在新的存储层上重新提供 Hadoop 文件提交曾经隐含的保证。

第一阶段由此拥有了明确的旧约束：不是“机器数量不够”，而是一个集群同时拥有数据、执行、资源和恢复，任何扩容、升级或故障都牵动整套系统。资源解耦首先拆开的正是这组共同生命周期。

3.2 执行从机器归属变成可替换对象#

2016 年前后的关键变化，是平台开始把“在哪台机器启动进程”改写为“提交一个由系统持续调谐的执行对象”。Google 的 Borg, Omega, and Kubernetes(2016) 总结了共享集群从中心式控制到共享状态和声明式对象的演进。Kubernetes 把期望状态写入 API，由调度器选择节点、控制器反复调谐、kubelet 在节点上落实。应用交出了机器身份，换得自动重建、滚动发布和资源池化；API 版本、重试、幂等和观察结果的时效性也随之进入执行语义。

这一转变改变了调度问题的对象，而不只是调度算法。Cambridge、MIT CSAIL 与 Google 的 Firmament(2016) 用增量式最小费用最大流算法证明，集中式全局优化并非天然不能扩展，但其效果依赖成本函数能够表达目标，输入状态在求解窗口内也必须足够稳定。Kubernetes 采用可扩展的过滤—评分—绑定框架，牺牲一部分统一求解能力来容纳不断增加的约束。Stack Overflow 的 Insufficient CPU Pending 问题(2016) 揭示了这种资源抽象容易引起的理解偏差：节点实时利用率很低，Pod 仍可能因资源请求值（requests）和滚动更新期间的可调度容量不足而处于 Pending 状态。帖子不能评价调度器优劣，却说明声明资源、实际利用率和部署策略已经成为三种不同状态。

短生命周期的另一个方向是把隔离本身服务化。AWS 的 Firecracker(2018) 用最小化的 KVM 微型虚拟机，将虚拟机隔离的开销降低到短任务可以承受的范围。UC Berkeley 的 Ray(2018) 则用任务与有状态执行体（actor）统一动态并行和有状态服务，让 CPU、GPU、自定义资源与对象引用进入同一个运行时。二者分别转移了隔离和动态任务管理责任；它们都没有解决状态恢复的全部问题。Ray 当前的 Object Fault Tolerance(文档) 明确区分对象值、所有者元数据与任务谱系，所有者失效不会让任意对象自动恢复。可替换执行单元必须配套明确的状态恢复机制。

3.3 持久化状态从节点资产变成共享服务#

计算单元能够快速出现和消失，前提是持久化数据不再随节点生命周期消失。Snowflake 团队的 The Snowflake Elastic Data Warehouse(2016) 让多个计算集群共享同一持久化数据层，并由服务层管理元数据、安全和资源协调；Google Cloud 团队的 BigQuery under the hood(2016) 则把 Colossus 存储、Borg 计算与 Jupiter 网络组合成按查询供给的服务。两者都解除了查询算力与存储容量的同比例绑定，但只有在高带宽存储网络、缓存和服务层元数据能够支撑远程访问时才能成立。

OLTP 把同一原则推进到了提交路径内部。AWS 的 Amazon Aurora(2017) 不再向每个传统副本复制完整数据页，而是把 redo 送入跨可用区的存储服务，由存储层承担复制、重放与修复。数据库计算可以更快替换，网络、慢存储节点和写放大却成为提交路径的一部分。Snowflake 解决的是多个分析计算集群共享数据，Aurora 解决的是事务日志与存储副本职责；“存算分离”从一开始就包含多种不同的状态迁移，不能仅以两个方框之间是否有网络来分类。

资源解耦仍受一项无法抽象掉的物理边界约束。Google 的 Network Requirements for Resource Disaggregation(2016) 指出，远程内存和存储必须占用应用的时延与带宽预算。共享存储扩大了资源池，却把局部性从默认的物理属性变成需要通过缓存、预取、放置和迁移主动维持的系统目标。后续十年的许多控制面，实质上都在弥补资源解耦造成的局部性损失。

3.4 第一阶段将状态语义留给了后续层#

持续计算最早暴露了这一问题。Apache Flink 的 Stateful Stream Processing(文档) 把热点键状态放在任务本地，通过检查点将状态和输入位置写入外部存储；失败后恢复快照并重放输入。MIT CSAIL 等机构的 Noria(2018) 则只物化查询图中需要的状态，缺失数据通过反向查询重建。前者依靠外部快照实现恢复，后者通过按需重建减小常驻内存；二者都把顺序、一致性与恢复条件显式化。

第一阶段留下的状态缺口在无服务器计算中集中暴露。UC Berkeley 的 Serverless Computing: One Step Forward, Two Steps Back(2019) 因而构成阶段转折，而非对无服务器计算的简单否定。平台接管机器和隔离以后，短生命周期、不可直接寻址的函数需要通过外部存储交换状态，数据密集型工作负载把本地调用变成远程 I/O。第一阶段建立了资源弹性，却把事务、可靠进度、状态寻址和多对象提交留给了下一阶段。

4.1 状态型执行需要明确状态归属或保存执行历史#

无服务器计算的后续发展没有恢复一个全局共享内存，而是把状态归属缩小到单个业务对象。Cloudflare 的 Durable Objects(2020) 为每个业务对象提供全局唯一 ID，将针对该 ID 的消息路由到同一执行位置，并让对象私有存储与执行共置。它以大量可分片对象换取局部串行化；单个热点对象仍受单一执行位置和网络传播时延约束。

Microsoft Research 的 Durable Functions(2021) 选择了另一种状态保存方式：工作流历史记录成为恢复时的最终依据，不可靠的执行过程通过“记录—重放”映射为可恢复的高层控制流。可靠进度由历史记录、确定性和幂等副作用共同保证，而不是依靠函数暂停后永久保留进程内存。Stack Overflow 的 Durable Functions replay 问题(2019) 显示，平台接管恢复并没有消除开发者的语义责任；重放、副作用和不断增长的历史记录成为新的运维与理解负担。

Durable Objects、Durable Functions、Flink 检查点与 Ray 任务谱系共同说明，弹性执行必须选择一种可持久化的进度表示。它可以是业务对象、工作流历史、算子快照或任务谱系；不同选择会改变写入排序、热点、重放和副作用边界。所谓“无服务器”移走的是机器管理，而非状态归属。

4.2 对象存储上的表是一个提交状态机#

对象存储适合按键保存大量持久化数据，却不直接提供关系表快照、模式演化、多文件原子提交或高效的文件发现。Databricks、CWI、UC Berkeley 与 Stanford 的 Delta Lake(2020) 将不可变的 Parquet 对象与事务日志组合：一次提交发布新的表版本，读取者先确定快照，再读取该快照包含的对象。Apache Iceberg 社区的 Iceberg Specification(持续演进) 用元数据、清单列表和清单文件描述表状态，并依赖元数据目录中的原子指针替换与乐观重试发布版本。两者的共同抽象是发布一组对象的逻辑成员关系，而不是原地修改一个大文件。

底层对象服务的增强缩小了表状态机需要补偿的范围。AWS 的 S3 Strong Read-After-Write Consistency(2020) 收回了过去由 EMRFS Consistent View 与 S3Guard 补偿的一部分可见性语义；后续 S3 conditional requests(文档) 又允许对单个键执行条件写入。单对象可见性和比较后交换仍无法定义一批数据文件、删除标记、模式与统计信息的原子版本。对象服务增强减少了一层辅助系统，表提交协议与元数据目录并未消失。

持续更新把这套状态机变成了需要长期运营的系统。Uber 工程团队的 Apache Hudi 工程回顾(2020) 比较写时复制与读时合并：前者在写入时重写列式文件，读取简单；后者先追加变化，再在读取时或由后台任务合并文件。UC Berkeley 与 Databricks 等机构的 Analyzing and Comparing Lakehouse Storage Systems(2023) 在相同 Spark/EMR 环境比较 Delta、Hudi 与 Iceberg，说明原子性、元数据组织与维护操作比“是否使用对象存储”更能解释差异。Stack Overflow 的 Iceberg compaction 问题(2022) 进一步暴露分区与阈值如何影响操作者的判断。文件合并、快照过期、孤儿文件清理和统计信息重写由此成为表控制面的一部分，而不是部署完成后的附属任务。

4.3 统一控制接口内部重新划分控制权#

声明式平台也在重新划分自己的控制状态。etcd 的 API guarantees(文档) 区分线性化 KV 操作、异步 Watch 与可能读到旧值的可串行化读取。Kubernetes 控制器通常通过 informer 缓存消费 Watch，因此“后端使用共识”并不能推出“每次调谐都观察到最新现实”。控制器必须用 resourceVersion、幂等操作、冲突重试和 observedGeneration 说明自己处理的是哪个版本。

共识成员本身也需要调度。etcd 的 learner design(2019) 让新副本先以无投票成员追平日志，再显式晋升，避免尚未同步的成员立即扩大多数派规模并拖慢心跳。Reddit 上 k3s 从 SQLite 切到 etcd 的讨论(2024) 记录了“多一个控制节点自然更高可用”的误解；副本数量、奇数成员、多数派协议、磁盘时延和备份才共同决定结果。

逻辑统一的控制接口仍需要在内部划分局部控制权。Meta 的 Delos(2019) 将控制面存储拆成排序、物化与重配置三个部分；Facebook 团队的 Twine(2020) 虽然提供地域级统一资源池，内部却按资源权益对调度器和分配器分片，让每个作业只属于一个调度分片，并把快速资源分配与耗时的全局再平衡分开。逻辑统一不等于只有一份不可分割的控制状态。系统要扩大规模，就需要按控制对象分片，允许已有任务在控制面故障时维持原状，并限制破坏性操作的作用范围。

服务网格内部也发生了同样的责任拆分。Istio 的 Architecture(文档) 把路由、证书和策略从应用移入 Istiod 与 Envoy；Ambient Mesh(2022) 又把原先部署在每个 Pod 中的 L4/mTLS 边车代理下沉到节点级 ztunnel，并把可选的 L7 能力移入 waypoint。应用减少了跨语言重复实现，平台则接管代理生命周期、配置传播和调试。Reddit 的 Service Mesh Wars(2021) 同时出现小团队遭遇的边车代理运维摩擦，以及大集群对统一 mTLS 的认可，说明责任集中是否划算取决于服务数量、合规要求和平台能力。

第二阶段的稳定结论是：被外置的状态语义会重新集中到规模更小的关键状态层。日志、元数据目录、检查点、租约和控制器缓存让数据面能够扩展，却也使体积很小的控制状态决定海量数据能否被发现、提交和恢复。第三阶段面对的已不只是“怎样扩展这些关键状态层”，还包括它们怎样与物理拓扑和特定工作负载的进度共同参与决策。

5.1 数据库内部继续拆分，元数据再次集中#

Microsoft Azure 与 Research 的 Socrates(2019) 已经把云数据库内部的“磁盘”拆成低延迟日志、页面服务器与缓存、长期存储三个部分。计算节点更容易替换，写入可用性却依赖日志落盘、复制、页面生成、下刷和回收的整体进度；如果低延迟日志层在下刷前被填满，更新就必须停止。Neon 团队的 Architecture decisions in Neon(2022) 由多个 Safekeeper 确认 WAL，再由页面服务器生成页面并写入对象存储，展示了 PostgreSQL 生态的另一种实现。两者共同证明，“计算无状态化”依赖一条必须持续推进的状态物化管道。

数据库内部的责任拆分继续深入到日志、页面、目录和缓存。Google Cloud 的 AlloyDB under the hood(2022) 把日志存储、日志处理、分片块存储和多级缓存分别服务化。ClickHouse 团队的 Stateless compute in ClickHouse Cloud(2025) 则记录了从无共享架构中的本地数据与 .sql 元数据文件，迁移到 SharedMergeTree、Keeper 和 Shared Catalog 的过程。它并不证明无共享架构已经过时，而是说明：当云服务优先考虑节点替换和独立伸缩时，本地数据归属与目录管理会成为运维约束。

开放湖仓也出现了控制信息重新集中的现象。LinkedIn 工程团队的 OpenHouse(2023) 指出，开放的存储、计算与目录组件可以各自运行，组织仍需要统一管理表的所有权、策略、快照过期、孤儿文件清理和灾备；DuckDB 团队的 DuckLake(2025) 提议用对象存储保存 Parquet，用 SQL 数据库事务管理元数据。二者是不同团队对元数据目录事务化的趋同信号，不足以宣布 Iceberg 或 Delta 已成历史。元数据体积很小，却持续承担版本、索引、所有权和维护进度，因此反复成为解耦架构中的关键集中依赖。

5.2 AI 训练与推理改变了五个分析维度的具体对象#

传统数据处理、AI 训练与 AI 推理都使用分区、检查点和背压，却对“进度”以及“哪些状态可以局部恢复”作出不同承诺。MapReduce、Spark 和 Flink 主要处理可辨识的记录与分区；同步训练的一次参数更新只有在一组进程全部汇合后才成立；自回归推理则已经向用户流式输出 token，同时为每个请求维护不断增长的 KV 缓存。GPU 只是物理条件，状态归属、通信图和用户可见进度才真正决定三者的分布边界。

下文把数据并行（data parallelism，DP）、张量并行（tensor parallelism，TP）、流水线并行（pipeline parallelism，PP）和专家并行（expert parallelism，EP）作为四种不同切分维度；作业完成时间（job completion time，JCT）衡量批作业从提交到结束的时间。推理中的预填充（prefill）一次处理输入上下文，解码（decode）随后逐个生成 token；首 token 延迟（time to first token，TTFT）衡量请求到首个输出的等待，每输出 token 时间（time per output token，TPOT）与 token 间时延（time between tokens，TBT）都描述首 token 之后的生成节奏，前者通常按请求平均，后者强调相邻 token 间隔。

UC Berkeley 的研究谱系把这次对象变化连成一条线。AMPLab 时代的 Spark 把规则 DAG、RDD 任务谱系和批流分析从 Hadoop 组合中抽出；Berkeley EECS 对 RISELab 与 Ray 的回顾(2017) 又把动态任务、actor 和对象引用交给运行时；后续 RISELab/Sky retreat(2022) 将无服务器计算、Alpa 等工作放在同一研究迁移中，vLLM 再把 KV 块变成调度对象。这里的连续性并不只是某所学校“产出了很多系统”，而是运行时必须理解的应用内部状态从数据分区逐步扩展到动态对象、模型图和内存页。

5.3 训练把模型状态、统计进度和通信图交给分层控制#

训练最初改变的是参数的存放和更新方式。Google 的 TensorFlow(2016) 允许参数服务器持有集中或分片变量，由工作进程拉取并更新，适合稀疏、异步或能够容忍旧梯度的负载。Uber 的 Horovod(2017) 则把常见的稠密同步数据并行改写为工作进程对称的环形全归约，并通过张量融合合并小消息。中心带宽瓶颈被移除，所有进程也由此进入同一个同步步骤；集合通信并没有普遍淘汰参数服务器，而是适用于另一类状态与同步方式，并形成不同的故障耦合关系。

单卡容量不足后，模型图本身成为切分对象。Google 的 GPipe(2019) 用微批填充按层切分的流水线，Microsoft Research 等机构的 PipeDream(2019) 以 1F1B 等调度降低流水线空泡并处理权重版本，Megatron-LM(2021) 又把 Transformer 的矩阵运算切分为高频张量集合通信。它们解决了“模型或激活无法放入一张卡”的问题，同时也让流水线空泡、激活传输、版本一致性和拓扑放置成为执行机制的一部分。

状态分片与稀疏模型把这条变化继续推进。Microsoft 的 ZeRO(2020) 和 PyTorch 的 FSDP(2022) 不再让每张卡常驻完整参数、梯度与优化器状态，而是在计算前临时聚合所需参数、计算后再执行归约分散；扩大可训练模型规模的代价是更频繁的数据迁移和更复杂的检查点布局。Google 的 GShard(2020) 则让 token 只访问少数专家，把传统按键交换数据的过程改成每层、每个步骤都由学习路由决定的同步全交换，专家热点会同时影响慢节点和训练信号。GSPMD(2021) 与 UC Berkeley 等机构的 Alpa(2022) 因而把数据并行、张量并行、流水线并行和设备网格的组合交给编译器与分层代价规划；这仍依赖性能分析和静态假设，并不保证动态生产集群中的全局最优。

并行计划、集群分配和平台准入属于三个控制层。Stanford 与 Microsoft 的 Gavel(2020) 用模型在不同设备上的有效吞吐描述异构性；Petuum/CMU 的 Pollux(2021) 把系统吞吐与统计效率合成为有效训练吞吐；CMU、Cornell 与 Petuum 的 Sia(2023) 再联合选择 GPU 类型、数量和作业配置。它们处理跨作业的有效进度，而 Alpa 处理单个作业内的并行；Kubernetes 的 Kueue(文档) 则负责租户、队列、配额、借用和准入，再把已准入的工作负载交给节点放置。把三者合成一个调度器，会混淆各自维护的状态和故障边界。

同步训练也改变了恢复的最小单位。Meta 的 Llama 3 训练报告(2024) 记录了 1.6 万张 GPU 长周期训练中单张 GPU、HBM、网络或慢进程对全组进度的影响，并将有效训练时间、检查点突发写入与故障诊断放在同一组运行证据中；Meta 的 RoCE 训练网络复盘(2024) 又把分散的进程放置、上行链路拥塞和集合通信性能连接起来。HKU 与 ByteDance 的 ByteCheckpoint(2025) 因而把检查点表示、异步 I/O、完整性屏障和跨 TP/PP/DP/EP 布局重分片做成独立系统。训练恢复不再等于重启 Pod 并读取一个文件，而是要重建通信组、确定一致的训练步骤，并让状态适配新的拓扑。

5.4 推理把 KV 状态和双重尾延迟交给路由与数据面#

在线生成首先改变了调度进度。首尔大学的 Orca(2022) 将调度粒度从完整请求缩小到一次生成迭代：已经完成的请求退出，新请求进入，只合并能够安全批处理的算子。它减少了长短请求混合成批时的等待，却没有解决长度不一的 KV 缓存造成的显存碎片。UC Berkeley 等机构的 vLLM(2023) 再用固定大小的块和块表管理 KV，使连续批处理的准入、抢占和前缀共享共同依赖显存页状态。PagedAttention 的内存管理与按迭代调度是两次不同的责任迁移，不能把连续批处理的整个谱系归给一个系统。

推理还包含两个相互独立的分布维度。张量并行或流水线并行把权重与算子切分到一组进程，解决模型承载或单请求延迟问题，代价是模型实例内部需要成组执行和集合通信；模型之外的请求与 KV 调度则决定并发、缓存命中和 SLO。增加一个 TP 进程，并不等于增加一个可以独立接收请求的副本；KV 所在的位置也不会由权重切分自动决定。

预填充与解码分离把两种状态路径连接起来。北京大学、UC San Diego 与 StepFun 的 DistServe(2024) 以同时满足 TTFT 和 TPOT 的有效吞吐为目标，为两个阶段选择并行度和放置位置；Microsoft 与 UW 的 Splitwise(2024) 则根据计算、内存带宽与功耗特征设计资源池。两者都需要跨资源池传输 KV，因此阶段隔离是否值得，取决于上下文长度、请求比例、两类 SLO 和互连网络；分块预填充在某些条件下可以在单一资源池内提高算术强度，分离并不是无条件的终局。

Moonshot AI 与清华的 Mooncake(2024) 将这条路线推进到作者方的生产系统：Conductor 同时考虑前缀复用、预填充与解码负载以及 TTFT/TBT，KV 通过 RDMA 在 GPU、CPU 内存和 SSD 之间迁移，热点复制和过载拒绝用于防止传输或解码队列失控。NVIDIA 的 Dynamo architecture(文档) 又把请求、控制、存储与事件平面，以及感知 KV 的路由、传输和拓扑域设计成明确接口。前者提供一线生产经验与匿名追踪数据，后者主要是厂商公开设计；它们共同证明远程 KV 已经成为控制对象，但不足以证明某一种分离架构适合所有服务。

训练以统计进度和同步步骤为核心，推理则以 TTFT、TPOT 与用户已经看到的 token 为核心。解码节点失效后，系统可以重新执行预填充、从远程 KV 恢复、迁移请求或返回失败；这些选择会产生不同数量的重复工作和不同的用户可见行为。传统任务重试的思想仍然存在，但流式输出和派生状态已经改变了局部恢复的条件。

5.5 网络和硬件从透明管道变成共享资源图#

硬件卸载首先改变了基础设施代码的执行位置。AWS 的 Nitro 架构(2017) 与 NVIDIA 的 BlueField DPU(2021) 将网络、存储、虚拟化或安全路径移入专用组件。主机 CPU 因而能把更多周期用于业务，平台则新增固件、设备程序、版本回滚和独立观测通道。卸载减少了主机上的共享特权代码，却没有减少控制层数量。

CXL 又试图改变内存边界。CXL Consortium 的 CXL 3.0(2022) 定义了内存池化、共享与交换网络能力；Virginia Tech、CMU、Microsoft Azure 等机构的 Pond(2023) 只在有限内存池、工作负载敏感度预测和显式迁移条件下评估成本—性能折衷；Université de Fribourg 与 ETH Zürich 的 CXL and the Return of Scale-Up Database Engines(2024) 仍属于研究议程。标准允许一种拓扑，并不意味着多主机透明共享内存已经具备可审计的生产恢复语义。

GPU 集合通信让物理拓扑直接决定一个训练步骤的同步时间。NVIDIA 的 NCCL(文档) 根据设备拓扑构造集合通信；Northeastern University、Alibaba Cloud 与中国科学院等机构的 HeteCCL(2026) 在 32-GPU 异构测试床上进一步根据带宽图合成通信计划。Meta 的 RoCE 复盘则提供生产反证：逻辑上拥有相同 GPU 数量的作业，各进程跨越不同上行链路后会产生不同的拥塞和慢节点行为。通信计划、任务放置和网络管理器必须交换约束，但现有证据仍不支持一个全局控制器能够同时求得三层问题的最优解。

第三阶段的转折在于，物理条件和应用进度开始共同约束资源抽象。资源仍可独立供给，但“一张 GPU”“一页内存”或“一次远程读取”不再是稳定的等价单位；性能、正确性与恢复取决于资源在拓扑中的位置、参与的同步组和状态迁移路径。

6.1 阿里云：一体化数据平台内部也经历分层与再协同#

MaxCompute 的早期体系与 Hadoop 大栈相似，但在同一运营者内部实现了更彻底的规模化。阿里云的 MaxCompute/Fuxi/Pangu 回顾(2019) 将 Fuxi 资源控制、Pangu 存储和 Nvwa 一致性放在同一多租户平台；后续团队对 Fuxi 2.0(2020) 的说明又将数据放置、资源调度、应用调度和节点内执行拆成多个层级。统一资源池没有消失，启动关键路径、全局优化和局部自治被分配给不同控制器。这与 Twine 的控制分片、Kubernetes 的声明式控制形成独立互证，而不是一个“中国版同类产品”标签。

存储责任也沿另一条实现路径独立迁移。Pangu 2.0 的 工程说明(2018) 以分布式元数据、ChunkServer、RDMA/SPDK 重写数据路径，同时保留 HDFS 重命名、删除等兼容语义；Alibaba Cloud 团队的 PolarFS(2018) 则为 PolarDB 提供 RDMA/NVMe 共享存储、ParallelRaft 和文件元数据串行化，让主节点与只读节点共享数据和重做日志。它与 Aurora、Socrates 都解除了数据库计算与存储容量的共同生命周期，具体选择的日志、页面、文件元数据和共识路径各不相同，论文测试环境也不能用来宣布跨产品优胜。

第二阶段的语义回流在实时平台中更加可见。阿里云的 Hologres 架构回顾(2021) 以 Pangu 共享存储、工作进程分片与本地缓存连接分析和在线查询服务；Realtime Compute for Apache Flink(2021) 则把 Flink 作业运行在 Kubernetes 中，把检查点和保存点放入 OSS，并连接 MaxCompute/Hologres。旧离线数仓不是被一个实时框架简单替换，而是执行、状态、SQL 服务与控制面被重新组合；厂商公布的“双十一”规模和性能不承担通用结论。

物理约束同样没有留在软件架构图之外。阿里云的 神龙架构回顾(2021) 将网络、存储和虚拟化责任移入专用硬件，与 AWS Nitro 形成两条独立工业路线。主机获得更稳定的业务资源，平台则接管设备固件、I/O 隔离、版本和恢复。阿里云这条纵向证据说明，资源解耦—语义回流—物理再协同并非由某一个开源生态或地区独占。

6.2 Cloudflare：全球边缘中的分层控制与局部自治#

Cloudflare 把第一阶段的执行粒度推到了共享进程内部。Workers 的 security model(2020) 以 V8 隔离实例快速装载和抢占租户代码，同时保留进程、隔离边界、监管进程与本地代理作为不同的信任和资源边界；V8 隔离实例本身并不是完整安全域。代码和配置必须随请求到达边缘，Quicksilver(2020) 因而为读多写少的配置选择中心顺序日志与边缘 LMDB 快照，通过序号补齐缺口，并允许中心失联时按旧状态继续服务。执行越轻量，全局配置分发越容易成为新的集中依赖。

第二阶段没有把这项集中依赖改造成通用的全球多主数据库，而是按状态类型选择不同的单一写入点。Cloudflare 对 Durable Objects 提交语义(2021) 的说明将同名对象固定到一个执行位置，由单线程处理，并使用对象私有存储保存状态；输入门和输出门分别约束事件并发，并确保数据持久化后再响应。全局可寻址不等于单个热点对象可以无限并行，也不等于支持跨对象事务。网络控制选择了另一种局部单元：Unimog(2020) 在全球任播之下为每个数据中心设置主备控制器与独立 Consul，把健康状态和负载编译成不可变的 XDP 转发表。逻辑上的全球网络仍由数据中心级控制单元共同组成。

2024—2026 年的数据库和对象存储进一步证明，“单机执行内核 + 分布式外层”并非 DuckDB 独有的做法。D1 的 global read replication(2025) 为每个数据库保留一个 Durable Object 和 SQLite 单写内核，在外层增加负责持久化 WAL 的跟随节点、异步只读副本与会话书签；写入顺序并没有变成全球多主。R2 Local Uploads(2026) 则先把数据写到接入位置附近，再以单个元数据事务发布对象、物理位置和待复制任务，随后异步迁移数据。一个把顺序控制留在 SQLite，一个把可见性控制留在元数据状态机；两者都只把持久化、读取或物理复制中确实需要跨节点的部分分布出去。R2 Local Uploads 与 D1 读副本的相应能力仍处于 Beta 阶段，不能当作行业终局。

Cloudflare 的事故把设计自述转成了因果证据。2019 年 WAF 事故表明，Quicksilver 的数秒传播会把配置错误扩大成全球共同故障；2023 control-plane outage(2023) 又显示旧数据面可以按本地状态继续服务，而变更、分析和灾备启动受隐藏依赖、惊群效应与恢复顺序约束；June 2025 service outage(2025) 则暴露 Workers KV 的中央数据源如何穿透“无核心边缘”叙事，并在恢复时触发缓存回填与请求积压。到 Code Orange/Snapstone(2026)，Cloudflare 把配置拆成发布单元，通过健康观察、分批发布、暂停、自动回滚以及失败时继续服务、保留旧值或关闭服务等策略控制发布。配置发布由简单的数据复制升级成带有作用范围与恢复语义的协议；这些修复仍是厂商自述，需要后续事故和跨组织证据检验其效果。

6.3 两条路径的共同结构：局部控制、有限作用域与异步复制#

这组比较也解释了为何“覆盖主流云厂商”不等于给每家公司分配相同篇幅。AWS、GCP、Azure、阿里云与 Cloudflare 的实现和公开证据强度不同，真正可以综合的结论是：它们都把统一服务建立在更小的状态归属单元、故障单元和物理单元之上。厂商数字、路线图和单次事故不能被拼接成市场份额或可靠性排名。

7.1 元数据集中依赖：数据分散并不保证故障分散#

元数据集中依赖的危险在于，体积很小的关键状态可以决定海量数据能否被发现。AWS 的 S3 US-EAST-1 disruption(2017) 始于容量移除命令输入错误。受影响的索引子系统保存对象元数据与位置，放置子系统为新对象分配存储；大规模重启后，GET、LIST、PUT 与 DELETE 分阶段恢复，依赖 S3 的 EC2、EBS 快照、Lambda 和健康面板也受到影响。修复包括限制工具一次可移除的容量、增加安全检查，并进一步划分隔离单元。共享对象存储减少了各服务重复持久化数据的需要，却让索引和放置成为跨服务依赖。

同类集中依赖还会隐藏在缓存和后台迁移中。Google Cloud 的 Cloud Storage incident 18003(2018) 显示，元数据预取与缓存失效会把负载集中到少数后端；BigQuery 2024 incident(2024) 则把 Colossus 迁移、SSD 缓存刷盘、缓存丢失、HDD 回退和人工容量操作连接成一条尾延迟链。对象接口保持一致，并不意味着元数据、缓冲区、缓存与后台迁移不再构成状态机。缓存也不是单纯的性能优化，它可能决定系统容量和恢复速度。

7.2 控制动作作用域：传播越快，隔离窗口越短#

配置传播越快，错误被隔离前的窗口就越短。Cloudflare 的 July 2 outage(2019) 中，一条灾难性回溯的 WAF 正则经全球配置系统在数秒内传播，使边缘代理 CPU 很快耗尽；内部构建和终止错误规则的路径又依赖同一网络。Fastly 的 June 8 outage(2021) 提供另一种组合：先前的软件部署引入潜伏缺陷，之后一个合法客户配置触发全球错误。两者共同说明配置是可执行的控制输入；只对代码进行金丝雀发布，不足以覆盖“代码版本 × 配置形态 × 发布范围”。

错误作用域不仅由数量决定，也由控制对象的类型系统决定。Atlassian 的 April 2022 outage(2022) 中，同一个删除 API 同时接受应用 ID（app ID）和站点 ID（site ID），批处理脚本带入错误类型，在 23 分钟内删除了 883 个站点；恢复需要重建 cloudId、权限、功能开关、第三方应用与跨服务引用。较小的数据损失并未带来较短的 RTO，因为恢复图比删除图复杂。破坏性 API 需要类型分离、范围确认、软删除、速率限制和可演练的恢复路径。

AWS Builders’ Library 的 Minimizing correlated failures(持续更新) 将这些机制概括为变更速率控制和故障域纪律：能够同时操作多台服务器或多个隔离单元的工具，本身就是相关故障的来源。自动化是否安全，取决于它能同时触及多少控制对象，而不是它是否通过了一个中心审计器。

7.3 恢复反馈：共识之后仍有完整服务恢复#

符合共识协议的主节点切换，仍可能形成应用无法承受的拓扑。GitHub 的 October 21 post-incident analysis(2018) 中，网络分区触发跨地域 MySQL 主库提升；连接恢复后，两侧都存在尚未复制的写入，应用又无法承受跨洲写延迟。团队选择暂停会写入元数据的后台任务，从远端对象存储恢复，并分阶段清理积压任务；事后则禁止跨地域自动提升主库。共识安全、应用可用与恢复时间是三个不同问题。

恢复入口只有跨越受损故障域才算独立。Meta 的 October 4 outage(2021) 中，一条管理骨干网的命令断开了数据中心间连接，DNS 因无法联系数据中心而撤销 BGP 宣告，内部工具和带外访问也不可用，工程师最终需要现场恢复。若监控、DNS、身份和回滚工具共享同一故障域，逻辑上的控制面与数据面分离无法提供恢复能力。

控制面故障时维持旧状态，可以避免受损的控制面主动破坏仍能工作的数据面。Google Cloud 的 Networking Incident #19009(2019) 与 Incident #19020(2019) 显示，控制组件重新调度后需要重建配置，拥塞又让监控与调试流量争抢受损的数据面；主节点选举抖动和错误配置下发还可能主动破坏数据面。较长时间保留旧配置、拒绝明显错误的新状态，有时比积极收敛更安全。

恢复动作本身也会形成正反馈。AWS 的 US-EAST-1 service event(2021) 显示，自动扩容增加内部连接，设备拥塞引发延迟与错误，客户端继续重试并形成请求积压。Marc Brooker 的 Timeouts, retries, and backoff with jitter(持续更新) 因而把超时、重试限额、退避和随机化视为系统级约束，而不是客户端实现细节。

独立工程复盘补齐了服务恢复的最后一段。Grafana Labs 的 bad etcd client setup outage(2020) 记录主节点切换后旧 TCP 连接没有及时恢复；Ahmet Alp Balkan 的 node-feature-discovery incident(2024) 记录控制器在缓存尚未同步时把“缺失”误判为“空状态”，进而删除节点标签；Trigger.dev 的 June 22 incident(2026) 则显示 etcd 恢复多数派后，组件同时重连并列举历史对象，又形成新一轮冲击。三者规模不同，却共同证明客户端连接、缓存新鲜度、重放与重连节奏决定服务何时真正恢复。

三类故障放大机制由此形成闭环：元数据集中依赖决定多少数据能够被发现，控制动作的作用范围决定错误传播多远，恢复反馈决定系统能否在修复时承受自身产生的负载。它们比“采用哪个共识协议”更接近工业系统可用性的完整边界。

8.1 单机复兴提高的是远程协调的举证责任#

可复现实验表明，单机分析的可行域大于许多架构讨论的默认假设。DuckDB 团队的 The Lost Decade of Small Data?(2025) 用公开二进制、脚本、查询和数据库文件展示：一台 2012 年、16 GB 内存的 MacBook 可以完成约 265 GB TPC-H SF1000 的 22 个查询。这个实验不覆盖高并发服务、实时流状态、跨地域事务或超过单机 I/O 时间预算的作业。

“数据量”本身还需要拆成不同的测量对象。前 BigQuery 创始工程师和产品负责人的 Big Data is Dead(2023) 报告，在其分析的重度使用客户子集中，存储中位数远低于 100 GB；对年消费超过 1,000 美元、排除只访问元数据的查询后得到的另一组内部样本，90% 的查询处理少于 100 MB 数据，并呈现明显的近期数据偏好。原始遥测数据、样本日期和完整方法没有公开，因此这些数字不能代表 BigQuery 全体用户或行业分布；它们的证据价值在于迫使容量讨论分别报告总保有量、热数据窗口、单查询扫描量、并发峰值、恢复副本和地域复制，而不能用其中一个数字替代其余五个。

其他系统给出了方向相同、工作负载不同的证据。SQLite 项目的 Appropriate Uses For SQLite(持续更新) 把边界放在网络拓扑、并发写入者与文件访问方式，而不是某个固定的数据量阈值；ClickHouse 团队的 Make Before Break(2025) 建议先利用单节点并行和纵向扩展，但这是供应商经验，不是通用成本定律；Fivetran 的 Production PostgreSQL(2024) 记录了单个 PostgreSQL 实例在其条件下继续承担大量事务，并通过基于 WAL 的变更数据捕获（CDC）把分析职责移往数据仓库。

数据库扩展至少包含纵向、读副本和写分片三种不同动作。OpenAI 的 Scaling PostgreSQL(2026) 记录主库继续纵向扩容和优化查询，近 50 个地域只读副本承担读流量，可分片的写密集工作负载迁往 Cosmos DB；副本增加后，WAL 扇出和级联复制又成为故障切换约束。社区对该文的 架构讨论(2026) 也主动指出其读多条件和写职责外移，防止把个案误读为单库可以承担任意规模。

8.2 分布粒度可以停在任务、分区或租户层#

单机与完整的分布式算子运行时之间存在宽阔的中间地带。MotherDuck 的 Separating Storage and Compute in DuckDB(2024) 为每个用户保留单节点 DuckDB 执行器，以共享存储支持数据分享与独立实例；系统整体是分布式的，单次查询则尽量避免算子级的跨节点同步。

粗粒度分布式外层的另一种实现，是按分区分发能够在单节点内完成的查询。DeepSeek-AI 的 smallpond(2025) 将分区交给不同 DuckDB 进程，由 Python 调度器分发任务，底层 3FS(2025) 提供共享分布式文件系统。3FS 仓库中的 GraySort 结果来自 25 个存储节点、50 个计算节点和高带宽 RDMA 网络，只能证明特定硬件与排序负载下的能力。DuckDBLab 的 Smallpond Deep Dive(2026) 适合解释“DuckDB 工作进程 + 3FS + 小型调度器”的职责划分；其中缺少正式出处的 Spark/TPCH 对比和商业咨询内容不能承担性能结论。

这一职责划分也出现在中国工业实践中。携程技术认证机构号在知乎发布的 Ray + DuckDB 归因系统(2026) 让 Ray 将归因 SQL 拆成可独立任务，在每个任务或 actor 内启动 DuckDB，先把 Ceph/S3 中的 Parquet 分片预载到本地磁盘，再进行节点内向量化执行；Ray/KubeRay/Kubernetes 管理并发、工作进程生命周期和弹性。其性能数字是单团队自报，不能证明 Ray + DuckDB 普遍优于 Spark 或 ClickHouse；但这项职责划分表明，分布式外层可以提供并发隔离、任务树并行和确定的完成时限，而节点内 SQL 执行不必因此跨越多台机器。

完整运行时仍有不可替代的适用范围。Meta 工程团队的 Apache Spark 60 TB production case(2016) 暴露了数据获取失败、驱动进程元数据、数据交换超时与磁盘溢写等问题，说明超大规模数据交换既需要多个节点，也必须承担协调成本；Uber 工程团队的 Distributed Shuffle as a Service(2022) 将临时交换数据从执行器本地 SSD 移入专用远程服务，又发现直接替换为 HDFS/NFS 会显著变慢。分布式数据交换的必要性来自交换规模、完成时限和故障语义，而不是“已经使用 Spark”这一事实。

8.3 分布式准入取决于跨越哪项硬边界#

“数据很多”“未来可能增长”“团队已有 Kubernetes/Spark”以及“云服务已经存在”都不能单独构成准入理由。更稳健的顺序是先量化 CPU、内存、I/O、日志、锁、并发与 SLO，拆开读/写、热/冷、OLTP/分析或租户职责，为最大合理单节点建立基线，再只为已经越界的部分引入最小分布式机制。

这只是第一道门。第二道门是生命周期内的净收益：抽象是否真的隔离了团队需要控制的变化，还是把浏览器、容器、JVM、操作系统、云 API 或远程服务的升级同时带入关键路径；系统能否在依赖停止维护、硬件接口改变和组织交接后继续演化；回退通道是否位于受损故障域之外。早期用通用运行时换取交付速度，后期在边界稳定后收回为本地进程、单机执行内核或专用控制器，并不必然是架构倒退，也可能是责任已经明确后的重新内聚。生命周期和团队能力不会凭空产生跨节点需求，却会决定一项确有必要的分布式机制能否被长期运营。

9.1 控制面将通过分层接口交换约束#

Twine 的控制分片、Kueue 的准入、kube-scheduler 的节点放置、Sia、Alpa 与 DistServe 提供的领域专用方案，以及 NCCL/HeteCCL 的通信图，已经分别证明各层需要维护不同状态。近期更可信的方向是定义可版本化的接口：上层给出配额、故障域与 SLO；训练运行时给出有效吞吐、并行计划与检查点重分片成本；推理运行时给出 TTFT/TPOT、KV 命中率以及预填充和解码队列；通信层返回拓扑域、可行方案或降级信号；发布控制还必须说明一次变更能够触及哪些控制单元，以及允许多大的回滚代价。验证这一方向需要生产追踪中的作业完成时间、资源碎片、公平性、两类尾延迟、网络故障回退与控制开销；固定拓扑上的峰值吞吐不足以证明端到端收益。

9.2 状态移动会成为调度的一等成本#

KV 缓存、检查点、页面缓存、文件合并、CXL 内存层级和跨地域复制都涉及状态迁移。未来的调度器需要区分状态是否是最终依据、能否重建、大小与新鲜度、迁移后多久可以回收旧副本，并比较“移动计算”“移动状态”和“等待本地资源”三种选择。训练侧还要处理检查点在新 TP/PP/DP/EP 布局上的重分片，推理侧则要判断迁移 KV、重新执行预填充或放弃请求分别会产生什么用户可见后果。一个可检验的基准应同时报告状态数据量、p99 延迟、恢复时间、网络拥塞和失败后的重复工作，而不是只给平均吞吐量。

9.3 隔离单元与本地自治会成为恢复的基本单位#

本地自治比“全球只有一个最终控制源”更接近可恢复系统的边界。AWS 的 Cell-based architecture(持续更新) 将隔离单元（cell）定义为完整、独立且不共享状态的服务实例，由轻量路由按天然分区键分流。Kubernetes SIG Multicluster 的 MCS API(文档) 也优先让消费者依赖本地物化的 ServiceImport，而没有建立全球调度器或跨广域网的单一多数派。未来的全球接口更可能建立在可独立运行的隔离单元或地域之上；所需证据是断网期间的本地服务能力、跨单元状态滞后、故障转移 RPO/RTO 和恢复演练，而不是“拥有一个全球 API”本身。

9.4 单机执行器会成为更多分布式系统的内核#

MotherDuck、smallpond 与携程案例以三种组织方式支持了同一趋势：先在一个节点内完成尽可能多的扫描、连接、聚合和磁盘溢写，再在租户、分区、任务、共享存储或少数重分区点引入协调。它不会替代持续流状态、跨地域事务或大规模集合通信，却会迫使完整的分布式运行时在端到端时间、恢复、并发和组织成本上证明净收益。未来基准应当在相同硬件预算和故障注入条件下，比较单节点、单机执行内核加粗粒度分布式外层、共享存储多实例与细粒度分布式运行时。

9.5 自治控制将先收敛为可审计的局部闭环#

自治控制目前最可信的形态，是动作空间受限、能够回退和审计的局部闭环。Google 的 Carbon-Aware Computing for Datacenters(2021) 在时间弹性工作负载上把碳强度预测转为容量曲线；Google DeepMind 的 Safety-first cooling control(2018) 则让学习控制只在本地与云端双重安全约束内行动。调用控制 API 只提供执行能力；自治安全还需要误动作率、策略约束范围（policy envelope）、人工接管、回滚时间和分布漂移等公开证据。