信息速览

数据集名称HuBMAP — 人体生物分子图谱计划 AI-Ready Wikipedia

数据类型5,032 个数据集（2025-10）,310 位捐献者,22 种数据类型,27 个器官大类,CC BY 4.0 开放许可,AnnData/OME-TIFF

规模310 位捐献者（健康成人组织）

接入方式NIH HuBMAP Consortium url: https://portal.hubmapconsortium.org/

AI 就绪度

HuBMAP — 人体生物分子图谱计划 AI-Ready Wikipedia

INFOBOX


数据集名称	HuBMAP Data Portal Datasets
英文全称	Human BioMolecular Atlas Program
别名/简称	HuBMAP、人体生物分子图谱计划、人体组织图谱；关联产物 Human Reference Atlas（HRA）
疾病分类	健康成人多器官组织（参照基线，不含疾病队列）；在千方分类中归入肿瘤学与病理组织类别，用于癌旁组织与肿瘤微环境的健康对照
SNOMED CT	119376003 Tissue specimen（组织标本）/ 260413007 Normal（定性概念）；器官级示例：64033007 Kidney structure、80248007 Heart structure、39607008 Lung structure（详见 §2.2）
数据模态	组织成像（H&E、免疫荧光、CODEX、MIBI、成像质谱）+ 空间转录组（Visium、Slide-seq、seqFISH、Xenium）+ 单细胞/单核测序（snRNA-seq、ATAC-seq、SNARE-seq2、10X Multiome）
AI 任务类型	细胞类型注释与注释迁移、细胞核与细胞分割、功能组织单元（FTU）分割、空间邻域分析、跨模态整合、组织空间注册（RUI/CCF）、健康基线构建
样本总数	5,032 个数据集 / 310 位捐献者 / 27 个器官大类 / 22 种数据类型（截至 2025-10）
数据大小	无单一总量口径；单数据集从 MB 级（元数据、降维矩阵）到 TB 级（3D 与多重成像原始数据）；建议按数据集增量下载
数据格式	AnnData (.h5ad)、OME-TIFF、zarr、CSV/TSV 元数据、厂商原始格式（.mcd、影像序列等）
许可证	CC BY 4.0（全部已发布数据；API 与 CCF 3D 参考对象库同为 CC BY 4.0，软件多为 MIT/GPL v3）
访问级别	开放下载（浏览与下载无需注册）；极小部分受控数据经 NIH 数据访问委员会与 dbGaP 审批
DUO 标签	开放数据为主；受控子集适用 HMB、IRB、PUB
语言	英文
首发日期	2020 年（首次公开数据发布：7 种器官、300+ 数据集）
最后更新	持续滚动发布（截至 2025-10 口径：5,032 个数据集）
发布机构	NIH HuBMAP 联盟（NIH Common Fund 资助；400+ 成员、60+ 机构，横跨美国与欧洲）
官方主页	https://portal.hubmapconsortium.org/
下载地址	https://portal.hubmapconsortium.org/（Globus 批量传输 + 浏览器内云工作区）
DOI	奠基论文 10.1038/s41586-019-1629-x；已发布数据集逐个分配 DOI
引用次数	官方统一要求引用 Nature 2019 奠基论文（DOI: 10.1038/s41586-019-1629-x）；联盟成果分散于数百篇论文，未设单一引用快照
AI 就绪度评分	⭐⭐⭐⭐（4/5）— FAIR 基建与 API/可视化顶配、HRA 坐标对齐独家；扣分项：无官方 ML 划分、器官×测定覆盖不均、大文件工程门槛高
页面状态	published

§0 E-E-A-T 信任声明与免责声明

医学审核者：千方病案医学编辑部交叉审核：§2 医学背景（组织学与空间组学术语、器官系统与功能组织单元定义、SNOMED CT 概念引用）、§7 偏倚分析。

数据工程审核者：千方病案医学编辑部交叉审核：§4 DAIMS 数据字典（实体层级与标识符体系、AnnData/OME-TIFF 结构）、§5 数据划分策略、§6 预处理 Pipeline 和坑点。

审核日期：2026-09-05

审核方式：交叉审核

利益冲突声明：千方病案医数集与 NIH、HuBMAP 联盟及其成员机构无任何商业利益关联。本页面不销售 HuBMAP 数据或服务，仅提供 AI 就绪指南与学术信息服务。编辑者未接受 NIH 或 HuBMAP 联盟任何形式的资助。

医疗免责声明：本页面提供的医学信息仅供研究和教育目的，不构成医疗建议、诊断或治疗方案。数据集的医学描述基于公开发表的文献，未经逐一临床验证。任何基于该数据集训练的 AI 模型在应用于临床决策前，必须经过独立的临床验证和监管审批。

技术免责声明：本页面的代码示例、预处理建议和基准性能数据基于公开资料整理，不保证在特定环境下的准确性和适用性。使用者应自行验证代码安全性和数据预处理流程的正确性。千方病案医数集不对因使用本页面信息而导致的任何直接或间接损失承担责任。

数据使用合规：使用本页面描述的数据集前，请务必阅读并遵守数据集原始许可协议。HuBMAP 已发布数据采用 CC BY 4.0 许可（署名即用），但使用者须遵守联盟数据使用协议（DUA，2020-02-03 版）——不得尝试识别或联系捐献者及其家属；受控数据需经 NIH 数据访问委员会审批并经 dbGaP 分发。具体使用限制以数据集官方协议为准。

§1 数据集概览

§1.0 30 秒速览

HuBMAP（Human BioMolecular Atlas Program，人体生物分子图谱计划）是美国 NIH Common Fund 于 2018 年启动、为期 8 年资助的大型联盟项目，目标是在单细胞分辨率下绘制健康成人身体的开放式三维分子图谱。截至 2025-10，其官方数据门户（portal.hubmapconsortium.org）托管 5,032 个数据集，覆盖 22 种数据类型、27 个器官大类、310 位捐献者，横跨单核测序、空间转录组、多重蛋白质成像与代谢成像四大技术版图。

一句话概括：HuBMAP 回答的是"健康人体每个器官里，什么细胞在哪里、表达什么分子"——它是肿瘤、肾病、肠病等一切疾病空间组学研究不可缺少的"正常对照底图"。

你可以用它来：为疾病样本构建健康基线对照、训练细胞分割与细胞类型注释模型、把组织数据注册进 Human Reference Atlas 做跨研究对齐、或者直接在浏览器里用 Vitessce 探索 1,500+ 个数据集的空间可视化。全部已发布数据采用 CC BY 4.0 许可，无需注册即可下载。

§1.1 摘要

HuBMAP 由 NIH Common Fund 资助，由来自 Common Fund、NHLBI、NIBIB 与 NIDDK 的跨 NIH 工作组管理，联盟横跨美国与欧洲，从最初的 18 个协作团队发展至 400 余名成员、60 余家机构。联盟组织为三大组件：Tissue Mapping Centers（TMC，组织测绘中心，含 Stanford、Vanderbilt、UC San Diego、Beth Israel Deaconess Medical Center 等）负责产数据；变革性技术开发（TTD）与快速技术实施（RTI）负责造工具；HIVE（Harvard、Indiana、Pittsburgh 等组成的计算基础设施）负责管数据。所有数据经统一可复现管线（CWL、Docker、Airflow）处理，以 AnnData、OME-TIFF 等标准格式发布，按 FAIR 原则管理，并通过门户、Globus 传输、五大 REST API 与 Vitessce 可视化向全球开放。其另一支柱产物 Human Reference Atlas（HRA）已覆盖 4,499 个解剖结构、1,195 种细胞类型与 2,089 种生物标志物，成为跨联盟数据对齐的本体骨架。

§1.2 战略价值分析

范式开创维度：在 HuBMAP 之前，人体组织层面的空间组学数据散落在各实验室，格式、坐标与注释互不兼容，跨器官、跨技术的比较近乎不可能。HuBMAP 做对了一件别人没做的事：在产数据的同时定标准——统一管线、统一元数据 schema（CEDAR 校验）、统一本体（Uberon、Cell Ontology）、统一坐标框架（CCF/HRA）。这套"数据加坐标系"的打法被 SenNet、HTAN 等后续联盟直接继承，可以说 HuBMAP 定义了"空间细胞图谱"这一研究范式的基础设施形态。

生态推动维度：HuBMAP 的工具生态全部开源且可独立使用——可视化引擎 Vitessce 已成为空间单细胞可视化的社区标准之一；细胞注释工具 Azimuth 由 Satija 团队维护，内置多个 HuBMAP 参考图谱；RUI/EUI/CDE 三件套让组织空间注册与细胞距离分析开箱即用。2023 年功能组织单元（FTU）Kaggle 竞赛吸引 60 个国家 1,200 支队伍参赛，冠军算法 Tom 已并入 HuBMAP 基础设施规模化运行，展示了"联盟出题、社区解题"的开放科学模式。

临床影响维度：2023 年 7 月 Nature 封面同期刊发 HuBMAP 三篇器官图谱论文——肠道（单细胞分辨率，9 名捐献者 8 个肠段）、肾脏（45 个健康与 48 个病变肾脏、51 种细胞类型，与 KPMP 协同）、母胎界面（约 50 万细胞、近 600 条动脉的时空图谱）——同日另有 6 篇配套论文发表。这些图谱以健康与疾病状态的空间细胞关系为坐标系，为肿瘤微环境、移植耐受、妊娠并发症等方向提供了可复用的参照底图；其对"正常"的严格定义，正是肿瘤病理 AI 里"癌旁对照"最缺的那块拼图。

§1.3 横向对比

数据集/联盟	主体定位	核心模态	规模口径	核心差异化
HuBMAP	健康成人多器官空间图谱	单核测序 + 空间转录组 + 多重成像	5,032 数据集 / 310 捐献者 / 27 器官大类（截至 2025-10）	健康"正常"底图 + HRA 坐标框架，CC BY 4.0 全开放
HCA（Human Cell Atlas）	全人体细胞百科	单细胞测序为主	千万级细胞（多来源汇总）	范围更广但空间信息与影像密度不及 HuBMAP
GTEx	成年组织基因表达参考	bulk 与单核 RNA-seq	数十器官、千余捐献者	eQTL 与表达参考金标准，但无空间成像
SenNet	衰老细胞图谱（细胞衰老计划）	与 HuBMAP 同源的工具栈	滚动建设中	HuBMAP 的"续集"，共享 HRA 与管线经验
HTAN	肿瘤单细胞与空间图谱	肿瘤组织多组学	滚动建设中	疾病侧对应物，常与 HuBMAP 健康底图联用
KPMP	肾脏精准医学项目	肾脏单细胞与空间数据	45 健康 + 48 病变肾脏（联合分析）	HuBMAP 2023 肾脏图谱的疾病侧伙伴

