Microsoft Azure

Azure HDInisght

Work in progress

Genomic and Clinical Data

For this proof of concept (PoC) we loaded all the genomic variants of about 4,700 genomes from Genomics England, variants were loaded and indexed in the development version OpenCGA 2.0.0-beta. In total we loaded about 208 million unique variants from 4,700 gVCF files accounting for about 20TB of compressed disk space. It is worth noting that these files were generated using Dragen 2.x and the are unusually big, about 5-6GB per file.

Platform

For this proof of concept (PoC) we used the development version OpenCGA v2.0.0-beta using the Hadoop Variant Storage Engine that uses Apache HBase as back-end. We also used CellBase 4.6 for the variant annotation.

For the platform we used a 10-nodes **[Azure HDInsight](https://azure.microsoft.com/en-gb/services/hdinsight/) 3.6 cluster using [Data Lake Storage Gen2](https://docs.microsoft.com/en-gb/azure/storage/blobs/data-lake-storage-introduction). HDInsight 3.6 uses [Hortonworks HDP](https://www.cloudera.com/products/hdp.html) 2.6.5 (with Hadoop 2.7.3 and HBase 1.1.2**) and we used Azure Batch for loading concurrently all the VCF files which had been copied previously to a NFS server, you can see details here:

Initially, we evaluated the new HDInsight 4.0, although it worked quite well there were some few minor issue, so for this PoC we decided to use the more stable HDInsight 3.6 (HDI3.6) over Data Lake Gen2 (DL2), we will refer to this as HDI3.6+DL2. During the PoC we worked with Azure engineers to debug and fix all these issues, unfortunately we did no have time to repeat the benchmark.

As you will see below in the Analysis Benchmark section, once we completed the PoC we increased the size of HDInsight to 20 nodes and repeated some tests to study the performance improvement.

Genomic Data Loading and Indexing

In order to study the loading performance we set up a Azure Batch queue of 20 computing nodes. This allowed us to load multiple files at the same time from different servers. We configured Azure Batch to load 1 VCF file per node resulting in 20 files being loaded in HBase simultaneously. During the load we studied two different configurations:

Loading VCF files vs. loading transformed files
Using HDD vs. SSD disk in the NFS server
You can observe the results in the following plot:

Discussion

As expected loading already transformed files is much faster since we only need to load and index data in HBase. See this link for more information Indexing Genomic Variants
Loading from SSD disks showed a better performance

The most typical scenario when indexing genomic data is to transform+load at the same time, so assuming SSD disk the observed performance was about 380 VCF files indexed a day, or about 2TB/day. It is worth noting that:

gVCF used were several times bigger than usual
the number of Hadoop worker nodes was just 10
we loaded up to 20 files concurrently but this could have been increased

These variables have a huge impact in the indexing performance, so the expected performance with more real gVCF files and production cluster is more than 1,000 VCF a day.

Analysis Benchmark

In this section you can find information about the performance of main variant storage engine operations, queries and analysis. Please, for data loading performance information go to section Genomic Data Load above.

Variant Storage Operations

Variant Storage operations take care of preparing the data for executing queries and analysis. Some of the most important operations include: Genotype Aggregation, Variant Annotation, Cohort Stats Calculation and Sample Variants Indexing.

Genotype Aggregation

We executed an initial aggregation with the first batch 700 samples accounting for 74.096.015 variants. This run in about 4:10 hours without any issue, this performance is expected to be quite stable. Also, the number of worker nodes affects the performance, unfortunately, because lack of time we could only test with 10 nodes.

Variant Annotation

This operation uses the **[CellBase](http://docs.opencb.org/display/cellbase/CellBase+Home) to annotate each unique variant in the database, this annotation include consequence types, population frequencies, conservation scores clinical info, ... and will be typically used for variant queries and different analysis. We executed variant annotation during the variant indexing, in OpenCGA 2.0.0 you can load variants and annotate at the same time, the performance of variant annotation is affected mainly by CellBase installation, in this PoC we used a small CellBase installation from University of Cambridge which is far from ideal. The performance observed was about 120 million variants annotated a day.**

Cohort Stats Calculation

We pre-computed the variants stats for the 200 million variants across the 4,700 samples, this operation includes the calculation and indexing of the variant stats. We run this few times with 10 nodes and 20 nodes. The observed performance was:

With 10-nodes: 1:50 hours
With 20-nodes: 53 min

As expected the performance improves linearly (2.07x speed-up) with the number of nodes.

Sample Variant Indexing

This operation plays a crucial role when querying by sample genotype. This is also one of the most complex and intensive operation since we index here all the genotypes loaded, all the variants for each sample is indexed, in this PoC we have about 20 billion variants across the 4,700 samples. We run this few times with 10 nodes and 20 nodes. The observed performance was:

With 10-nodes: 4:53 hours
With 20-nodes: 2:37 min

As expected the performance improves linearly (1.86x speed-up) with the number of nodes. Note: this operation is incremental so if we load new samples we only need to index variants from these samples, the runtime above was obtained indexing all sample genotypes in one single execution.

Query Benchmark

To study the query performance we tried different configurations:

Variants table compression - Either GZ (2.9TB) or SNAPPY (4,7TB)
Bucket cache size per node - Using the 1TB premium disk to improve writes to extend the bucket size
Cache compression - HBASE-11331
Cache warmup - Custom MR job to read the whole hbase table and warm up the caches

Queries

filter=PASS,region,sample(1, OR)
filter=PASS,region,sample(2, OR)
filter=PASS,region,sample(3, OR)
filter=PASS,region,sample(4, OR)
filter=PASS,region,sample(5, OR)
filter=PASS,region,sample(1, AND)
filter=PASS,region,sample(2, AND)
filter=PASS,region,sample(3, AND)
filter=PASS,region,sample(4, AND)
filter=PASS,region,sample(5, AND)
filter=PASS,region=15,sample(3, AND)
filter=PASS,region=15,sample(3, OR)
filter=PASS,region,ct=(lof,missense_variant),sample(1, OR)
filter=PASS,region,ct=(lof,missense_variant),sample(2, OR)
filter=PASS,region,ct=(lof,missense_variant),sample(3, OR)
filter=PASS,region,ct=(lof,missense_variant),sample(4, OR)
filter=PASS,region,ct=(lof,missense_variant),sample(5, OR)
filter=PASS,region,ct(6),sample(1, OR)
filter=PASS,region,ct(6),sample(2, OR)
filter=PASS,region,ct(6),sample(3, OR)
filter=PASS,region,ct(6),sample(4, OR)
filter=PASS,region,ct(6),sample(5, OR)
filter=PASS,region,ct=(lof,missense_variant),biotype=protein_coding,sample(1, OR)
filter=PASS,region,ct(9),biotype=protein_coding,sample(1, OR)

Scenarios

Results

GWAS

We defined two cohorts of 100 samples each and run a GWAS analysis over the 208 million variants. The performance observed was very similar to Cohort Stats Calculation.

The Stats calculation took about 2 hours with 10 nodes and about 1 hour with 20 nodes.

PreviousGenomics England Research NextInstallation

Last updated 3 years ago