You are viewing an old version of this page. View the current version.
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 200 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.
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 3.6 cluster using Data Lake Storage Gen2. HDInsight 3.6 uses Hortonworks HDP 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:
|Node Type||Nodes||Azure Type||Cores||Memory (GB)||Storage|
|Hadoop Master||3||Standard_D12_V2||4||28||Data Lake Gen2|
|Hadoop Worker||10||Standard_DS13_V2||8||56||Data Lake Gen2|
|Azure Batch Queue||20||Standard_D4s_v3||4||16||NFS Server|
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:
- 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
- Also, 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.
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.
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.
This operation uses the CellBase 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: that 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 and Aggregation Stats
Table of Contents:
- No labels