HuBMAP 的不可替代性在三点：它是目前唯一以"健康成人"为总纲、以标准化管线与公共坐标框架贯穿全部器官的大型开放资源；它是多重蛋白质成像（CODEX、MIBI 等）数据最集中的公共门户之一；它与 HRA 的深度绑定让"我的数据在人体的哪里"第一次成为可计算的量。

§1.4 版本演进时间轴

时间	事件
2018	NIH Common Fund 正式启动 HuBMAP，8 年资助期，首批 18 个协作团队（美国与欧洲）
2019-10	奠基论文发表于 Nature 574 卷（HuBMAP Consortium，DOI: 10.1038/s41586-019-1629-x），确立总体框架
2020	首次公开数据发布：心、肾、大肠、小肠、淋巴结、脾、胸腺 7 种器官、300+ 数据集（CalTech、Stanford、UCSD、佛罗里达大学、Vanderbilt 贡献）
2020-02	数据使用协议（DUA）定版；开放/受控双轨访问政策确立
2021-2022	器官与测定矩阵快速扩张：CODEX、MIBI、Cell DIVE、Light Sheet、DESI 等技术陆续入库；HRA 工具链（RUI/EUI）上线
2023-07-19	Nature 封面三连发：肠道、肾脏、母胎界面参考图谱；同日 6 篇配套论文发表于 Cell 与 Nature 子刊
2023-07	OMAP（器官测绘抗体面板）社区标准发表于 Nature Methods，覆盖 60+ 靶标
2023	FTU 分割 Kaggle 竞赛收官：60 国 1,200 支队伍，冠军算法 Tom 并入基础设施
2024-2025	联盟进入收获期：HRA v2.0 发布（4,499 解剖结构/1,195 细胞类型/2,089 生物标志物）；Nature Methods 2025 发表 HRA 系统论文
2025-11	数据门户系统性论文发布（arXiv:2511.05708）：截至 2025-10 托管 5,032 数据集、310 捐献者、22 种数据类型、27 个器官大类

§1.5 典型 AI 应用场景

健康基线与疾病对照：为肿瘤（癌旁对照）、肾病（KPMP 联合分析）、肠病等疾病空间组学研究提供严格定义的"正常"参照——这是 HuBMAP 最不可替代的用法。
细胞分割与 FTU 建模：H&E、免疫荧光与 CODEX 影像支撑细胞核/细胞分割模型训练；肾单位、胰岛等功能组织单元（FTU）分割已有 Kaggle 竞赛级基准与开源冠军算法。
细胞类型注释与注释迁移：以 Azimuth 参考图谱和 ASCT+B 本体标签体系为锚，把新数据的细胞注释到统一本体上，解决"各论文细胞命名不互通"的老大难。
跨模态整合方法研发：同一样本常有多模态测定（影像 + 测序 + 代谢），是检验多模态整合算法（影像到转录组预测、跨模态检索）的天然试验场。
空间注册与图谱对齐：用 RUI 把自己的组织数据注册到 3D 参考器官，用 CCF API 查询空间关系，让多中心数据第一次"住在同一张地图上"。

§1.6 读者路线图

不同角色的读者建议按不同路径消化本条目：

读者角色	推荐路径	关键小节
ML 工程师	先看数据形态与获取，再进入代码与坑点	§3.2 → §4.1/§4.3/§4.4 → §5.1 → §6.0-§6.6 → §6.5
计算生物学家	先看技术版图与器官覆盖，再选分析范式	§2.4 → §2.6 → §3.6 → §6.9/§6.10 → §8.7
数据管理者/合规	先看许可与伦理框架，再核对引用规范	§3.0 → §7.3 → §7.7（第 22/24 项）→ §8.6
综述写作者	先定口径，再取规模与里程碑证据	§3.1 → §1.4 → §8.1 → §9.2
教学者	从速览与概览切入，配可视化资源	§1.0 → §1.1 → §2.3 → §8.4

路线图仅是导航建议，各节独立可读；跨角色引用关系已内嵌于正文链接（如 §5.6 模板引用 §8.7 的阳性对照设计）。

§2 医学背景

§2.1 为什么"正常组织"需要一张图谱

人体由数十万亿细胞组成，同一器官内细胞类型可达数十种，它们的空间排布方式直接决定器官功能。病理学的全部诊断逻辑——“结构异常即疾病”——都隐含着一个前提：我们知道正常结构长什么样。但直到最近，"正常"本身仍是各教科书示意图的集合，缺乏定量、分子级、可计算的参照。HuBMAP 的核心命题即在此：以单细胞分辨率、多模态测定和公共坐标框架，把健康成人的细胞组织方式变成一个可查询、可比对、可注册的数字底图。

对肿瘤研究而言这个底图尤其关键：肿瘤微环境研究的全部问题——免疫细胞浸润到哪、血管如何构筑、成纤维细胞如何排布——都需要与"正常该是什么样"对照。HuBMAP 在千方分类体系中被归入肿瘤学与病理组织类别，正是这个原因：它本身不含肿瘤数据，却是肿瘤空间组学缺一不可的对照组。

§2.2 覆盖器官与解剖学体系

截至 2025-10，HuBMAP 覆盖 27 个器官大类、310 位捐献者，门户层面可见的器官包括：血液与骨髓、血管系统、膀胱、脑、眼、心脏、肾脏、肝脏、肺、淋巴结、大肠、小肠、胰腺、胎盘、皮肤、脾、胸腺、输卵管、卵巢、子宫、膝关节、主支气管等。每个器官大类下的组织样本按解剖分区细分（如肾脏的皮质/髓质/肾盂），并经 RUI 注册到对应 3D 参考器官的具体坐标上。

本体层面，HuBMAP 采用三层编码体系：

本体层	用途	示例
解剖结构（AS）	器官与分区命名	Uberon 术语：kidney、cortex、medulla
细胞类型（CT）	细胞命名与注释	Cell Ontology 术语：podocyte、enterocyte
生物标志物（B）	基因/蛋白/代谢物	HGNC 基因符号、UniProt 蛋白、脂质命名

三者由 ASCT+B 表联结（33 张表覆盖 4,499 个解剖结构、1,195 种细胞类型、2,089 种生物标志物，HRA v2.0 口径），构成"哪个器官有哪些细胞、用什么标志物识别"的机器可读知识图谱。SNOMED CT 层面，捐献者与样本元数据使用 UMLS CUI 与 SNOMED 编码（如 119376003 Tissue specimen 标注组织标本、64033007 Kidney structure 标注肾脏），保证临床语义可互操作。

§2.3 功能组织单元（FTU）：比细胞高一级的结构单元

功能组织单元（Functional Tissue Unit, FTU）是执行某一器官核心功能的最小重复结构单位——肾的肾单位、小肠的隐窝-绒毛轴、胰腺的胰岛。FTU 是 HuBMAP 提出的图谱构建关键中间层：比细胞高一级（承载功能语义）、比器官低一级（可逐个分割定量）。2023 年 HuBMAP 主办的 Kaggle FTU 分割竞赛（60 国 1,200 支队伍）产出的冠军算法 Tom 已并入官方基础设施，对肾脏 FTU 的规模化分割 Dice 系数可达约 0.96。对 AI 研究者，FTU 分割是 HuBMAP 影像数据最成熟、评测最规范的任务之一。

§2.4 核心测定技术速查

技术家族	代表技术	测什么	数据形态
单细胞/单核测序	snRNA-seq、10X Multiome、SNARE-seq2	基因表达、染色质可及性	AnnData 矩阵（细胞 × 基因）
染色质可及性	ATAC-seq	开放染色区域	矩阵/片段文件
多重蛋白成像	CODEX/PhenoCycler、MIBI、2D/3D Imaging Mass Cytometry、Cell DIVE	20-60+ 蛋白标志物的单细胞空间分布	多通道 OME-TIFF（通道=标志物）
空间转录组	Visium、Slide-seq、seqFISH、CosMx、Xenium	空间位置上的基因表达	网格/珠点/像素 × 基因矩阵
组织学与形态	H&E、免疫荧光、Light Sheet	形态学结构与解剖参照	大幅面影像/三维体数据
代谢与脂质成像	DESI、MALDI、LC-MS	代谢物与脂质的空间分布	质谱影像立方体（m/z × 坐标）

理解这六大技术家族的数据形态差异，是读懂 §4 数据结构与 §6 处理指南的前提：测序家族给"矩阵"，成像家族给"多通道大图"，代谢家族给"立方体"——三种世界的坐标系、体量与预处理逻辑完全不同。

§2.5 与疾病术语的关系

HuBMAP 的队列设计刻意保持"健康成人"边界：捐献者为非相关疾病死亡的器官捐献者或手术富余组织，经过筛查排除已知重大疾病。这带来两个推论：第一，任何以 HuBMAP 数据训练的模型输出的是"正常组织分布规律"，不可直接当作疾病诊断依据；第二，疾病研究需自行引入疾病侧数据集（如 KPMP 的病变肾脏、HTAN 的肿瘤样本、TCGA 的分子分型），HuBMAP 提供的是对照臂。页面对"肿瘤学"类目下相关疾病（实体瘤微环境、癌旁对照）的讨论均以此为语境。

§2.6 四大测定版图的原理与适用场景

§2.4 的速查表按"测什么"分类；本节按"为什么这么测"展开四大版图的技术原理与选型逻辑，帮助读者判断"我的科学问题该用哪个家族的数据"。

单核测序版图（snRNA-seq / 10X Multiome / SNARE-seq2）：HuBMAP 大量采用单核而非单细胞测序，原因很实际——图谱计划必须回收利用冻存组织（捐献器官的取材与测定往往跨数日、跨多个中心），而冻存对细胞膜的破坏远大于核膜；核 RNA 保留了大部分转录信息且解离偏好更小（神经元、心肌细胞等大细胞在 scRNA 中容易丢失）。10X Multiome 更进一步在同一细胞核内同时捕获基因表达与染色质可及性，让"表达什么"与"哪个调控区开放"在单核层面配对，是构建基因调控网络的首选输入。

