老周是个家庭摄影师，每年除夕都雷打不动给全家拍一张全家福。快门一响，所有人的站位、表情，连同屋里的陈设，就永远锁进了那张底片。多年以后孩子们各奔东西，只要翻出相册，那一年的团聚随时都能“重现”。做机器学习实验也离不开这份“咔嚓”的仪式感——数据永远在变，线上涌来新订单，用户改了资料，特征分布悄悄漂移。如果训练时不留下一张“全家福”，几个月后想解释模型当初为何表现优异，面对面目全非的数据，只能干瞪眼。数据快照（Data Snapshot）就是给数据拍全家福：在特定时间点，把数据集的完整状态原样保存，并配上编号、时间、说明等“相册索引”。于是每场实验都有了自己的时间胶囊，随时可查证、可回滚、可复现。本文就以老周家的相册为向导，带你认识全量快照、增量快照、存储优化、版本恢复，看看它们如何为实验锁定一个可信的过去。

岗位关联

掌握数据快照，意味着你的每一轮实验都有据可查、可复现、可回滚——这是 MLOps 数据版本控制的核心基石，也是面试官检验工程素养的高频考点。

目录
  1. 可视化演示
  2. 快照概念与价值
  3. 全量快照机制
  4. 增量快照策略
  5. 快照存储优化
  6. 版本切换恢复
  7. 实验复现保障
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示ML数据快照结构(Content+Metadata+Timestamp+Hash)、增量快照策略(Diff/CoW)、以及分层存储生命周期管理(Hot/Warm/Cold)。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.snapshot+'

快照概念与价值

老周拍下第一张全家福时，奶奶还住在老屋，小孙女刚满月。那张照片记录的不仅是人，更是那个瞬间整个家“完整的状态”：谁在场、什么表情、站在哪、屋里摆着什么。数据快照做的正是这件事——在某个时间点，把数据集里的每个样本、每条字段、每份划分，原封不动地“拍”下来。

机器学习场景里，数据从不安分。你上午下载的公开数据集，下午作者可能就更新了；你辛苦清洗的训练集，同事可能悄悄改了几行。于是最尴尬的问题出现了：模型训练时用的到底是哪一份数据？三个月后想复现结果，数据早已物是人非。快照就是为回答“当时用了什么数据”而生的机制。

数据快照（Data Snapshot）在定义好的时间点对数据集做完整状态保存，并登记快照时间、来源、内容哈希等元数据。每个快照拥有唯一版本号，成为实验的“时间锚点”。DVC（Data Version Control）等数据版本控制工具正是如此：把快照元数据交给 Git 管理，把数据本体放进对象存储，一个命令即可切换任意版本。

就像老周在相册首页写目录、标日期，快照的意义不在“存了”，而在“能追溯”。有了版本锚点，数据再怎么流动，你都能斩钉截铁地回答：这场实验，当时用的就是这份数据。

Vi={d∈D∣version(d)=i}\displaystyle V_i = \{ d \in \mathcal{D} \mid \mathrm{version}(d) = i \}
第 i 个版本快照，就是数据集中所有被标记为“属于版本 i”的数据项的集合。快照的价值在于“挑得出来、对得上号”。
  1. 数据全集 $\mathcal{D}$所有数据项组成的集合，对应相册里所有待入镜的家庭成员。
    D={d1,d2,…,dn}\mathcal{D} = \{ d_1, d_2, \ldots, d_n \}
  2. 版本标记函数 $\mathrm{version}(d)$给每条数据分配一个版本号，相当于照片上的日期章。
    version(d)∈{0,1,2,…}\mathrm{version}(d) \in \{ 0, 1, 2, \ldots \}
  3. 构造快照 $V_i$筛选出版本号为 $i$ 的全部数据项，得到该版本的完整集合。
    Vi={d∈D∣version(d)=i}V_i = \{ d \in \mathcal{D} \mid \mathrm{version}(d) = i \}

全量快照机制

