数据质控概述与常用工具

测序仪下机的那一瞬间，你手里的 FASTQ 文件其实并不干净。接头残留、低质量碱基、甚至还有 PCR 引入的重复——这些东西不清理，下游的比对和变异检测全得翻车。

我做生物信息管线多年，踩过最大的坑就是跳过质控直接跑分析。结果呢？垃圾进，垃圾出，浪费几天时间重跑。嗯，从那以后我定了个死规矩：跑任何分析前，先花 15 分钟做质控。

质控到底在干什么？

说白了就三件事：

  • 看清数据质量——每个碱基的 Q 值分布如何？有没有 GC 含量异常？
  • 去除污染与低质量片段——接头、引物二聚体、N 占比过高的 reads 统统干掉。
  • 汇总成可读报告——多个样本的质控结果合在一起，一眼看出哪个批次有问题。

你想想看，如果 100 个样本里有一个文库出问题了，没做质控的话你根本不知道。我曾经就因为一个样本的接头没切干净，整组差异基因分析的假阳性率飙升到 40%——教训惨痛。

核心流程：原始 FASTQ → FastQC 对每个样本出报告 → Trimmomatic 清洗 → 再次 FastQC 确认干净 → MultiQC 汇总全部样本。

FastQC：第一道安检

FastQC 是什么？一个轻量级的 Java 工具，跑一条记录几秒钟，输出一个 HTML 报告。它检查 11 项指标，最关键的几个我列出来：

模块检查内容常见红灯信号
Per base sequence quality每个碱基位置的 Q 值箱线图尾部 Q 值低于 20 说明测序长度过长或试剂降解
Per sequence GC content整条 read 的 GC 含量分布出现双峰，可能是污染或 PCR 偏好
Adapter Content接头序列富集情况超过 5% 必须用 Trimmomatic 切除
Overrepresented sequences出现频次极高的短序列通常就是未切除的接头

用法极其简单：

fastqc sample_R1.fastq.gz sample_R2.fastq.gz -o fastqc_results/

我个人习惯同时跑 4 个样本，用 -t 4 参数多线程加速。注意输出目录要提前建好，否则它会直接扔在当前目录，乱得很。

技巧：对双端数据一定要同时跑 R1 和 R2。我曾经只跑了 R1，结果 R2 的接头残留完全没发现，浪费了两天时间分析错误数据。

Trimmomatic：剪刀手工具

Trimmomatic 是我最顺手的清洗工具。它支持双端模式，能同时切接头、滑窗裁剪、过滤短 reads。一句话总结：把低质量区域切除，把长度不足或过短的 read 对扔掉。

典型的命令行长这样：

java -jar trimmomatic-0.39.jar PE \
  sample_R1.fastq.gz sample_R2.fastq.gz \
  sample_1P.fastq.gz sample_1U.fastq.gz \
  sample_2P.fastq.gz sample_2U.fastq.gz \
  ILLUMINACLIP:TruSeq3-PE.fa:2:30:10 \
  LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36

参数解释清楚就不用背：

  • PE 表示双端，SE 是单端。
  • ILLUMINACLIP 后面是接头文件、允许的最大错配数和罚分阈值。我一般用 2:30:10，很稳。
  • LEADING:3 切除开头的低质量碱基（Q<3）。TRAILING:3 同理切尾部。
  • SLIDINGWINDOW:4:15 以 4 个碱基为窗口，平均 Q 低于 15 就切掉。
  • MINLEN:36 过滤掉裁剪后长度小于 36bp 的 read 对。

我用这个组合跑几十个公共数据集，从来没有翻过车。

注意：双端模式输出四个文件——P（paired）和 U（unpaired）。清洗后一定要确认 R1 和 R2 的 read 数目一致，否则后续比对会报错。我曾经有一次忘记检查，BWA 直接崩了。

MultiQC：多合一雷达