多重蛋白成像版图（CODEX/PhenoCycler、MIBI、Imaging Mass Cytometry、Cell DIVE）：这一族回答"细胞身份与空间组织"——用 20-60+ 种抗体同时标记蛋白，逐通道成像。CODEX 用 DNA 条码化抗体循环孵育-成像；MIBI 以金属同位素标记抗体并逐点读出；成像质谱则以激光逐点烧蚀加质谱检测。三者殊途同归：产出"每个细胞在哪个位置、表达哪些标志物"的高维表型矩阵，是肿瘤微环境、免疫浸润与细胞邻接分析的主力数据。代价是通量与体量：通道数有限（需 OMAP 级别的面板设计，见 §4.7）、原始影像动辄数 GB（见坑点 4）。

空间转录组版图（Visium、Slide-seq、seqFISH、CosMx、Xenium）：这一族沿"空间分辨率—基因通量"权衡轴排布：Visium 以约 55 微米的捕获点提供全转录组覆盖（每点聚合数个细胞）；Slide-seq 用条码珠逼近单细胞分辨率；seqFISH、CosMx、Xenium 以成像或探针方式达到亚细胞定位，但基因数为数百至数千的靶向组合。选型逻辑：无偏发现选全转录组（Visium/Slide-seq），单细胞级空间假设验证选成像式（Xenium/CosMx）。

代谢成像版图（DESI、MALDI、LC-MS）：前三个版图绕着"基因—蛋白"转，代谢版图补上分子图谱的最后一层——脂质与小分子代谢物的空间分布。质谱成像无需抗体、无需扩增，直接对组织扫描出每个坐标的 m/z 谱，天然适合绘制代谢区室化（如肾脏皮质-髓质的脂质梯度）。其数据形态（m/z × 坐标立方体）也是四大版图中对存储与算法挑战最大的。

版图	空间分辨率	分子靶标	核心优势	典型任务
单核测序	单核（无空间或粗空间）	全转录组 ± 染色质	无偏、可回收冻存组织	细胞类型发现、调控网络
多重蛋白成像	亚细胞	20-60+ 蛋白	直接读细胞表型与微环境	表型聚类、邻域分析
空间转录组	点级多细胞 → 亚细胞	全转录组或数百-数千基因	表达与位置兼得	空间基因表达制图
代谢成像	数十微米级	数百-数千 m/z 峰	无需抗体、无偏代谢检测	代谢区室化、脂质成像

§3 数据集规格

§3.0 获取渠道抉择矩阵

渠道	适合谁	获取内容	门槛
门户网页浏览	探索者、教学	检索、元数据、Vitessce 在线可视化	无需注册
Globus 批量下载	下载完整数据集	原始 + 处理后文件	需 Globus 账号，大文件走断点续传
REST API（Search/Entity）	程序化检索与管线	元数据、 provenance、下载链接	开放，外部批量访问建议联系 Helpdesk
云工作区（Workspaces）	不想配环境的分析者	浏览器内 JupyterLab（15+ 模板、GPU 选项）	免注册额度，注册后可共享
Integrated Maps	快速跨数据集分析	按"测定 × 组织"聚合的整合数据	直接下载
dbGaP（受控子集）	需要敏感字段的研究者	受控访问数据	NIH DAC 审批

§3.1 总体规模与口径说明

HuBMAP 的规模数字必须绑定"时间点 + 口径"两个维度，这是使用该门户最重要的元知识：

指标	数值（截至 2025-10，官方门户论文口径）
数据集总数	5,032 个
数据类型	22 种
器官大类	27 个
捐献者	310 位
可在线可视化的数据集	1,500+（Vitessce）
单细胞/单核测序数据集	约 1,469
ATAC-seq 数据集	约 1,023
每捐献者-器官平均样本数	约 8.2

口径警告：门户首页另有"9,000+ datasets across 40+ facets"的宣传口径（含派生数据集与更宽的计数规则）。引用 HuBMAP 规模时务必注明时间点与口径来源——两个数字都"对"，但混用会让文献综述的数字互相打架（详见 §6.5 坑点 1）。

§3.2 22 种数据类型矩阵

门户按测定类型组织数据（括号内为该类典型格式）：

家族	门户数据类型（非穷举）
测序	10X Multiome、ATACseq、RNAseq、RNAseq（with probes）、SNARE-seq2、WGS
多重成像	2D Imaging Mass Cytometry、3D Imaging Mass Cytometry、CODEX/PhenoCycler、MIBI、Cell DIVE、MUSIC
空间转录组	Visium（no probes）、Slide-seq、seqFISH、CosMx Transcriptomics、Xenium
组织学	Histology（H&E 与特殊染色）、Light Sheet、Auto-fluorescence
质谱/代谢	LC-MS、DESI、MALDI
流式/其他	CyTOF、GeoMx (NGS)

snRNA-seq 与 ATAC-seq 是数量最多的两类（约 1,469 与 1,023 个数据集），构成 HuBMAP 的分子骨架；CODEX、MIBI 等多重成像数量较少但单个体量大、价值密度高，是空间微环境分析的主力。

§3.3 捐献者队列与元数据

310 位捐献者均为经知情同意的脱敏供体，来源包括器官捐献与手术富余组织。元数据覆盖年龄、性别、BMI、血型、死因类别等临床字段，全部以 UMLS CUI 与 SNOMED CT 编码。三点使用须知：捐献者人口学分布在各器官项目间不均衡（北美与欧洲采购管道为主）；"健康"是筛查性定义而非体检级定义，个别供体可能携带未诊断的早期病变；样本取材环境（捐献 vs 手术）影响缺血时间，是重要的批次协变量。

§3.4 采集与处理管线

HuBMAP 数据从组织到发布经过标准化五步：

取材与注册：TMC 按 protocols.io 公开协议取材，用 RUI 在 3D 参考器官上注册取样位置；
测定：TMC 与技术团队执行各家族测定，多重成像须提交抗体验证报告（OMAP 标准）；
处理：统一管线（CWL 描述、Docker 容器、Airflow 编排）完成 QC、分割、定量、降维，输出 AnnData/OME-TIFF 等标准格式；
校验：CEDAR 元数据 schema 校验 + 人工 QC 指标复核；
发布：Elasticsearch/UBKG 索引入门户，状态转为 Published 并分配 DOI。

这套流程保证"不同实验室、不同器官、不同捐献者的结果可比"——是 HuBMAP 相对散装文献数据最大的工程优势。外部实验室经官方管线处理的数据可通过 EPIC（Externally Processed Integrated Collections）机制入库，提供官方视角外的补充。

§3.5 发布与更新节奏

HuBMAP 采用滚动发布：数据经 QA 后即发布，无固定版本号，每个已发布数据集拥有永久 DOI。由此推导三条使用准则：规模数字必须注明"截至"日期；跨数据集分析前用 API 重新拉取清单（上次跑批后可能有新发布）；引用具体数据集时引其 DOI 而非门户链接，保证引用可解析。联盟的 8 年资助期覆盖至 2025 年前后，其方法论与工具栈由 SenNet 等后续计划延续。

§3.6 器官覆盖的定性分层

27 个器官大类并非均匀覆盖。基于门户论文的公开描述与首次发布史，覆盖密度大致呈三层分布。下表为定性评估，精确计数请用 Search API 按器官现查（口径纪律见坑点 1）：

覆盖层级	器官（非穷举）	特征
高覆盖	肾脏、大肠、小肠	多模态齐备（测序 + 多重成像 + 空间转录组），有 2023 年 Nature 级参考图谱与 Kaggle FTU 基准
中覆盖	心脏、淋巴结、脾、胸腺、胰腺、胎盘、肺、肝脏	首发七器官或其他重点项目的主力测定已入库，模态组合因项目而异
低覆盖/新进	脑、眼、膝关节、输卵管、卵巢、子宫、膀胱、血管、皮肤、血液与骨髓、主支气管	多为后期加盟项目，部分仅有单一模态或少量捐献者

三条使用推论：第一，跨器官泛化实验的可信度受制于低覆盖器官——在仅有两三位捐献者的器官上得出的"泛化失败"结论不可靠；第二，“热器官”（肾、肠）内部也存在模态空隙，做器官内分析前仍应按数据类型过滤；第三，覆盖随滚动发布持续变化，三个月前绘制的覆盖矩阵应当重绘。这正是 §7.1"器官与测定覆盖不均"偏倚的量化入口。

§4 数据结构详解

§4.1 实体层级与标识符体系

HuBMAP 的一切数据都挂在一条严格的存在链上：

Donor（捐献者）
  └─ Sample（组织样本：block 块 / suspension 悬液 / section 切片）
       └─ Dataset（一次测定产出的数据集：原始 + 派生）
            └─ [Processing runs / 派生 Dataset]

每个实体拥有三种标识符，混用是新手第一大坑：

标识符	形态示例	用途
HuBMAP ID	HBM123.ABCD.456	人可读，用于门户展示、论文与人际沟通
UUID	32 位十六进制	系统内部主键，API 查询的主用键
DOI	10.1234/HBM123.ABCD	已发布数据的永久引用

HuBMAP ID 与 UUID 一一对应（并非所有 UUID 都有 HuBMAP ID）；provenance 链完整记录 Donor→Sample→Dataset 的派生关系与管线执行历史（W3C PROV 兼容）。

§4.2 DAIMS 标准化字段描述表

下表给出程序化访问 HuBMAP 时最高频的核心字段（字段名以门户元数据为准）：

实体	字段	类型	说明	AI 使用要点
Donor	hubmap_id	Text	捐献者 HBM ID	分组划分的分组键
Donor	donor_metadata	JSON	年龄/性别/BMI/死因（UMLS CUI 编码）	偏倚分析与亚组分层
Sample	organ	Text	Uberon 器官术语	跨器官分析的分层变量
Sample	rui_location	JSON	3D 空间注册信息	空间对齐与邻域计算
Dataset	data_type	Text	22 种测定类型之一	模态筛选主字段
Dataset	status	Text	New/QA/Published 生命周期	只对 Published 数据做正式分析
Dataset	pipeline	JSON	处理管线版本与参数	复现性与批次校正
Dataset	local_directory_full_path	Text	Globus 下载路径	批量下载寻址
Derived	antibody	JSON	抗体验证信息（成像类）	通道语义与跨批次可比性
Derived	cell_type_annotations	JSON	细胞类型标签（CL 本体）	注释任务标签列

§4.3 单细胞数据格式：AnnData

测序家族的标准交付格式是 AnnData（.h5ad）：X 存表达矩阵（细胞 × 基因），obs 存细胞级元数据（样本来源、注释标签），var 存基因元数据（HGNC 符号），obsm 存降维嵌入（UMAP/tSNE），obsp 存邻接图（用于空间邻域或 kNN）。HuBMAP 统一管线已完成 QC 过滤、标准化与降维，obs 中的细胞类型注释列已对齐 Cell Ontology，因此"读入即可分析"——这正是其 AI 就绪度的核心加分项。

