1. GATK概述与版本选择
GATK，全称 Genome Analysis Toolkit，在生物信息学里的地位，这么说吧——它就像基因测序数据分析领域的“Linux内核”。不是唯一的选择，但绝大多数pipeline都绕不开它。
我最早接触GATK还是2013年，那时候刚入行做肿瘤样本分析。记得当时最头疼的不是变异检测本身，而是每次跑完流程都不知道结果到底对不对。后来才慢慢悟出来：GATK的厉害之处，不只是算法，而是它背后那套严谨的贝叶斯理论框架。
今天开篇，咱们先把GATK的“家底”摸清楚。版本选不对，后面参数调得再好也是白搭。
1.1 GATK发展史：三个关键节点
GATK的演进，我习惯按“代”来分。每代的底层设计思路都不太一样。
- GATK 1.x - 3.x（Broad Institute 维护期）
奠基阶段。核心算法是 HaplotypeCaller 的前身——UnifiedGenotyper。嗯，那时候还没有深度学习什么事。全部基于经典的贝叶斯模型，计算量巨大但结果稳定。我到现在还记得第一次跑全基因组WGS，整整挂了三天三夜。 - GATK 4.x（2018年起）
架构大改。从单一JAR包拆成多个“工具”模块，引入Spark分布式引擎。主打灵活和可扩展。也是从这一代开始，官方正式推荐用HaplotypeCaller替代早期的 UnifiedGenotyper。 - GATK 5.x+ / funcotator 工具生态
近两年在向“功能注释+临床解读”延伸。GATK本身不再是单纯的变异检测工具，而是变成了一个完整的数据处理平台。
你想想看，一个工具能维持十年以上的迭代，说明它的设计框架足够好。说白了，大部分开发生物信息学工具的人都会参考GATK的架构设计。
1.2 不同版本特性对比
版本选择这事，我踩过不少坑。下面这张表是我个人的使用总结:
| 版本 | 核心引擎 | 推荐使用场景 | 我个人不建议的场景 |
|---|---|---|---|
| GATK 3.x | MapReduce（队列调度） | 旧流程维护、不支持Java 11的环境 | 新项目、大数据量WGS |
| GATK 4.x | Spark + 本地模式 | 大部分生产流程、肿瘤-正常配对分析 | 内存极小的HPC集群 |
| GATK 5.x (alpha) | Spark + 模块化工具 | 需要funcotator内置注释的场景 | 尚未稳定，不建议生产环境 |
我的建议：如果你的项目从零开始，选 GATK 4.2.x 或 4.3.x，这是当前最成熟、社区支持最完善的版本。我最近三个项目都用的 4.2.6.1，没出过兼容性问题。
1.3 参数优化场景归纳
为什么同一个工具，同一个参考基因组，不同人跑出来的结果差距会那么大？
问题出在参数上。GATK的默认参数是“通用”的，不是“最优”的。我归纳了几类必须优化参数的场景：
- 数据质量问题
测序深度低（<20X）或碱基质量分布不均匀时，默认的--min-confidence阈值可能过滤掉真实变异，或者保留太多假阳性。 - 样本类型特殊
比如肿瘤样本的Mutect2参数，需要根据肿瘤纯度调整-- contamination-fraction。我做过一个30%纯度的样本，默认0.02的污染率参数完全不行，改到0.1后结果才正常。 - 计算资源受限
内存不够时，GATK的Spark模式需要调整--spark-master和--conf中的shuffle分区。闭着眼睛默认跑，OOM是家常便饭。 - 窗口化/并行化的粒度
GATK 4.x的最大优势是可以把基因组切块并行。但--intervals如何切，切多大，直接决定运行速度和资源利用率。我习惯切成20-30MB的区间，太大容易内存溢出，太小又频繁启动任务。
一个实用的经验：当你想优化参数时，先在1%的基因组区域上跑，验证效果再全量跑。我遇到过最惨的教训就是直接全基因组上试参数，跑了三天发现全错。
1.4 本章知识体系
下面这张图是我自己整理的，把GATK版本演进和参数优化的关系画清楚了。你一看就明白。
我曾经犯过的错：在GATK 3.8的旧流程上直接升级到GATK 4.2，没注意到 HaplotypeCaller 的 --emit-ref-confidence 参数默认值变了。结果输出的GVCF文件格式不兼容，下游合并全废。教训就是：版本切换后一定要在小样本上做一次完整端到端测试。
总结一下这章的核心：GATK不是铁板一块的工具，版本不同决定了你能用的参数类别和优化方向。记住，再好的参数策略，在错的版本上都是徒劳。