☰
TCGA数据库使用教程:从数据分层到下载与分析全流程
2026/10/21 19:00:19 网站建设 项目流程

简介:癌症基因组图谱(TCGA)数据库使用教程以PDF格式发布,面向肿瘤学研究人员、生物信息学初学者及医学大数据分析爱好者。教程系统讲解TCGA的数据层级结构,包括病例、样本、样本类型与分子数据的组织关系,并演示基因突变(单核苷酸变异、插入缺失)的检索方法,以及肿瘤与正常组织间差异表达基因的分析流程。教程还延伸到拷贝数变异、甲基化、蛋白磷酸化等多组学数据的整合利用,并介绍如何通过GDC数据门户高级搜索、条件筛选和批量下载数据,便于用户按需获取特定癌种样本信息。压缩包内为1份PDF文档,大小12.75MB,已有1150人浏览学习。读者学完后可快速上手TCGA数据挖掘,为探索癌症驱动机制、寻找潜在药物靶点及生物标志物打下基础。

1. TCGA数据库使用教程:为什么我觉得数据分层比检索语法更值得先看

第一次接触 TCGA 数据库,打开 GDC 数据门户,你不会先去数滤条件,而是被各种 Case、Sample、File 的名称震得不敢点下一步。等到真正想下载某个癌种的全部 RNA-seq 数据时,才发现页面选出的文件要么包含不该有的样本类型,要么数量远远超过预期。这份 TCGA 使用教程没有从按钮介绍入手,而是把病例、样本、分子数据的层级关系和不同访问工具放在一起拆解,适合需要自己完成数据获取、又要保证后续分析可复现的研究生和分析人员。跟着走完一遍,你会知道某个基因的突变频率该去哪一页查、counts 文件和 MAF 文件分别是什么概念、以及什么时候该用命令行而不是浏览器。

2. TCGA数据结构与访问方式:先分清Cases和Samples,再决定用哪个工具

2.1 病例、样本、分子数据的层级关系与条码拆解

TCGA 数据不是平铺的一堆文件,而是按 Project、Case、Sample、Molecular Data 四个层级组织。Project 是一个癌种研究项目,比如肺腺癌项目、乳腺癌项目;Case 是入组患者编号,一般是一个患者一个;Sample 是一个 Case 下的具体组织标本,同一个患者可能同时提供肿瘤组织(01 类型)和癌旁正常组织(11 类型);Molecular Data 才是挂在这些样本上的测序文件、突变注释文件或甲基化谱。

这种层级关系在你做样本量统计时特别容易踩坑。举个例子,某个 Case 的条码 TCGA-56-7582-01A-01R-1234-07,前四位 TCGA 是项目前缀,56 是组织来源机构代码、7582 是患者序号,第 5-6 位的 01 表示样本类型(原发性实体瘤),之后是 vial、portion、分析物和测序中心编号。如果同一位患者还提供了正常组织,会得到 TCGA-56-7582-11A 开头的条码。也就是说,01 和 11 的区别只体现在条码的中间两位,而不是整个病例序号不同。

实际操作里,把 01 和 11 当成两个独立患者的错误并不少见。尤其是用临床表格直接和表达矩阵做合并时,如果只用前 7 位或 8 位去对接 case,就会把同一个人的肿瘤和正常样本冲掉;反过来,如果用 15 位全条码去连临床数据,又可能因为版本差异导致匹配失败。我的做法是先在数据准备阶段把样本条码分层做好:保留 15 位完整条码作为唯一索引,再派生出 sample_type(取第 5、6 位)和 case_id(取前 12 位)两个辅助列,后续所有合并都在这个基础上做。

不同样本类型代码的使用场景差异很大,我把最高频的几种整理成了参考表:

样本代码英文名中文含义常见分析用途
01Primary Solid Tumor原发实体肿瘤肿瘤组的默认选择
02Recurrent Solid Tumor复发实体瘤复发机制研究
06Metastatic转移灶转移相关分析
10Blood Derived Normal血液来源正常对照生殖系变异对照
11Solid Tissue Normal癌旁正常组织配对正常对照