§4.4 影像数据格式：OME-TIFF 与多通道立方体

成像家族以 OME-TIFF 为主：每个文件是一个多通道立方体（C 个标志物通道 × H × W 像素），OME XML 头记录通道语义（哪个通道是哪个标志物）、物镜、缩放与物理像素尺寸。CODEX/MIBI 的原始数据可能以厂商格式（如 .mcd）或影像序列交付，官方管线统一转换为标准化产物。三个工程要点：通道数 20-60+ 导致单文件可达数 GB；OME XML 的轴序（C/Z/T）必须显式解析；向下采样金字塔（zarr 化）是在线可视化的基础。代谢成像（DESI/MALDI）则以 m/z × 坐标的质谱立方体交付，规模更大。

§4.5 元数据与本体对齐

每个数据集的元数据经 CEDAR 模板校验，器官、细胞类型、标志物分别挂接 Uberon、Cell Ontology、HGNC/UniProt，捐献者临床字段挂接 UMLS CUI。全部本体关系汇入统一生物医学知识图谱（UBKG，neo4j），经 Ontology API 查询。对 AI 工作流的意义：跨数据集合并时，用本体 ID 而非字符串匹配做标签对齐；细胞命名冲突（同一细胞不同叫法）通过 ASCT+B 表的层级关系归并。

§4.6 API 实体模型速查

五大 REST API 对应实体模型的五个切面：Entity API 返回实体属性与 provenance（/entities/{uuid}、/entities/{uuid}/provenance）；Search API 提供按 40+ facet 的检索（Donor/Sample/Dataset 全集查询）；UUID API 供联盟内部注册使用；Ingest API 供 TMC 上传；Ontology API 查询 UBKG。另有 CCF API 与 HRA SPARQL 端点服务空间注册查询。数据传输本体经 Globus Transfer（支持断点续传与批量同步）。

§4.7 Provenance、EPIC 与抗体验证深读

W3C PROV 谱系记录：HuBMAP 的 provenance 采用 W3C PROV 标准三元模型——entity（数据节点：Donor/Sample/Dataset）、activity（处理活动：一次测定、一次管线运行）、agent（执行者：TMC、管线版本）。每个已发布数据集都能沿链回溯到取材样本与捐献者，并读出每一步由哪个机构、哪个管线版本完成。对 AI 复现研究，这条链有三个用途：审计数据血缘（确认训练集不混入同一原始数据的派生重复）、定位批次变量（activity 层记录的机构与时间信息是天然的批次协变量）、复核管线版本（版本号变化往往是分布漂移的元凶）。

EPIC（Externally Processed Integrated Collections）：外部实验室若用官方开源管线处理了自己的 HuBMAP 组织数据，或对已发布原始数据做了再处理，可经 EPIC 机制申请入库。门户因此可能同时存在同一原始数据的官方管线版本与 EPIC 版本——合并数据清单时务必按 Dataset ID 去重并标注版本来源（§5.3 的管线泄漏与重复风险正源于此）。

抗体验证报告（OMAP 标准）：多重成像数据的每个抗体需提交验证记录（克隆号、供应商、验证方式）；联盟于 2023 年在 Nature Methods 发布了器官测绘抗体面板（OMAP）社区标准，为各器官给出经验证的抗体组合面板（覆盖 60+ 靶标）。用 CODEX/MIBI 做跨批次表型分析前，先核对各数据集的抗体面板——通道名相同不等于抗体克隆相同，更不等于表型可跨批合并。

# 重建数据谱系（示意：字段名以 API 实际返回为准）
import requests

def lineage(uuid_or_hmid: str) -> list:
    """沿 provenance 链枚举 Donor -> Sample -> Dataset 节点"""
    r = requests.get(
        f"https://entity.api.hubmapconsortium.org"
        f"/entities/{uuid_or_hmid}/provenance",
        timeout=60,
    )
    r.raise_for_status()
    prov = r.json()
    # W3C PROV-JSON 顶层三键：entity / activity / agent
    out = []
    for node_id, meta in prov.get("entity", {}).items():
        out.append({
            "prov_id": node_id,
            "type": meta.get("prov:type"),        # 实体类型（含联盟扩展字段）
            "hubmap_id": meta.get("hubmap:id"),   # 人可读 ID（如存在）
        })
    return out

for node in lineage("PUT_A_DATASET_UUID_HERE"):
    print(node["type"], "|", node["hubmap_id"], "|", node["prov_id"][:12])

把 lineage 输出与 Entity API 的实体属性交叉核对，是排除"同源重复数据集"混入训练集的最后一道闸门。

§5 数据划分与使用建议

§5.1 官方无划分：现实与对策

HuBMAP 不是监督学习基准，官方不提供 train/val/test 划分——这与其"图谱基础设施"的定位一致。由此，任何建模任务都需要自建划分，且必须遵守一条铁律：以 Donor（捐献者）为分组键划分。同一捐献者的多个样本、多个测定高度相关（同一器官不同分区、相邻切片），按数据集或样本划分会把同一个人的细胞同时放进训练与测试集，造成教科书级的数据泄漏。

推荐三级划分策略：按捐献者分层分组（GroupShuffleSplit，按器官分层保证各器官均在三集中出现）→ 器官级留出验证（整器官留出，模拟跨个体泛化）→ 时间级留出（按数据发布时间，模拟"用旧数据预测新批次"）。三种策略回答的泛化问题不同，论文中应明示所用策略。

§5.2 任务与标签的获取路径

任务	标签来源	注意事项
细胞类型注释	AnnData obs 注释列 / Azimuth 参考	注释粒度因 TMC 而异，合并前先做本体映射
细胞/核分割	影像 + 官方管线分割产物	以官方分割为弱标签，人工精标子集做校准
FTU 分割	Kaggle 竞赛数据与冠军算法产物	遵守竞赛数据使用条款
空间邻域/微环境	CODEX/MIBI 分割产物 + 表型标签	邻域定义（半径/近邻数）需敏感性分析
跨模态整合	同样本多模态配对数据	用 Sample ID 对齐，勿假设像素级对齐
空间注册	RUI 注册信息 + CCF API	未注册样本需先补注册

§5.3 数据泄漏风险清单

除"跨捐献者泄漏"这一头号风险外，HuBMAP 语境还有三种特有泄漏模式：切片相邻性泄漏——相邻连续切片几乎无信息差，一张进训练一张进测试等于复制粘贴；管线泄漏——官方管线已做标准化与降维，若下游任务直接使用管线产物中的聚合统计量，等于把测试集分布信息带入特征；EPIC 与官方产物重复——同一原始数据可能同时存在官方管线版本与外部处理版本，合并去重时以 Dataset ID 而非文件名为准。

§5.4 跨数据集联合使用建议

与疾病侧数据联用是 HuBMAP 的标准打开方式：肾脏方向与 KPMP 的健康-病变配对设计是最成熟的范式（2023 年 Nature 肾脏图谱即 45 健康 + 48 病变联合分析）；肿瘤方向可与 HTAN、TCGA 的空间与分子数据对照，构建"癌 vs 癌旁"设计；表达参考方向 GTEx 提供更大捐献者数的 bulk 层面交叉验证；单细胞注释可借道 HCA 生态的参考图谱互校。联合使用时务必统一本体（Uberon/CL/HGNC）与空间框架（CCF），否则联合只会放大噪声。

§5.5 外部验证路径

以 HuBMAP 数据训练的模型，其外部验证优先级：同器官跨联盟数据（如 SenNet 共享组织、HPA 的免疫荧光影像）→ 跨技术同器官（Visium 注释迁移到 CODEX 表型）→ 跨器官泛化极限测试（刻意验证"模型学到的是器官还是方法"）。评估设计上，器官级留出是最严格也最诚实的方案——多数"跨数据集性能下降"的真因不是生物学差异，而是测定协议与批次差异。

§5.6 三个标准任务的实验设计模板

把 §5.1-§5.5 的原则折叠成三张可直接套用的设计卡。

模板 A：细胞类型注释迁移（把官方/Azimuth 标签迁移到自有数据）

设计要素	建议方案
训练数据	同器官 HuBMAP AnnData（Published 状态），官方注释列为主标签
划分	GroupShuffleSplit（donor 级）+ 整器官留出做最终验证
特征基线	官方管线产物的高变基因 + PCA；自建流程须报告官方基线对照
主指标	macro-F1（长尾类别敏感）+ 每类 F1 明细
验证	换 TMC 留出、换测定家族（snRNA → Visium）迁移测试

模板 B：FTU/细胞分割（影像 → 掩码）

设计要素	建议方案
训练数据	目标器官影像 + Kaggle FTU 数据与冠军算法产物（弱标签）
划分	按捐献者分组；相邻连续切片强制归入同一 split（§5.3 切片相邻性泄漏）
标签策略	官方/竞赛分割为弱监督起点，人工精标一至两位捐献者做校准与测试
主指标	Dice + 边界 F 值（FTU 级与实例级分别报告）
验证	跨 TMC 影像（染色/扫描批次不同）的 Dice 衰减分析

模板 C：空间微环境聚类（CODEX/MIBI → 邻域表型）

设计要素	建议方案
训练数据	多重成像 + 官方或社区分割产物 + 表型标签
划分	按捐献者与 TMC 双分层
邻域定义	半径/近邻数做敏感性分析，报告主结论的稳定性
主指标	ARI（跨重复运行稳定性）+ 邻域富集显著性 + 生物学合理性人工评审
验证	在 2023 年 Nature 图谱已发表结论上做阳性对照（§8.7）

§6 AI 就绪指南

§6.0 环境准备

组件	用途	安装
Python 3.10+	主语言	官方建议
scanpy + anndata	单细胞读取与分析	`pip install scanpy anndata`
tifffile	OME-TIFF 读取	`pip install tifffile`
squidpy	空间组学分析	`pip install squidpy`
requests	API 访问	`pip install requests`
globus-sdk	批量传输	`pip install globus-sdk`
Vitessce（浏览器）	在线可视化	无需安装

# 一键环境（conda 示例）
conda create -n hubmap python=3.11 -y
conda activate hubmap
pip install scanpy anndata squidpy tifffile requests globus-sdk jupyterlab

硬件建议：单细胞类数据集 8 GB 内存起步；多重成像原始数据（单文件数 GB、解压后更大）建议 32 GB 内存与 SSD，TB 级 3D 数据直接申请云工作区或在 HPC 处理。

§6.1 用 Search API 检索数据集

Search API 是程序化获取数据集清单的主入口（POST JSON 查询，返回实体与元数据）：

import requests

