4 数据管理与研究工作流

5 数据管理与研究工作流

前两章我们了解了数据采集和数据预处理的基本概念。但在动手搭建环境、编写代码之前，还有一个关键问题需要回答：你打算如何管理你的数据？

很多研究生的数据管理方式是这样的：实验数据存在 U 盘里，分析脚本散落在桌面上，文件名叫 data_final_v3_真的最终版.xlsx，三个月后自己都看不懂当初做了什么。这不是个例——2016 年 Nature 的一项调查显示，超过 70% 的研究者无法复现其他科学家的实验，超过 50% 甚至无法复现自己的实验（Baker, 2016, Nature, 533: 452–454, DOI: 10.1038/533452a）。

数据管理不是”锦上添花”的额外工作，而是科学研究的基础设施。本章将介绍数据管理的核心原则和研究工作流的组织方法，为后续的环境搭建和实操章节打下基础。

5.1 可重复性危机：为什么数据管理如此重要

5.1.1 什么是可重复性？

可重复性（Reproducibility）是科学研究的基石，指的是：给定相同的数据和代码，其他研究者能够得到相同的结果。与之相关的概念还有可复现性（Replicability）——独立收集新数据，使用相同方法，能够得到一致的结论。

可重复性（Reproducibility）：相同数据 + 相同代码 → 相同结果
可复现性（Replicability）：新数据 + 相同方法 → 一致结论

5.1.2 可重复性危机的根源

2015 年，开放科学协作组织（Open Science Collaboration）在 Science 上发表了一项里程碑式的研究（Open Science Collaboration, 2015, Science, 349: aac4716, DOI: 10.1126/science.aac4716），尝试复现 100 项心理学研究，结果只有 36% 的研究获得了统计显著的复现结果。这一发现引发了跨学科的”可重复性危机”讨论。

在生态学领域，Archmiller 等人（2020）对 Ecology Letters 和 Journal of Applied Ecology 上的论文进行了可重复性评估（Archmiller et al., 2020, PLOS ONE, 15: e0200303, DOI: 10.1371/journal.pone.0200303），发现大量论文缺乏足够的数据和代码共享，导致结果难以复现。

可重复性失败的常见原因包括：

原因	具体表现
数据不可获取	原始数据未公开，或存储在已失效的链接中
代码缺失	分析过程未用代码记录，或代码未随论文发布
环境不可复现	软件版本、包版本未记录，换台电脑就跑不通
方法描述不充分	论文中的方法部分省略了关键细节
手动操作	在 Excel 中手动删除异常值、手动调整图表

可重复性不是可选项

在现代科学研究中，越来越多的期刊要求作者在投稿时提交数据和代码。例如，Nature 自 2016 年起要求所有论文的数据必须”可获取”（Data Availability Statement），PLOS ONE 要求数据存储在公共仓库中。不具备可重复性的研究，发表的门槛正在越来越高。

5.2 FAIR 原则：数据管理的国际标准

2016 年，Wilkinson 等人在 Scientific Data 上提出了 FAIR 原则（Wilkinson et al., 2016, Scientific Data, 3: 160018, DOI: 10.1038/sdata.2016.18），为科学数据管理提供了一套被广泛接受的指导框架。FAIR 是四个英文单词的首字母缩写：

5.2.1 Findable（可发现）

数据应该容易被人和机器找到。

为数据分配全局唯一的持久标识符（如 DOI）
用丰富的元数据描述数据内容
将元数据注册到可搜索的资源中

生态学实例：将物种调查数据上传到 GBIF（全球生物多样性信息网络），系统会自动分配 DOI，其他研究者可以通过物种名、地理位置等条件检索到你的数据。

5.2.2 Accessible（可访问）

数据应该能够通过标准化的协议获取。

元数据可通过标准化通信协议（如 HTTP）访问
协议是开放、免费的
即使数据本身不再可用，元数据仍应保持可访问