老周拍全家福有个讲究：把全家老小叫齐，整整齐齐排成两排，一张底片装下所有人，缺一个都不算数。这种“把当前全家状态完整记录”的做法，就是全量快照（Full Snapshot）——拍到什么存什么。

工程里的全量快照，就是对当前数据集做一次完整拷贝：每一行数据、每一列特征，连同划分好的训练/验证/测试集，全部复制进快照存储。它的优点是无条件可靠——恢复时不需要任何额外信息，读出来就是当时的样子，像极了那张永不褪色的全家福。

全量快照通常伴随三件事：元数据登记（记录快照时间、来源、文件哈希，相当于相册目录页）；一致性保证（拷贝时若数据仍在写入，要先冻结写入再复制，或复制后校验，确保快照对应同一时间点）；存储规划（做 m 次全量快照，成本约等于 m 份完整数据）。

全量快照像每年一张的全家福：完整、可靠、一眼看懂，可代价是相册越来越厚。家里添丁、换了窗帘都要重拍，底片和整理成本都吃不消。于是老周开始琢磨省事的办法——只拍变化的部分。

Cfull=m×∣D∣\displaystyle C_{\text{full}} = m \times |D|
做 m 次全量快照，总存储成本约等于 m 份完整数据的大小。全家福拍得越多，相册越厚。
  1. 快照次数 $m$全量快照的执行次数，相当于给全家拍了多少张合影。
    m∈{1,2,3,…}m \in \{ 1, 2, 3, \ldots \}
  2. 数据规模 $|D|$数据集总体大小，由每个数据项的大小求和得到。
    ∣D∣=∑j=1nsize(dj)|D| = \sum_{j=1}^{n} \mathrm{size}(d_j)
  3. 总存储成本 $C_{\text{full}}$次数与规模相乘，得到全量快照的总开销，直观揭示“全量虽简单，重复保存代价高”。
    Cfull=m×∣D∣C_{\text{full}} = m \times |D|

增量快照策略

后来老周学聪明了：与其每年把全家叫齐重拍，不如只在添丁进口时，单独给新人补一张，再在目录里写一句“今年新增二宝、客厅换了新沙发”。想看全家福时，把最初的合影与新拍的部分拼起来。这就是增量快照（Incremental Snapshot）的朴素原型。

工程实践是：先保存一份基线快照（通常是首次全量快照），之后每次快照只计算并存储当前数据与基线的差异（diff）。差异通常分三类：新增的行、被修改的字段值、被删除记录的标记。增量快照大幅降低存储成本，尤其适合“每天只变一小部分”的训练数据。

多个增量快照首尾相连形成快照链（snapshot chain）。要还原某个版本，就从基线出发，按顺序应用链上所有增量。结构化数据常用行哈希比对生成差异；链太长时，系统会周期性“合并增量、重建基线”，避免恢复性能劣化。

有了这套“补拍”手艺，老周的相册不再疯长，想看哪一年，按目录把底片拼起来就行。增量快照把“省”做到了极致，但省下的每一张底片都依赖链条的完整——这又引出新的问题：怎么把相册管理得更省、更稳。

ΔDt=Dt∖Dt−1\displaystyle \Delta D_t = D_t \setminus D_{t-1}
Dt=D0∪⋃k=1tΔDk\displaystyle D_t = D_0 \cup \bigcup_{k=1}^{t} \Delta D_k
第 t 时刻的增量快照是当前数据相对上一版本的差异；合成第 t 版完整数据时，把初始基线与所有增量依次合并，如同把老合影和新照片拼成一张完整全家福。
  1. 差异集 $\Delta D_t$当前状态减去上一版本状态的结果，数学上写作差集，对应“只给新变化的部分拍照”。
    ΔDt=Dt∖Dt−1\Delta D_t = D_t \setminus D_{t-1}
  2. 基线快照 $D_0$快照链的起点，通常是首次创建的全量快照。
    D0=Snapshot(t=0)D_0 = \mathrm{Snapshot}(t = 0)
  3. 按链合成 $D_t$从基线出发并上全部增量，还原出第 t 版的完整数据。
    Dt=D0∪⋃k=1tΔDkD_t = D_0 \cup \bigcup_{k=1}^{t} \Delta D_k