GDC 的数据分类体系还有一个容易忽略的点:文件在门户中被划分为 Data Category、Data Type、Experimental Strategy、Workflow Type 四级。同样是基因表达定量,STAR - Counts 与 STAR - FPKM 在 Workflow Type 上就不同,前者是 counts 值,适合做差异表达;后者是长度标准化后的相对表达量,适合看基因之间的表达高低。如果你下载时没有注意 Workflow Type,后面选择算法的空间会被大幅压缩。

2.2 网页端、gdc-client、R包:三种访问通道的边界与选型

访问 TCGA 数据至少有三种通道:网页端、命令行工具、R 包。网页端的正式名称是 GDC Data Portal,适合做探索式筛选,比如“某个癌种有多少 RNA-seq 样本”“某基因在多少例样本里发生了非沉默突变”。它的交互直观,但批量下载时容易断线,受控文件在浏览器里做鉴权也不够稳定;文件一多,页面还会因为渲染慢变得很卡。

第二种是 GDC 官方的数据迁移命令行工具,通常叫 gdc-client。它本身没有检索能力,只负责按 manifest 清单下载。它的拿手活是批量文件获取,支持断点续传和多线程下载,下载几百个 TSV 或 BAM 时比浏览器稳定得多。代价是你要先把 manifest 准备好,而且受控文件必须额外传 token 做鉴权。

第三种是 R 包,比如 TCGAbiolinks。它把查询、下载、读取到 R 对象封装成一条流水线,查询语法与网页端 Filter 一一对应,输出结果可以无缝接入 DESeq2、edgeR、survival 等包做后续分析。如果想做多组学联合分析,比如同时拿表达、突变、临床生存数据,它的效率最高。缺点是依赖环境配置成本较高,初次使用容易卡在安装环节。

选型没有绝对标准。我个人的分界线是:只要样本清单超过 50 个文件,就优先考虑 gdc-client;如果拿完数据后还要做差异分析或画生存曲线,再叠加 R 包处理。网页端更多是前期侦察用途,不建议用它批量下载大文件。三者的适用场景可以这样理解:

访问通道适合场景主要限制
GDC Data Portal探索式筛选、查看样本量、零星下载大批量下载易断线
gdc-client批量下载、断点续传、自动化脚本需要先准备manifest
TCGAbiolinks查询+下载+读取一体化、多组学分析需要R环境和依赖包

注意 GDC 各通道使用的文件标识统一是 file UUID,网页端看到的文件 ID 与 manifest 中的 file_id 是同一个值,这保证了你在不同工具之间切换时不会丢失文件映射关系。

3. GDC Data Portal实操:从四个检索维度到manifest清单的完整操作

3.1 四个核心检索维度与筛选顺序

在 GDC Data Portal 里筛选数据,本质上是对四类实体做布尔过滤:Project、Case、Sample、File。很多人一进 Repository 就顺手在左栏的 Facet 里点了一堆条件,最后下载到的文件却和自己设想的完全不一致,原因在于没有理顺 Filter 的作用顺序。以“获取某癌种的肿瘤与癌旁 RNA 表达数据”这个需求为例,我一般按以下顺序操作:

第一,在 Cases 页面选择 Project 为指定癌种项目,比如 TCGA-LUAD;第二,再叠加 Sample Type 为该癌种对应可用样本类型,泛癌分析时通常选 Primary Tumor 和 Solid Tissue Normal 这两个;第三,切到 Files 页面,设定 Data Category=Transcriptome Profiling、Data Type=Gene Expression Quantification、Workflow Type=STAR - Counts;第四,检查 Files 页面统计的病例数和文件数是否符合预期,再决定加入 Cart。

这个顺序能最大程度避免筛选条件之间的“或/与”歧义。Repository 页面里的 Project 和 Primary Site 两个维度是交集关系,如果你同时选了某个项目又顺手选了一个解剖部位,筛选结果就可能混入同一部位但不同项目的数据,而且页面不会提醒你。让我再强调一次:Cases 用来固定患者集合,Files 用来固定数据类型,Sample 类型夹在中间用来控制样本来源,三者不要混着乱搭。

3.2 把Case加入Cart并生成manifest的完整操作

