1. FASTQ 格式入门：文件结构、质量编码、常见格式问题
大家好，欢迎来到《从FASTQ到VCF》这门课。第一站，我们先聊聊测序数据的起点——FASTQ 文件。
嗯，这玩意儿说白了就是测序仪吐出来的原始数据。你想想看，一次测序跑下来，动辄几十个G，里面藏着基因组的秘密，但也可能藏着让你头疼的坑。我个人习惯，在处理任何测序数据之前，第一件事就是先检查FASTQ文件长什么样，质量行不行。这步省了，后边分析出问题你都不知道从哪追。
1.1 什么是FASTQ？
FASTQ 格式是由 Wellcome Trust Sanger Institute 的 Jim Mullikin 和 Simon Dear 在1999年左右提出的。目的很单纯——给核酸序列追加一个“质量分数”。
在这之前，大家用 FASTA 格式，只有序列信息，好坏全靠猜。FASTQ 的出现，相当于给每个碱基配了一张“体检报告”。
我记得以前处理一个古老的公共数据集，下载下来才发现是旧版FASTA，硬生生要自己去写脚本模拟质量值。浪费时间不说，还引入额外误差。现在有了FASTQ，至少有了统一的标准。
1.2 文件结构：四行一条记录
一个标准的FASTQ文件，每一条read（读长）有四行。看着简单，但每一行都有讲究。
@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG
CTACGTCCGTACGTCCGTACGTCCGTACGTCCGTACGTCCGTACGTCCG
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII我们拆开来看看：
- 第一行（@行）：序列标识符。以 @ 开头，后面跟着测序仪的信息，比如仪器ID、Flowcell编号、坐标等。不同厂家格式略有不同，但基本都能追溯到是哪台机器、哪个簇（cluster）产的。
- 第二行（序列行）：实际的碱基序列。由 A、T、C、G 以及 N 组成。N 代表测序仪无法确定该位置是哪个碱基。
- 第三行（+行）：通常只有一个 + 号。按规范，+ 号后面可以重复第一行的标识符，但我见过99%的情况都是空的。不过这不影响解析。
- 第四行（质量行）：质量分数行。每个字符对应第二行对应位置的质量值。字符数必须和序列行严格相等。这里最容易出错，后面会讲。
| 行号 | 示例 | 字段 |
|---|---|---|
| 1 | @EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG | 序列标识符 |
| 2 | CTACGTCCGTACGTCCGTACGTCCGTACGTCCGTACGTCCGTACGTCCG | 碱基序列 |
| 3 | + | 分隔符 |
| 4 | IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII | 质量分数（ASCII编码） |
⚠️ 特别提醒： @ 和 + 开头的行，如果序列标识符以 @ 开头，那么第四行以 + 开头是合法的。但大量解析器会忽略 + 后面的内容。我个人建议别在 + 后面加东西，能省很多麻烦。
1.3 质量编码：从 ASCII 字符到 Phred 值
质量行里的那些字符，其实是对应着一个个数字。这个数字就是 Phred 质量分数，计算公式是：
Q = -10 * log10(P)P 是该碱基测错的概率。嗯，这里要注意：Q值越高，代表测错的概率越低。比如 Q30 表示错误率是 1/1000，也就是千分之一。Q20 就是 1/100，百分之一。
为什么会用到 ASCII 码？因为早期的存储介质和软件对二进制支持不好，把 Phred 值加上 33 或 64 再转成 ASCII 字符，是最通用的办法。不同时期的测序仪用了不同的编码方案。这曾让很多新手栽跟头。
我当年处理一个来自 Illumina Genome Analyzer II 的老项目，上来就用现代脚本解析，结果发现质量全是乱码。折腾半天才发现那是旧版 Phred+64 编码，不是现在主流的 Phred+33。
1.4 常见质量编码体系对比
| 编码体系 | ASCII 偏移量 | Phred 范围 | 代表仪器/时代 |
|---|---|---|---|
| Sanger / Illumina 1.8+ | 33 | 0 ~ 41 | 目前主流，几乎所有新数据都用这个 |
| Illumina 1.3 ~ 1.7 | 64 | 0 ~ 61 | 早期SoLexa/Illumina 数据 |
| SoLexa / Illumina 1.0 ~ 1.2 | 64 + 舍入 | -5 ~ 40 | 最早的SoLexa系统，几乎淘汰 |
💡 怎么快速判断？试试这个：看质量行里有没有小于 'I'（ASCII 73）的字符。如果有，那基本都是 Phred+33 体系。如果全是 'K' (ASCII 75) 以上的字符，很可能是 Phred+64。跑一下 fastqc 是最稳的办法。
1.5 常见格式问题与避坑指南
实战中，FASTQ 文件经常会出现各种小毛病。你不修复它，流程跑着跑着就崩了。我来列几个最常见的：
- 行数不对：FASTQ 必须 4 行一组。如果文件末尾多了空行或者少了一行，很多解析器会报错。我曾经因为一个尾随换行符的问题，排查了整整半天。解决方法：永远用
zcat配合wc -l检查行数是否能被 4 整除。 - 序列行和质量行长度不一致：这条特别隐蔽。序列有100个碱基，质量行却有101个字符。这种情况往往是因为测序仪在末尾加了空格或换行符，但脚本没处理好。我会写一个简单命令快速扫描：
awk 'NR%4==2{seq_len=length($0)} NR%4==0{if(length($0)!=seq_len) print "Mismatch at record", int(NR/4)}'。 - 非法碱基字符：FASTQ 标准只允许 A、T、C、G、N。但偶尔你能见到 IUPAC 模糊编码（R、Y、S、W 等）。多数比对软件会直接忽略或报错。处理前最好去掉这些。
- 质量值负值截断：SoLexa 编码体系允许负 Phred 值，但转换成 ASCII 后可能出现不可打印字符。现代解析器需要特殊处理。不过这种情况你基本碰不到了。
图里很清楚，FASTQ记录就像一条流水线，四行都对了，才能往下走。序列行和质量行的长度一致性是生命线，一错全盘皆输。
1.6 用一行代码验证 FASTQ 质量
你在拿到一个新数据集时，我建议第一时间跑一下 fastqc，或者直接用这个快速检查脚本，初步看看这四行结构是不是完整。如果发现任何异常，趁早处理。
awk '
BEGIN{ok=1}
NR%4==1 && $0 !~ /^@/{ok=0; print "Line "NR": expected @-line"; exit}
NR%4==3 && $0 !~ /^\+/{ok=0; print "Line "NR": expected +-line"; exit}
END{if(ok) print "File looks like valid FASTQ (structure check passed)"}
' sample.fastq❗ 核心要领：FASTQ 的结构错误大部分集中在行数不对、质量行与序列行长度不一致、以及@/+行前缀混淆。花几分钟用脚本扫描一遍，可以避免后续流程莫名其妙崩溃。
1.7 小结
这章我们聊了FASTQ的起源、四行结构、质量编码的数学逻辑，还排了常见的坑。嗯，说实话，格式本身不复杂，但细节决定成败。尤其是当你需要在一台没有图形界面的计算集群上调试流程时，理解这些底层逻辑会大大减少你的查错时间。