快照存储优化

相册越攒越厚，老周开始收拾家当：重复的背景照筛掉，老照片扫描压缩，再按年代分层——常翻的放进客厅抽屉，陈年的收进阁楼纸箱。数据快照的存储优化，翻来覆去也是这三板斧。

第一板斧是内容去重（deduplication）：多个快照之间常有大量完全相同的数据块，按内容哈希（如 SHA-256）识别重复块，只存一份，其余用引用代替。第二板斧是压缩编码：结构化数据用列式压缩，文件用通用压缩算法，体积通常能再降一大截。第三板斧是分层存储：热数据放高速磁盘，冷数据迁到廉价对象存储甚至归档存储。

去重效果取决于快照间的真实重叠度。训练集几乎不变、只追加新样本时，相邻快照去重率极高。工程实践常把“增量快照 + 周期性全量重组 + 去重压缩”组合使用，在存储成本与恢复性能之间取平衡。目标不是把数据“弄没”，而是去掉冗余、加快访问。

老周整理完阁楼，找照片更快、纸箱更空。存储优化不是把回忆丢弃，而是把冗余剔除、让还原更从容。省下的空间和时间，最终都变成实验追溯时的底气。

rsave=1−∣Dunique∣∣Draw∣\displaystyle r_{\text{save}} = 1 - \frac{|D_{\text{unique}}|}{|D_{\text{raw}}|}
存储节省率 = 1 − 去重后唯一数据量 ÷ 原始数据总量。去重越有效，节省率越接近 1，好比相册里十几张重复的夕阳照最终只留一张。
  1. 原始数据总量 $|D_{\text{raw}}|$所有快照去重前的体积总和。
    ∣Draw∣=∑i∈snapshotssize(i)|D_{\text{raw}}| = \sum_{i \in \mathrm{snapshots}} \mathrm{size}(i)
  2. 去重后唯一数据量 $|D_{\text{unique}}|$按内容合并重复块后，实际保存的数据块总数。
    ∣Dunique∣=∣⋃i∈snapshotsblocks(i)∣|D_{\text{unique}}| = \left| \bigcup_{i \in \mathrm{snapshots}} \mathrm{blocks}(i) \right|
  3. 节省率 $r_{\text{save}}$两者代入公式，得出可量化的优化收益，指导去重与压缩的投入力度。
    rsave=1−∣Dunique∣∣Draw∣r_{\text{save}} = 1 - \frac{|D_{\text{unique}}|}{|D_{\text{raw}}|}

版本切换恢复

一个冬日午后，孙女说想看看十年前的除夕。老周不慌不忙走上阁楼，按相册目录找到卷宗，把底片冲洗出来——十年前的团聚，瞬间在餐桌上复活。数据快照的版本切换与恢复，就是这套“查目录、取底片、冲洗还原”的流程。

系统维护一张版本索引（version index），记录每个版本号对应的快照存储位置、创建时间、依赖基线等信息，相当于相册的目录页。恢复分两种情况：全量快照直接加载；增量快照则从基线开始依次应用增量。若只想“看一眼”某个旧版本，甚至可以把快照挂载为只读数据做探索式分析，这就是所谓的时间旅行（time travel）。

恢复必须搭配数据校验：比对文件哈希、统计行数、抽查特征分布。否则一份损坏的“底片”会被当成真相，让后续实验全部失真。工程上，DVC 的 dvc checkout、dvc repro 支持按版本快速切换，并把数据与代码、参数绑定在同一标签下，实现“一键回到实验起点”。

老周常说，目录做得细，找过去就快。版本索引就是快照系统的阁楼目录，把索引持久化、定期校验底片，才能在无数个实验之间自由穿越，随时回到任何一场实验的起点。

