3、数据管理基础：文件系统结构、数据命名规范、版本控制（Git）入门、数据备份策略

做高通量计算这几年，我踩过最大的坑，往往不是计算本身，而是数据管理。

你想想看，跑一个高通量任务，动辄生成几百上千个文件夹。每个文件夹里又有输入文件、输出文件、日志文件、中间文件……要是没有一套规矩，三天之后你自己都找不到哪个是哪个。我见过不止一个同事，为了找一个算错的中间结果，把整个硬盘翻了个底朝天。

所以这一章，咱们就把数据管理的基础打牢。说白了，就是四件事：怎么放文件、怎么起名字、怎么管版本、怎么防丢失。

3.1 文件系统结构：给数据安个家

我个人习惯，每个项目一开始，先搭好目录骨架。就像盖房子先画图纸，后面才不会乱。

一个典型的高通量计算项目，我建议这样组织：

project/
├── 00_docs/          # 项目文档、笔记、参考文献
├── 01_raw_data/      # 原始实验数据、下载的数据库
├── 02_scripts/       # 所有脚本，按功能分
│   ├── preprocess/   # 前处理
│   ├── run/          # 提交计算
│   └── postprocess/  # 后处理
├── 03_inputs/        # 计算输入文件
├── 04_outputs/       # 计算结果
│   ├── batch_001/
│   ├── batch_002/
│   └── ...
├── 05_analysis/      # 数据分析、可视化
├── 06_reports/       # 报告、论文、PPT
└── README.md         # 项目说明
我的小习惯：目录编号用两位数字（00, 01, 02...），这样在文件管理器里会自动按顺序排列。而且我习惯把文档放在最前面，因为很多时候，你最先需要看的不是数据，而是「这个项目是干嘛的」。

这里有个关键点：原始数据目录（01_raw_data）要设为只读。我在项目中遇到过不止一次，有人不小心把原始数据覆盖了，结果整个项目都得重来。所以，原始数据一旦放进去，就别再动了。所有处理都在后面的目录里做。

3.2 数据命名规范：名字起得好，找数据不愁

嗯，说到命名，这可是个大学问。我见过最离谱的命名是什么？「最终版」、「最终版2」、「打死不改版」……这种名字在科研计算里就是灾难。

我推荐一套命名规则，你直接拿去用：

元素 规则 示例
项目 缩写 + 序号 LiFePO4_001
材料 化学式 + 相 LiFePO4_olivine
计算类型 方法 + 精度 DFT_GGA_PBE
日期 YYYYMMDD 20250315
版本 v + 两位数字 v01

组合起来就是：

LiFePO4_001_olivine_DFT_GGA_PBE_20250315_v01.inp
避坑指南：我曾经因为文件名里用了空格和中文，导致一个批处理脚本跑了三天全报错。后来排查才发现，是文件名里的空格把脚本的循环给搞崩了。所以记住：文件名里只用字母、数字、下划线、连字符。别用空格，别用中文，别用特殊符号。

3.3 版本控制（Git）入门：给代码上保险

做高通量计算，脚本改来改去是家常便饭。今天加个参数，明天改个循环，后天又觉得原来的更好……如果没有版本控制，你只能靠「另存为」来救命。

Git 这东西，说白了就是个时光机。它能记录你每一次修改，还能让你随时回到过去。

我建议你至少掌握这几个命令：

# 初始化仓库
git init

# 查看状态（这个命令我一天能用几十次）
git status

# 添加文件到暂存区
git add filename.py

# 提交修改
git commit -m "修改了晶格参数扫描范围"

# 查看历史
git log --oneline

# 回到上一个版本
git checkout HEAD~1

我的工作流：

  1. 每天开始工作前，先 git pull（如果是团队项目）
  2. 每改完一个功能点，就 git add + git commit
  3. 提交信息要写清楚「改了啥，为什么改」
  4. 下班前 git push 到远程仓库

你可能会问：「我就一个人做项目，也要用 Git 吗？」我的回答是：越是一个人，越要用。因为没人帮你记你改过什么，只有 Git 能帮你。

小技巧：提交信息不要写「修改了一些东西」这种废话。我要求自己每次提交信息都要能回答两个问题：改了什么？为什么改？比如「将K点密度从3x3x3改为5x5x5，以提高能带计算精度」——这才是有用的提交信息。

3.4 数据备份策略：别等丢了才后悔

做计算的人，最怕听到的一句话是什么？「硬盘坏了」。

我有个朋友，博士做了三年的计算数据，全存在一块移动硬盘里。结果有一天硬盘摔了一下，数据全没了。三年啊，说没就没了。从那以后，我对备份这件事就特别较真。

我现在的备份策略，叫「3-2-1 法则」：

  • 3 份数据副本（1份原件 + 2份备份）
  • 2 种不同介质（比如本地硬盘 + 云存储）
  • 1 份异地备份（放在不同物理位置）

具体到我个人，我是这么做的：

数据类别 备份方式 频率
原始数据 本地 + 云盘 + 冷存储 每次新增后立即备份
脚本代码 Git 仓库（本地 + 远程） 每次 commit 后自动同步
中间结果 本地 + 云盘 每周一次
最终结果 本地 + 云盘 + 打印纸质 项目结题时
注意：云盘也不是万能的。我遇到过云盘同步出错的案例，文件同步到一半断了，结果两边都不完整。所以我的原则是：重要数据至少要有两份物理隔离的备份。比如一块硬盘放实验室，一块放家里。

最后分享一个自动化备份的小脚本，我用了好几年：

#!/bin/bash
# 自动备份脚本，每天凌晨3点执行

BACKUP_DIR="/mnt/backup/$(date +%Y%m%d)"
SOURCE_DIR="/home/user/projects"

# 创建备份目录
mkdir -p $BACKUP_DIR

# 使用 rsync 增量备份
rsync -av --delete $SOURCE_DIR $BACKUP_DIR

# 保留最近30天的备份
find /mnt/backup/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;

echo "备份完成：$(date)"

把这个脚本加到 crontab 里，每天自动跑一次。你想想看，就算硬盘突然挂了，最多也就丢一天的数据，是不是安心多了？

好了，数据管理的基础就这些。说白了就是：目录要规整、命名要规范、版本要控制、备份要到位。这四件事做好了，你的高通量计算之路就稳了一大半。

公众号：蓝海资料掘金营，微信 deep3321
← 上一章 📖 返回目录 下一章 →