当你有几十个样本时，挨个看 FastQC 的 HTML 报告会疯掉。MultiQC 就是干这个的——它会扫描整个目录，把所有 FastQC、Trimmomatic、甚至后来用到的 STAR、BWA 的日志全收进来，生成一个超清爽的网页报告。

用法只有一行：

multiqc . -o multiqc_report/

它会自动找当前目录下所有 fastqc_data.txt、trimming 的 log 文件。我个人习惯在项目根目录建一个 qc/ 子目录，把 FastQC 和 Trimmomatic 的输出全放进去，然后运行 multiqc qc/，干净利落。

MultiQC 的三大杀招：

  • 全局概览：一个表格列出每个样本的 read 数、GC%、Q30 比例，排序后一眼看出异常值。
  • 交互式图表：点击单个点就能跳转到对应的 FastQC 详细报告。
  • 清洗前后对比：把 raw 和 cleaned 的结果放在同一个 MultiQC 报告里，效果立竿见影。

我记得有一次帮同事排查一批 RNA-seq 数据，MultiQC 的 Q30 柱状图里有个样本明显偏低，点进去发现是测序孔道堵塞。如果不用 MultiQC 汇总，我可能得手动翻 20 个 HTML 文件才能发现这个问题。

质控流程总图

下面这张 SVG 把整个质控管线串联起来。你照着这个顺序走，基本不会踩坑。

数据质控核心流程 原始 FASTQ FastQC 单样本报告 Trimmomatic 清洗 再次 FastQC 确认干净 MultiQC 汇总报告 左侧为并行路径： 多个样本同时跑 FastQC 清洗参数可写在 YAML 中 以便 Docker 环境复现

用 Docker 封装质控套件

既然我们在讲 Docker 管线，当然要把这套工具容器化。写一个 Dockerfile，把 FastQC、Trimmomatic、MultiQC 还有必要的接头文件都装进去：

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
    openjdk-11-jre-headless \
    python3 python3-pip \
    wget unzip \
 && rm -rf /var/lib/apt/lists/*

# FastQC
RUN wget -q https://www.bioinformatics.babraham.ac.uk/projects/fastqc/fastqc_v0.12.0.zip \
 && unzip fastqc_v0.12.0.zip \
 && chmod +x FastQC/fastqc \
 && mv FastQC /opt/fastqc \
 && ln -s /opt/fastqc/fastqc /usr/local/bin/fastqc

# Trimmomatic
RUN wget -q https://github.com/usadellab/Trimmomatic/raw/0.39/Trimmomatic-0.39.zip \
 && unzip Trimmomatic-0.39.zip \
 && mv Trimmomatic-0.39 /opt/trimmomatic

# multiqc
RUN pip3 install multiqc

ENV PATH="/opt/fastqc:/opt/trimmomatic:${PATH}"
WORKDIR /data

构建镜像：docker build -t qc-pipeline:1.0 .。之后跑一个样本只需要：

docker run --rm -v $(pwd)/data:/data qc-pipeline:1.0 \
  bash -c "fastqc /data/sample.fastq.gz -o /data/qc && \
           java -jar /opt/trimmomatic/trimmomatic-0.39.jar \
           SE /data/sample.fastq.gz /data/cleaned.fastq.gz \
           LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36 && \
           multiqc /data -o /data/multiqc"

为什么这样封装？ 因为不同的项目可能使用不同版本的 Trimmomatic（比如 0.38 vs 0.39）。容器化之后，你跟合作者之间再也不会出现“我这边跑出的结果不一样”的问题。版本锁死，复现无忧。

好了，这一章基本把质控的核心工具和流程捋清楚了。你只需要按图索骥：FastQC 做初检 → Trimmomatic 清洗 → MultiQC 汇总 → 确认数据干净。把这个步骤嵌到你的 Docker 容器里，整个管线就稳了一半。

← 上一章 📖 返回目录 下一章 →