Spark 對於生物大數據分析來講有什麼缺點和不足?

---

謝邀。

MapReduce是IO intensive的，所以IO密集的生物信息演算法就可以使用spark，比較典型的是GATK。現在GATK的Scala代碼是與日俱增啊。其實個人認為SNP calling本身還是下面說到的CPU intensive，只不過GATK中大量使用了Machine Learning的演算法（瞅著像SVM）來做Variant Recalibration，這玩意兒可是IO intensive的。

碰到CPU intensive的生物信息演算法就不合適了。你沒見過BWA或者Bowtie這類mapping的軟體用MapReduce來做的吧？這種演算法你要是用Spark，分分鐘哭死你。MPI是你更好的選擇。當然現在大部分生物信息演算法還是CPU intensive的，比如alignment, de bruijn graph construction, error correction, evolution...

所以只要區分好你的演算法是IO還是CPU intensive的就可以，就是這麼簡單。

說句題外話，IO intensive的推薦Scala+AKKA+Spark，CPU intensive的推薦C++TBB+MPI+CUDA。這兩條技術流分別解決了兩種計算類型下多核和分散式的生物信息計算，也是大部分生物信息軟體走的方向。

什麼，你問我JAVA呢？

---

今年年初寫過一些spark，個人感覺缺陷是API部分用著不如mapreduce豐富，雖然框架靈活性顯然大於後者，社區貌似也不是那麼活躍，問了問題一直沒人回答（或許我的問題比較低端也不好說...）。另外spark要玩的好，機器內存要求也不低，否則和玩mapreduce差不多效果，甚至更差，不過一般弄spark都是比較新的環境。GATK應該已經準備上spark了，和谷歌強強聯手，自然比我這種半路出家要寫的溜和好很多。

---

Spark主要做分布，BWA等使用了SIMD等技術來加速seed extension階段的sequence alignment，而用純的scala代碼很慢。所以比較合理的是使用Spark來做數據分布，用BWA在每個節點運行。

目前Spark和BWA的結合，Spark中FPGA加速，變異分析與Spark的結合，還有ADAM用於數據的分散式存儲和簡單的計算，都在發展，但目前沒有一個系統可以將這個生物信息學的流水線集合在Spark上，但分散式是一個趨勢，只是時間的問題。

---

沒什麼本質的局限，伯克利和UCSC已經開始建設基於Spark的bioinformatics項目了：

Big Data Genomics

---

推薦閱讀：