Trestore=Tbase+∑k=base+1targett(ΔDk)\displaystyle T_{\text{restore}} = T_{\text{base}} + \sum_{k=\mathrm{base}+1}^{\mathrm{target}} t(\Delta D_k)
恢复时间 ≈ 加载基线快照的时间 + 依次应用目标版本之前所有增量快照的时间。快照链越长，恢复越慢。
  1. 基线加载时间 $T_{\text{base}}$从存储读出基线快照并完成校验的开销。
    Tbase=load(base_snapshot)T_{\text{base}} = \mathrm{load}(\mathrm{base\_snapshot})
  2. 增量应用时间之和把基线之后、目标版本之前的每个增量依次合并的总耗时。
    ∑k=base+1targett(ΔDk)\sum_{k=\mathrm{base}+1}^{\mathrm{target}} t(\Delta D_k)
  3. 总恢复时间 $T_{\text{restore}}$两项相加，揭示了“快照链越长，恢复越慢”的工程规律。
    Trestore=Tbase+∑k=base+1targett(ΔDk)T_{\text{restore}} = T_{\text{base}} + \sum_{k=\mathrm{base}+1}^{\mathrm{target}} t(\Delta D_k)

实验复现保障

老周家有个传统：每年年夜饭都要“复刻”十年前的味道。靠的不是记忆，而是当年的完整记录——菜单、食材、掌勺人、灶台火候，一样不缺。数据快照之于机器学习实验，就是这份“完整记录”。

一次实验的成败由三样东西决定：代码版本、超参数、数据版本。数据快照负责锁死数据这一环。训练启动前先打快照并记下版本号，之后无论数据怎样漂移，实验报告上的“数据版本 v3”永远指向一个确定的状态。任何人拿到同一快照，都能把数据“放回”实验当天。

在 MLOps 实践中，快照不是孤立操作，而是流水线的正式一环：数据采集 → 快照 → 特征工程 → 训练 → 评估，每步都登记版本。模型上线后若线上表现回退，只需回到旧实验的完整状态做根因分析——是数据变了还是代码变了，一查便知。这正是“数据可复现性”的工程落地。

老周用“时间胶囊”让每顿年夜饭都有仪式感，数据快照则让每场实验都经得起追问。锁定数据状态，不只是保存文件，更是在团队里建立一种共识：任何结论，都必须能回到它诞生的那一刻，被重新验证一遍。

R(M,Dv)=R(M,Snapshot(v))\displaystyle R(\mathcal{M}, D_v) = R\big(\mathcal{M}, \mathrm{Snapshot}(v)\big)
固定模型与代码时，用版本 v 的数据快照复现实验，结果应与原始实验一致。这是“可复现”最简洁的数学表达。
  1. 实验函数 $R$给定模型与数据，输出一组评估指标的完整实验过程。
    R:(M,D)↦metricsR: (\mathcal{M}, D) \mapsto \mathrm{metrics}
  2. 版本数据 $D_v$实验中实际使用的第 $v$ 版数据集，即快照还原结果。
    Dv=Snapshot(v)D_v = \mathrm{Snapshot}(v)
  3. 复现等价性快照忠实且代码一致时，两次实验结果相等，这是可复现性的保证。
    R(M,Dv)=R(M,Snapshot(v))R(\mathcal{M}, D_v) = R\big(\mathcal{M}, \mathrm{Snapshot}(v)\big)

AI 应用场景

数据漂移后的模型回归分析

阶段：模型评估与监控

解决的问题：线上数据每天在变，模型指标下滑时，没人说得清是数据变了还是模型退化。传统做法靠人工翻日志，效率低且无法还原现场。数据快照让“数据问题”与“模型问题”一秒分离。

具体案例：某推荐团队发现 CTR 两周内下滑 2%。工程师调出训练当天的数据快照与当前线上数据做分布对比，发现用户年龄字段缺失率从 0% 升到 15%，是上游数据管道修复引入的 bug，与模型无关。快照让根因定位从数天缩短到数小时。

Kaggle 竞赛与论文结果复现

阶段：实验复现与成果交付

解决的问题：公开数据集会被更新或下线，论文复现常因“拿不到当时的数据”而失败。口头承诺“我用的就是那个数据集”无法让人信服，需要可验证的版本锚点。