筛选条件设置完毕后,问题就变成“怎么把选中的病例和文件变成可下载的清单”。GDC 的 Cart 概念我不建议跳过:它相当于是购物车,但里面装的不是病例而是文件。你在 Cases 页面勾选病例后点 Add all cases to cart,系统会自动把这些病例下满足当前筛选条件的文件加入 Cart;随后可以在 Cart 页面按类型查看文件清单,并检查文件数量是否符合预期。

一个常见困惑是 Cases 数与 Files 数明显不对等。这是正常的,原因之一是一个 Case 不一定同时拥有你筛选的所有数据类型,比如某些早期入组患者只做了 WES 突变检测,没有 RNA 测序,那么在表达数据筛选下该 Case 不会有对应文件;原因之二是某些样本被分类为受控访问后被排除在可见范围之外。只要 Files 数与 Cases 数的差异能用这两个逻辑解释,就不需要额外补救。

提示:在 Repository 页面和 Cases 页面之间来回切换时,浏览器不会自动清空已选 Facet。最好先把当前选中的条件截图或记录下来,再切到另一个页面,免得筛选条件互相污染。

确认清单无误后,点击 Cart 页面右上角的 Download Manifest 按钮,得到一份 manifest.txt。文件内容按行组织,包含 file_id、file_name、md5、size 四列。file_id 是 GDC 内部 UUID,也是 gdc-client 下载时真正依据的键。我的习惯是把 manifest 重命名为带日期和癌种的名字,比如 manifest_LUAD_RNA_20240630.txt,保留一份可追溯的下载记录,再连同后续的分析脚本一起归档。

3.3 受控数据鉴权与gdc-client下载参数

TCGA 文件按可见性分成开放数据和受控数据。开放数据可以直接下载;受控数据需要先通过 dbGaP 受控访问授权系统完成项目申请,并在 GDC 网站上生成 token。token 是一段很长的 JWT 文本,相当于身份凭证,下载时必须把它传给 gdc-client。我见过不少人把开放数据下载成功后,误以为所有文件都能直接下,结果碰到受控文件时一直报 401。

我常用的下载命令组合如下:

# 下载开放数据 gdc-client download -m manifest_open.txt -d ./tcga_open # 下载受控数据,需要带token文件 gdc-client download -m manifest_controlled.txt -d ./tcga_protected -t /home/organization/gdc_token.txt # 限制并发数,降低对网络和磁盘的压力 gdc-client download -m manifest_controlled.txt -d ./tcga_protected -t /home/organization/gdc_token.txt -n 4

逻辑说明:-m指定 manifest 路径,-d指定输出目录,-t指定 token 文件路径,-n限制并发下载线程数。GDC 官方默认并发数为 8,但在内网环境或磁盘 IO 有限时,建议降到 4 或 2,减少因资源争抢导致的下载中断。

参数说明:token 文件必须是无多余字符的纯文本,从浏览器复制时注意不要带行尾空格。如果下载出现 401,优先检查 token 是否过期、当前账号在 dbGaP 中是否已通过申请;如果出现 403,说明文件权限确实未授予当前账号,只能联系项目合作者或走重新申请流程。gdc-client 本身只认 manifest 中的 file_id,如果手改清单导致 ID 损坏,下载会直接提示文件不存在,所以不建议在 Excel 里反复编辑 manifest。

如果在下载中途断网,gdc-client 支持断点续传,重新执行同一条命令就能继续拉取未完成的文件;但注意不要把-d指向一个含同名文件的目录,否则它会跳过已有文件,不会自动做覆盖校验。想彻底确认下载完整性,我会在命令执行完后再补一轮 md5 对比,具体脚本放在最后一章。

4. 突变与表达数据读取:MAF和HTSeq文件怎么变成可分析的数据框

4.1 MAF突变文件读取:注意注释行与Variant_Classification过滤

TCGA 突变数据以 MAF 格式存储,全称 Mutation Annotation Format。它本质上是一个 tab 分隔表格,但文件头部通常有几行以 # 开头的注释文本,直接使用pd.read_csv会导致列名错位。读取时带上comment='#'可以跳过这些注释行;再加上压缩格式指示和low_memory参数,就能稳定地把全基因组突变注释读进来。

