GATK4标准分析流程 丨如何选择合适的线程和内存大小?数据预处理方法与注意事项

简介: GATK4标准分析流程 丨如何选择合适的线程和内存大小?数据预处理方法与注意事项

GATK4 实用技巧

前言

本篇笔记围绕GATK4流程中注意事项进行介绍,包括如何选择合适的线程和内存?如何按步骤进行数据预处理。

  • GATK实战工作流程
  • 脚本优化方法
  • 参数设置技巧

GATK 全称“基因组分析工具箱” Genome Analysis Toolkit,它是一组命令行工具,用于分析高通量测序数据,主要侧重于变异发现。这些工具可以单独使用,也可以链接在一起形成完整的工作流程。

所需数据与软件

需要有简单的Linux知识储备和高通量基因组学基础,流程中用到的软件如下:

GATK 4.3.0.0
fastp 0.20.1
bwa 0.7.17
samtools 1.11
mosdepth 0.3.0

示例数据来自ERP001960项目,数据结构为illumina测序原始数据,包含三个样本,如果想重复测试需要大概700GB空间。

数据预处理

预处理的步骤包括质控、去接头、排序等,需要用到FATSP等工具,为了提高效率建议直接用fastp标准输出到BAM文件,避免不必要的磁盘读写,用管道串联起来能提高工作效率。

无论是否进行排序,都不要直接将未压缩的sam文件写入磁盘!最好用管道直接把两步合为一起生成排序去重之后的bam文件

fastp去除接头

使用fastp程序进行操作,为了提高数据吞吐效率,将默认输出信息定向到/dev/null中,避免磁盘读写。

fastp -i /lscratch/${SLURM_JOB_ID}/$(basename $r1) \
     -I /lscratch/${SLURM_JOB_ID}/$(basename $r2) \
     --stdout --thread $threads \
     -j "${logs}/fastp-${SLURM_JOB_ID}.json" \
     -h "${logs}/fastp-${SLURM_JOB_ID}.html" \
     > /dev/null

下图展示了不同线程与处理速度的关系,很显然啊!这里如果超过6个线程就没多大意义了,设置6个线程就能达到最佳计算效率。

bwa mem 序列比对

比对过程实际上是拿着参考基因组,然后把每个小片段进行对齐,举个比较抽象的例子,就好比是拼图的过程,目的是让每一个小碎片都找到匹配的位置。

使用bwa mem程序进行比对,注意这里每个样品需要两条序列(因为二代双端测序两个方向是一对儿)。

bwa mem -M -t ${threads} \
        -R "@RG\tID:$id\tPL:ILLUMINA\tLB:$lb\tSM:$sm" \
        $genome \
        /lscratch/$SLURM_JOBID/$(basename ${r1[small]}) \
        /lscratch/$SLURM_JOBID/$(basename ${r2[small]}) \
        > /dev/null

通过下图可以看出线程数与计算效率的关系,很明显在32线程以内基本呈正相关,因此建议此处设置的线程数稍微高一点,理论上线程数越多的话,拼图的速度也越快,就好比你找了几个小伙伴帮你同时拼图。

但是,也需要注意不要设置的太高,否侧多个线程的并行过程可能出现干扰,反而影响速度。就好比你为了拼一张地图把全校的人都叫过来了,一间屋里全是人,每个人移动起来都费劲,CPU也一样,线程过多相互打架

samtools sort 排序

SAM文件输出后直接管道传递给sort进行排序,这样可以避免磁盘读写浪费时间(就好比买了一份外卖我直接吃就行了,没必要拿到厨房加工一下再取出来,多此一举浪费时间)。可以再理解一下磁盘吞吐和溢出概念,这对提高性能非常重要。

使用重定向把输出信息丢弃,基准测试过程中BAM文件大概25GB左右,临时文件储存在lscratch中,需要格外注意设置线程数每个线程的内存大小时综合考虑,需要根据机器配置和计算需求灵活修改。

samtools sort -T /lscratch/$SLURM_JOBID/part \
    -m ${mem_mb_per_thread}M \
    -@ ${threads} \
    -O BAM \
    /lscratch/$SLURM_JOBID/$(basename $bam) \
     > /dev/null

通过对比可以发现,在设置10个线程时,计算效率最高,盲目的增加线程数反而导致计算效率降低了。另外,启用10个线程之后,设置内存参数也对速度有影响,例如16线程状态下,采用10GB内存的速度比30GB明显要快。为了方便理解,举个不太抽象的例子:假如有很多乒乓球,每个上面有一个数字编号,打乱后放在一个屋子里,想让你按顺序排好放到另一个屋子。

如果人数增加很明显是有助于提高排序速度(线程数增加),正常情况下每个人一次只能拿一个球(单个线程内存比较小),如果让每个人每次可以多拿几个球就可以避免来回跑(增加内存也能提高效率)。

但是存在某个临界情况,此时整体效率最大,也就是线程数和内存最匹配(上面图中的最高点处)。

samtools view转换bam文件

上步生成的sam文件要转换成bam文件,使用如下命令,此步骤占用的内存相对较少。

samtools view -@ ${threads} \
    -O BAM \
    /lscratch/\$SLURM_JOBID/$(basename $sam) \
    > /dev/null

通过下图发现这一步设置的线程数和计算速度呈正比关系,测试最大采用16线程。