生态学实例：将数据存储在 Dryad 或 Zenodo 等公共数据仓库中，而不是个人网站或实验室服务器上。公共仓库提供长期存储保障和标准化的访问接口。

5.2.3 Interoperable（可互操作）

数据应该能够与其他数据集整合使用。

使用通用的、开放的数据格式（如 CSV、JSON）
使用领域公认的术语和本体（Ontology）
包含对其他数据的引用关系

生态学实例：记录物种名称时使用国际公认的分类系统（如 GBIF Backbone Taxonomy），而不是自创的缩写代码。这样你的数据才能与全球其他研究者的数据对接。

5.2.4 Reusable（可重用）

数据应该能够被未来的研究者重复使用。

附带详细的元数据描述（采集方法、质量控制、使用限制）
使用明确的数据使用许可协议（如 CC BY 4.0）
符合领域相关的社区标准

生态学实例：在数据集中附带一份 README 文件，说明每个变量的含义、单位、测量方法、缺失值编码规则，以及数据的使用许可。

FAIR 不等于 Open

FAIR 原则强调的是数据的”可管理性”，而不是要求所有数据都必须公开。涉及濒危物种精确位置、患者隐私等敏感数据，可以在元数据中说明访问限制条件，同时仍然满足 FAIR 原则。

5.3 数据管理计划

数据管理计划（Data Management Plan, DMP）是在研究开始之前制定的文档，描述你将如何收集、组织、存储和共享数据。越来越多的基金资助机构要求申请者在项目申请书中提交 DMP。

5.3.1 为什么需要 DMP？

避免事后补救：提前规划比事后整理高效得多
满足资助要求：国家自然科学基金、欧盟 Horizon Europe 等均要求提交 DMP
促进团队协作：统一数据格式和命名规范，减少沟通成本
保护数据安全：明确备份策略和访问权限

5.3.2 DMP 的核心内容

一份完整的 DMP 通常包含以下要素：

要素	需要回答的问题
数据描述	将产生哪些类型的数据？预计数据量多大？
数据格式	使用什么文件格式？是否为开放格式？
元数据标准	如何描述数据？使用哪种元数据标准？
数据存储	数据存储在哪里？如何备份？
数据共享	数据是否公开？何时公开？使用什么许可协议？
数据保存	项目结束后数据保存多久？存放在哪个仓库？
责任分工	谁负责数据管理？谁有权访问数据？
伦理与合规	是否涉及敏感数据？是否需要伦理审查？

5.3.3 生态学 DMP 示例

以下是一个完整的生态学研究数据管理计划（DMP）示例，以”马尾松混交林土壤孔隙与碳储量关系研究”为案例，逐步说明DMP各部分的撰写方法。

1. 项目基本信息

项目名称：马尾松–红椎混交林土壤孔隙结构与有机碳储量关系研究。资助来源：广西大学青年教师基础研究基金（2026年）。项目负责人：刘华清。执行时间：2026年6月—2027年5月。数据管理者：刘华清（负责数据的日常维护和备份）。

2. 数据描述

本研究将产生以下四类数据：

土壤物理性质数据——包括土壤容重（g/cm³）、总孔隙度（%）、毛管孔隙度（%）、非毛管孔隙度（%）、含水量（%）。每个样点测定3个重复，共20个样点×3个土层（0-10cm、10-20cm、20-40cm）= 180个样品。原始记录使用纸质表格，数字化后存入CSV文件。

土壤化学性质数据——包括有机碳含量（g/kg）、全氮（g/kg）、C/N比、pH值。每个样品测定2个技术重复，最终取平均值。预计约180条记录。

植被调查数据——包括树种组成、胸径（DBH, cm）、树高（m）、枝下高（m）、郁闭度。每木检尺法记录所有胸径≥5cm的树木，预计约500条记录。

空间数据——包括20个样点的GPS坐标（精度±2m）、样方分布图（CAD格式转换为GeoJSON）、DEM数据（30m分辨率，从SRTM获取）。