具体案例：研究团队用 DVC 在训练前对数据集打快照，并在论文附录公布快照版本号与内容哈希。审稿人执行一条命令，就能把数据精确还原到作者训练时的状态，复现出论文中的指标。

模型迭代回归测试

阶段：CI/CD 与模型发布

解决的问题：每轮训练的数据不同，新旧模型对比就不公平——指标提升可能来自数据更新而非模型改进，导致误上线。

具体案例：某平台每次发版前，自动回滚到上一代模型训练时的数据快照，用同一份数据重新评估新旧模型。只有“同数据下新模型更优”才允许上线，把偶然性挡在发布门外。

Python 演示

python78 行
import copy  class DataStore:    """迷你数据存储：支持全量/增量快照与版本恢复"""     def __init__(self, data):        self.data = dict(data)        self.versions = {}        self.next_version = 0     def create_full_snapshot(self):        """全量快照：完整拷贝当前数据并登记元数据"""        v = self.next_version        self.versions[v] = {"type": "full", "data": copy.deepcopy(self.data)}        self.next_version += 1        return v     def _resolve_full(self, version):        """沿快照链向上解析出最近的完整基线"""        snap = self.versions[version]        if snap["type"] == "full":            return snap["data"]        return self._resolve_full(snap["base"])     def create_incremental_snapshot(self, base_version):        """增量快照：只记录相对基线变化的键值"""        base_data = self._resolve_full(base_version)        diff = {k: val for k, val in self.data.items()                if k not in base_data or base_data[k] != val}        v = self.next_version        self.versions[v] = {            "type": "incremental",            "base": base_version,            "diff": copy.deepcopy(diff),        }        self.next_version += 1        return v     def _compose(self, version):        """按链合成完整数据：基线 + 全部增量"""        snap = self.versions[version]        if snap["type"] == "incremental":            data = self._compose(snap["base"])            data.update(snap["diff"])            return data        return copy.deepcopy(snap["data"])     def restore(self, version):        """恢复指定版本到当前数据"""        self.data = self._compose(version)        return self.data     def storage_size(self, version):        """统计版本存储占用（近似：按条目数计）"""        snap = self.versions[version]        if snap["type"] == "incremental":            return len(snap["diff"])        return len(snap["data"])  if __name__ == "__main__":    store = DataStore({"id1": "ok", "id2": "ok", "id3": "ok"})    v0 = store.create_full_snapshot()     store.data["id4"] = "new"    store.data["id2"] = "fixed"    v1 = store.create_incremental_snapshot(v0)     store.data["id5"] = "new"    v2 = store.create_incremental_snapshot(v0)     print("全量 v0 占用:", store.storage_size(v0), "条")    print("增量 v1 占用:", store.storage_size(v1), "条")    print("增量 v2 占用:", store.storage_size(v2), "条")    print("版本总占用:", sum(store.storage_size(i) for i in (v0, v1, v2)), "条")    print("当前数据:", store.data)    print("恢复到 v2:", store.restore(v2))
目的：实现一个极简的数据快照系统，支持全量快照、增量快照、按链合成恢复，并对比两种快照的存储占用。
  1. store = DataStore({"id1": "ok", "id2": "ok", "id3": "ok"})初始化含三条样本的数据存储，相当于老周最初的“家庭底册”。
  2. v0 = store.create_full_snapshot()创建全量快照，把整份数据深拷贝进版本库，拍下第一张全家福。
  3. store.data["id4"] = "new"模拟数据变化：新增一条样本，像家里添了新成员。
  4. v1 = store.create_incremental_snapshot(v0)相对基线 v0 创建增量快照，只记录新增和修改。
  5. diff = {k: val for k, val in self.data.items() if k not in base_data or base_data[k] != val}核心差异计算：挑出新增的键和被改动的值。
  6. "base": base_version,在快照里记录父版本号，构成快照链的一环。
  7. data = self._compose(snap["base"])恢复时递归合成基线，再与增量合并。
  8. data.update(snap["diff"])把增量差异并入基线数据，还原完整版本。
  9. print("版本总占用:", sum(store.storage_size(i) for i in (v0, v1, v2)), "条")对比全量与增量成本：三个版本只多存了 4 条差异。
  10. print("恢复到 v2:", store.restore(v2))一键切回 v2 版本，数据状态精确还原。

