念書筆記
Ref: Navigating bottlenecks and trade-offs in genomic data analysis
ref: Navigating bottlenecks and trade-offs in genomic data analysis | Nature Reviews Genetics
https://doi.org/10.1038/s41576-022-00551-z
Technical trade-off
Compute
無論是mapping或是variant calling都是超級花時間與運算力的工作，甚至在前面的read sorting, quality control, 處理CIGAR, 計算獲得quality score profile都是花算力，而且不一定是線性增長，有些甚至是log linear長大！！
Space
儲存與運算空間都要錢。以長時間儲存來說，就算用Amazon Glacier Deep Archive一樣很貴，所以目前如何長期保存genomic data依舊是個熱門研究領域 (ref [32](DNA stability: a central design consideration for DNA data storage systems | Nature Communications))。而短時間儲存更貴，要夠快夠穩定的效能，也需要有效率的壓縮方式 (bam, cram…)，甚至，因為需要把資料讀進RAM裏才能運算，所以目前更需要high RAM機器，那又更貴！！
Communication
在不同的儲存裝置之間的資料傳輸是更嚴重的瓶頸，當然在雲端上傳輸也是問題，因為每一個 bytes的傳輸都是錢！所以要傳輸raw read? Bam? Or vcf? 這都是考量。更甚者在single cell analysis裡面這更是大問題，因為資料量更大。
User-facing bottleneck
Time
使用者需要花費多少時間去運算？即使現在有FPGA, GPU, or TPU加速，時間仍是問題。尤其是現在的computer cluster通常是由high RAM, more CPU, 有GPU等等異質性的運算結點組成，而整個genomic analysis pipeline又有不同步驟，有些要多RAM，有些要多核，如何分配這些步驟到適合的節點運算，以及資料如何安全的在這些節點裡傳輸，就成了大問題。或是每個人都在排隊搶大機器但排上的人根本用不了那麼多算力！
解決方法百百種，像跑GATK如果在google cloud上跑，可能一筆30x全基因體定序就要數十小時，但用Illumina Dragen只要不到一小時。因此該如何運用平行運算等等的方法，就是使用者們的智慧了。
Money
上面說的那些平行運算或是能加速的方法通通要錢！！像是如果機器的RAM不夠，除了插好插滿插爆之外，就只能用硬碟做swap然後慢到天荒地老了。
Accuracy
生物資訊演算法開發者永遠在速度與正確性之間權衡取捨，就像是BLAST這麼知名的演算法，他其實也是local alignment Smith-Waterman dynamic programming的變體，但正確性與古老的Smith-Waterman相比已經降低了。但相較於正確性問題，目前速度問題更是龐大。無論如何，使用者願意多花超過兩倍的錢去買算力以提升正確性嗎？要等更久時間？所以在合理範圍內降低正確性提高速度是必須的，但這需要好的benchmark才知道如何權衡。
Complexity
許多常見的運算邏輯，是用low level language C or C++寫成的一個個演算法，再由各實驗室自己用high level language如python當膠水，把一個個程式的input與output串聯起來，雖然這些膠水程式通常很簡單，但因為只要任何一個步驟的input output改了，這些膠水程式就需要改，所以這部分需要花費極大人力時間成本去維護。
Modern computational methodologies
Data compression
Lossless compression
像是bgzip, bam等等都是目前常用的資料壓縮方法，同時也能執行random access，讓我們不用解開整個壓縮檔，就能找到特定區域的資料
Lossy compression
但就像影音資料處理的jpeg, mp3等格式，由於人眼與耳朵無法接收那麼高頻率的資料，所以丟掉一些資料是可容忍的，而且也是必須的，目前這也是標準資料處理的辦法。而在genomic data裡面，我們勢必面對丟棄部分資料的抉擇。但其實也沒那麼困難，因為生物學家愛用的exon seq，本質上就是丟棄了所有non coding region的實驗設計，所以很多時候實驗設計上的丟棄資料，遠比後續分析時的lossy compression還多。
Data sketching
在使用lossy compression時，重點是找到不需要的資料並把它丟掉，而且要確保下游的分析方法真的不會用到這些資訊。但data sketch可以說是直接萃取生物學上的重要特徵，舉例來說，像是bloom filter, Mash這些根植於hash function的方法都屬於data sketch。甚至根植於kmer 的分析方法，像是minimizer-like approach, mininap2, Kraken2, mashmap都是根植於萃取kmer直接比較，當然基於data sketching的方法正確性比較差，但速度絕對是超群，所以也是解決辦法之一。
Hardware acceleration
靠GPU, FPGA還是有用的，但它們只有在特定功能裡幫忙加速，目前要根植於GPU寫的生物資訊工具仍然不多，更別說是透過FPGA。
Cloud parallelization
平行運算當然是解決困境的方法之一，但評估機器成本太困難了，雲端租借也是簡單的解決辦法之一。目前大量的biobank資料都上雲了，無論是從Amazon，Google cloud或 Microsoft Azure都有這類服務。
Domain specific library and languages
生物資訊類的工具不像deep learning之類的有TensorFlow 或PyTorch簡單好用的工具，所以發展一直快不起來。雖然C++, Rush, Julia夠快也容易做平行運算，但在生物資訊領域一直不是主流。
另一種做法是類似Snakemake這種workflow，或是GUI的Galaxy都是開發的重點，這些都屬於domain specific language。也許生物資訊能靠這類型domain specific language而進展更快。
未來期望
未來single cell dataset會是更大的問題，更肥，單一樣品，該怎麼好好處理它會是大問題。
Take home messages
本文簡述了genomics data的生物資訊類研究，所面對的困境與可能解決的方法。對於這領域完全陌生的人，可以當作好的入門參考
Keywords
bioinfomatics, genomics, ngs