SEARCH_URL = "https://search.api.hubmapconsortium.org/search"

def search_hubmap(data_type: str, organ: str = None, size: int = 100):
    """按测定类型与器官检索 HuBMAP 已发布数据集"""
    query = {
        "size": size,
        "query": {
            "bool": {
                "must": [
                    {"term": {"entity_type.keyword": "Dataset"}},
                    {"term": {"dataset_status.keyword": "Published"}},
                    {"term": {"data_types.keyword": data_type}},
                ]
            }
        },
        "_source": [
            "hubmap_id", "uuid", "data_types", "organ", "donor.hubmap_id",
            "status", "title",
        ],
    }
    if organ:
        query["query"]["bool"]["must"].append({"term": {"organ.keyword": organ}})
    r = requests.post(SEARCH_URL, json=query, timeout=60)
    r.raise_for_status()
    hits = r.json()["hits"]["hits"]
    return [h["_source"] for h in hits]

# 示例：检索肾脏的 CODEX 数据集
datasets = search_hubmap("CODEX", organ="kidney")
for ds in datasets[:5]:
    print(ds["hubmap_id"], "|", ds.get("title", "")[:60])

字段名以门户 API 文档为准（Search API 支持 40+ facet 过滤：捐献者人口学、测定类型、器官、状态等）；查询结果分页用 "from" 参数递增。

§6.2 用 Entity API 获取元数据与 Provenance

拿到数据集后，用 Entity API 获取完整元数据、provenance 链与下载信息：

import requests

ENTITY_URL = "https://entity.api.hubmapconsortium.org"

def get_entity(uuid_or_hmid: str) -> dict:
    """查询任意 HuBMAP 实体（Donor/Sample/Dataset）的完整元数据"""
    r = requests.get(f"{ENTITY_URL}/entities/{uuid_or_hmid}", timeout=60)
    r.raise_for_status()
    return r.json()

def get_provenance(uuid_or_hmid: str) -> dict:
    """获取 provenance 链（Donor -> Sample -> Dataset -> 派生）"""
    r = requests.get(
        f"{ENTITY_URL}/entities/{uuid_or_hmid}/provenance", timeout=60
    )
    r.raise_for_status()
    return r.json()

ds = get_entity(datasets[0]["uuid"])
print("HuBMAP ID :", ds["hubmap_id"])
print("数据类型   :", ds.get("data_types"))
print("状态       :", ds.get("status"))
print("供体       :", ds.get("donor", {}).get("hubmap_id"))

prov = get_provenance(datasets[0]["uuid"])
# provenance 返回 W3C PROV 风格的节点与关系，可用于重建取材-测定-处理全链

三条工程守则：对批量请求加限速与指数退避重试（服务端在高负载下偶发 502/504，详见坑点 7）；UUID 与 HuBMAP ID 都能查询，但批处理流程中统一用 UUID；正式引用用 DOI（Entity 元数据中包含）。

§6.3 批量下载：Globus 路径

每个数据集元数据中的 local_directory_full_path 指向其 Globus 存储位置。小文件可直接经门户"Download"按钮或 HTTPS 端点获取；规模化下载推荐 Globus CLI：

# 安装并登录 Globus
pip install globus-sdk
globus login

# 在 Entity 元数据中找到数据集的 Globus endpoint 与路径后：
# globus transfer <source_endpoint> <dest_endpoint> \
#   --path /path/in/endpoint/ --recursive

下载策略：先下"处理后数据"（AnnData/OME-TIFF，体积可控）验证任务可行，再决定是否拉原始数据；TB 级多重成像永远走 Globus（断点续传），勿用 requests 硬拉大文件。

§6.4 单细胞数据读取与基础分析

import scanpy as sc
import anndata as ad

# 读取 HuBMAP 统一管线产物（AnnData）
adata = ad.read_h5ad("HBM123.ABCD.456_snRNA-seq.h5ad")

print(adata)                      # 细胞 × 基因维度
print(adata.obs.columns.tolist()) # 细胞级元数据（含细胞类型注释列）
print(adata.obsm.keys())          # 官方降维嵌入（UMAP/tSNE）

# 官方已完成 QC 与标准化，直接进入分析：
# 1) 按器官/捐献者检查细胞构成（防泄漏前置检查）
print(adata.obs.groupby(["donor_hubmap_id", "organ"]).size())

# 2) 细胞类型注释分布
ct_col = [c for c in adata.obs.columns if "cell_type" in c.lower()][0]
print(adata.obs[ct_col].value_counts().head(10))

# 3) 标记基因表达验证（示例：肾脏足细胞 NPHS1/NPHS2）
sc.pl.umap(adata, color=ct_col, legend_loc="on data")

要点：官方产物的 obs 注释已对齐 Cell Ontology，跨数据集合并用本体 ID 对齐而非字符串比对；如需重跑 QC（例如更严格的线粒体阈值），先保留官方 obs 原始列以便复现比对。

§6.5 常见坑点

⚠️ 坑点 1：数字口径混乱——"9,000+"与"5,032"都是官方数字（分类：口径理解）

问题：门户首页宣传"9,000+ datasets across 40+ facets"（含派生数据集与更宽计数规则），而官方门户论文（arXiv:2511.05708）口径为"截至 2025-10 托管 5,032 个数据集"。文献综述、基金申请与模型卡片中混用两个口径，数字对不上还找不到原因。

症状：同一项目文档里出现两个不同的"数据集总数"；审稿人质疑数据规模陈述前后矛盾；跨时间比较规模增长时算出"负增长"。

解决：引用任何规模数字时强制绑定三元组——数值 + 截至时间点 + 口径来源（“5,032 个数据集，截至 2025-10，官方门户论文口径”）；规模随时间变化的分析用 Search API 现查现用，并在论文方法节注明查询日期与查询条件；不要用门户首页截图当证据。

参考：https://arxiv.org/abs/2511.05708 ；https://portal.hubmapconsortium.org/

⚠️ 坑点 2：三种标识符（HuBMAP ID / UUID / DOI）混用导致 API 404（分类：标识符体系）

问题：HuBMAP ID（HBM123.ABCD.456）用于人读、UUID 是 API 主键、DOI 只给已发布数据。把 DOI 当 UUID 查 Entity API、把论文里的 HuBMAP ID 直接拼进下载 URL，都会 404 或查到错误实体。

症状：脚本批量查询时"随机"失败；同一数据集在论文与门户间"对不上号"；下载目录里的文件名与论文附录引用的 ID 不一致。

解决：批处理管线统一以 UUID 为工作主键（从 Search API 结果中原样透传，不要自行截断或转小写）；跨文档对账用 HuBMAP ID；对外发布引用用 DOI；在元数据 JSON 中三者并存，写一个 ID 归一化函数而不是各处散落转换逻辑。

参考：https://docs.hubmapconsortium.org/apis （Identifiers 节）

⚠️ 坑点 3：HuBMAP 以 snRNA-seq（单核）为主，直接套 scRNA-seq 预处理会伤数据（分类：预处理陷阱）

问题：冻存组织测序以单核 RNA-seq 为主，细胞质 RNA 部分丢失、线粒体 Reads 占比天然偏低、ambient RNA 更明显。照搬 scRNA-seq 教科书流程（高线粒体占比即剔除、按 UMI 上限过滤核数据）会系统性丢掉真实细胞或引入偏差。

症状：某些细胞类型（如神经元、心肌细胞等大细胞）数量异常偏少；QC 后细胞数骤降且分布偏斜；doublet 比例评估失真。

解决：优先使用官方管线产物（已完成适配 snRNA 的 QC）；自行重跑 QC 时用更宽的线粒体阈值并保留核质比指标；用 SoupX 类方法处理 ambient RNA；对照官方 obs 中的原始 QC 列核对剔除影响。

参考：HuBMAP 统一管线文档（portal 关联 GitHub）；arXiv:2511.05708 方法节。

⚠️ 坑点 4：多重成像（CODEX/MIBI）体量与 OME-TIFF 轴序陷阱（分类：工程陷阱）

问题：CODEX/MIBI 数据集是 20-60+ 通道的大图立方体，单文件数 GB、序列化存储轴序（C/Z/T/HW）各异；用 imread 默认读入会把通道轴当 Z 轴，或因整图载入内存直接 OOM。

症状：某个"标志物"图像其实是空间 Z 层；可视化出现规律条纹；内存占用瞬间爆掉；多页 TIFF 只读了第一页。

解决：永远用 tifffile 读 OME-TIFF 并先解析 ome_metadata 的 Dimensions（确认 C 在哪一轴）；按需惰性读取单通道（tifffile.imread(..., key=页码) 或 zarr 存储的 multiscale pyramid）；下采样金字塔做探索、原分辨率只跑最终分割；TB 级数据直接申请云工作区或 HPC。

参考：https://docs.hubmapconsortium.org/ ；tifffile 文档 OME 节。

⚠️ 坑点 5：空间坐标体系互不相通——Visium 网格、CODEX 像素、HRA 全球坐标是三套系统（分类：多模态整合）

问题：Visium 是网格点坐标（像素单位）、CODEX/MIBI 是显微像素坐标、HRA/CCF 是毫米级 3D 解剖坐标。三者数值、单位、原点全不同。直接把不同技术的坐标拼进同一张"空间图"做邻域分析或可视化，得到的是没有物理意义的马赛克。

症状：跨技术叠加图上细胞"越界"到别的器官；邻域分析跨样本混算后 ARI/接口密度指标异常；用 RUI 注册后查询返回的位置与预期相差很远。

解决：每份数据先声明其坐标空间（单位、原点、2D/3D）；跨技术对齐经由样本 → 器官 → CCF 的注册链（RUI 注册 + CCF API 查询），不要点对点硬配准；同一器官内跨样本比较时统一缩放到物理单位（微米）；分析脚本里显式打印坐标元数据做 sanity check。

参考：https://humanatlas.io/ ；https://docs.hubmapconsortium.org/apis （CCF API 节）。

⚠️ 坑点 6："健康捐献者"不是零风险正常对照——队列与批次偏倚（分类：偏倚）

问题：捐献者来自器官捐献与手术富余两条管道，年龄、性别、BMI、死因分布不均；取材缺血时间、固定/包埋批次因 TMC 而异。"健康"是筛查性定义（无已知重大疾病），非体检级保证。把 HuBMAP 队列当作无偏"ground truth"直接外推，会把采购管道的选择效应带进模型。

症状：模型在某器官上"正常/疾病"分离度好得可疑，实为批次效应；亚组分析发现某年龄段细胞构成系统性偏移；跨 TMC 数据合并后 UMAP 按实验室聚类而非按细胞类型聚类。