常见误区

误区快照和备份都是把数据另存一份，我看着没啥区别。反正都是留个底，快照完全可以当备份用，备份也能当快照用。

正解两者目的不同：快照回答“当时数据长什么样”，服务于状态追溯、版本切换与实验复现；备份回答“数据丢了怎么找回来”，服务于灾难恢复。快照通常保留多个版本供回滚，备份往往保留最近一份用于还原。老周的全家福相册是快照，保险柜里的身份证复印件才是备份。

为何常见：两者在操作层面都是“复制一份数据”，形式太像了，初学者容易只看到操作，忽略快照侧重版本追溯、备份侧重应急恢复的本质差异。

误区增量快照又小又省空间，这个优点太香了。那我每次改动都打一个增量快照，打得越多肯定越划算，反正又不占地方。

正解增量快照确实省空间，但每多一个增量，恢复时就要多应用一环，快照链过长会让恢复越来越慢，任何一环损坏还会导致整条链失效。工程上需要定期“合并增量、重建基线”。只补拍新成员而不重拍全家福，十年后想还原某一年，就得拼几十张碎片。

为何常见：增量省空间是立竿见影的收益，而链变长导致恢复变慢、链条损坏这些代价是滞后的，人们天然容易低估滞后成本。

误区我已经给数据打了快照，实验肯定能 100% 复现。到时候谁质疑，我把快照甩给他就行。

正解数据快照只锁定了数据的维度。代码版本、超参数、随机种子、依赖环境都会影响结果，必须与数据快照一起登记才能完整复现。老周的相册里只有全家福没有菜谱，就复刻不出当年的年夜饭。快照是复现的必要条件，不是充分条件。

为何常见：把“复现”的问题简化为“数据”的问题，忽略了一次实验是多因素共同作用的结果，单点思维最容易犯这个错。

误区快照元数据当然要越全越好，最好把所有人的操作日志、机器信息、中间输出全都记下来，这样查起来才放心。

正解元数据是快照的检索索引，记录时间、版本号、来源、内容哈希、基线依赖就足以定位与校验。堆砌无关信息只会让索引臃肿、维护成本上升，还可能掩盖关键字段。老周的相册目录只需写“年份 + 卷宗号 + 备注”，写满流水账反而找不到照片。

为何常见：正常思维里记录越多越安全，但元数据的职责是快速定位快照，不是记录全过程，职责混淆导致了误区。

面试题

Q1. 数据快照最核心的作用是什么？

单选题 · easy

  • A.锁定数据集在特定时间点的状态← 正确答案
  • B.删除已过期的无用数据文件
  • C.加速模型训练收敛的速度
  • D.自动修复数据中的异常值

答案：A。快照的本质是锁定特定时间点的数据状态，以便日后追溯与复现。删除数据、加速训练、修复异常都是其他工具的职责，与快照无关。就像全家福的价值在于“锁住瞬间”，而不是替家人整理家务。

Q2. 关于全量快照，下列说法正确的是？

单选题 · easy

  • A.每次完整复制当前全部数据← 正确答案
  • B.只保存相对上次的差异
  • C.比增量快照更节省存储
  • D.不需要记录任何元数据

答案：A。全量快照每次完整复制当前所有数据；“只保存差异”是增量快照的特性，“更省空间”“不记元数据”也都是错误说法。一张全家福拍齐所有人，才是全量快照的模样。

Q3. 增量快照在存储时主要记录什么？

单选题 · mid

  • A.数据集的完整原始拷贝
  • B.相对基线的差异内容← 正确答案
  • C.模型训练的全部日志
  • D.所有历史版本的数据

