6月，我们宣布了基因组学的统一分析平台，目标很简单：利用大规模交互式基因组数据处理、分析和人工智能的协作平台加速发现。在这篇文章中，我们将更详细地介绍这个平台的一个组件：一个可伸缩的DNASeq管道，它与GATK4以最好的速度一致。在尺度上理解序列数据绝大多数基因组数据来自大规模的并行测序技术。在这项技术中，样本DNA必须首先被切成大约100个碱基对的短片段。测序器将为每个片段发出遗传序列。为了纠正测序错误，我们通常要求基因组中的每个位置至少包含30个这样的片段。因为人类基因组中大约有30亿个碱基对，这意味着测序后，我们必须重新组合30亿/100*30=9亿个短读，然后才能开始真正的分析。这是不小的努力。因为这个过程对于任何处理DNA数据的人来说都是很常见的，所以制定一个合理的方法是很重要的。Broad Institute的GATK团队在描述处理DNASeq数据的最佳实践方面走在了前列，如今许多人要么运行GATK本身，要么运行GATK兼容的管道。在高水平上，该管道包括3个步骤：将每个简短的读数与参考基因组对齐将统计技术应用于具有某些变量读数的区域，以确定与参考值存在真实差异的可能性用诸如它影响哪种基因的信息注释变异位点处理DNASeq数据的挑战尽管DNASeq管道的组件已经被很好地描述，但我们发现，我们的许多客户都面临着将其管道扩展到不断增长的数据量的共同挑战。这些挑战包括：基础设施管理：我们的许多客户在其本地高性能计算（HPC）集群上运行这些管道。然而，HPC集群并不是弹性的-你不能根据需求快速增加大小。在最好的情况下，数据量的增加会导致请求的队列变长，从而导致等待时间变长。在最坏的情况下，客户会与影响生产率的昂贵停机作斗争。即使是那些已经将工作负载迁移到云端的公司，人们花在编写配置文件和执行有价值的分析上的时间也是一样多的。数据组织：生物信息学家习惯于处理各种各样的文件格式，如BAM、FASTQ和VCF。但是，当样本数达到某个阈值时，管理单个文件变得不可行。为了缩放分析，人们需要更简单的抽象来组织他们的数据。性能：每个人都关心其管道的性能。传统上，每个基因组的价格是最重要的考虑因素，尽管随着临床使用案例的成熟，速度变得越来越重要。当我们看到这些挑战在不同的组织中反复出现时，我们意识到有机会利用我们作为大型数据处理和机器学习的领先引擎Apache SparkTM的最初创造者的经验，以及Databricks平台，帮助我们的客户快速、大规模地运行DNASeq管道，而不会带来操作上的麻烦。我们的解决方案我们已经建立了第一个与GATK4最佳实践相一致的水平可伸缩管道。我们使用Spark高效地切分每个样本的输入数据，并将其传递给单节点工具，如BWA-MEM进行对齐，GATK的单倍型调用者用于变量调用。我们的管道作为一个Databricks作业运行，因此平台可以在不需要用户干预的情况下处理基础设施的供应和配置。当新数据到达时，用户可以利用restapi和Databricks CLI启动新的运行。当然，这条管道只是从基因组数据中获取生物学见解的第一步。为了简化下游分析，除了输出熟悉的格式（如VCF文件）外，我们还将对齐的读取（称为变量）和带注释的变量写入高性能Databricks Delta parquet表中。由于所有样本的数据都在一个单一的逻辑表中可用，因此很容易将基因变体与有趣的来源（如医学图像和电子病历）连接起来，而无需对数千个单独的文件进行纠结。然后，研究人员可以利用这些联合数据集来搜索一个人的遗传密码和属性之间的相关性，比如他们是否有某种疾病的家族史。基准测试我们的DNASeq管道准确度由于DNASeq管道的输出可用于重要的研究和临床应用，因此准确性至关重要。与精心策划的高置信度变量调用相比，我们管道的结果达到了高精度。请注意，这些结果不包括任何变量分数重新校准或硬过滤，这将通过消除假阳性进一步提高精度。精密度召回F分数SNP公司99.34%99.89%99.62%索引99.20%99.37%99.29%Concordance vs GIAB NA24385 PrecisionFDA Truth Challenge数据集（根据意外事故)性能对于我们的基准测试，我们将我们的DNAseq管道与Edico Genome的FPGA实现与代表性的全基因组和全外显子组数据集进行了比较。我们还针对GIAB的300x覆盖率数据集测试了我们的管道，以展示其可伸缩性。每次运行包括最佳实践质量控制措施，如重复标记。此表不包括变量注释时间，因为并非所有平台都包括它。在这些实验中，Databricks集群直接读写S3。对于运行Edico或OSS GATK4，我们将输入数据下载到本地文件系统。下载时间不包括在下面的运行时中。根据Edico的文档，该系统可以流式传输来自S3的输入数据，但我们无法使其正常工作。我们在Databricks中使用spot实例，因为集群将自动从spot实例终止中恢复。以下计算成本仅包括AWS成本；不包括平台/许可费。30倍覆盖全基因组站台参考置信码集群运行时近似计算成本速度提升数据块VCF公司13 c5.9X大型（416芯）24平方米292.88美元3.6倍于洋VCF公司1个f1.2XL（fpga）1小时27米2.40美元–数据块全球价值链13 c5.9X大型（416芯）39平方米234.64美元3.8倍于洋全球价值链1个f1.2XL（fpga）2小时29米4.15美元–30倍覆盖整个外显子站台参考置信码集群运行时近似计算成本速度提升数据块VCF公司13 c5.9X大（416芯6米36秒0.77美元3.0倍于洋VCF公司13 c5.9X大（416芯19米31秒0.54美元–数据块全球价值链13 c5.9X大型（416芯）7米22秒0.86美元3.5倍于洋全球价值链1 f1.2XL25立方米0.71美元–300倍覆盖全基因组站台参考置信码集群运行时近似计算成本速度提升数据块全球价值链50 c5.9X大（1600芯）2小时34米69.30美元（没有这种规模的竞争解决方案）在大致相同的计算成本下，我们的管道通过水平缩放获得更高的速度，同时与GATK4保持一致。随着数据量或时间敏感性的增加，通过增加集群大小来增加额外的计算能力是很简单的，这样可以在不牺牲精度的情况下加速分析。技术和优化切分变体调用尽管GATK4包含了它常用的单倍型调用者的Spark实现，但它目前处于beta测试阶段，并且被标记为对实际用例不安全。在实践中，我们发现该实现与单节点管道不一致，并且运行时长且不可预测。为了扩展变量调用，我们在sparksql的基础上实现了一种新的分片方法。我们添加了一个催化剂生成器，它可以有效地将每个短读映射到一个或多个填充的容器中，每个容器包含大约5000个碱基对。然后，我们重新分区并按bin id排序，并在每个bin上调用单节点单倍型调用者。Spark SQL进行简单转换我们的第一个实现使用ADAM项目进行简单的转换，比如在不同的变量表示之间转换和分组成对的结束读取。这些转换通常使用Spark的rddapi。通过将它们重写为sparksql表达式，我们节省了CPU周期并减少了内存消耗。优化的基础设施最终，我们设法减少了数据移动开销，几乎所有的CPU时间都花在运行核心算法上，比如BWA-MEM和单倍型调用者。在这一点上，我们没有优化这些外部应用程序，而是将重点放在优化配置上。因为我们控制了流水线包装，所以我们可以只做一次这一步，这样我们所有的用户都能受益。最重要的优化集中在减少内存开销上，直到我们可以利用高CPU虚拟机，后者每核价格最低，但内存最少。一些有用的技术包括通过尽早绑定参考区域来压缩GVCF输出，以及修改SnpEff变量注释库，以便在执行器线程之间共享内存数据库。所有这些优化（以及更多）都内置在我们的DNASeq管道中，为以业界领先的速度、精度和成本处理和分析大规模基因组数据集提供现成的解决方案。试试看！我们的DNASeq管道目前可作为基因组学统一分析平台的一部分进行私人预览。如果您有兴趣使用该平台进行旋转，请填写预览申请表，或者访问我们的基因组解决方案页面了解更多信息。免费试用Databricks。今天就开始吧