解决：以捐献者元数据（年龄/性别/死因）与 TMC/批次变量做分层与协变量校正（Harmony/scVI 类方法）；对照 §7.1 偏倚表设计分析；疾病对照研究明确写出 HuBMAP 队列的纳排口径；跨批次合并前先做小样本 PCA 检查批次聚类强度。

参考：arXiv:2511.05708（队列与 QC 描述）；https://docs.hubmapconsortium.org/faq

⚠️ 坑点 7：API 批量访问的限速、502/504 与静默丢数据（分类：工程陷阱）

问题：Search/Entity API 在高负载下存在网关超时（502/504）与连接池耗尽的公开 issue（entity-api 曾有专门的压测与修复记录）。无重试、无分页、无断言的爬取脚本会在半夜静默漏掉一批数据集，事后无从察觉。

症状：全量清单行数每次跑都不同；下游出现"幽灵数据集"（引用了但查不到元数据）；长脚本偶发 ConnectionError 后继续运行。

解决：所有请求套指数退避重试（requests + urllib3 Retry）并校验返回 hits.total 与本地行数一致；分页遍历用 from/size 并断言无重叠；大规模外部批量访问先联系 Helpdesk 报备；跑批结果落盘并记录查询时间戳，便于事后对账。

参考：https://github.com/hubmapconsortium/entity-api/issues （性能与稳定性 issue）；https://docs.hubmapconsortium.org/faq （API 节）

⚠️ 坑点 8：数据集状态与版本会变——引用前核对 Published 状态与 DOI（分类：引用规范）

问题：数据集生命周期为 New → QA → Published，且存在状态变更甚至撤回（Retracted 状态支持在联盟开发计划中）；论文补充材料对应的 Collection 可能随滚动发布更新。写作时抓取的"临时"数据（New/QA 状态）在正式发表时可能已变更或不可引。

症状：论文评审阶段数据集链接失效；复现者拿到的数据与论文数字对不上；引用的 Collection 内容已被更新。

解决：只以 Published 状态数据做正式分析与引用；引用用数据集 DOI（永久可解析）而非门户页面 URL；在方法节记录"数据获取日期 + 查询条件 + 数据集 ID 清单"三件套；动手前用 Entity API 核对一次状态。

参考：https://docs.hubmapconsortium.org/apis ；https://github.com/hubmapconsortium/entity-api/issues

§6.6 多重影像读取与表型分析

import tifffile
import numpy as np

# 读取 OME-TIFF 多重成像（示例：CODEX 数据集）
path = "HBM456.CDEF.789_CODEX.ome.tif"
with tifffile.TiffFile(path) as tif:
    ome = tif.ome_metadata          # 先解析 OME XML：通道语义、轴序、物理尺寸
    # 惰性读取：只取需要的通道（示例：DAPI=0, PanCK=1, CD45=2）
    dapi  = tif.pages[0].asarray()  # 单页读入，避免整立方体 OOM

# 解析 OME XML 确认通道 → 标志物映射（伪代码框架）
# channel_names = parse_ome_channels(ome)
# assert "DAPI" in channel_names, "先确认轴序与通道命名再取数"

工作流建议：探索期用门户 Vitessce 在线确认通道语义与质量，再下载做本地分割与表型；分割用官方产物或社区模型（如 Mesmer 类核-细胞分割），表型聚类后按标志物组合命名细胞类型，最后映射到 CL 本体与 OMAP 面板定义对齐。

§6.7 空间注册与 HRA 对齐

把自己的组织数据对齐进 Human Reference Atlas 的最短路径：

在 RUI（Registration User Interface）中为样本选择 3D 参考器官并标注取采位置，导出 rui_location JSON；
用 CCF API 或 HRA SPARQL 查询该位置的解剖语义（落在哪个分区、邻近哪些结构）；
细胞类型注释经 ASCT+B 表映射到 HRA 术语体系；
用 EUI（Exploration User Interface）在 3D 人体上查看注册结果与细胞类型分布。

import requests

# 查询 CCF API 获取 HRA 参考信息（端点以 humanatlas.io 文档为准）
def query_ccf(rui_location_json: dict) -> dict:
    """将 RUI 注册 JSON 提交至 CCF API，返回解剖语义与空间关系"""
    r = requests.post(
        "https://ccf-api.hubmapconsortium.org/v1/rui-location-to-jsonld",
        json=rui_location_json, timeout=60,
    )
    r.raise_for_status()
    return r.json()

对齐的价值在复利：注册一次，你的数据即可被 EUI 检索、与全联盟数据做空间邻接分析、并自然获得跨研究可比的解剖语义。

§6.8 评估指标速查

import numpy as np
from sklearn.metrics import f1_score, adjusted_rand_score

def cell_type_metrics(y_true, y_pred, labels):
    """细胞类型注释：macro-F1 为主（类别不均衡敏感）"""
    return {
        "macro_f1": f1_score(y_true, y_pred, labels=labels, average="macro",
                             zero_division=0),
        "per_class_f1": f1_score(y_true, y_pred, labels=labels, average=None,
                                 zero_division=0).tolist(),
    }

def dice_coef(pred_mask, true_mask):
    """分割（细胞核/FTU）：Dice 系数"""
    inter = np.logical_and(pred_mask, true_mask).sum()
    return 2.0 * inter / (pred_mask.sum() + true_mask.sum() + 1e-9)

def spatial_clustering_ari(labels_ref, labels_pred):
    """空间邻域/微环境聚类一致性：ARI"""
    return adjusted_rand_score(labels_ref, labels_pred)

指标选择原则：注释任务看 macro-F1（细胞类型长尾分布，accuracy 会骗人）；分割看 Dice 与边界 F 值；空间聚类看 ARI/LISI 并按器官分层报告；跨模态任务补报按捐献者分组的稳定性（同一模型跨捐献者方差）。

§6.9 用 Azimuth 做细胞类型注释迁移

Azimuth 是 Satija 团队维护的开源参考映射工具（R/Shiny，基于 Seurat 的集成映射算法），内置多个以 HuBMAP/KPMP 等联盟数据构建的器官级参考图谱。它把"我的新数据里是什么细胞"转化为"我的数据映射到官方参考的哪个位置"，输出对齐 Cell Ontology 的层级注释与映射置信度——这是把自建数据接入官方注释体系的最低成本通道，也是 §5.2 注释标签获取路径的推荐实现。

# R 环境：install.packages("Azimuth")；可用参考列表见 azimuth.satijalab.org
library(Azimuth)

# 1) 载入查询数据（Seurat 对象；AnnData 可经 SeuratDisk 先行转换）
obj <- readRDS("my_query_object.rds")

# 2) 一行完成参考映射（以肾脏参考为例）
obj <- RunAzimuth(obj, reference = "kidney")

# 3) 取回映射结果：层级注释 l1/l2 + 置信度得分
head(obj@meta.data[, c("predicted.celltype.l1",
                       "predicted.celltype.l1.score",
                       "predicted.celltype.l2")])

三条使用纪律：置信度得分必须随注释一起报告——低分细胞往往是参考未覆盖的细胞状态，强行采纳会制造错误标签；跨物种或跨测定的强行映射不在工具设计范围内；映射输出的 l2 标签并入自有标签体系时，仍需经 §4.5 的本体 ID 对齐，不要字符串拼接。

§6.10 用 squidpy 做空间邻域分析

squidpy 是 scanpy 生态的空间组学标准库，直接读取 AnnData（空间坐标在 obsm["spatial"]），可在 HuBMAP 空间数据上完成邻域图构建、邻域富集与配体-受体交互分析：

import anndata as ad
import squidpy as sq

# 以 Visium 类数据为例（坐标在 obsm["spatial"]）
adata = ad.read_h5ad("HBM789.GHI.012_Visium.h5ad")

# 1) 构建空间邻域图：网格数据用 coord_type="grid"（环形邻接）
#    像素坐标的单细胞表（CODEX/MIBI）用 coord_type="generic" + n_neighs
sq.gr.spatial_neighbors(adata, coord_type="grid", n_rings=1)

# 2) 细胞类型/组织域的邻域富集：谁喜欢挨着谁
sq.gr.nhood_enrichment(adata, cluster_key="cell_type")
sq.pl.nhood_enrichment(adata, cluster_key="cell_type")

# 3) 配体-受体交互分析（表达矩阵 + 配受体数据库）
sq.gr.ligrec(
    adata, n_perms=100,
    cluster_key="cell_type",
    interactions_params={"resources": "CellPhoneDB"},
)

与 HuBMAP 结合的两个注意点：邻域统计对样本敏感，务必按样本/捐献者分别建图后再汇总，禁止把多个捐献者的坐标拼进同一张邻域图（三套坐标系统互不相通——坑点 5）；邻域富集结果解读时对照 §2.3 的 FTU 概念——隐窝-绒毛轴、肾单位这类重复结构会让"邻接偏好"呈现强规律，这是结构信号而非统计偶然。

§7 质量评估与局限性

§7.1 偏倚与缓解措施

偏倚类别	具体表现	缓解措施
队列选择偏倚	捐献者经器官捐献/手术管道采购，年龄、性别、BMI、 ancestry 分布不均	用捐献者元数据分层分析；明确报告队列口径
器官与测定覆盖不均	热门器官（肾、肠）×热门技术过采样，冷门组合数据稀薄	分析前绘制器官×测定覆盖矩阵；结论限定在覆盖充足的组合
批次与实验室效应	60+ 机构、多 TMC、多批测定	官方标准化管线 + 下游 Harmony/scVI 校正；保留批次协变量
取材环境差异	缺血时间、固定方式、运输条件影响组织质量	记录在元数据；作为协变量纳入
注释粒度不一致	不同 TMC/技术的细胞注释粒度与命名有差异	经 ASCT+B/CL 本体归并后再合并
"健康"定义的筛查性	无体检级筛查，可能携带未诊断早期病变	敏感性分析：剔除极端捐献者后重跑核心结论

§7.2 官方质量控制体系

HuBMAP 的 QC 是双层的：管线内自动 QC（CEDAR schema 校验、测定级指标阈值、分割质量检查）与人工复核（TMC 提交时与发布前）。QC 指标随数据集元数据公开，用户可在复现前自行评估质量分布。相比之下，散装文献数据集普遍缺失的是"QC 过程可审计"这一环——HuBMAP 的管线与 QC 全部开源，这是其可信度主张的实质支撑。

§7.3 数据隐私与伦理框架

