下载工具设计思路与局限性

Aspera是非常给力的下载工具，NCBI的SRA和EBI的ENA都支持。但是，直接利用该工具下数据，命令非常繁琐。因此我考虑，可否封装Aspera命令，让用户只输入数据ID即可下载？

于是，参考SRA、SAM以及Fastq文件高速下载方法，我写了ASCPsra，封装了SRA和ENA测序数据的下载命令，实现下载的并行化，并在后续版本中，添加了断点续传、文件检查、格式转换等功能。

再后来我自己下载了几十T的测序数据，发现主要通过ENA来下载，而不是SRA，基于下面几点原因：

1、SRA默认下载格式为sra，而ENA提供fastq格式下载。通过ENA直接下fastq免去数据转换；

2、感觉，SRA的Aspera下载链接常常失灵，ENA似乎稳一些（只是个人感觉）；

3、ENA提供文件信息查询的API，通过API可方便获取文件md5，链接等信息，甚至影响了下载方法的设计。而在NCBI上，尚未留意到有类似的API。

因此，撰写FTPena.pl时，逐渐形成了下面的设计思路：

• 只针对ENA，只针对数据下载，不考虑SRA；
• 通过ENA的API拿到数据详细信息，提取出指定格式的下载链接、md5，再规划下载任务，或者直接输出下载代码；
• 下载任务尽量确保万无一失，但是也要避免任务重复
• 使用尽量足够简单，数据下载和数据检查使用一模一样的命令无脑跑即可
• 方便数据调研，提供下载备选方案

而目前，还有下面一些局限性：

1、ENA的下载链接时常断掉； 2、ENA的API拉取数据信息时，api发送了两次，而非一次，主要是这部分代码直接从原有脚本搬来，我懒得修改了 3、部分测序数据的支持还不完美，需要更多测试