3. 数据格式与标准

所有表格数据使用UTF-8编码的CSV格式存储，避免使用Excel的.xlsx格式作为长期存储格式（Excel格式存在版本兼容性问题，且不便于Git追踪变更）。变量命名统一采用snake_case格式（如soil_bulk_density、species_dbh）。数值型变量保留3位有效数字，坐标保留6位小数（≈0.1m精度）。空间数据采用GeoJSON格式存储矢量数据，GeoTIFF格式存储栅格数据。

4. 元数据标准

使用EML（Ecological Metadata Language）标准描述数据集，确保数据的机器可读性。元数据文档包括：变量定义（变量名、数据类型、单位、数据来源）、数据采集方法（采样时间、采样人员、仪器型号）、质量控制程序（异常值判定标准、重复测量允差）、坐标系说明（WGS84坐标系，EPSG:4326）。

5. 存储与备份策略

原始数据存储在实验室NAS服务器（192.168.1.100/data）上，每日增量备份到外接硬盘（2TB WD Blue），每周同步到OneDrive云盘。Git仓库托管在GitHub私有仓库中，分析脚本自动同步。任何人修改数据前必须通过Pull Request审核，确保修改可追溯。

6. 数据共享与再使用政策

论文发表后，将数据上传至Dryad数据仓库，使用CC BY 4.0许可协议。代码同步公开在GitHub仓库中，采用MIT许可协议。本数据集允许在注明来源的前提下自由使用，包括教学、学术研究等非商业用途。

7. 数据保存期限

数据在Dryad上永久保存。GitHub仓库保持公开访问。纸质原始记录表扫描后存入实验室档案柜，保存期限不少于10年。

8. 伦理与安全考量

本研究不涉及人类受试者或受保护物种，数据中不包含个人隐私信息。样点精确坐标在公开数据中降采样至100m精度，防止研究成果被滥用于破坏活动。

生态学案例

某生态学实验室曾因服务器硬盘损坏丢失了5年的野外观测数据，导致多名研究生的论文被迫延期。这个教训让他们建立了”3-2-1备份原则”：数据至少3份副本，存储在2种不同介质上，其中1份异地保存。现在该实验室的所有项目都强制要求在申请时就提交DMP，数据管理员每季度检查一次备份完整性。数据安全不是事后补救，而是研究设计的一部分。

扩展记录: 2026-04-10 | 扩展者：Clawd | 目标字数：800+

DMP 工具推荐

DMPTool：美国加州数字图书馆开发的免费 DMP 编写工具，提供多种基金模板
DMPonline：英国数字管理中心开发的 DMP 工具
国家科技资源共享服务平台：国内科学数据管理相关资源

5.4 研究项目的文件组织

良好的文件组织是数据管理的第一步。一个结构清晰的项目文件夹，能让你（和你的合作者）在任何时候都能快速找到需要的文件。

5.4.1 推荐的项目结构

科研项目的文件组织需要在灵活性和规范性之间取得平衡。一个设计良好的项目结构应当具备以下特征：（1）目录层次清晰，任何人都能快速定位文件；（2）数据流向明确，从原始数据到最终结果的路径可追溯；（3）便于版本控制，避免将大文件或临时文件纳入 Git 管理；（4）支持协作，团队成员能够无障碍地理解和运行项目代码。

下面展示的项目结构参考了 Wilson et al. (2017) 提出的”科研计算良好实践”（Good Enough Practices in Scientific Computing, PLOS Computational Biology, DOI: 10.1371/journal.pcbi.1005510）以及 British Ecological Society 的数据管理指南（2018），已在多个生态学研究项目中验证其有效性。