import pandas as pd # 读取TCGA MAF文件,忽略#注释行 maf = pd.read_csv("TCGA.LUAD.somatic.maf.gz", sep="\t", comment="#", compression="gzip", low_memory=False) # 保留有功能影响的突变类型,用于驱动基因筛选 maf_coding = maf[maf["Variant_Classification"].isin([ "Missense_Mutation", "Nonsense_Mutation", "Frame_Shift_Del", "Frame_Shift_Ins", "In_Frame_Del", "In_Frame_Ins", "Splice_Site" ])].copy() print(maf_coding.shape)

逻辑说明:low_memory=False是为了避免 pandas 按块读取时对大量字符串列做过早类型推断,弹出一堆 dtype 警告后再回退重读,得不偿失。Variant_Classification列说明突变对蛋白编码的影响,Silent 同义突变在肿瘤驱动基因分析中通常不保留,所以先用一个显式列表做过滤。

参数说明:后续如果接入 maftools 画瀑布图,需要保留的列包括Tumor_Sample_Barcode、Hugo_Symbol、Variant_Classification、Variant_Type、Chromosome、Start_Position、End_Position。一行记录并不代表一个突变事件,同一个样本同一个基因可能有多行不同转录本注释,按样本去重统计时要在这些关键列上做 groupby,再决定保留策略。

4.2 HTSeq表达文件读取:__开头的行必须剔除

表达定量文件在 GDC 中常见后缀是 reads.tsv.gz,对应 STAR-Counts 流程输出。文件第一列是 Ensembl 基因 ID,最后一列是 counts 值。与 MAF 一样,这类文件也有“非基因”行:文件末尾存在__alignment_not_unique、__no_feature、__ambiguous等以双下划线开头的行,它们是比对统计的汇总,不是真实基因。

expr = pd.read_csv( "TCGA-56-7582-01A-01R-1234-07.reads.tsv.gz", sep="\t", skiprows=1, index_col=0, compression="gzip" ) # 删除非基因行 expr = expr[~expr.index.str.startswith("__")].copy() print(expr.shape)

逻辑说明:skiprows=1是因为部分 GDC 文件的第二行才是真正的 header,但并不是所有文件都如此。更稳妥的写法是先读前 3 行判断结构:如果第一行只有版本信息,就skiprows=1;如果第一行直接是 Gene 开头,就不要跳行。建议用 Python 的 gzip 模块直接 peek 前三行再决定。

参数说明:做差异表达时,推荐保留原始 counts,后续交给 DESeq2 或 edgeR 做内部归一化,而不是自己转成 TPM 或 FPKM。这背后的考虑是 counts 模型能更合理地处理测序深度差。如果你下载时选的是 STAR - FPKM,文件里数值已经做过长度标准化,就不能直接当 counts 使用。

如果要合并多个样本的表达文件,常见做法是先读取所有文件,再用 pandas 对齐基因索引:

import glob sample_files = glob.glob("TCGA-*.reads.tsv.gz") expr_dict = {} for f in sample_files: sample_id = f.split(".")[0] tmp = pd.read_csv(f, sep="\t", skiprows=1, index_col=0, compression="gzip") tmp = tmp[~tmp.index.str.startswith("__")] expr_dict[sample_id] = tmp.iloc[:, 0] expr_matrix = pd.concat(expr_dict, axis=1) expr_matrix.columns = [s.split("_")[0] for s in expr_matrix.columns]

逻辑说明:sample_id取文件名第一段作为列名,读取时保持相同的过滤逻辑;pd.concat按基因索引对齐,缺失值会以 NaN 呈现,后续统一决定是补零还是剔除。参数说明:合并前先看一眼不同文件的基因数是否一致,如果批次间基因注释版本差异太大,合并后会出现大量缺失行,这时候要考虑使用共同基因子集。

4.3 临床数据与样本条码关联:以case_id为桥梁

临床表格和分子数据表格的关联,是很多人反复试错的一步。MAF 和表达文件里的条码是样本级,例如 TCGA-56-7582-01A;临床表格里的case_submitter_id是病例级,例如 TCGA-56-7582。两个字段长度不同,直接合并会导致大多数行匹配不上。正确做法是先从样本条码中提取 case_id,也就是取前 12 位统一格式,再做关联。