脚本的优化过程

有没有一种更厉害的方法,能达到比较高的计算效率呢?

下述代码中,使用两个管道命令将中间结果依次传递,采用32核心进行计算,完成了fastp、bwa、samtools等步骤。

fastp -i $read1 -I $read2 \
    --stdout --thread 2 \
    -j "${logs}/fastp-${SLURM_JOB_ID}.json" \
    -h "${logs}/fastp-${SLURM_JOB_ID}.html" \
    2> "${logs}/fastp-${SLURM_JOB_ID}.log" \
| bwa mem -v 2 -M -t 32 -p \
    -R "@RG\tID:$id\tPL:ILLUMINA\tLB:$lb\tSM:$sm" \
    $genome - 2> ${logs}/bwa-${SLURM_JOB_ID}.log \
| samtools sort -T /lscratch/$SLURM_JOBID/part \
    -m 1706M \
    -@ 12 \
    -O BAM \
    -o /lscratch/$SLURM_JOBID/$bam \
    2> ${logs}/samtools-${SLURM_JOB_ID}.log

运行中占用的最大线程数为45左右,最大内存为60GB左右,大部分时间都是32线程进行运算,比对结果逐步记录到缓存区,当缓存区满了后再进行排序,这样极大地提高了效率。

  https://hpc.nih.gov/training/gatk_tutorial

END

© 素材来源于网络,侵权请联系后台删除

往期推荐:

1. Rstudio 在线云同步功能怎么用?

2. 重测序数据分析笔记与常用流程

3. ChatGPT4 Plus只需上传数据就能分析

4. 生信麻瓜的 ChatGPT 4.0 初体验

相关文章
|
12月前
|
存储 弹性计算 缓存
阿里云服务器ECS经济型、通用算力、计算型、通用和内存型选购指南及使用场景分析
本文详细解析阿里云ECS服务器的经济型、通用算力型、计算型、通用型和内存型实例的区别及适用场景,涵盖性能特点、配置比例与实际应用,助你根据业务需求精准选型,提升资源利用率并降低成本。
717 3
|
8月前
|
设计模式 缓存 Java
【JUC】(4)从JMM内存模型的角度来分析CAS并发性问题
本篇文章将从JMM内存模型的角度来分析CAS并发性问题; 内容包含:介绍JMM、CAS、balking犹豫模式、二次检查锁、指令重排问题
208 1
|
8月前
|
设计模式 消息中间件 安全
【JUC】(3)常见的设计模式概念分析与多把锁使用场景!!理解线程状态转换条件!带你深入JUC!!文章全程笔记干货!!
JUC专栏第三篇,带你继续深入JUC! 本篇文章涵盖内容:保护性暂停、生产者与消费者、Park&unPark、线程转换条件、多把锁情况分析、可重入锁、顺序控制 笔记共享!!文章全程干货!
437 1
|
9月前
|
数据采集 存储 弹性计算
高并发Java爬虫的瓶颈分析与动态线程优化方案
高并发Java爬虫的瓶颈分析与动态线程优化方案
|
11月前
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
760 4
AI代理内存消耗过大?9种优化策略对比分析
|
11月前
|
人工智能 Java Linux
Go 调度器:一个线程的执行流程
本文详细解析了Go语言运行时调度器的初始化流程,重点介绍了GMP模型的构建过程。内容涵盖调度器初始化函数`runtime·schedinit`、线程与处理器的绑定、P结构体的创建与初始化,以及主Goroutine的启动流程。通过源码分析,帮助读者深入理解Go运行时的底层机制。
246 0
|
并行计算 安全 Java
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
在Python开发中,GIL(全局解释器锁)一直备受关注。本文基于CPython解释器,探讨GIL的技术本质及其对程序性能的影响。GIL确保同一时刻只有一个线程执行代码,以保护内存管理的安全性,但也限制了多线程并行计算的效率。文章分析了GIL的必要性、局限性,并介绍了多进程、异步编程等替代方案。尽管Python 3.13计划移除GIL,但该特性至少要到2028年才会默认禁用,因此理解GIL仍至关重要。
1282 16
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
|
12月前
|
存储 Ubuntu Linux
内存卡格式化必看!4个格式化工具与注意事项
今天就给大家推荐几款经过实测的内存卡格式化工具,它们不仅使用简单、支持多种格式,而且在修复损坏卡方面也表现稳定,是实用性与安全性兼具的好帮手。
|
存储 Java
课时4:对象内存分析
接下来对对象实例化操作展开初步分析。在整个课程学习中,对象使用环节往往是最棘手的问题所在。
151 4
|
Java 编译器 Go
go的内存逃逸分析
内存逃逸分析是Go编译器在编译期间根据变量的类型和作用域,确定变量分配在堆上还是栈上的过程。如果变量需要分配在堆上,则称作内存逃逸。Go语言有自动内存管理(GC),开发者无需手动释放内存,但编译器需准确分配内存以优化性能。常见的内存逃逸场景包括返回局部变量的指针、使用`interface{}`动态类型、栈空间不足和闭包等。内存逃逸会影响性能,因为操作堆比栈慢,且增加GC压力。合理使用内存逃逸分析工具(如`-gcflags=-m`)有助于编写高效代码。
279 2

热门文章

最新文章