捐献者数据经 DUA（2020-02-03 版）约束的脱敏处理：直接标识符移除，临床元数据以 UMLS CUI/SNOMED 编码；使用者承诺不尝试再识别捐献者及家属。极小部分敏感数据走 NIH GDS 政策下的受控通道（dbGaP + DAC 审批）。对 AI 研究者，这套框架意味着：开放数据可自由分发与建模（CC BY 4.0 要求署名），但禁止任何再识别尝试；发表涉及受控子集的成果须遵守相应 DAAC 条款。

§7.4 已知局限清单

无官方 ML 划分：任何监督任务需自建 donor 级划分（§5.1）；
覆盖不均：器官 × 测定矩阵存在大片空白，"全器官全模态"叙事不成立；
体量门槛：多重成像与 3D 数据 TB 级，个人工作站难承载原始数据；
滚动发布无版本快照：跨时间复现需自行记录数据获取日期与清单；
健康队列的先天边界：不支持疾病进展类问题，疾病侧需外联数据；
EPIC 与官方产物并存：同一原始数据的多版本需要谨慎对账。

§7.5 公平性评估建议

公平性检查三步：按捐献者元数据（年龄、性别、死因类别）分层重训模型，比较亚组性能方差；检查细胞类型注释质量在各亚组上的 macro-F1 差异；对"正常基线"类应用，检验基线统计量是否被人口学变量系统性漂移。HuBMAP 公开了全部捐献者元数据（脱敏后），使得这类检查可以直接落地——这是许多临床数据集做不到的。

§7.6 与疾病数据集的互补关系

疾病方向	互补数据来源	联合设计
肾脏疾病	KPMP	健康（HuBMAP）vs 病变（KPMP）配对空间图谱
肿瘤微环境	HTAN、TCGA	癌旁正常对照 + 肿瘤样本空间比对
全身表达参考	GTEx	单细胞空间层（HuBMAP）× bulk eQTL 层（GTEx）
细胞图谱互校	HCA 生态	注释体系与参考图谱交叉验证
细胞衰老	SenNet	共享工具栈下的跨联盟扩展

§7.7 DAIMS 24 项数据就绪度评估

#	检查项	状态	说明
1	数据为宽格式（每行一个样本/事件）	✅	AnnData 矩阵、影像立方体、元数据表均结构化
2	有唯一标识符列	✅	HuBMAP ID / UUID / DOI 三件套一一对应
3	无 Unicode 或特殊字符	⚠️	元数据标准化良好；厂商原始格式与自由文本字段存在差异
4	无重复行	✅	管线去重 + 发布前 QC；合并 EPIC 时按 Dataset ID 对账
5	缺失值已识别并编码	✅	CEDAR 校验 + QC 指标随元数据公开
6	标签列被明确标识	✅	细胞类型注释列对齐 Cell Ontology
7	已对罕见类别（<3%）进行分组	⚠️	注释粒度跨 TMC 不一致，长尾细胞类型需本体归并
8	偏倚评估已完成	✅	§7.1 六类偏倚与缓解措施
9	有完整的数据字典	✅	门户文档 + Ontology API + ASCT+B 表
10	对"信息性缺失"有明确编码解释	⚠️	取材与批次信息有记录但非结构化字段
11	数据采集设备和设置已记录	✅	protocols.io 公开协议 + 抗体验证报告（OMAP）
12	已移除完全共线性变量	❌	保留全部原始测定，未做特征选择（图谱定位使然）
13	对编码的映射标准已说明	✅	Uberon / CL / HGNC / UMLS CUI 全挂接
14	对时间戳的处理已明确说明	✅	W3C PROV 全程 provenance 记录
15	训练/验证/测试划分建议已给出	❌	无官方划分；需按捐献者分组自建（§5.1）
16	数据泄漏风险已被讨论	✅	§5.3 四种特有泄漏模式
17	标签分布已被分析	✅	集成地图与细胞类型丰度统计公开
18	选择性测量偏倚已被讨论	⚠️	器官×测定覆盖不均有文档，但量化分析需自行完成
19	外部验证建议已给出	✅	§5.5 三级验证路径与 §7.6 互补矩阵
20	数据更新和版本信息已记录	✅	滚动发布 + 每数据集 DOI + release notes
21	最小必要预处理脚本已提供	✅	官方管线全开源 + Workspaces 模板 + Azimuth
22	合规使用要求已明确	✅	CC BY 4.0 + DUA + dbGaP 双轨清晰
23	多模态对齐方法已说明	✅	RUI/CCF 空间注册 + ASCT+B 本体对齐（联盟核心能力）
24	去标识化方法已被记录	✅	DUA 脱敏框架 + UMLS 编码 + dbGaP 受控通道

DAIMS 评分：19.5 / 24

评分解读：优秀——FAIR 基建、本体对齐与合规框架在同类数据集中处于第一梯队；扣分集中于"图谱定位带来的先天项"（无 ML 划分、保留原始变量）而非工程缺陷。

对你意味着什么：HuBMAP 的 17 个 ✅ 项里，标识符体系、provenance、本体对齐与合规四项做到了教科书级——跨联盟数据对齐（第 23 项）甚至是多数临床数据集不设分的独家能力。两个 ❌（无划分、未去共线性）不是疏漏而是定位：它是图谱基础设施，不是监督基准。使用策略因此明确——把 DAIMS 表当作"建库检查单"用，把你自己的任务管线（划分、特征工程、标签归并）叠加在它之上，而不是期待它替你完成监督学习的最后一步。

§7.8 外部验证矩阵

外部数据集/场景	来源	评估任务	关键发现
KPMP 病变肾脏	华盛顿大学等	健康-病变细胞状态对照	2023 年 Nature 肾脏图谱联合 45 健康 + 48 病变肾脏，定义 51 种细胞类型在健康与损伤下的状态变化
HPA 影像	人类蛋白图谱	多重免疫荧光跨库泛化	抗体面板与成像协议差异是主要泛化障碍，OMAP 标准即为弥合而生
Kaggle FTU 竞赛	60 国 1,200 队	FTU 分割泛化	冠军算法 Tom 在独立肾/结肠数据上保持领先，验证了联盟数据可支撑竞赛级基准
HRA 跨联盟注册	25+ 联盟	空间注册与语义对齐	RUI/EUI 已成为跨联盟（含 SenNet、GTEx 数据映射）的事实标准

HuBMAP 在 2026 年还值得用吗？ 值得，而且正处黄金窗口。健康人体空间图谱没有竞品替代；HRA 工具链已被后续联盟继承为基础设施；全部数据 CC BY 4.0 意味着商用与教学零门槛。需要警惕的只有两件事：把"健康基线"当"临床正常"的越界使用，以及不做 donor 级划分的天真建模。

§8 基准性能与生态

§8.1 里程碑成果速览

HuBMAP 不设传统 ML 排行榜，其"基准"以里程碑成果形式存在：

成果	发表	意义
奠基框架	Nature 2019（574:187-192）	确立健康人体单细胞空间图谱的总纲领与联盟结构
肠道单细胞图谱	Nature 2023（Snyder 团队）	9 名捐献者 8 个肠段，发现新上皮细胞亚型与免疫"社区"
肾脏健康-损伤图谱	Nature 2023（Jain 团队，联合 KPMP）	51 种细胞类型的健康/病变空间状态，45+48 肾脏
母胎界面时空图谱	Nature 2023（Angelo 团队）	约 50 万细胞、近 600 条动脉的妊娠时空动态
HRA 系统	Nature Methods 2025（22:845-860）	4,499 解剖结构/1,195 细胞类型/2,089 生物标志物的图谱框架
门户系统	arXiv 2025（2511.05708）	5,032 数据集的 FAIR 化门户工程全记录

§8.2 工具生态矩阵

工具	维护方	用途	入口形态
Vitessce	哈佛 Gehlenborg 团队	多模态空间数据在线可视化	浏览器 / 嵌入组件
Azimuth	Satija 团队（NYGC）	细胞类型注释参考图谱	网页 / R 包
RUI	Indiana 大学主导	组织取样位置 3D 注册	网页应用 / API
EUI	Indiana 大学主导	空间语义数据探索	网页应用 / API
CDE	Indiana 大学主导	细胞距离分布计算	网页应用
FUSION	联盟团队	WSI 功能单元状态导航	网页应用
Workspaces	门户原生	浏览器内 JupyterLab 分析（15+ 模板、GPU）	网页
Integrated Maps	门户原生	按"测定 × 组织"聚合的整合数据	直接下载

§8.3 开源代码与协议

全部管线、API 与工具代码开源在 HuBMAP GitHub 组织（hubmapconsortium）下，主体许可证为 MIT 或 GPL v3；API 文档注册于 SmartAPI。全部实验协议公开于 protocols.io（含 CODEX、成像质谱、各器官取材协议）；多重成像配套抗体验证报告（OMAP 标准，Nature Methods 2023），覆盖 60+ 靶标的社区验证面板。对复现者，"协议 + 抗体 + 管线 + 数据"四件套齐备是 HuBMAP 复现性主张的完整闭环。

§8.4 社区与教学资源

Visible Human MOOC：Indiana 大学制作的公开课，系统讲授 HRA 目标、数据与工具，适合新手入门；
Kaggle FTU 竞赛遗产：竞赛数据、获胜方案与评测框架公开，可作为分割任务的起点；
Helpdesk：portal 支持工单与外部 API 批量访问报备的正式通道；
邮件列表与发布说明：滚动发布动态的官方渠道。

§8.5 与兄弟联盟的关系

HuBMAP 是 NIH "体细胞图谱"投资组合的旗舰：与 HCA（Human Cell Atlas）在细胞本体与参考图谱上深度互操作；向 SenNet（细胞衰老图谱）移交工具栈与 HRA 经验；与 KPMP 在肾脏方向形成健康-疾病配对；与 HTAN（肿瘤图谱）构成"正常 vs 肿瘤"的两极。HRA 则独立成长为跨联盟基础设施（25+ 联盟参与），其本体、3D 参考对象库与 RUI/EUI 已是事实标准。

§8.6 引用规范

官方要求：使用 HuBMAP 数据发表时，引用奠基论文（HuBMAP Consortium, Nature 574:187-192, 2019, DOI: 10.1038/s41586-019-1629-x），并加注致谢语 “The results here are in whole or part based upon data generated by the NIH Human BioMolecular Atlas Program (HuBMAP)”。引用具体数据集时加引其数据集 DOI。这是 CC BY 4.0 署名要求与联盟学术规范的合并条款。

§8.7 2023 年 Nature 三篇器官图谱深读

2023-07-19 的三篇封面论文是 HuBMAP"从基础设施到生物学发现"的转折点，也是使用数据时最值得精读的方法学示范：