my-ecology-project/
├── README.md                # 项目说明：目的、方法、运行指南
├── LICENSE                  # 数据和代码的使用许可
├── .gitignore               # Git 忽略规则
│
├── data/
│   ├── raw/                 # 原始数据（只读，绝不修改）
│   │   ├── tree_survey_2027.csv
│   │   ├── soil_samples_2027.csv
│   │   └── README.md        # 数据说明：来源、变量定义、单位
│   └── processed/           # 清洗后的数据
│       ├── tree_clean.csv
│       └── soil_clean.csv
│
├── scripts/                 # 分析脚本（按执行顺序编号）
│   ├── 01-data-cleaning.R
│   ├── 02-exploratory-analysis.R
│   ├── 03-statistical-models.R
│   └── 04-figures.R
│
├── output/                  # 脚本生成的输出（可重建）
│   ├── figures/
│   │   ├── fig1-species-richness.png
│   │   └── fig2-soil-carbon.png
│   └── tables/
│       └── table1-summary-stats.csv
│
├── docs/                    # 文档和报告
│   ├── manuscript.qmd
│   └── supplementary.qmd
│
└── renv.lock                # R 包版本锁定文件

目录功能说明：

data/raw/：存放未经任何处理的原始数据文件。这些文件应当被视为”只读档案”，任何清洗、筛选、转换操作都不应直接修改原始文件。建议在此目录下添加 README.md 文件，记录数据来源、采集时间、变量定义、测量单位等元数据信息。
data/processed/：存放经过清洗、标准化处理后的数据。这些文件是分析脚本的直接输入，应当具有一致的格式和命名规范。如果数据清洗过程复杂，建议在此目录下也添加说明文档，记录主要的处理步骤。
scripts/：存放所有数据分析脚本。脚本文件名应以数字前缀标记执行顺序（如 01-、02-），确保分析流程的可重复性。每个脚本应当专注于单一任务（如数据清洗、统计建模、图表生成），避免将所有代码堆积在一个文件中。
output/：存放脚本生成的所有输出文件，包括图表、表格、模型结果等。这些文件应当是”可重建的”，即删除后可以通过重新运行脚本完全恢复。因此，output/ 目录通常不纳入版本控制（在 .gitignore 中排除）。
docs/：存放项目文档、研究报告、论文手稿等。使用 Quarto 或 R Markdown 编写的文档可以直接引用 output/ 目录中的图表和表格，实现文档与分析代码的无缝衔接。
renv.lock：记录项目所依赖的 R 包及其版本号。使用 renv 包管理依赖关系，可以确保项目在不同计算机或不同时间点运行时，使用相同版本的 R 包，避免因包更新导致的结果不一致。

注意事项：

避免中文路径和文件名：虽然现代操作系统支持中文路径，但在跨平台协作或使用某些命令行工具时可能出现编码问题。建议使用英文命名，用下划线或连字符分隔单词（如 soil_carbon_data.csv）。
不要在项目根目录堆积文件：所有数据、脚本、输出文件都应归入相应的子目录，保持根目录简洁。根目录只应包含 README.md、LICENSE、.gitignore 等项目级配置文件。
定期清理临时文件：分析过程中产生的临时文件（如 .Rhistory、.RData、~$*.xlsx 等）应及时删除或添加到 .gitignore 中，避免污染项目目录。

5.4.2 文件组织的核心原则

原则一：原始数据只读

data/raw/ 目录中的文件一旦放入，就永远不要修改。所有的数据清洗和转换都通过脚本完成，结果保存到 data/processed/。这样做的好处是：

随时可以从原始数据重新开始
清洗过程完全可追溯
不会因为误操作丢失原始数据

原则二：脚本按顺序编号

用数字前缀标记脚本的执行顺序（01-、02-、03-……），让任何人都能按顺序运行脚本，从原始数据一步步得到最终结果。

原则三：输出可重建

output/ 目录中的所有文件（图表、表格、报告）都应该能通过运行脚本重新生成。如果你删除整个 output/ 文件夹，运行一遍脚本就能全部恢复。

原则四：有 README

