生物样本元数据标准设计与信息检索 - 第3节
UUID：从概念到落地
标识一个样本，最怕什么？
怕重复。怕混淆。怕数据打通时发现两个样本ID撞车了。
你肯定见过这种事：同一批样本，A部门叫S20240101_001，B部门叫BJSH-240101-01，等数据合并的时候，一眼看去全是乱码。说白了，缺一个全局唯一的身份。
我这些年经手的项目，只要是跨平台、跨团队的样本元数据，底层ID几乎都统一走UUID。为什么？因为它不去重，不依赖中心服务器，离线也能生成唯一ID。
UUID 的组成模型
UUID 是 128 位的数字，通常以 32 个十六进制字符表示，按 8-4-4-4-12 的格式分组。这个结构不是瞎分的，每个字段都有语义。
xxxxxxxx-xxxx-Vxxx-xxxxxxxxxxxx这里的 V 标识版本号。比如 V4 是随机生成，V5 是基于名字的哈希。我建议你至少记住这两个，日常够用了。
版本与变体
UUID 定义了多个版本，但生物样本领域常用的就三个。我列一个对比表，看起来更清楚。
| 版本 | 生成方式 | 重复概率 | 典型场景 |
|---|---|---|---|
| v1 | 时间戳 + MAC 地址 | 极低（同机微秒级） | 实验室仪器内部记录 |
| v4 | 伪随机数 | 极低（122 位随机） | 样本入库、批量生成（最常用） |
| v5 | 命名空间 + 名称哈希（SHA-1） | 零（确定性） | 根据已有 ID 派生子样本标识 |
我个人习惯用 v4 做样本主标识。随机、快速、不用联网。但是要注意一个细节：伪随机数生成器的种子质量。如果开发板或者容器的熵不够，v4 可能产生可预测的 ID。我在一个嵌入式采集项目里遇到过这个问题，后来强制改用了 v5。
实践：用 Python 生成 UUID
直接上代码。我不喜欢讲太多理论，你跑一遍就知道了。
import uuid
# UUID v4：随机
sample_id = uuid.uuid4()
print(sample_id)
# 输出类似：a1b2c3d4-e5f6-4789-abcd-ef0123456789
# UUID v5：基于命名空间和样本源名称哈希
namespace = uuid.NAMESPACE_DNS
derived_id = uuid.uuid5(namespace, "blood_sample_2025-001")
print(derived_id)
# 输出类似：6ba7b810-9dad-5a1b-80b4-00c04fd430c8注意 v5 是确定性的。只要输入相同，输出永远一样。这在做样本溯源对齐时很有用。比如你的原始样本 ID 是 DB 里的自增主键，通过 v5 派生出全局唯一 ID，多端对接不会乱。
uuid.uuid4().hex 去掉短横线，变成 32 字符，降低存储压力。去掉短横线后仍是唯一的，只是可读性略差。
样本 ID 生成规则：让 ID 说话
UUID 给了你唯一性，但纯 UUID 没有业务含义。你想想看，一个样本来了，只看 ID 你能看出它是什么时间采集的、什么类型的吗？不能。所以我们还需要一套样本 ID 生成规则。
说白了，在唯一性之外，ID 应该承载少量元的上下文信息。比如：
- 采集年份和流水号
- 样本类型缩写（BLD：血液，TIS：组织）
- 中心或设备标识
- 批处理批次
我推荐一个四段式结构，我自己用了好几年，没出过碰撞问题。
[前缀]-[时间戳]-[递进号]-[校验位]例子：
BLD-20250318-00123-C字段拆解
| 字段 | 长度 | 说明 |
|---|---|---|
| 前缀 | 3 字符 | 样本类型缩写，如 BLD、TIS、URN |
| 时间戳 | 8 字符 | YYYYMMDD，按采集时间走 |
| 递进号 | 5 字符 | 每日分中心自增，从 00001 开始 |
| 校验位 | 1 字符 | 简单 Luhn 或者字母校验，防止手输错误 |
这个结构的优点是：一眼可读。你拿个 ID 就知道类型、日期、是当天第几个。而且加上前缀和校验位后，整体唯一性足够高：同一天同类型最多 99999 个样本，大型项目足够用了。
我的原则是：
- 入库主键、跨系统传输 → UUID（无条件唯一）
- 实验记录、临床汇报、人工阅读 → 规则 ID（可读性强）
实际项目中可以两个并存：主键用 UUID，显示/报表字段用规则 ID。
实践：避坑与工具链
讲到这里，我不妨把踩过的坑列出来。你避开了，就是赚到。
坑一：递进号重复
我曾经在一个项目里直接用自增主键当天重置。结果分布式部署下两个节点同时入库，当天递进号撞了。解决方案是引入节点ID + 递进号，或者用 Redis 的 INCR 命令保证原子递增。
# 用 Redis 保证当日递进号唯一
import redis
r = redis.Redis()
seq = r.incr("sample:seq:20250318")
sample_id = f"BLD-20250318-{seq:05d}"坑二：MAC 地址泄漏隐私
UUID v1 依赖 MAC 地址。如果你的样本数据对外共享，v1 会暴露实验室的内网 MAC，存在安全风险。我建议生产环境禁用 v1，除非你明确替换为随机节点标识。
坑三：UUID 太长影响索引
MySQL InnoDB 用 UUID 做主键，如果按 UUID 字符串排序插入，每次 INSERT 都可能触发页分裂。性能会恶化。我的做法是：UUID 用 BINARY(16) 存储，节省空间且支持 MySQL 内置 UUID 排序函数。
# 将 UUID 转为 16 字节二进制
import uuid
uid = uuid.uuid4()
binary_uid = uid.bytes # 16 字节，比字符串节省一半空间坑四：时间戳精度不够
同一台机器毫秒级并发生成 ID，如果用 YYYYMMDDHH24MISS 的高精度时间戳，还是可能碰撞。处理办法是时间戳后追加随机数或进程 PID。
import datetime, random
ts = datetime.datetime.now().strftime("%Y%m%d%H%M%S%f")
rand = random.randint(100, 999)
sample_id = f"BLD-{ts}-{rand}"坑五：校验位算法
我原来用简单取模作为校验位，发现在手抄场景下漏掉一位字母很难查出来。后来改用 Luhn mod N 算法，对字母数字混合字符串也有效，抄错一位能自动检测。
SVG：样本 ID 生成流程
下面这张图展示了从原始数据到最终唯一 ID 的完整流程。你可以在自己的项目文档里复用这个结构。
这个流程走完，你拿到的是一个可读、唯一、带校验的 ID。说白了一个原则：机器读数据用 UUID 做主键，人读数据用规则 ID 做标签。两者不冲突，而且都应该存放在元数据表里。
嗯，样本标识的部分就到这。记住一句话：ID 是样本的身份证，别让它成为数据的断头路。