NCBI数据下载这件事说大不大说小不小。做生信的人几乎绕不开这个入口不管是做基因组组装、群体重测序还是转录组差异分析第一步往往不是跑软件而是去NCBI把数据拽下来。但NCBI这个拽下来远比想象中麻烦——它是几十个数据库叠加起来的巨型体系数据分散在GenBank、RefSeq、SRA、GEO、Assembly这些库里文件的组织方式、下载协议、更新频率各不相同。我在实际项目里见过太多人卡在这一步要么下载到一半断掉要么下载了好几T才发现文件版本选错了要么一口气并发拉几千个文件被NCBI限流封IP。这篇文章就围绕NCBI数据下载这条主线把这些年操作过的下载思路、具体命令、踩坑记录系统整理一遍。适合刚接触生信的同学参考也适合已经有分析经验但总在数据获取环节浪费时间的人对照检查。内容以实操为主所有命令都是我在Linux服务器上验证过的。1. 把下载当回事NCBI数据规模与选路逻辑1.1 你下载的是哪种数据决定了走哪条路NCBI不是一个单一的数据库它更像一个生物信息数据仓库集群。我接手过的需求大致分几类下载某个物种的参考基因组序列文件、下载某个课题的原始测序数据SRA、下载基因表达芯片或RNA-seq的整理结果GEO、批量获取某个基因家族所有成员的序列、同步某个分类群的完整基因组列表。每一类对应的存储路径、下载工具、协议完全不同。第一件事不是急着敲命令而是想清楚自己要的东西在哪个库。参考基因组序列多数在Assembly数据库里文件存放在FTP/HTTPS的genomes目录下以GC开头的RefSeq组装或以GCA开头的GenBank组装为文件夹名。SRA原始数据则在SRA数据库文件以SRR/ERR/DRR开头需要通过SRA Toolkit来下载和解压。GEO的数据要看具体平台芯片数据通常可以直接下载Series Matrix文件RNA-seq则往往还要跳转到SRA取原始reads。如果你要的是经过整理的基因序列比如某个物种的全部mRNA那就得从RefSeq或者GenBank的序列库里抓。我见过不少新人拿着一个SRA编号试图用wget直接从网页下载折腾半天拿到一个几十KB的描述文件以为成功了实际上真正的测序数据根本没下来。所以选路逻辑就是先确定数据类型再选对应通道。这不是教条是避免无效劳动的第一步。1.2 常见误区以为NCBI只是个网页很多人第一次接触NCBI是从浏览器搜索基因、看序列比对开始的以为整个NCBI就是一个大型网页查询工具。实际上数据下载走的是完全不同的基础设施NCBI提供HTTPS网页接口、FTP镜像服务器、E-utilities REST API、SRA专用工具、Aspera高速通道五条路各有适用场景。网页界面适合人工浏览和确认元数据比如看看某个基因有几个转录本、某个组装版本对应哪个BioProject。真要下载几百个文件在网页上一个个点既慢又容易断而且浏览器直接下载大文件经常出现中断后从头再来的情况。FTP或者HTTPS直链更适合脚本批量拉取E-utilities适合在程序里查询-解析accession列表然后交给FTP或者SRA工具去真正传输数据。Aspera则是NCBI官方推荐的高速传输协议能在跨洋网络条件下把速度提升一个数量级。理解这套逻辑之后再去看网上各种NCBI下载教程就会清晰很多每篇教程其实都在讲某一条特定路径并不存在一个万能方法覆盖所有需求。下面几个部分我按实际使用频率从高到低把每条路的关键操作和参数拆开讲。2. 网页端到程序端先学会精准定位数据2.1 Assembly库里的基因组怎么挑下载基因组最怕挑错版本。NCBI的Assembly数据库记录着每个组装的历史版本同一个物种可能有几十个assembly版本随时更新。进入Assembly页面后先看两个字段一是Assembly accession有GCF开头和GCA开头两种GCF代表RefSeq代表版本由NCBI人工整理GCA代表GenBank原始提交版本由测序中心直接提交二是Assembly name比如著名的人类参考基因组GRCh38.p14这个名称要软性记住很多下游分析软件参数里要用到。我的习惯是做常规分析优先挑选RefSeq版本因为它的注释信息统一、基因ID稳定下游比对工具默认索引多数也是基于RefSeq生成的。但也要注意某些特定物种或特定研究传统可能习惯用GenBank版本比如有些植物的小基因组GenBank版本反而更新更全。关键在于选定之后后续所有样本比对、注释、变异calling都围着同一个版本做不要混用。在Assembly页面右下角能找到FTP directory链接这就是基因组文件的物理存放位置。点进去会看到一组文件常用的包括*_genomic.fna.gz基因组碱基序列、*_genomic.gff.gz基因结构注释、*_protein.faa.gz编码蛋白序列、*_rna.fna.gz转录本序列、*_cds_from_genomic.fna.gzCDS序列。新手容易下载全部文件但实际分析可能只需要两三个全下的结果就是多花时间传输和占用磁盘。2.2 RefSeq和GenBank两个版本别选错前面说过GCF和GCA的差异这里再展开讲一下使用场景。RefSeq是NCBI对已有数据进行整理、去冗余、标准化注释后形成的参考集特点是稳定、有权威编号如NM_、NP_开头的编号都来自RefSeq非常适合做基因层面的比对和功能分析。GenBank则是原始递交数据的直接归档代表测序实验室提交时的样子编号以AU、AY等字母开头信息更原始、更新更快但也更杂可能存在冗余和注释不一致。实际项目中遇到过一个典型问题同一物种在Assembly里同时存在GCF和GCA两个组装两者序列长度和基因数量都有差别。有同事用A版本下载了参考基因组跑完一轮变异检测后项目总结时才发现原始项目说明书里写的是B版本只能重新下载比对白白浪费了几天算力。所以下载前务必对照BioProject或文章的说明确认使用哪个版本并把GCF/GCA编号和下载日期记录在项目日志里。数据溯源是生信项目的基本功NCBI数据下载是第一个环节绝不能偷懒。2.3 用E-utilities批量查询accession列表当你需要下载一批样本数据比如某个项目中所有样本的测序数据不可能一个个去网页上复制SRA编号。这时候要用E-utilities来做批量查询。E-utilities是NCBI开放的REST风格API包含esearch、esummary、efetch、elink等接口其中esearch负责搜索并返回ID列表。下面用一段脚本演示在SRA数据库里搜索某个研究项目下的所有run编号。# 先拿到这个BioProject对应的SRA数据库ID列表esearch返回的ID是SRA内部的UID curl https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?dbsratermPRJNA123456[BioProject]retmodejsonretmax10000 -o search_result.json # 解析JSON拿到UID列表然后用esummary补全每个UID对应的SRR号 python3 - EOF import json with open(search_result.json) as f: data json.load(f) idlist data[esearchresult][idlist] print(\n.join(idlist)) EOF拿到UID列表后下一步调用esummary把UID转换成SRR号。这里有个细节E-utilities的ID字段在不同数据库里含义不同SRA数据库返回的是内部UID而不是SRR号本身必须经过esummary或efetch转换才能得到你真正要用的run accession。这一步很多人第一次接触时会疑惑我当初也在这个转换上卡了半天。关于API速率限制NCBI对未注册key的请求限制是每秒3次请求如果注册了API key可以提升到每秒10次。在批量查询时尤其是retmax设得很大时必须在脚本中加入sleep或者并发控制否则很容易收到429或者被临时封禁。一个稳妥的组合是每次请求之间sleep 0.5秒每次esummary批次200个ID。3. 三条下载路径HTTP、FTP与E-utilities的取舍3.1 小文件优先走网页/HTTP如果只是下载几个文件每个小于500MB最省事的办法就是直接在浏览器或者用wget/curl拉HTTP链接。NCBI的FTP目录同时支持HTTPS访问所以把FTP链接里的ftp://ftp.ncbi.nlm.nih.gov替换成https://ftp.ncbi.nlm.nih.gov同样可以下载而且不少代理环境对HTTPS的支持更友好。直接下载时wget建议加上几个参数wget -c -t 5 -O GCF_000001405.40_genomic.fna.gz \ https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_000001405.40_GRCh38.p14/GCF_000001405.40_GRCh38.p14_genomic.fna.gz参数含义-c表示断点续传-t 5表示失败后最多重试5次-O指定输出文件名。这些小文件走HTTP完全够用不需要上SRA Toolkit或者Aspera。注意NCBI有些路径下同时提供.md5校验文件下载完顺手比对一下MD5防止传输过程中文件损坏。MD5校验在后面专门展开。3.2 FTP批量同步脚本化下载的组织方式当文件数量上升到几十、几百个时手动wget就明显不现实了需要写脚本来组织。NCBI的FTP服务器设计成了标准目录树用脚本遍历目录、拼接FTP路径是可行方案。以genomes目录为例目录结构遵循这样的规律/genomes/all/GCF/xxx/yyy/zzz/GCF_xxx.yyy_assembly_name/其中xxx/yyy/zzz是把accession号按每3位分组形成的层级路径。比如GCF_000001405.40就放在GCF/000/001/405/GCF_000001405.40_GRCh38.p14/下。知道这个规律批量构造URL就方便了。当然更建议直接用lftp来同步目录lftp -c open https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_000001405.40_GRCh38.p14/; pget -n 8 GCF_000001405.40_GRCh38.p14_genomic.fna.gzpget -n 8表示把这个文件分成8个线程并行下载适合单文件比较大的场景。lftp还支持通配符批量下载比如同时抓取某个目录下所有.gz文件。用脚本组织下载的核心思路是把文件清单和下载动作分开管理先用查询脚本生成清单再用循环或lftp批量执行同时记录日志方便排查哪几个文件失败了。3.3 E-utilities查询接口也能当下载器E-utilities除了用于查询ID列表还经常被用来直接抓取小规模序列数据。比如要批量提取一组基因的fasta序列可以用efetch接口curl https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?dbnucleotideidNM_001301860.2rettypefastaretmodetext把id参数替换成逗号分隔的accession列表就能一次批量获取序列。对于几百条基因序列的场景这种方式比逐条点击网页快得多也比下载整个物种的序列库再本地grep要轻量。这里要注意两个限制一是单次请求的ID数量不要超过400个否则NCBI可能截断响应二是对于超长序列10Mb的完整基因组efetch不适合用来下载原始序列文件应该走FTP/HTTPS获取完整.fna.gz文件。efetch本质上适用于元数据和中小型序列的交互式获取大文件传输不是它的场景。把API当成查询小规模抓取的工具把FTP/HTTPS当作批量大文件传输的通道这样分工最合理。4. SRA原始测序数据的下载prefetchfasterq-dump实战4.1 为什么要用SRA Toolkit而不是wgetSRA是NCBI里最特殊的数据库之一。它的数据文件以.sra格式存储这是NCBI自定义的二进制格式包含reads和元数据。直接用wget下载.sra文件虽然可行但后续还要解压成FASTQ才能比对而且NCBI的SRA文件存放在独立的存放服务器路径格式复杂手动构造URL很容易出错。SRA Toolkit就是为了解决这个问题设计的。它包含prefetch、fasterq-dump、fastq-dump、vdb-validate等多个子命令prefetch负责下载在本地创建SRA缓存fasterq-dump负责把SRA格式转成FASTQ。工具安装可以通过condaconda install -c bioconda sra-tools版本很稳定不需要编译。安装完第一步是配置路径写一个~/.ncbi/user-settings.mkfg或者直接运行vdb-config -i交互配置。实际上如果只是下载公共数据不配置也能用默认设置跑通但配置一下有好处可以指定下载缓存路径避免默认写到~/ncbi/下把home目录塞满。4.2 完整流程从accession到fastq我常用的标准下载流程是这样的。假设我要下载一个成对的双端测序样本SRR12345678# 第一步下载 prefetch --max-size 200G SRR12345678 # 第二步验证完整性和元数据 vdb-validate SRR12345678 # 第三步转成fastq按配对拆分文件 fasterq-dump SRR12345678 --split-files --threads 8 --outdir fastq/关键参数逐一说明。prefetch --max-size用来绕过默认的20G大小限制这个限制是SRA Toolkit早期版本留下的现在很多测序样本的SRA文件动辄几十上百GB不加这个参数直接会报错说文件超出最大值。fasterq-dump --split-files对双端测序会输出_1.fastq和_2.fastq两个文件单端测序则只会生成一个文件。--threads 8可以并行压缩明显减少耗时。vdb-validate是在转换之前做完整性检查的它比对SRA文件里的元数据哈希确认下载过程中没有损坏。转换到一半磁盘满、文件损坏这些事有了这一道检查能提前发现。还有一点如果只是想要fastq而不想保留SRA缓存可以通过--tmp指定转换时的临时目录转换完成后删除对应缓存目录来释放空间。实践中我的做法是先下载一批SRA转换完一批就删一批缓存避免磁盘峰值过高。4.3 磁盘空间与中断恢复的实操建议SRA原始数据最大的特点就是大。一个30X的人类全基因组样本SRA文件可能超过100GB解压成FASTQ后体积膨胀2倍以上。因此下载前必须预先规划磁盘空间SRA缓存、中间临时文件、最终FASTQ三者峰值加在一起至少要为每个样本预留下载文件体积的3倍空间。磁盘空间之外还有两个容易被低估的问题。第一个是临时文件机制fasterq-dump在转换期间会先写一个临时的.fastq文件在临时目录下转换完成后再改名如果没指定临时目录且系统默认的/tmp挂载在系统盘上很可能把系统盘写满拖垮整个服务器。建议显式加上--temp-dir /data/tmp这样的大盘路径。第二个是prefetch的续传逻辑prefetch在下载中断后支持断点续传重新执行同样命令会从上次的中断点继续但前提是你没有手动删除它的临时下载文件。有些集群环境在作业被kill后会清理临时目录因此不建议把prefetch和fasterq-dump放在同一个提交作业里执行分两步跑更稳。关于转换时间fasterq-dump对比老的fastq-dump速度提升非常明显。这是因为它采用多线程流水线设计而且利用SRA文件内部的索引结构按块处理reads老版本逐条记录读取的方式是历史包袱效率差距很大。实际测试中同样一个20G的SRA文件fastq-dump可能要跑40分钟fasterq-dump在8线程下10分钟出头就完成了。所以现在新装环境下我直接用fasterq-dump除非遇到某些老SRA文件的兼容性问题才会回退。5. 大文件提速Aspera与并行下载的实测经验5.1 Aspera为什么能跑到千兆NCBI的FTP和HTTPS下载跨洋连接的瓶颈通常在TCP吞吐和丢包重传上。普通wget下载大文件从国内服务器拉NCBI速度经常只有几MB/s甚至几百KB/s。Aspera是一种基于UDP的传输协议通过能够感知网络状况的速率控制和数据包重传机制大幅提升了高带宽时延网络下的实际吞吐量这也是为什么NCBI官方专门提供Aspera作为高速下载的推荐通道。Aspera的命令行客户端叫ascpNCBI官网有对应的下载页。使用前要下载NCBI提供的密钥文件一个.openssh格式的key然后通过ascp连接NCBI的Aspera服务器。一个典型用法如下ascp -i /path/to/aspera.openssh -QTr -l 500M -P 33001 \ anonftpftp.ncbi.nlm.nih.gov:/sra/sra-instant/reads/ByRun/sra/SRR/SRR123/SRR12345678/SRR12345678.sra ./参数拆解-Q表示使用自适应流控-T禁用encryption公共数据不需要加密-l 500M设定最大带宽为500Mbps-P 33001指定NCBI的Aspera服务端口。路径中的ByRun组织方式是SRA文件在NCBI服务器上的原始存放结构按SRR前6位的run号分层定位。需要注意Aspera并不适用于所有场景对单个大文件加速效果最明显但对大量小文件反而不如lftp做并发下载因为Aspera每个会话都要先建立连接握手的固定开销。实测中同样的100GB SRA文件wget走HTTPS可能平均只有800KB/sAspera能稳定跑到20MB/s以上具体取决于网络链路质量。5.2 并行下载的写法和取舍即便不用Aspera普通下载工具也可以通过并发拉文件来提速。关键是理解单文件并发和多文件并发的区别。单文件并发是把一个大文件切成多个块多线程同时下载如aria2、lftp pget多文件并发是同时发出多个下载请求每个请求负责一个文件。对于NCBI这种服务器我实测下来多文件并发更实用因为每个FTP/HTTPS连接本身能跑满的速率有限同时开几个连接做文件级别的并行整体吞吐量提升明显而且脚本可维护性好。下面是基于aria2的批量下载示例aria2c -x 8 -s 8 -c \ -i download_list.txt \ -d /data/ncbi_downloads/-x 8表示每个文件最多8个连接-s 8表示单文件拆8个分片-c启用断点续传-i指定URL列表文件。download_list.txt每行一个URL这是我从项目样本表生成的文件清单。并发数油水平衡的讲究。并发太高容易触发NCBI限流我本人在一次1000个文件的批量下载中曾因为并发20导致服务器返回503之后把并发降到4就稳定了。建议公共数据集下载时并发控制在4-6之间单文件连接数控制在4左右。如果网络质量好可以适当上调但切记不要无脑拉满。5.3 断点续传与数据一致性校验大文件下载最怕中途断网或者服务器不稳定而断点续传恰恰是各种工具里最容易踩坑的点。wget的-c在有部分文件时能续传但如果服务器端不支持Range请求续传就会失败wget可能从头开始下载覆盖已有文件。aria2的-c更能处理复杂场景它在本地保存下载控制文件.aria2后缀能准确知道哪些分片已经完成、哪些没完成。在NCBI的HTTPS服务器上Range请求是支持的所以wget -c和aria2 -c都能用。不过我更推荐在批量脚本里明确记录每次下载的日志连status code都记录下来而不是纯粹依赖工具的续传能力。下载完成后还要做数据一致性校验。NCBI在FTP/HTTPS目录里普遍提供了.md5文件里面记录了对应数据的MD5校验值。校验方法很简单md5sum -c GCF_000001405.40_GRCh38.p14_genomic.fna.gz.md5如果输出显示OK说明传输完整。如果是FAILED不用犹豫重新下载这个文件。这个步骤在本地磁盘充足的情况下成本很低但它能预防一种很尴尬的情况文件传输过程中有一个bit损坏下游比对的时候怎么跑都报错排查了半天才发现源头数据就错了。6. 掉过坑才算会用路径变动、配额与数据更新三个老问题6.1 NCBI路径说变就变NCBI的FTP目录结构不是一成不变的。历史上genomes目录经历过多次大规模重组早期按物种拉丁名组织目录后来改成按accession编号分层的结构现在还提供latest重定向链接来指向最新组装版本。这类变动的常见后果是网络上老教程里的FTP路径失效直接404或者路径指向了旧版本但目录下其实已经有新的子目录。我的应对策略是不去死记硬背长路径而是用NCBI提供的Report页面或者E-utilities接口动态获取当前的有效路径。比如在Assembly数据库里搜索某个组装通过esummary返回的FTPPath字段就能拿到最新路径。把这一步骤脚本化每次下载前自动查询比手工拼URL可靠得多。另外NCBI的https://ftp.ncbi.nlm.nih.gov/genomes/all/下每个assembly目录末尾都有latest_assembly_versions/这类链接也可以善加利用。6.2 限流与反爬策略别把NCBI当本地盘前面提到过E-utilities的限制这里再扩展到整个NCBI实施层面。NCBI对所有外部请求都有限流策略尤其是高并发下载时。实际遇到的情况主要有两种一是瞬时请求过多返回403或429二是长时间高带宽占用导致IP被临时封禁。根据我的经验遵守以下规则基本能安安静静下完大数据E-utilities请求控制在每秒3次以内注册API key后可以放宽到10次批量下载并发控制在6以内两次请求失败后主动休眠60秒再继续。如果确实需要下载镜像级的数据量可以考虑使用NCBI官方的aws s3 open data存储桶NCBI在AWS和谷歌云上都开放了公开的数据副本通过云存储传输往往更快更稳定但这需要自己确认数据的可用性和计费规则。6.3 版本更新同一个基因组的两次下载最后一个老问题是版本更新。参考基因组和SRA数据库都在持续更新NCBI会修正旧的组装错误、补充注释信息这意味着你上个月下载的基因组文件这个月可能已经有新的patch版本。SRA数据相对稳定但偶尔也有数据被重新提交或标注为撤回的情况。应对方式就是在项目日志中记录数据下载出处的详细信息accession号、下载日期、文件大小、MD5值、所用工具的版本号。这样即使后来发现数据已更新也能清楚判断当前分析基于哪个版本以及是否需要重新下载。我在实际项目中把NCBI下载当做一个流程化步骤来管理而不是一次性手工操作利用脚本把查询、下载、校验、记录整合成一条命令日后再有类似数据需求时可以直接复用。NCBI数据下载看起来简单其实每个环节都有对应的组织和工具逻辑选对路径、掌握工具参数、做好校验和记录才是高效获取数据的关键。几百次下载实验做下来我自己最深的体会是下载前多花10分钟设计好取数方案远比下载完成后花几小时处理数据文件要划算。