论文	队列设计	技术组合	对 AI 使用者的意义
肠道图谱（Snyder 团队）	9 名捐献者 × 8 个肠段	单细胞测序 + 空间转录组	"多捐献者 × 多分区"采样矩阵的设计范本；新上皮细胞亚型的发现与验证流程可复用
肾脏图谱（Jain 团队，联合 KPMP）	45 健康 + 48 病变肾脏	单核测序 + 空间测定	健康与疾病队列联合分析的标准范式——§7.6 互补关系的实践样板
母胎界面时空图谱（Angelo 团队）	约 50 万细胞、近 600 条动脉	多重成像为主	大规模多重成像如何组织成时空叙事；微环境表型聚类的上限演示

三篇论文共同演示了 HuBMAP 数据的正确打开方式：以健康队列定义"正常"的细胞状态与空间组织，再在疾病或妊娠等扰动下追踪这些状态的变化。对肿瘤空间组学研究者，肾脏篇的"健康-病变"配对设计几乎可以平移为"癌旁-肿瘤"设计；对方法论研究者，三篇论文的补充材料本身就是器官级多模态数据组织的教学案例。同日另有 6 篇配套论文发表于 Cell 与 Nature 子刊，覆盖方法与工具侧面，宜与主文并读。

§9 相关资源与引用

§9.1 官方资源入口

资源	URL
数据门户（浏览/下载/工作区）	https://portal.hubmapconsortium.org/
联盟官网（新闻/出版物）	https://hubmapconsortium.org/
官方文档（政策/FAQ/API）	https://docs.hubmapconsortium.org/
API 文档	https://docs.hubmapconsortium.org/apis
Human Reference Atlas	https://humanatlas.io/
GitHub 组织	https://github.com/hubmapconsortium
NIH Common Fund 项目页	https://commonfund.nih.gov/hubmap
实验协议	https://www.protocols.io/（搜索 HuBMAP 空间）

§9.2 核心论文列表

HuBMAP Consortium. “The human body at cellular resolution: the NIH Human Biomolecular Atlas Program.” Nature 574(7777): 187-192 (2019). DOI: 10.1038/s41586-019-1629-x —— 奠基论文，官方指定引用。
Börner K, et al. “Human BioMolecular Atlas Program (HuBMAP): 3D Human Reference Atlas construction and usage.” Nature Methods 22(4): 845-860 (2025). DOI: 10.1038/s41592-024-02563-5 —— HRA/CCF 系统论文。
Turner ML, et al. “HuBMAP Data Portal: A Resource for Multi-Modal Spatial and Single-Cell Data of Healthy Human Tissues.” arXiv:2511.05708 (2025) —— 门户系统论文，本文规模数字主源。
Jain S, et al. “Advances and prospects for the Human BioMolecular Atlas Program (HuBMAP).” Nature Cell Biology 25: 1089-1100 (2023). DOI: 10.1038/s41556-023-01194-w —— 中期进展综述。
Hickey JW, et al. “Organization of the human intestine at single-cell resolution.” Nature (2023) —— 肠道参考图谱。
Lake BB, et al. / Jain S 团队. “An atlas of healthy and injured cell states and niches in the human kidney.” Nature (2023) —— 肾脏参考图谱。
Angelo M 团队. “A spatially resolved timeline of the human maternal–fetal interface.” Nature (2023) —— 母胎界面时空图谱。
Quardokus EM, et al. “Organ Mapping Antibody Panels (OMAPs): A community resource for standardized multiplexed tissue imaging.” Nature Methods (2023) —— 多重成像抗体面板社区标准。
Jain Y, et al. “Segmentation of human functional tissue units in support of a Human Reference Atlas.” Communications Biology (2023) —— FTU 分割与 Kaggle 竞赛。

§9.3 引用本页面的推荐格式

千方病案医数集. HuBMAP — 人体生物分子图谱计划 AI-Ready Wikipedia.
https://www.qianfanghub.com/ai-ready-dataset/hubmap/517 （审核日期 2026-09-05）

使用 HuBMAP 数据本身时，请按 §8.6 的官方规范引用 Nature 2019 奠基论文与相应数据集 DOI。

§9.4 快速上手清单

浏览门户确认目标器官与测定组合的覆盖（§3.2）；
用 Search API 拉取 Published 数据集清单并落盘（§6.1，绑定查询日期）；
按 donor 级划分设计实验（§5.1，防泄漏）；
下载处理后数据（Globus，§6.3），先跑通再拉原始；
注释对齐走本体 ID（§4.5），空间对齐走 RUI/CCF（§6.7）；
发表时引用 Nature 2019 + 数据集 DOI + 致谢语（§8.6）。

§9.5 高频问题速答

Q1：商用或教学使用要授权吗？ 已发布数据为 CC BY 4.0，商用与教学均可行，唯一义务是署名（§8.6 的致谢语 + 奠基论文引用）；受控数据子集除外（需 NIH DAC 审批）。

Q2：下载需要注册账号吗？ 浏览门户、下载已发布数据、使用 REST API 均无需注册；云工作区有免注册额度，共享功能需登录。

Q3：里面有癌症数据吗？ 没有。队列刻意保持健康成人边界，肿瘤研究需搭配 HTAN/TCGA 等疾病侧资源（§7.6），HuBMAP 提供癌旁与正常组织对照臂。

Q4：官方有 train/test 划分吗？ 没有。必须按捐献者分组自建划分，并警惕切片相邻性、管线、EPIC 重复三种特有泄漏（§5.1、§5.3）。

Q5：规模数字为什么各处不一样？ 滚动发布 + 口径差异（门户首页宣传口径 vs 门户论文 5,032 口径），引用时强制绑定"数值 + 截至日期 + 口径来源"三元组（坑点 1）。

Q6：数据太大下载不动怎么办？ 先下处理后数据（AnnData/OME-TIFF）验证可行性，原始与 TB 级数据走 Globus 断点续传，或直接用浏览器内云工作区（§3.0、§6.3）。

§10 AI 使用声明卡

§10.1 AI 模型使用

AI 模型	版本	用途
fast-model（CodeBuddy）	2026-09	初稿生成：INFOBOX 数据汇编、§1-§9 结构化写作、§6 代码示例生成、JSON-LD 构建
WebSearch（多源检索）	2026-09-17	5 组检索：官方门户与 NIH 资助背景、Nature 2019 奠基论文、TMC 联盟构成与 Nature 2023 成果、HRA/CCF 体系、数据规模口径与 API/GitHub 坑点

§10.2 AI 参与范围

AI 参与范围：初稿生成 + 资料整理 + 代码生成 + 格式化排版。

AI 在本页面的工作中负责：(1) 从 HuBMAP 门户、官方文档、NIH Common Fund 页面、Nature/Nature Methods 论文与 arXiv 门户论文中整理结构化信息；(2) 生成 §6 的 Python/Bash 代码示例；(3) 系统化组织 §6.5 的 8 个坑点与 §7.1 偏倚表；(4) 执行 G1/G2/G3 排版规范检查与中英文格式标准化；(5) 构建 §C 统一 JSON-LD @graph。

§10.3 输入来源

HuBMAP Data Portal（portal.hubmapconsortium.org）首页与数据浏览界面（截至 2025-10 规模口径）
Turner et al., “HuBMAP Data Portal” (arXiv:2511.05708, 2025-11-07) —— 5,032 数据集 / 310 捐献者 / 22 数据类型 / 27 器官大类主源
HuBMAP Consortium, Nature 574:187-192 (2019), DOI: 10.1038/s41586-019-1629-x —— 奠基论文
Börner et al., Nature Methods 22:845-860 (2025), DOI: 10.1038/s41592-024-02563-5 —— HRA v2.0 数字与工具体系
Jain et al., Nature Cell Biology 25:1089-1100 (2023), DOI: 10.1038/s41556-023-01194-w —— 进展综述
NIH Common Fund HuBMAP 页面与首次数据发布新闻稿（7 器官、300+ 数据集）
NIH Research Matters：2023 年三器官图谱报道（肾脏 45+48、51 细胞类型；胎盘 50 万细胞）
hubmapconsortium.org/featured-publications（TMC/TTD/RTI 构成、OMAP、Kaggle FTU 竞赛）
docs.hubmapconsortium.org/about（引用规范、团队分工、DUA 与 dbGaP 政策）
docs.hubmapconsortium.org/apis（五大 API、Globus、标识符三件套）
docs.hubmapconsortium.org/faq（许可证条款、本体编码、API 访问政策）
portal 首页 Data Use Guidelines（CC BY 4.0 原文条款）
github.com/hubmapconsortium/entity-api issues（502/504、状态变更、Retracted 支持计划）
BIH 讲座资料（RUI/EUI/CDE、VHMOOC、25+ 联盟协作）

§10.4 人工校验表

内容模块	审核者	审核方式	审核状态
§2 医学背景（FTU、本体体系、SNOMED 概念）	千方病案医学编辑部	交叉审核	✅ 已通过
§3 数据集规格（规模口径、数据类型矩阵）	千方病案医学编辑部	与门户论文 arXiv:2511.05708 交叉比对	✅ 已验证
§4 数据结构（实体层级、标识符、格式）	千方病案医学编辑部	与 docs.hubmapconsortium.org 交叉比对	✅ 已验证
§5 数据划分策略	千方病案医学编辑部	交叉审核	✅ 已通过
§6 代码示例与坑点	千方病案医学编辑部	逻辑审查 + 与官方 API 文档比对	✅ 已通过
§7 质量评估与 DAIMS 评分	千方病案医学编辑部	交叉审核	✅ 已通过
§8 里程碑成果与引用规范	千方病案医学编辑部	与原文及官方致谢语比对	✅ 已验证
§C JSON-LD @graph	千方病案医学编辑部	Schema v3.9 字段逐项校验	✅ 已通过

§10.5 AI 生成章节标注

以下章节由 AI 生成初稿并经人工审核：§1.0 30 秒速览、§1.6 读者路线图、§2.6 四大测定版图、§3.0 获取渠道抉择矩阵、§3.6 器官覆盖分层、§4.7 Provenance/EPIC 深读、§5.6 实验设计模板、§6.0-§6.4 与 §6.6-§6.10 代码示例、§6.5 八个坑点、§7.5 公平性评估建议、§7.7 DAIMS 评估表与评分、§8.2 工具生态矩阵、§8.7 Nature 2023 深读、§9.5 高频问题速答、§C JSON-LD。

§10.6 最后审核

最后一次人工审核日期：2026-09-05

页面状态：published（全部内容已完成审核并发布）