1. 长读长WGS分析流程工程导论
长读长全基因组测序（Long-read WGS）正在从“能测”走向“能稳定交付”。它带来的不只是读长变长，而是整套分析工程范式的改变：输入数据的错误结构不同、比对与变异检测算法不同、计算资源画像不同、结果判读的边界也不同。本课程的目标不是罗列工具，而是把长读长WGS当作一条可复现、可观测、可扩展的工程流水线来建设。
一、长读长测序技术原理：读长换来了什么
当前主流长读长平台分为两大类。以PacBio HiFi为代表的方案，通过环形一致性测序（CCS）对同一DNA分子多次读取后取共识，单条读长通常在10–20 kb，碱基准确率可达99.9%以上，错误以少量插入缺失为主且近似随机分布。以Oxford Nanopore（ONT）为代表的方案，直接读取核酸分子穿过纳米孔时的电流信号变化，读长可达数十至上百kb，原始单读准确率约90%–97%，经R10.4.1化学与高精度basecalling后可提升至99%左右，错误更集中于同聚物区域。
理解这一差异对工程至关重要：HiFi的“高准确率+中等读长”适合以SNV/indel和小结构变异为主的分析；ONT的“超长读长+略低准确率”在跨越复杂重复、大片段缺失、平衡易位和甲基化联合分析上更有优势。二者不是替代关系，而是根据目标变异类型选择或组合。
二、WGS分析全流程概览
一条完整的长读长WGS流程可以拆成六个阶段，每个阶段都有明确的输入、输出和验收标准：
- 原始数据与质控：输入为pod5/fast5或subreads.bam，经basecalling得到FASTQ。质控关注读长N50、Q值分布、接头残留和污染。常用NanoPlot、Chopper或NanoFilt按长度与质量过滤。
- 比对与排序：推荐minimap2的map-hifi或map-ont预设，输出BAM后经samtools排序、去重（如Picard MarkDuplicates或samtools markdup）。
- 变异检测：SNV/indel可用Clair3、DeepVariant；结构变异用Sniffles2、cuteSV或SVIM；拷贝数用CNVnator或HiFiCNV。
- 变异过滤与分型：结合深度、支持读段数、基因型质量（GQ）和人群频率过滤，输出VCF。
- 注释与解读：用VEP或SnpEff注释，结合表型做优先级排序。
- 报告与归档：生成可追溯的QC报告、VCF、BAM索引和运行日志。
下面这张图把上述阶段与关键输入输出、验收点串成一条数据流，便于在工程实现时对照检查：
三、工程化思维：从脚本到流水线
很多团队第一次跑长读长WGS时，往往在一台服务器上用几条命令就能出结果。但当样本量从1个变成100个、从单一平台变成HiFi与ONT混合、从一次性分析变成每月例行交付时，问题会集中暴露：版本不一致导致结果漂移、中间文件散落无法追溯、单点故障让整批任务重跑、资源争抢拖垮集群。工程化的本质，是把“能跑通”变成“可重复、可观测、可扩展”。
具体落地时，建议抓住四个抓手。第一，流程描述与执行分离：用Nextflow或Snakemake把每个步骤写成带输入输出声明的process/rule，而不是一长串shell。第二，环境与版本锁定：用conda、容器或模块系统固定minimap2、Clair3、Sniffles2等工具版本，并在报告中记录。第三，资源画像与调度：长读长比对内存消耗大，minimap2对人类基因组约需30–50 GB，basecalling建议GPU；应在流程中声明CPU、内存、GPU需求，交给Slurm或K8s调度。第四，可观测性：每个样本产出统一的QC指标文件，失败时能定位到具体阶段而非整条流程。
四、核心挑战与应对思路
长读长WGS工程化面临几类典型挑战。其一是计算成本：basecalling和比对是两大耗时环节，GPU加速与增量处理是常见优化方向。其二是变异检测的准确性边界：HiFi在SNV上已接近短读长水平，但ONT在低覆盖或同聚物区域的假阳性仍需谨慎过滤。其三是结构变异的标准化：不同工具输出的SV表示方式不统一，需要统一到VCF 4.3或使用SVbench等工具做规范化。其四是数据管理与合规：原始信号文件体积大，需制定保留策略；人类样本还涉及隐私与伦理要求。
应对这些挑战，核心原则是“先定义验收标准，再选择工具与参数”。例如，若目标是临床级SNV检测，应优先保证覆盖度与Q值，选择Clair3并严格过滤；若目标是群体结构变异图谱，则应接受略低的单碱基精度，换取更长的读长和更高的SV召回。工程决策永远服务于分析目标，而不是反过来。