项目根目录和 data/raw/ 目录都应该有 README 文件，说明项目目的、数据来源、变量定义、运行方法等关键信息。README 是项目的”使用说明书”。

5.4.3 文件命名规范

好的文件名应该是自描述的、机器友好的、排序友好的：

规则	好的命名	差的命名
使用小写字母和连字符	`soil-carbon-analysis.R`	`Soil Carbon Analysis.R`
包含日期时用 ISO 格式	`survey-2027-03-15.csv`	`survey-3月15日.csv`
用数字前缀控制排序	`01-clean.R`, `02-analyze.R`	`clean.R`, `analyze.R`
避免空格和特殊字符	`tree-height-data.csv`	`tree height data (final).csv`
名称反映内容	`species-richness-by-plot.png`	`figure1.png`

避免中文文件名

在编程环境中，中文文件名经常导致编码问题（尤其是 Windows 系统）。建议所有数据文件、脚本文件、项目文件夹都使用英文命名。

5.5 元数据：数据的”身份证”

元数据（Metadata）是”描述数据的数据”。如果数据是一本书的正文，元数据就是书的封面、目录和版权页。没有元数据的数据集，就像一堆没有标签的试管——三个月后连你自己都不知道里面装的是什么。

5.5.1 元数据应该记录什么？

对于生态学研究数据，元数据至少应包含以下信息：

数据集层面：

数据集名称和描述
创建者和联系方式
创建日期和更新日期
地理范围和时间范围
使用许可协议
引用方式

变量层面：

变量名称和描述
数据类型（数值、分类、日期）
单位
取值范围或允许值列表
缺失值编码（如 NA、-9999、空白）
测量方法或仪器

5.5.2 用 README 记录元数据

最简单的元数据记录方式是在 data/raw/ 目录下创建一个 README.md 文件：

# 数据说明

## tree_survey_2027.csv

亚热带常绿阔叶林样方调查数据，采集于广西弄岗国家级自然保护区。

- **采集时间**：2027年3月1日至3月15日
- **采集方法**：20m × 20m 样方，记录胸径 ≥ 5cm 的所有个体
- **坐标系**：WGS 84 (EPSG:4326)

| 变量名 | 描述 | 类型 | 单位 | 备注 |
|:---|:---|:---|:---|:---|
| plot_id | 样方编号 | 文本 | — | 格式：P001-P050 |
| species | 物种拉丁名 | 文本 | — | 依据《中国植物志》 |
| dbh | 胸径 | 数值 | cm | 1.3m 处测量 |
| height | 树高 | 数值 | m | 激光测高仪 |
| latitude | 纬度 | 数值 | 度 | WGS 84 |
| longitude | 经度 | 数值 | 度 | WGS 84 |
| date | 调查日期 | 日期 | — | ISO 8601 格式 |
| observer | 调查人 | 文本 | — | — |

- **缺失值编码**：NA
- **已知问题**：P023 样方因暴雨中断，仅完成部分调查

元数据标准

对于需要正式发布的数据集，建议使用领域标准的元数据格式：

EML（Ecological Metadata Language）：生态学领域最常用的元数据标准，被 LTER、DataONE 等平台采用
Dublin Core：通用的元数据标准，适用于各类数字资源
Darwin Core：生物多样性数据的元数据标准，被 GBIF 采用

5.6 数据存储与备份

5.6.1 3-2-1 备份原则

数据备份的黄金法则是 3-2-1 原则：

3 份副本（1 份原件 + 2 份备份）
2 种不同的存储介质（如硬盘 + 云端）
1 份异地备份（防止火灾、盗窃等物理灾难）

对于研究生来说，一个可行的备份方案是：

原件：实验室电脑硬盘
备份1：学校云盘（如坚果云、学校 OneDrive）
备份2：GitHub 私有仓库（代码和小型数据）

5.6.2 数据存储格式选择