# 从样本条码提取case_id maf["case_id"] = maf["Tumor_Sample_Barcode"].str.slice(0, 12) # 按case_id统计每个病例的突变基因数 mut_count = ( maf.groupby("case_id")["Hugo_Symbol"].nunique() .rename("mutated_genes").reset_index() ) # 与临床表格合并 clin = pd.merge(clinical, mut_count, on="case_id", how="left")

逻辑说明:str.slice(0, 12)对大多数 TCGA 条码有效,但有少数字段在 15 位后还带额外后缀。写这段代码前先观察Tumor_Sample_Barcode的 unique 长度分布,如果出现 16 位或 28 位字符串,需要调整截断长度。临床表格里的分隔符也可能是点号而非横线,合并前先统一字符格式。

参数说明:case_id 只是简化映射,并不等于 GDC 内部的 case UUID。如果遇到两个条码前 12 位相同但实际分属不同病例的极端情况,需要用 GDC 的 API 或 TCGAbiolinks 返回的 case UUID 做校对。不过在大多数 TCGA 数据分析项目里,前 12 位映射已经足够,重点是把这一步放在数据清洗流程最前面,避免后续所有统计都建立在错位关联上。

5. TCGA使用避坑指南:权限、条码、空文件四类高频问题

5.1 查询结果混入其他癌种:Project与Primary Site不能同时乱用

现象:我在 Repository 页面选了某个癌种项目,又顺手勾了一个解剖部位,下载完成后发现文件条码里混入了其他项目样本。

原因:GDC 的 Facet 筛选条件之间按“与”关系叠加。Project 和 Primary Site 是两个独立的维度,同时设置会把结果限缩到两个条件都满足的空间里,而同一解剖部位可能对应多个项目。页面不会提示这种交集导致的样本膨胀,于是文件清单里就出现了非目标项目的数据。

解决:固定病例集合时,只用 Project 这一个维度;Primary Site 只在你不确定项目代码时才用。更稳妥的流程是先在 Cases 页面按项目筛选,再切到 Files 页面按数据类型过滤,两个步骤之间用 Cart 把中间结果固定下来,防止筛选条件互相污染。下载之前再抽查 10 个条码,确认前四位项目代码都一致。

5.2 受控数据下载一直401:token未生效的三种原因

现象:gdc-client 下载受控文件时反复提示 401,浏览器端却能正常打开同一文件。

原因:最常见的是 token 文件传参错误;其次是 token 已经过期或者申请尚未在授权系统里同步完成;再有一种是 token 文本里混入了不可见字符或换行符号,shell 把参数截断后提交了残缺凭证。

解决:在 GDC 官网重新生成 token,保存为纯文本后先执行wc -c确认长度大于 500;下载命令中 token 路径用绝对路径。我一般会先把 token 路径写入环境变量,避免每次手敲出错:

export GDC_TOKEN=/home/organization/gdc_token.txt gdc-client download -m manifest_controlled.txt -d ./tcga_protected -t "$GDC_TOKEN"

逻辑说明:$GDC_TOKEN在 bash 中展开为绝对路径,命令可读性更高。参数说明:如果换了一台机器运行,还要确认 gdc-client 版本与 token 格式兼容,旧版本客户端可能不识别新签发的 JWT,遇到这种情况升级客户端再试。

5.3 样本条码错位:01A与11A被当成两个样本或一个病例

现象:做完配对比较后,绘制分组图时发现某些“正常样本”的表达轮廓和肿瘤样本高度相似,热图里出现了两条异常聚类的分支。

原因:表达矩阵的列名来自样本条码,但条码的第 5、6 位标识样本类型,有人直接把 01A 和 11A 分别当作独立样本,忽略了它们可能属于同一患者;另一类问题是把 01A 与 01B 视为不同样本,实际上 01B 只是同一样本分装后的另一个 vial。

解决:读入任何表达或突变数据后,第一步就拆出 sample_type 列,避免在复杂操作里反复回头检查条码。处理 01A 与 01B 时,按分析目的决定保留策略:做个体层面比较可以取均值,做样本级比较时确保全流程使用同一 vial 的选择规则,并在代码里注释清楚。

