Trimmomatic双端测序全攻略：从FASTQ质控到参数调优实战

发布时间：2026/10/20 3:15:56
Trimmomatic双端测序全攻略：从FASTQ质控到参数调优实战
做生信的朋友对 Trimmomatic 这个名字应该都熟。它是二代测序数据预处理阶段最常被提到的工具之一专门处理下机后最原始的 FASTQ 文件去接头、剪低质量碱基、过滤掉太短的序列。如果说测序是原料采购那 Trimmomatic 就是洗菜、切菜和挑烂叶子的环节后面不管是比对、组装还是定量吃进去的都是这份处理后的干净数据。这篇内容主要适合刚接触生信、准备跑 RNA-seq 或全基因组流程、以及想自己搭一套分析 pipeline 的人我会把 PE 双端模式的核心逻辑、每个参数背后的设计动机还有我实际使用中踩过的坑都拆开讲清楚。1. 先看明白Trimmomatic 到底在清理什么1.1 FASTQ 里的“脏东西”主要有三类测序仪下机后的数据远没有想象中干净。第一类是接头残留建库时那段用于捕获和扩增的已知序列有时会被一起读出来直接留在 read 的末端或中间第二类是低质量碱基测序越往后面信号衰减越明显read 3 端的碱基质量往往越来越差第三类是长度不合格的序列比如整条 read 被修剪得太短已经没有比对或组装价值。如果不做处理下游比对时会出现大量横跨外显子或不匹配的 read组装时则会贡献一堆虚假的 contig。Trimmomatic 的定位就是针对这些问题做“定点清除”。它不是像 FastQC 那样只输出质量报告而是真正动手改造数据输出修剪后的新 FASTQ 文件。FastQC 负责诊断Trimmomatic 负责治疗两者配合使用是标准的质控流程。1.2 Phred 质量值的读取方式为什么有时候会看到“乱码”要理解 Trimmomatic 的参数先得懂 FASTQ 文件里质量值是怎么编码的。FASTQ 的第四行是一串 ASCII 符号每个符号对应一个质量分数。常见的编码体系是 Phred33也就是 ASCII 码值减去 33 得到 Q 值另一个是 Phred64对应老版本 Solexa 或部分旧平台数据码值减去 64 得到 Q 值。Q 值的计算公式是 Q -10 * log10(P)其中 P 是碱基判读错误的概率。Q20 代表错误率 1%Q30 代表错误率 0.1%。如果直接用文本编辑器打开 FASTQ 文件看到的第四行是一堆看起来像乱码的符号——IIIIIIIIIIIIIIIIIII这种就是质量很高的表现。老版本 Trimmomatic 需要手动指定-phred33或-phred64新版本会自动识别但如果你在用某个旧版本开源镜像里的脚本还是容易踩到这个坑。判断数据是哪套编码体系看 FastQC 输出的质量分布图最直接也可以观察 ASCII 符号范围如果在 33 到 74 之间基本是 Phred33如果大量出现小于 59 的符号却显示高质量可能就是 Phred64。1.3 跳过预处理的代价很多人嫌预处理麻烦尤其是手头数据已经经过了某平台的官方质控觉得可以跳过。我见过不止一次直接拿原始 FASTQ 去做比对结果 mapping rate 从 85% 掉到 60% 多的情况。接头残留会导致 read 的末端全部比对到同一段已知序列上产生大量不可信的比对低质量碱基则会让错配增多尤其在 SNP 检测中这些位置很容易被误判成变异位点。做一次 Trimmomatic 通常只需要几分钟到十几分钟省下的却是下游排查问题的数小时时间。2. PE 双端模式理解四个输出文件背后的逻辑2.1 PE 模式为什么会产生 paired 和 unpaired 两种输出Trimmomatic 最常用的场景是双端测序即一对 read 分别来自 DNA 片段的两端用 PE 模式处理时命令会指定两个输入文件和四个输出文件。这四个文件分别对应 R1 端保留且 R2 端也保留的 paired 数据以及只有一端能保留、另一端因为太短被丢弃的 unpaired 数据。刚接触的人经常不理解为什么还要输出 unpaired reads。我的理解是Trimmomatic 的设计理念是“能救就救”。假设 R1 端质量很好长度也够但 R2 端因为测序深度不够或质量太差被修剪到了 MINLEN 以下这时候如果强制把成对的 R1 也丢掉就白白浪费了一部分可用数据。某些下游工具比如组装类的 SPAdes是支持单独使用 unpaired reads 的即使在比对流程中如果某一步骤只接受 paired 文件这些 unpaired reads 也可以在后续步骤作为单端数据补充进去。2.2 四个输出文件在实际流程中的去向实际写 pipeline 的时候我会把 PE 配对文件作为主分析输入而把两个 unpaired 文件攒起来留到需要单端数据的环节再用。比如跑某个基因组组装项目时SPAdes 命令里可以直接指定--unpaired参数把这些原本会被丢弃的数据重新派上用场。RNA-seq 定量流程中如果比对工具支持单端模式也可以把这些 reads 单独比对后再合并统计。有一点要特别说明如果一条 read 因为接头残留被剪掉了一大段但另一端完全正常那么被剪短的一端如果还能达到 MINLEN它仍然会进入 paired 输出只是长度变短了。Trimmomatic 的判断逻辑是看修剪后是否满足最小长度而不是看是否发生了修剪。2.3 单端 SE 模式只需要两个文件SE 模式相对简单输入一个 FASTQ 文件输出一个修剪后的 FASTQ 文件。SE 模式下无法使用依赖双端信息的 palindrome 接头检测只能依赖 simple 模式。如果你的数据本身是单端测序或者少数 read 被单独保存为单端文件就用 SE 模式跑。3. 核心参数逐条拆解明白每一步在干什么3.1 ILLUMINACLIP接头去除的两种检测机制ILLUMINACLIP 是 Trimmomatic 最复杂的参数格式为ILLUMINACLIP:adapters.fa:seedMismatches:palindromeClipThreshold:simpleClipThreshold。我这里用一个实际例子来说明ILLUMINACLIP:TruSeq3-PE.fa:2:30:10。第一个值是允许的种子序列错配数常用 2偶尔调整到 1 会更严格第二个值是 palindrome 模式下的剪接得分阈值通常 30 到 40第三个值是 simple 模式下的阈值一般设 10 到 12。注意adapters.fa里必须放你实际建库用的接头序列Trimmomatic 安装包自带的 TruSeq、Nextera 等文件只是常见平台的默认接头集合。palindrome 模式是双端数据的特有优势。当双端 reads 是从同一个 DNA 片段两端测序且片段较短时两条 reads 会在中间区域相互重叠形成一条长序列此时接头序列往往会出现在重叠区域的末端。Trimmomatic 会把 R1 和 R2 拼成一条序列来检测接头这样即使接头本身有测序错误也能通过整体评分识别出来。simple 模式则是每条 read 独立找接头适合检测那些没有形成重叠、直接读到接头的 read。两个阈值越高剪接越保守误剪风险越低但也越容易漏掉真实接头。3.2 LEADING 和 TRAILING读首读尾的定点修剪LEADING:3的意思是如果 read 5 端某个碱基质量值低于 3就持续向前切除直到遇到一个质量达标的碱基为止。TRAILING 的逻辑完全相同只是从 3 端往回收。这个参数阈值设得很低比如 3 或 5因为 5 端和 3 端的末尾偶尔会出现一两个质量极低的碱基但又不值得因此动用滑窗把整条 read 切掉一大段。LEADING 和 TRAILING 是“点状清理”动作轻成本低。在实际数据里5 端低质量很少出现3 端低质量则很常见所以 TRAILING 通常比 LEADING 影响更大。如果你发现样本的 3 端质量整体衰退严重可以把 TRAILING 提高到 5 甚至 10这会切掉更多低质量尾部碱基但同时也会让 read 变短。这个取舍要看你的下游分析需求。3.3 SLIDINGWINDOW为什么用窗口平均质量而不是单碱基质量SLIDINGWINDOW 是 Trimmomatic 最核心的质量过滤步骤。格式是SLIDINGWINDOW:windowSize:requiredQuality最经典的参数是SLIDINGWINDOW:4:15意思是每次取 4 个碱基作为一个窗口计算窗口内碱基的平均质量如果平均质量低于 15就从窗口的第一个碱基位置开始往右全部切除然后窗口向后移动一个碱基继续判断剩余序列是否符合要求。为什么不用单碱基质量直接判断因为测序仪每个碱基的质量分数本身有一定噪声单看一个碱基很容易因为个别波动做出错误判断。取 4 个碱基平均能滤掉这种随机波动同时保留对整体质量趋势的敏感度。窗口大小选 4 而不是 10是因为窗口太大会导致质量信号被稀释某些已经明显变差的区域可能因为混入几个高质量碱基而“蒙混过关”窗口太小又容易过度修剪。4:15 是经过大量实践验证的经验值大多数常规转录组、基因组数据用这个参数都不会出错。3.4 MINLEN长度过滤的底线思维MINLEN:36的意思是经过所有修剪步骤后如果 read 长度还不足 36 个碱基就整条丢弃。这个值的核心逻辑是太短的 read 很难定位到参考基因组上的唯一位置还容易造成多比对或错误比对宁可丢掉也不留给下游添乱。MINLEN 的取值要结合实际场景如果是 150 bp 的 PE 数据建议 36 或 50如果后续做转录组定量比对算法对短 read 的容忍度更低可以适当提高。如果设得太高比如 100会把很多质量不错但被 TRAILING 削掉一段的 read 也丢掉导致整体数据量锐减设得太低比如 20下游比对工具会报错或产生大量低质量比对。做组装时SPAdes 对短 read 的容忍度相对高一些可以适当放低 MINLEN但也不建议低于 30。3.5 参数顺序会影响结果Trimmomatic 是严格按照命令行顺序执行各步骤的。一般推荐的顺序是先 ILLUMINACLIP 去接头再 LEADING、TRAILING 修两端接着 SLIDINGWINDOW 扫内部质量最后 MINLEN 做长度筛选。先去掉接头、再处理质量可以避免接头序列上的碱基干扰质量判断而如果先做质量修剪再接下去接头修剪过程可能已把接头序列切掉一部分导致残留接头检测不出来。实际调整参数时我会先跑一遍默认参数看日志再根据结果微调顺序和阈值。4. 实操全流程从原始 FASTQ 到干净数据4.1 环境准备Java 和 jar 包Trimmomatic 是 Java 写的所以机器上需要有 Java 运行环境。一般 OpenJDK 8 或 11 都够用不用特意装最新版。去官网下载对应版本的 jar 包放到一个专门的软件目录比如~/tools/Trimmomatic-0.39/。每次运行时用java -jar调用即可。我把 Trimmomatic 单独放在一个目录同时把适配文件也在同目录下放着因为 ILLUMINACLIP 参数里的 adapters 文件路径建议用绝对路径或相对路径写清楚避免脚本在不同工作目录下运行时找不到文件。4.2 一条实际可用的 PE 命令假设有一对样本文件sample_R1.fastq.gz和sample_R2.fastq.gz都位于同一目录下命令可以这样写java -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE \ -threads 8 \ sample_R1.fastq.gz sample_R2.fastq.gz \ output_R1_paired.fq.gz output_R1_unpaired.fq.gz \ output_R2_paired.fq.gz output_R2_unpaired.fq.gz \ ILLUMINACLIP:~/tools/Trimmomatic-0.39/adapters/TruSeq3-PE.fa:2:30:10 \ LEADING:3 \ TRAILING:3 \ SLIDINGWINDOW:4:15 \ MINLEN:36注意看几个关键位置PE 之后的-threads 8是设定并行线程数通常设成 CPU 核数的一半或略多即可四个输出文件的顺序必须严格对应 R1 paired、R1 unpaired、R2 paired、R2 unpaired很多人第一次用就在这里写反了输入文件如果是 gzip 压缩格式Trimmomatic 会根据文件名后缀自动解压和再压缩所以直接用.fastq.gz没问题。有的流程里会把未配对的 R1 和 R2 unpaired 合并成一个文件便于后续作为单端输入但我更建议单独保留因为不同来源的 unpaired 数据质量特征可能不同混合后不好追踪。4.3 如何看懂 Trimmomatic 的日志输出运行结束后屏幕上会打印一串摘要信息比如Input Read Pairs: 1000000 Both Surviving: 850000 (85.00%) Forward Only Surviving: 50000 (5.00%) Reverse Only Surviving: 30000 (3.00%) Dropped: 70000 (7.00%)这四行数据很重要。Both Surviving是双端都保留下来的比例是后续分析的主体Forward Only和Reverse Only是进入 unpaired 文件的 reads 比例Dropped是彻底丢弃的比例。理想情况下Both Surviving 应该在 80% 以上。如果 Dropped 比例超过 20%我会先去 FastQC 里看具体是什么问题而不是盲目调参数。日志还带有每个步骤处理前后 reads 数比如 ILLUMINACLIP 识别出多少条含有接头的 reads、SLIDINGWINDOW 从头修剪了多少条这些信息对判断数据质量非常有用。4.4 脚本化批量处理手头样本多的时候我不会手动一条条敲命令而是写一个简单的 Shell 循环。示例逻辑如下for sample in $(cat sample_list.txt); do java -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE \ -threads 8 \ ${sample}_R1.fastq.gz ${sample}_R2.fastq.gz \ ${sample}_R1_paired.fq.gz ${sample}_R1_unpaired.fq.gz \ ${sample}_R2_paired.fq.gz ${sample}_R2_unpaired.fq.gz \ ILLUMINACLIP:~/tools/Trimmomatic-0.39/adapters/TruSeq3-PE.fa:2:30:10 \ LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36 done建议在循环里加入日志重定向以便后续核验每个样本的存活率... ${sample}_trimmomatic.log 21批处理完后用一行命令快速提取所有样本的Both Surviving比例就能定位质量异常的样本。4.5 与 FastQC 和下游流程的衔接标准流程建议是先对原始 FASTQ 跑一次 FastQC拿到质量分布、GC 含量、接头残留等信息心里有数后再跑 Trimmomatic。修剪完成后再跑一次 FastQC确认接头残留是否消除、质量分布是否改善。这两次对比能直观反映预处理效果。下游流程中比对工具如主流比对软件接受 paired 和 unpaired 文件但命令写法不同组装工具可以同时接受 paired 和 unpaired。通常在 workflow 里我会把*_paired.fq.gz作为主输入unpaired 文件单独存档等组装阶段再看是否需要。5. 常见问题与排查我踩过的一些实际坑5.1 大量 reads 被丢弃Dropped 比例异常高如果 Both Surviving 降到了 50% 以下第一件事是打开日志看 MINLEN 前后的 reads 数变化。如果大量 reads 都栽在 MINLEN 这一关说明原本 read 长度就不够或者 SLIDINGWINDOW 修剪太狠。这时我会去看 FastQC 的 per-base sequence quality 和 sequence length distribution确认是测序本身质量问题还是参数问题。一个常见情况是样本测序深度不够有效长度本身就参差不齐。这时可以尝试把 MINLEN 降低到 30同时把 SLIDINGWINDOW 的阈值从 15 降到 12看是否能保住更多 reads。但降低阈值是有代价的保留下来的 reads 质量会略差需要在数据量和数据质量之间找到平衡。5.2 接头残留没去掉日志显示 ILLUMINACLIP 只处理了不到 1% 的 reads接头没有去除干净最可能的原因是适配器文件里没有包含你实际使用的接头序列。不同建库试剂盒用的接头不同如果 Trimmomatic 自带的 TruSeq3-PE.fa 和你手头的文库不匹配自然检测不到。比如某次我用自带文件处理某定制接头时日志中接头识别率几乎为 0但 FastQC 的 overrepresented sequences 里却明显有接头信号。解决方法是先跑 FastQC查看 overrepresented sequences 的具体序列内容再对照自带的 adapters 文件或者从试剂盒说明书里找到正确的接头序列写入自定义的my_adapters.fa文件然后替换 ILLUMINACLIP 参数里的文件路径。另外如果用的是双端数据但接头没有形成重叠palindrome 检测不到可以适当降低 simple 模式的阈值到 8 左右提高灵敏度但要注意降低阈值可能带来误剪。5.3 报错信息与内存问题运行过程中最常见的报错是 Java 堆内存不足提示java.lang.OutOfMemoryError。Trimmomatic 读取大 FASTQ 文件时默认 JVM 分配的内存可能不够尤其是几百 GB 的全基因组数据。这时在java -jar前加-Xmx4g或-Xmx8g例如java -Xmx8g -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE ...-Xmx8g表示最大堆内存 8 GB可以根据服务器可用内存调整一般 4 GB 足够处理大多数单样本数据全基因组级别的建议 8 GB 以上。另一个容易遇到的报错是输入文件格式问题。如果 FASTQ 文件被其他工具处理过行数不统一或者质量编码不一致Trimmomatic 会报出解析错误。解决办法是先检查文件完整性或重新下载原始数据不要强行修文件否则结果不可靠。5.4 输出文件里空文件如果某个样本输出文件为空先看是不是输入文件本身就是空文件或者文件是否被压缩格式搞混。比如有人把.fq.gz的文件改名为.fqTrimmomatic 按未压缩文件读取就会解析失败。这种情况用file命令检查实际格式最直接。还有一个小坑是输出目录与输入目录相同且文件名前缀一致可能覆盖掉原始文件。我习惯把原始 FASTQ 单独放一个raw_data目录修剪后的输出放另一个cleaned_data目录避免不小心覆盖原数据。5.5 单端模式下的常见注意事项SE 模式下无法使用 palindrome 检测所以接头去除只能靠 simple 模式这会让接头检测灵敏度下降。如果你处理单端数据时遇到接头残留除了降低 simple 阈值还可以先用 FastQC 明确接头序列手动补充到 adapters 文件中。SE 模式输出的文件只有修剪后的单端文件没有 paired 和 unpaired 之分所以日志中的处理结果描述也会相应简化。6. 参数调整的几个实战建议6.1 用默认参数优先再用数据和经验微调对于绝大多数标准建库数据LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36这套参数是经过大量文献和生产流程验证的基准。我不建议一上来就大改特改而是先按默认参数跑一遍再看日志和 FastQC 前后对比有的放矢地微调。比如 RNA-seq 数据如果平均 read 长度偏短可以把 MINLEN 降一点某个样本质量波动大可以把 SLIDINGWINDOW 改成4:12提高保留率。6.2 不同数据类型适合的参数组合参考数据类型推荐参数备注标准 RNA-seq双端 150 bpILLUMINACLIP:2:30:10, LEADING:3, TRAILING:3, SLIDINGWINDOW:4:15, MINLEN:36通用型全基因组重测序双端 150 bp同上必要时 MINLEN 提高到 50防止短 read 导致比对噪声单端 small RNAILLUMINACLIP:2:30:10, LEADING:3, TRAILING:3, SLIDINGWINDOW:4:15, MINLEN:18小 RNA 长度短MINLEN 要相应下调低深度/高降解样本降低 SLIDINGWINDOW 到 4:10TRAILING 不变优先保留 reads 数量这张表只是经验的起点不是标准答案。真正的参数取舍永远要结合 FastQC 报告和下游流程需求来定。6.3 保存配置文件保证可复现项目里我会把所用 Trimmomatic 版本、jar 包路径、参数行记录在一个params.txt里每次跑完批处理就把日志文件汇总归档。保存这些元信息对后续排查和论文方法部分写作都很有价值。以前吃过亏某次临时改了一个参数忘了记录后来想复现当时的结果费了好大劲才从日志里反推出来。7. 我自己的使用体会用 Trimmomatic 时间越长越觉得它的设计贴合实际需求双端模式考虑到了“能救就救”的单端保留策略参数顺序设计让每一步操作都有明确作用日志输出又足够直观方便快速判断数据质量。我最深的体会是预处理这一步看似机械但恰恰是决定整个分析流程成败的底层环节——很多下游分析结果异常追根溯源都能回到原始数据没洗干净。所以每次拿到新数据我都愿意花十几分钟先跑一遍 FastQC 和 Trimmomatic把数据脾性摸清楚再决定后续怎么走。刚开始做生信的朋友与其纠结各种高级分析工具不如先把 Trimmomatic 配合 FastQC 这套基本功练扎实后面会少走很多弯路。