答案：B。增量快照只记录相对基线的差异，包括新增、修改、删除三类变化；完整拷贝属于全量快照，模型日志与历史数据都不属于快照内容。好比只给新添的家人补拍一张，而不是重拍全家。

Q4. 快照链过长的主要风险是什么？

单选题 · mid

  • A.链上数据全部自动删除
  • B.存储空间反而迅速增大
  • C.恢复速度变慢且易损坏← 正确答案
  • D.快照无法被版本索引

答案：C。链越长，恢复时需应用的增量越多，耗时线性增长，且任一环节损坏会导致整条链不可用。存储空间不会因链长而暴涨，这正是增量的优点；版本索引通常总能记录链上各版本。链条像接龙，越长越容易断。

Q5. 恢复一个增量快照版本的完整流程是？

单选题 · easy

  • A.直接读取该版本快照文件
  • B.从基线依次应用增量最后再校验← 正确答案
  • C.重新下载整个公开数据集
  • D.忽略元数据直接覆盖当前数据

答案：B。增量快照没有存完整数据，必须先加载基线快照，依次应用目标版本前的全部增量，最后做数据校验。直接读增量文件只能得到差异；忽略元数据会丢失链条关系。这正是“老合影 + 零散补拍照片 = 完整全家福”的还原过程。

Q6. 下列哪项最能体现数据快照与备份的本质区别？

单选题 · hard

  • A.快照用于状态追溯备份用于灾难恢复← 正确答案
  • B.快照只用于训练数据备份只用于测试
  • C.快照不占存储空间备份占用空间较大
  • D.快照只能创建一次备份可多次执行

答案：A。快照服务于状态追溯与版本切换，回答“当时数据长什么样”；备份服务于灾难恢复，回答“数据丢了怎么找回来”。训练/测试之分、空间大小、次数多少都不是本质区别。全家福是快照，保险柜里的复印件才是备份。

Q7. 某些系统周期性执行“合并增量、重建基线”，主要目的是什么？

单选题 · hard

  • A.让快照数据完全无法恢复
  • B.缩短快照链提升恢复性能← 正确答案
  • C.删除所有历史版本记录
  • D.把所有数据压缩成一份文件

答案：B。合并增量重建基线可以缩短快照链、降低恢复延迟，同时保持完整可恢复状态。它不会删除历史版本，也不是把所有数据压成一份文件，更不会破坏可恢复性。相当于每隔几年重新拍一张全家福，取代越来越长的补拍拼贴。

Q8. 快照存储优化的常用手段包括哪些？

多选题 · mid

  • A.按内容哈希识别重复数据块← 正确答案
  • B.对快照数据做压缩编码← 正确答案
  • C.冷热数据分层存放管理← 正确答案
  • D.每次快照都完整重写一遍

答案：ABC。内容去重（按哈希识别重复块）、压缩编码、分层存储是三大常用手段；每次完整重写会放大存储成本，与优化目标背道而驰，所以 D 不正确。

Q9. 在 MLOps 中要保证实验可复现，除了数据快照还应锁定什么？

多选题 · mid

  • A.模型代码与依赖环境← 正确答案
  • B.超参数与随机种子← 正确答案
  • C.训练数据与代码版本← 正确答案
  • D.无关紧要的临时文件

答案：ABC。完整复现需要数据、代码、参数、环境四者齐备。仅锁数据快照，代码与参数不同，结果仍会漂移；临时文件与结果无关，无需锁定。就像复刻年夜饭，光有照片没有菜谱和食材清单是不够的。

Q10. 下列哪些场景更适合创建全量快照？

多选题 · hard

  • A.数据集规模较小更新频繁← 正确答案
  • B.首次建立实验数据版本基线← 正确答案
  • C.快照链过长需要合并重组← 正确答案
  • D.每次实验前无条件增量快照

答案：ABC。数据规模小、首次建基线、链过长需重组时，全量快照能夯实基础、简化后续恢复；日常频繁的小变化才适合增量快照，D 属于滥用增量。建立家庭相册的第一步，必然是一张完整的全家福。