测序数据格式详解：FASTQ文件结构
说实话，拿到测序原始数据的第一眼，很多人都会被那一堆乱码似的字母吓到。我刚开始做RNA-seq时也是这样，总觉得这玩意儿跟天书似的。但说白了，FASTQ就是测序仪吐出来的"原始口供"，里面既记录了每一条reads的碱基序列，也给出了每个碱基的测序质量——这两样东西，少了谁都不行。
FASTQ的"四行一首"结构
一个标准的FASTQ文件，每四条记录对应一条read。你拿任何文本编辑器打开看一眼，马上就能发现规律：
@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG
CTACGTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGC
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII看清楚了吗？第1行以@开头，是序列标识符（也叫read header）；第2行是碱基序列；第3行是一个+号，有时后面会跟重复的标识符；第4行是质量得分字符串，每个字符对应第2行对应位置的碱基质量。
我个人习惯，一拿到FASTQ文件就先检查这四行是否完整。如果有空行或者行数不是4的倍数，大概率是文件传输损坏了。我在一个合作项目中遇到过这种情况，测序公司传过来的文件缺了最后一行，结果后续的比对直接报错，排查了好几天才发现是FASTQ结构不对。
标识符行的"暗号"
标识符行藏着很多信息。以Illumina为例，典型的header长这样：
@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG冒号分隔的字段含义如下：
| 字段 | 含义 |
|---|---|
| EAS139 | 仪器名称/编号 |
| 136 | Run号 |
| FC706VJ | Flow cell ID |
| 2 | Lane编号 |
| 2104 | Tile编号 |
| 15343 | X坐标 |
| 197393 | Y坐标 |
| 1:Y:18:ATCACG | Pair成员(1或2)、是否通过过滤(Y/N)、索引号、barcode序列 |
这些东西看起来啰嗦，但做质控时特别有用。比如你可以根据Lane和Tile信息判断某个区域是不是存在系统性偏差。有一次我在做ChIP-seq时，发现某个tile的reads质量普遍偏低，后来发现是测序时那个区域出了气泡——这些信息都是从header里挖出来的。
碱基序列行：ATCG的世界
序列行很简单，就是A、T、C、G、N（N表示无法确定的碱基）组成的字符串。长度取决于测序读长，目前RNA-seq常见的是150bp或100bp双端。单端的话就一条序列，双端则每个片段前后各一条。
这里要提一个坑：某些早期的测序平台会使用.代替N。如果你从旧数据集里读到小数点，别以为是格式错误，那是另一套表示法。不过现在基本统一用N了。
质量得分行：读懂测序仪的"信心指数"
第4行是最容易被人忽略的，但它恰恰决定了后续分析的可信度。每个字符对应一个Phred质量得分（Q值），公式很简单：
Q = -10 × log10(P)其中P是该碱基测序错误的概率。举个例子：Q=30表示错误概率为0.001（千分之一）。
质量字符和Q值的对应关系取决于编码方案。目前主流的是Phred+33编码，也叫Sanger编码：字符的ASCII码减去33就是Q值。比如字符!的ASCII码是33，对应Q=0；字符I的ASCII码是73，对应Q=40。你想想看，测序仪直接输出ASCII字符，就是为了节省空间——每个字符正好一个字节。
快速判断编码方案
拿到一个未知的FASTQ文件，先看质量字符的范围：
- 如果字符主要在
!到I之间（ASCII 33-73），就是Phred+33 - 如果字符从
@开始（ASCII 64），可能是Phred+64（老式Illumina格式） - 现在99%的情况是Phred+33，但不要完全信任，用工具检查一下最保险
质量值的"隐秘语言"
我建议你用肉眼扫一眼质量行，就能看出大致情况。好的数据质量行是一串I或F（Q值40左右），越到3'端字符会逐渐"掉下来"变成B、?甚至!——这说明测序质量随着读长增加而衰减，正常现象。如果整个质量行从第1个字符就偏低，那你得警惕了。
曾经我处理过一批肿瘤RNA-seq数据，质量行前面全是#和$（Q值10以下），当时觉得不对劲，一查记录发现是建库时接头污染导致测序仪"读偏了"。所以别光盯着序列看，质量行才是真正的诊断利器。
常见的FASTQ格式变种
| 编码方案 | Q值范围 | ASCII偏移量 | 典型字符 |
|---|---|---|---|
| Sanger / Phred+33 | 0 – 40 | 33 | ! " # $ % & ' ( ) * + , - . / 0-9 : ; < = > ? @ A-I |
| Solexa / Illumina 1.0 | -5 – 40 | 64 | ; < = > ? @ A-h |
| Illumina 1.3+ / Phred+64 | 0 – 40 | 64 | @ A-B ... h |
| Illumina 1.5+ / Phred+64 | 2 – 40 | 64 | B C D ... h |
| Illumina 1.8+ / Phred+33 | 0 – 41 | 33 | ! " # ... J |
核心要点
- 当前绝大多数数据使用Phred+33（Sanger/Illumina 1.8+）
- 如果质量字符范围异常（如包含大括号、竖线等），需要检查编码
- 使用
fastQValidator或seqtk fqchk可以自动判断编码
如何"一眼看穿"一个FASTQ文件
在实际项目中，我通常这样快速检查：
- 用
head -n 20看了前几条记录 - 扫一眼标识符格式，确认测序平台
- 数一下质量字符的最低和最高ASCII码
- 用
awk 'NR%4==0 {print length}' file.fastq | sort | uniq -c确认所有read长度一致 - 用
wc -l除以4得到read总数
这些操作不需要任何生物信息学软件，一个终端加几个管道命令就能搞定。嗯，这里要注意：如果发现有些read长度不一致，可能是测序仪在末端提前终止了，这种数据在做比对前需要做trimming。
FASTQ文件内部结构一览
常见陷阱
- 不要混淆FASTQ和FASTA：FASTQ有质量行，FASTA没有
- 双端测序会产生两个FASTQ文件（R1和R2），两者的read顺序必须严格一致
- 压缩格式通常是
.fastq.gz，解压前用zcat或seqtk处理 - 我曾经碰到过FASTQ文件被从Windows传到Linux时换行符变成
\r\n，导致解析报错——先跑个dos2unix再干活
实战：用一行命令检查FASTQ质量概况
别急着写大脚本，先用seqtk看个概览：
# 安装seqtk（如果还没有）
conda install -c bioconda seqtk
# 查看质量统计
seqtk fqchk sample.fastq.gz
# 输出示例（截取关键行）
# min_len: 150 max_len: 150 avg_len: 150
# qual: 36.2 min_qual: 12 max_qual: 41
# base_N: 0.02%平均质量在36以上（Q36对应错误概率0.00025），说明数据很干净。如果平均质量低于30，我建议你先把QC报告跑出来看看具体问题出在哪。
说到这个，我记得有一次帮同事看数据，平均质量显示29.5，但实际是编码判断错误——工具自动识别成了Phred+64，而真实数据是Phred+33。所以自己手动检查一下质量字符范围，永远比完全相信自动检测要靠谱。
总结：FASTQ文件就是你的"测序日志"
每一条记录都记录了测序仪当时对那个片段的"所见"和"信心"。做RNA-seq分析的起点，就是理解并验证这个结构。从标识符提取样本信息，从序列行读取生物学内容，从质量行判断数据可靠性——三者缺一不可。下次收到数据时，先把FASTQ的这四行结构刻在脑子里，后续的质量控制、比对、定量才不至于在第一步就翻车。