# 从条码中提取样本类型:第5、6位 sample_barcode = "TCGA-56-7582-01A-01R-1234-07" sample_type_code = sample_barcode.split("-")[2][:2] print(sample_type_code) # 输出 01,代表肿瘤组织

逻辑说明:这段小代码展示的是条码解析思路,实际应用中应向量化处理整个列的条码。参数说明:样本类型代码在 TCGA 官方元数据里有专门字段sample_type_id,当你不确定条码第 5、6 位含义时,去 Cases 页面查该样本的 Sample Type 字段更可靠。

5.4 下载解压后出现空文件:按权限拆分manifest并做md5校验

现象:下载了 300 个表达文件,解压后发现有几十个 TSV 大小为 0,而网页端确认这些文件存在。

原因:这些空文件基本属于受控访问范围,当前 token 没有权限,服务端只返回了占位结果;也可能是下载中断后文件残留。

解决:按文件权限拆分 manifest,开放数据与受控数据分别下载。下载结束后遍历目录检查每个文件大小,对 0 字节文件单独重下。如果仍然失败,再用 manifest 里的 md5 做完整性校验,定位损坏文件。一个简单循环脚本就能完成这个检查:

# 校验下载文件的md5是否与manifest一致 while IFS=$'\t' read -r id name size md5; do if [ -f "$name" ]; then calc=$(md5sum "$name" | cut -d' ' -f1) if [ "$calc" != "$md5" ]; then echo "$name mismatch" fi else echo "$name missing" fi done < manifest.txt

逻辑说明:IFS=$'\t'让 read 按 tab 切分 manifest 行,分别取出 ID、文件名、大小和 md5。参数说明:GDC 的 manifest 没有表头,第一行就是真实文件记录,所以循环可以直接从第一行开始;如果之前手动编辑过 manifest,最好重新从网页端导出。

6. 进阶技巧:用TCGAbiolinks把查询、下载、读取合并成一段可复现流程

6.1 切到R包前的两个前置条件

如果你已经用前几章的网页端和命令行方式跑完一两个项目,会发现真正耗时间的不是下载,而是“查询什么、下载到哪、怎么读进来”这三件事之间的手工衔接。TCGAbiolinks 把这三步封装成一段连贯代码:GDCquery 负责检索,GDCdownload 负责下载,GDCprepare 负责把文件读成 R 对象。切换到这套流程前,确认 R 版本不低于 4.2,并且能正常安装 BiocManager 和依赖包。

6.2 表达与突变同时查询的代码框架

下面这段代码演示了在同一癌种下同时查询表达和突变数据的基本框架,适合作为后续差异表达或多组学合并的起点:

library(TCGAbiolinks) # 查询某癌种的STAR-Counts表达数据 query_expr <- GDCquery( project = "TCGA-LUAD", data.category = "Transcriptome Profiling", data.type = "Gene Expression Quantification", workflow.type = "STAR - Counts", sample.type = c("Primary Tumor", "Solid Tissue Normal") ) # 查询该癌种的体细胞突变数据 query_mut <- GDCquery( project = "TCGA-LUAD", data.category = "Simple Nucleotide Variation", data.type = "Masked Somatic Mutation", data.format = "MAF" ) GDCdownload(query_expr) GDCdownload(query_mut, token = readLines("/home/organization/gdc_token.txt")) expr_data <- GDCprepare(query_expr) mut_data <- GDCprepare(query_mut)

逻辑说明:sample.type接受字符向量,因此可以同时请求肿瘤和癌旁样本;GDCdownload在包含受控数据时传入 token,readLines读入 token 文本。参数说明:查询结果较大时,先执行nrow(getResults(query_expr))检查返回规模,再决定是否下载。从那以后,我每次接手新的癌种数据,都会先强制走一遍“分层确认-选通道-查权限-验条码”这四步,把数据结构理顺之后再让代码跑起来,返工次数明显少了很多。希望这些 TCGA 数据库的获取流程和踩坑记录能帮到你。

本文还有配套的精品资源,点击获取

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询