格式	优点	缺点	推荐用途
CSV	通用、纯文本、任何软件可读	不支持多工作表、无格式信息	表格数据的首选长期存储格式
TSV	同 CSV，适合含逗号的数据	同 CSV	含逗号文本的表格数据
Excel (.xlsx)	支持多工作表、格式丰富	专有格式、易引入隐藏错误	数据录入阶段，不推荐长期存储
JSON	支持嵌套结构、Web 友好	不适合大型表格数据	API 数据、配置文件
GeoTIFF	地理空间栅格数据标准格式	文件较大	遥感影像、DEM
Shapefile	GIS 矢量数据通用格式	多文件组成、字段名限制	矢量空间数据

Excel 的隐藏陷阱

Excel 会”好心”地自动转换数据格式，这在生态学中造成过严重问题。例如：

基因名 MARCH1 被自动转换为日期 3月1日（Ziemann et al., 2016, Genome Biology, 17: 177, DOI: 10.1186/s13059-016-1044-7）
物种编号 1E3 被解释为科学计数法 1000
前导零被自动删除：007 变成 7

建议：用 Excel 录入数据后，尽快导出为 CSV 格式，后续分析全部基于 CSV 文件进行。

5.7 研究工作流总览

将前面讨论的所有要素串联起来，一个完整的数据驱动研究工作流如下：

1. 研究设计
   ├── 明确研究问题和假设
   ├── 设计采样方案
   └── 编写数据管理计划（DMP）
         ↓
2. 环境搭建                          → 详见 0104
   ├── 安装 R/RStudio/Python/Git
   ├── 创建项目文件夹结构
   └── 初始化 Git 仓库
         ↓
3. 数据采集                          → 详见第三单元
   ├── 野外调查 / 实验 / 下载公共数据
   ├── 记录元数据
   └── 原始数据存入 data/raw/（只读）
         ↓
4. 数据预处理                        → 详见第四单元
   ├── 数据检查与清洗
   ├── 特征工程
   ├── 质量评估
   └── 清洗后数据存入 data/processed/
         ↓
5. 探索性分析与可视化                → 详见第五单元
   ├── 描述性统计
   ├── 数据可视化
   └── 初步模式识别
         ↓
6. 统计建模与结果解读
   ├── 选择合适的统计方法
   ├── 模型拟合与诊断
   └── 结果可视化
         ↓
7. 报告与共享
   ├── 撰写可重复的分析报告（Quarto）
   ├── 数据上传至公共仓库
   └── 代码公开在 GitHub 上

这个工作流的核心思想是：每一步都用代码记录，每一步都可以重新运行，每一步都有据可查。

5.8 工具链概览

本课程将使用以下工具链来支撑上述工作流。这些工具将在后续章节中逐一介绍：

环节	工具	章节
编程与分析	R + RStudio	0104, 0105, 0106
版本控制	Git + GitHub	0104, 0107
数据采集（网络）	Python + requests	0208
文档与报告	Quarto	0104
数据可视化	ggplot2	0501
包管理与环境锁定	renv	0104

为什么选择这套工具链？

R：生态学领域最主流的统计分析语言，拥有丰富的生态学专用包（vegan、ape、lme4 等）
Git：学术界和工业界通用的版本控制标准
Quarto：R Markdown 的下一代替代品，支持 R、Python、Julia 多语言
CSV + 纯文本：开放格式，不依赖特定软件，50 年后依然可读

5.9 课后练习

阅读 FAIR 原则的原始论文摘要（Wilkinson et al., 2016），用自己的话解释 FAIR 四个字母分别代表什么。
为你当前的研究课题草拟一份简化版数据管理计划，至少包含：数据描述、文件格式、存储方案、共享计划四个部分。
检查你现有的项目文件夹结构，对照本章推荐的结构，列出需要改进的地方。
为你的一个数据文件编写 README 元数据文档，包含变量名、类型、单位和缺失值编码。
评估你当前的数据备份情况：是否满足 3-2-1 原则？如果不满足，制定改进方案。