📚 课程目录第2章数据存储与版本管理

数据存储与版本管理：样本存储格式、版本控制与元数据管理

样本回溯这件事，说白了就是“存得好、找得到、回得去”。
我刚开始做算法工程化的时候，总觉得样本存下来就行了，结果项目一多、版本一乱，想复现一个三个月前的模型效果，光找数据就花了两天。
嗯，从那以后，我再也不敢轻视存储和版本管理了。

这一章，我们聚焦三个核心问题：用什么格式存、怎么管版本、元数据怎么设计。

2.1 样本存储格式：TFRecord vs LMDB

存储格式的选择，直接影响读写性能和训练效率。
我个人习惯把格式选择看作“IO 带宽与随机访问的权衡”。

2.1.1 TFRecord

TFRecord 是 TensorFlow 生态的标准序列化格式。
它将样本打包成二进制记录，顺序读取时吞吐量极高。

  核心特点：
  顺序读取友好，适合大吞吐训练
支持压缩（GZIP、ZLIB），节省存储
与 tf.data 无缝集成
不支持随机访问——想跳着读某条数据？得从头扫到尾

我在项目中遇到过一个问题：用 TFRecord 做样本回溯时，想快速定位某个 ID 的样本，结果发现必须全量扫描。
后来我们加了一层索引文件，才勉强解决。

# 写入 TFRecord 示例
import tensorflow as tf

def serialize_example(feature_dict):
    feature = {
        'image': tf.train.Feature(bytes_list=tf.train.BytesList(value=[feature_dict['image']])),
        'label': tf.train.Feature(int64_list=tf.train.Int64List(value=[feature_dict['label']])),
        'sample_id': tf.train.Feature(bytes_list=tf.train.BytesList(value=[feature_dict['sample_id'].encode()]))
    }
    return tf.train.Example(features=tf.train.Features(feature=feature)).SerializeToString()

with tf.io.TFRecordWriter('samples.tfrecord') as writer:
    for sample in samples:
        writer.write(serialize_example(sample))

避坑指南： 我曾经把 TFRecord 的压缩级别设到最高，结果训练时解压成了瓶颈。建议用 GZIP 压缩级别 3-5，平衡存储和速度。

2.1.2 LMDB

LMDB（Lightning Memory-Mapped Database）是另一种选择。
它本质是一个键值存储引擎，支持高效的随机访问。

  核心特点：
  基于内存映射，读写极快
支持随机访问——按 key 取数据，O(1) 级别
事务安全，支持并发读写
顺序读取吞吐略低于 TFRecord

你想想看，如果样本回溯需要频繁按 ID 查询，LMDB 天然适合。
我有个项目用 LMDB 存了 2000 万条样本，按 sample_id 查询延迟稳定在 1ms 以内。

# 写入 LMDB 示例
import lmdb
import pickle

env = lmdb.open('samples.lmdb', map_size=10*1024*1024*1024)  # 10GB
with env.begin(write=True) as txn:
    for sample in samples:
        key = sample['sample_id'].encode()
        value = pickle.dumps(sample)
        txn.put(key, value)

注意： LMDB 的 map_size 必须提前设置足够大，否则写入会报错。我吃过这个亏，后来统一按预估数据量的 1.5 倍设置。

2.1.3 格式对比

维度	TFRecord	LMDB
读取模式	顺序	随机 + 顺序
随机访问	不支持	支持（O(1)）
顺序吞吐	高	中
压缩支持	内置	需自行处理
生态集成	TensorFlow 原生	通用
适用场景	大规模训练流水线	样本回溯、按 ID 查询

我的建议是：训练流水线用 TFRecord，样本回溯系统用 LMDB。
两者可以共存——训练时从 TFRecord 读，回溯时从 LMDB 查。

2.2 版本控制策略

样本数据不是一成不变的。
标注修正、数据增强、采样策略调整……每次改动都可能影响模型效果。
没有版本控制，回溯就是空谈。

2.2.1 数据版本化方案

我见过三种主流方案：

基于 Git LFS：适合小规模数据，但大文件多了会爆炸
基于 DVC（Data Version Control）：Git 的扩展，只存元数据，数据存远程存储
基于快照 + 元数据表：每次变更生成快照，元数据表记录版本号、时间戳、变更说明

我个人倾向第三种，原因很简单——可控。
DVC 虽然好，但依赖 Git 的 commit 机制，回溯时得切分支，操作成本高。

  快照版本控制核心设计：
  每个版本对应一个快照目录，如 samples_v1/、samples_v2/
快照内包含完整数据文件 + 元数据文件
元数据文件记录：版本号、创建时间、父版本、变更说明、样本数量
保留最近 N 个版本，历史版本可归档到冷存储

# 版本元数据示例（JSON）
{
  "version": "v2",
  "created_at": "2025-03-15T10:30:00Z",
  "parent_version": "v1",
  "change_log": "修正 label 错误：将 cat_123 的标签从 'dog' 改为 'cat'",
  "sample_count": 1500000,
  "checksum": "sha256:a1b2c3d4..."
}

避坑指南： 我曾经只存增量变更，结果回溯时发现某个样本在 v1 存在、v2 被删了、v3 又加回来了，追溯逻辑极其复杂。后来改为全量快照，虽然存储成本高了，但回溯逻辑简单可靠。

2.2.2 版本回溯流程

回溯时，只需要两步：

配合元数据表，可以快速定位“模型 A 训练时用的是哪个版本”。
我习惯在模型训练日志里记录数据版本号，这样回溯时直接查日志就行。

2.3 元数据管理

元数据是样本的“身份证”。
没有元数据，你存下来的只是一堆二进制文件，根本不知道里面是什么。

2.3.1 元数据字段设计

我总结了一套最小必要字段：

字段	类型	说明
sample_id	string	全局唯一标识
source	string	数据来源（如采集批次、标注平台）
created_at	datetime	创建时间
label	any	标签值（支持多标签）
label_version	string	标签版本号，用于追溯标注变更
features	dict	特征字段，按需扩展
checksum	string	数据文件校验和，防篡改
tags	list[string]	自定义标签，用于过滤和分组

注意： 元数据不要和样本数据混在一起存。我见过有人把元数据写在文件名里，结果改个标签就得重命名文件，版本管理直接崩了。元数据单独存数据库或文件，通过 sample_id 关联。

2.3.2 元数据存储选型

小规模项目用 JSON 文件就够了。
大规模项目建议用 SQLite 或 PostgreSQL。

我个人习惯：单机用 SQLite，分布式用 PostgreSQL。
SQLite 零配置，一个文件搞定，适合实验阶段。
PostgreSQL 支持并发查询和复杂过滤，适合生产环境。

# 元数据查询示例（SQLite）
import sqlite3

conn = sqlite3.connect('metadata.db')
cursor = conn.cursor()

# 查询某个版本的所有样本
cursor.execute("""
    SELECT sample_id, label, created_at
    FROM samples
    WHERE label_version = 'v2'
    AND source = 'batch_202503'
""")

for row in cursor.fetchall():
    print(row)

2.4 整体架构图

下面这张图展示了数据存储、版本控制与元数据管理的整体关系：

2.5 小结

数据存储与版本管理，是样本回溯的基石。
格式选对了，读写效率翻倍；版本管好了，回溯才有意义；元数据设计合理了，查询才能快准狠。

我个人经验是：别想着一步到位。
先跑通最小闭环——选一种格式、建一个版本、记一套元数据。
等业务规模上来了，再逐步优化。