这是用来批量寻找论文信息的代码，可用通过DOI号、GSE编号、PMID来获取文献基本信息
增加了GSE下载的shell脚本,以及进行文件核对的ipynb文件
学到了wget的具有校验文件完整性的内建功能, 我为下载脚本增加了文件校验的步骤, 现在下载是否完成已经可以被标记了.
更改了下载文件的判断, 有些文件下载失败是对方服务器的问题, 莫得办法, 只能先记下了, 然后过一段时间再下载.
本次更新整理了原来的代码逻辑, 用函数的形式重构了脚本, 现在这个脚本原生支持并行下载! 原生支持下载文件后的校验! 很多时候GEO数据库的压缩文件在传输过程中会出错, 所以需要在下载完成后校验一下, 这在你需要下载很多数据的时候非常有用!
原本也不会更新的, 毕竟这个月太忙了, 我的leader在最初讨论的时候, 认为我们在生成环境部署了下载加速工具之后, 下载数据这个事情就不需要专门的人来做了, 这件事会变成“谁用谁下载”. 但俗话说
“复杂性不会消失, 它只会转移”,
在这件事上也是一样的. 好吧, 让我们有始有终.
学了面向对象编程的基本思想, 一直没地方用, 把这段时间的一些想法在这个下载脚本上实现了, 月初给自己画的饼🫓终于吃上了一部分. 🤔等我整明白GPT的api了就把🫓补全.
新的代码看起来真的像诗一样优美, 我竟然能搞出来这种东西! 此处着重推荐《代码整洁之道》这本书, 非常的amazing!!!
[代码整洁之道.pdf](https://github.com/OOAAHH/paperfit/files/13513016/default.pdf)
“ ———整洁的代码读起来令人愉悦. 读这种代码, 就像见到手工精美的音乐盒或者设计精良的汽车一般, 让你会心一笑. ”
补充了文件校验的方法, 写在python脚本中, 使用前需要预先准备python和R的环境.
增加脚本: 计算文件md5值.py, 用于利用parallel进行并行的md5计算, md5比sha256更快.
新增了用于按照关键词爬取PubMed文献信息的R语言脚本
由于缺乏自动化工具，且确实有“在下载文件之前获知文件格式”的需求。新增PRJ_ID_2_SRA_ID_0.0.2.py，用于自动化的从来自NCBI的Project ID获取SRR信息。
- 0.0.2 版本主要新增了查询逻辑和限速逻辑，同时增加了错误处理。
当前，在使用前，请先安装相关依赖，尤其是sra-tools，脚本中调用了vdb-dump工具。
$ python ./PRJ_ID_2_SRA_ID_0.0.2.py -e YOU_E.MAIL -k YOU_NCBI_API_KEY -i YOU_PROJECT_ID_FILE -o YOU_OUTPUT_DIR
-
-k/--api_key是可选参数，api_key可以在NCBI的账户设置中获取，这个key可以提高你的查询速率。 -
-v/--view是可选参数，用于实时监看程序查询结果，我在这里没有使用。
我个人建议你使用免费的colab来进行这个查询，这样可以避免你的查询受到网络的影响。运行起来就会像是下面👇这样。
程序会首先寻找每个project ID对应的SRA数据库的唯一ID，再进行SRA ID到SRR ID（run ID）的查询，最后再进行SRR ID到SRR文件对应格式信息。
新增需求“基于PMID寻找对应期刊的摘要信息”。更新了PMID_2_Abstract_0.0.1.py.
$ python /content/drive/MyDrive/pmid2abstract.py -e YOU_E.MAIL -k YOU_NCBI_API_KEY -i YOU_PROJECT_ID_FILE -o YOU_OUTPUT_FILE -v
我个人建议你使用免费的colab来进行这个查询，这样可以避免你的查询受到网络的影响。运行起来就会像是下面👇这样。
-
是的！你可能注意到了我这里使用了
-v/--view这个选项，正如👆上图中显示的，我们可以看到每个PMID的查询是否成功。 -
我强烈推荐你在查询结束后，统计一下abstract字段每个结果的字数，有些结果可能不尽如人意，这是因为一部分文章本身确实没有摘要部分。
-
-k/--api_key是可选参数，api_key可以在NCBI的账户设置中获取，这个key可以提高你的查询速率。 -
-v/--view是可选参数，用于实时监看程序查询结果，我在这里没有使用。
新增需求“基于PMID寻找对应期刊的全文”。更新了PMID2Fulltext.py.
新增DOI到PMID的py
做了一个有趣的工具vdbdump2fastq.py，在获取了vdb-dump SRRID产生的每条reads的基本信息后，把这个文件转换为可以被umitools接受的fastq文件格式。
- ps: vdb-dump也不失为一种下载方式
制作了一个基于rust的HRA下载的fastq数据的校验工具。使用方式：修改路径重新编译即可，已经写入了并行的逻辑。
- 首先安装EPEL仓库
sudo yum install epel-release
- 安装'proxychains'
sudo yum install proxychains-ng
- 编辑配置文件'proxychains.conf'
sudo vi /etc/proxychains.conf
这里需要注意, 需要根据使用的是http或者socks5来具体的设置代理, 以socks5为例, 我的代理软件设置在7890端口进行监听. 那么本地代理的设置则需要你在proxychains.conf的末尾添加这样一行代码.
socks5 127.0.0.1 7890
- 测试
proxychains4 wget ftp://ftp.example.com
如下图所示, 正在连接 ftp.ncbi...这一行显示了, 本机和远方服务器224.0.0.1:22的连接被proxychains严格按照我们设置的socks5监听端口127.0.0.1:7890进行转发.
btw 通过不同的加速节点进行下载时, 速度有较大的差异. 目前尝试了多个供应商的节点, iggscholar的US节点有最快的下载速度: 14.5MB/s, 但magicloud拥有最多的每月不限速流量: 100TB.
- 安装并行工具 GNU Parallel 是一个 shell 工具，用于在一台机器上并行执行命令.
sudo yum install parallel
- 测试并行下载
| 这里我预备了一个txt文件: |
|---|
./1.sh GSE194122 |
./1.sh GSE140203 |
./1.sh GSE164378 |
./1.sh GSE232523 |
./1.sh GSE182475 |
每一行都是可以直接执行的shell命令, 为了实现并行下载, 我们可以使用cat shell.txt | parallel -j 20. 这里的-j 20即代表并行20个下载进程的意思, 一般来说parallel的并行的设置是一个核对应一个进程, 但在下载任务中, 还需要根据你的网速来具体的考虑并行进程的数量, 以实现下载成功率和下载速度的最优配置.
- 一般来说, 我们验证文件是否完整的思路是: 首先检查文件是否齐全, 再校验本地文件和服务器文件的md5值是否一致, 而在从NCBI的GEO数据库的ftp服务器进行下载时, 很多情况下没有给出md5值,这时我的文件校验的思路是, 首先获取本地文件列表, 再通过python bs4爬虫从ftp服务器获取对应的文件结构和信息. 进行文件比对的桥接信息是GSE编号, 本地的文件和ftp的文件均按照GSE编号进行存储. 我们可以获得如下图所示的文件信息列表, 此时我们就有了进行比对的基础, 使用代码或者wps/office均可, 我在这里展示的是wps的可视化结果. ps: 我小学的时候Excel的最大行数就是65536, 几十年了还是这样(bushi.
- 另一个方法
我们使用wget的
-c参数来实现文件的校验, 它的功能是进行断点续传. 只要我们“重新下载”一次即可再一定程度上实现文件校验的目的. 它会遍历每个文件, 并不算是“聪明”的做法, 但是有效.
我本意是这个东西想想就得了, 所以简单的做了点东西, 想来我们的新下载节点不可能出这种问题的. BUT, 即使retry设置了20次, 还是有很多文件下载不完全, 离谱. 看日志发现可能是并行太多, 有些retry根本没有足够的带宽再连接服务器.
加入了判断逻辑, 大量下载数据的复杂度很高, 远超想象.尤其是复杂网络环境下, 我们如果有个物理位置很近的镜像可能会完全不一样.
重构了代码架构, 让它看起来像函数一样. shell并不完全像一些高级编程语言那样有函数传递值的非常严格的界限, 这会造成维护上的时间成本增加, 需要额外的时间来理顺函数结构. 复杂性转移到了我之外的外部.
增加并改善了一些函数逻辑, 把重复的代码块都改为函数式调用, 让结构更优美.
增加了对并行下载的原生支持, 现在只需要输入GSE编号的文件即可自动启动并行下载. 并行下载的问题在于, 并行数需要严格设计, 单一下载任务是有速度“天花板”的, 考虑到下载速度对下载成功率的正相关性, 需要着重考虑并行数的设置.
增加了校验逻辑, 模拟读取文件来判断完整性.