「生資無價系列專題」- 生物資訊工程師修練之路

17 min readOct 19, 2020

緣起

這陣子在公司面試新人的過程中，發現一個蠻有趣的現象：

每個人都說他是 Fast Learner，每個人都說他的生物資訊能力夠強，就如同現在大部分應屆畢業生都號稱自己是 AI 工程師一樣。（雖然很多都不是資訊相關學科出身的）。

老實說，不一定要資訊相關學科出身才能當 AI 工程師，我也遇過很多自學出師的高手。同理，生物資訊能力強的高手也不一定來自資訊相關學科，只是在短短1個小時的面試過程中，試著分辨出每位新人是否合適團隊，有關技術的問題大約只會分配到 10 分鐘左右，要在短短的時間中分辨其生物資訊能力是非常難的挑戰。

讓我想起當年是如何不小心踏入「生物資訊」領域的記憶，原本碩士班是在嵌入式作業系統實驗室，那時教授出去開做嵌入式系統的新創，他就問我要不要加入他的公司順便念博班，我二話不說就答應了，所以博班前幾年我的心力都放在公司，學校這邊只是修修課和應付一下資格考而己。只可惜後來公司衝得太快但市場還沒起來，因資金斷炊只好先回學校把學位拿到再說，那時一心只想找那個領域能很快畢業就挑那個，不小心聽到 Bioinformatics 很紅，論文審稿時間又快、接受率又高，所以一樣二話不說就直接跳進去了，雖然那時的我連什麼是 Bioinformatics 都不知道。

生物資訊工程師修練之路

refer to https://static.india.com/wp-content/uploads/2016/07/x11-buddha-guru-jpg-pagespeed-ic_-qosbdq5lsp.jpg

我們先來看一下「生物資訊學 (Bioinformatics)」在維基百科的定義 [1]：

生物資訊學（英語：bioinformatics）利用應用數學、資訊學、統計學和電腦科學的方法研究生物學的問題。生物資訊學的研究材料和結果就是各種各樣的生物學資料，其研究工具是電腦，研究方法包括對生物學資料的搜尋（收集和篩選）、處理（編輯、整理、管理和顯示）及利用（計算、類比）。目前主要的研究方向有：序列比對、序列組裝、基因辨識、基因重組、蛋白質結構預測、基因表現、蛋白質反應的預測，以及建立進化模型。

所以生物資訊學是跨領域的學科，就跟後來的資料科學 (Data Science) 一樣，需要結合各種不同領域的專長才能把問題解得漂亮。因為目前公司在市場定位的關係，所以我們會特別重視「電腦科學 (Computer Science) 」的部分，累積多次面試後的心得，整理出針對生物資訊工程師 (Bioinformatician) 分為以下五種階段：

第零階 — Runner

俗稱「一鍵式生物資訊」。聽過很多人說過：

生物資訊不就是滑鼠按幾下，結果就出來了嗎？

當然，有好的 GUI 套裝軟體或合適的工具，可以直接點一點就可以得到結果。若是這樣就能解決您的問題，那真的是祖上積德呀！因為我遇到的大部分情況都不是這樣。

再進階一點的就是會使用一些 Command-line 的工具完成想要的分析，不過，在我的歸類中，還是屬於這一層級。（至於參數調優的部分，我會將其歸為 Data Science 的議題，本文只著重程式撰寫的部分）

第一階 — Scripter

俗稱「串串」。因為處理的資料流程變得比較複雜，除了需要會使用 Command-line 之外，還需要會串接多個不同工具加上一些基本的判斷邏輯，而很多人會直接用 shell script 或 batch file 來串接多個步驟。然而，當串接流程越來越複雜時，當最後結果出不來時，常常會找不出原因，就需要碰觸 Error Handling 的議題。

另外，有時會遇到需要將原本的 script 放到其它地方跑的情況，就遇到很多環境的問題，諸如路徑的問題、工具版本的問題或 Library 的問題。這時，進階一點的有些人就會考慮使用 Workflow Language 來開發需要的 Workflow（或稱Pipeline），諸如 WDL [2] 、CWL [3]、NextFlow [4]、Snakemake [5] 及 Reflow [6]等等。這些主要是定義一些 Template 及 Syntax 來做模組的定義及串接，主要目標是讓每個生物資訊分析流程變得很 Readable 和 Reproducible，另位也觀察到目前每個 Workflow Language 也開始強調 Scalability 的功能了，如何容易地跟 HPC 和 Cloud Service Provider 的平台銜接。當然，在目前越來越被重視 Open Science 的精神，在撰寫論文時提供實驗所使用的 script 也是重要的，若能使用 Workflow Language，則可大大提高「可重覆性」（ Reproducibility）。（除非，你不太想讓 Reviewer 或其它人可以很容易地重覆你的實驗 … ）

這階段的生物資訊工程師通常只在意能不能得到預期的結果，對所使用工具的特性並不太重視，我曾看過別公司寫的 Pipeline 中有一段在呼叫一支 Java 程式時開頭如下：

java -Xms500g -Xmx500g …

我記得這支程師最多只需 7–8 GB 的記憶體就可以處理 WGS 了，因為他主要處理的資料只是小 Panel，我就好奇問了一下為什麼這樣寫，他回說：

「因為我們的主機有 512 GB的記憶體呀！」

就像捷運上下班時間，大家會試著把背包向前背或拿在手上，突然有位人兄橫躺在一排坐位上玩手機一樣，導致後面還有一堆人進不來一樣，資源沒有被有效分配。

當然，也有些生物資訊工程師是能有效運用手上僅有的資源，不需要寫程式就能把資源配置用到極致的。以下就要開始寫程式囉～～～

第二階 — Programmer

俗稱「碼農」。就是把客戶或教授的想法用程式語言寫出來，因為很多生物資訊工具有提供 Perl 、 R 及 Python 的函式庫 (Library)，所以大部分學生物資訊的學生都會以這類 Interpreter based 的程式語言進入寫程式的世界，也就是說前面介紹的二類原則上不算是軟體工程師，雖然他們是屬於生物資訊工程師。這邊需先澄清一件事：

不是每個生物資訊的工作都一定要親自寫程式才算，但若要把生物資訊做好，必須要會寫程式才行。

也就是打籃球時想得分，不一定都要會投三分球。只是現今 NBA 小球戰術盛行，會投三分球可以讓教練圈的戰術更多元（PS：火箭隊除外，因為他們只有球給 Harden 的戰術）。

因為這個領域發展很快速，新的定序技術一直進步，資料產生越來越多元，原本合適的分析工具就會漸漸不合適，總會遇到跑不出好結果的時候，這時就必須得「自己來」！若非又是遇到祖上積德，不然就是你都只是在玩非常成熟的資料分析，還沒機會玩到新的資料。

寫到這裡時，突然在臉書上看到某位教授好友對某則新聞寫的評論（圖二），記得大一第一學期，除了學「計算機概論」，另一門就是「邏輯」！這就是邏輯這門課一開始就會的 Contraposition。若開始自己寫程式，就會遇到如何設計程式的情況，除了要熟悉該程式語言的特性之外，最重要是「邏輯」、「資料結構」和「演算法」。若沒有這些能力或靈魂注入，仍會被歸類為只是「串串」。

然而，程式語言不會只有 Interpreter-based而己，有時為了效能或使用演算法函式庫限制而需要使用 Compiler-based 的程式語言，如圖三就是根據 TIOPE Programming Community index 所列出目前最常使用的程式語言，可以發現 C/C++ 及 Java 仍是大宗。然而，每種語言的特性都不太一樣，若對該語言了解程度不夠的情況下，可能會產生非常嚴重的效能問題。記得當年有找了一位生資博士加入團隊，請他負責 Variant Annotation 的程式開發，目標是將數十個 Population database 一起依人種來算其 MAF 的資訊，其數量約有數萬人的資料，全部約數千萬個變異點。在程式開發時，他發現有些資料庫的人種資訊是空的，這樣在後面比對時會造成困擾，所以他很直覺地就將空的資訊以"EMPTY"字串來表示，其它有資訊的統一以 The 1000 Genome Project 所使用三個字母來表示人種資料。這樣，最後在做 Variant Annotation 時，就可以直接進行不同人類的 MAF 過濾，如下：

if (strcmp(variant.population, “EMPTY”) != 0) {
if (strcmp(variant.population, “EAS”) == 0) { //East Asian
…
} else if (strcmp(variant.population,”EUR”) == 0) { //European
…
}
…
}

看起來有達到我們想做的功能，但就「效能」上來講就是非常糟糕的設計。大家也可以試著想看看，若是你，將會如何實作？

因為寫程式是需要設計的，要設計出好的程式，必須要了解資料的特性，以下是資料的特性：

1. 人種資訊來自數十個不同的 Population database，每個 database 定義的人種分類數都不太一樣，但最多就十來個。
2. 人種資訊不常變，或者應該說不會變。
3. 這類有人類資訊的資料庫也不常改版。
4. 數量上總共有幾億筆，大小約 5 TB 左右。
5. 偶有加新 Population database 的需求，但一年最多一次吧！
6. 整理好的資料，在每次分析時都要跟數百萬個變異點進行比對及進行過濾的運算。

那時，我們使用 Java 來開發系統，該博士說他博班都是用 Java 在進行程式開發，所以是屬於他熟的程式語言。但我們受過正規程式訓練的工程師應該都知道 String comparison 是比 Integer 貴非常多的運算，根據以上的資料特性，再怎樣也不會用 String 來進行設計才是，所以我們重新設計後，用 Bit Operator 來實作，效能馬上提升數十倍，資料庫也小了 20%。舉這個例子只是想說明：

碼農也是有分等級的！

一旦進入程式開發的領域，要知道這水可是很深的，至於多深，得自己跳進來才能體會，我至今也還踩不到底，仍在不斷學習中。

第三階 — Developer

再來會越來越屬於 Computer Science 的領域，主要是為了產品的效能提升和降低硬體需求，可以簡單分為 Hardware Solution 和 Software Solution。Hardware Solution 就是利用 GPU 或 FPGA 來進行軟體的開發，主要是進行效能的提升；Software Solution 就活潑多了（或者是我只比較熟軟體的部分），除了可以用不同程式語言來重新撰寫取代既有沒效率的分析工具外，還可以運用 Parallel Computing 及 Distributed Computing 的方式進行加速或以 Scale-out 的方式橫向擴展硬體的限制。例如 Sentieon [9] 就是運用 C/C++ 改寫原本用 Java 實作的 GATK，速度快了10–30倍；Broad Institute 在 GATK 4.0 [10] 時運用 Apache Spark [11]來實作，解決 JointGenotyping 的運算效能問題。

這個層級稱為 Developer，相對於前一等級的 Programmer，主要差別除了在設計上有更深更廣的手段來達成，在實作上也能充份運用合適的資料結構、演算法及硬體支援加速函式庫來完成目標，也能預期其時間複雜度或最少硬體資源的需求，最重要的是：

能實作出適合大型軟體產品或平台的能力！

記得之前在念書時寫的程式，只要跑得出結果就算交差了；但工作後才發現，之前寫的程式大約只完成 10～30%而己，還有 70% 以上的程式根本還沒寫。奇怪了，不是程式都可以跑了，怎麼還說有大部分程式都還沒寫呢？這些很多是功能外的部分，在小型程式不是那麼重要，但在開發大型系統或平台時，很多 Error Handling 和 Interface 串接更重要，尤其在分散式系統時，要如何有效地 Debug，完全取決於你如何模組化你的程式，這階段寫的程式會開始進入哲學的領域。每個 Developer 在寫第一行程式前心中應該就己描繪出這次的設計理念，為什麼採用這樣的設計，為什麼不採用另外一種設計，分析其 Pros/Cons，估計出 Time / Space Complexity，了解這次的設計會是 CPU / Memory / IO Bound、、、等。這些能力不太能直接從看別人的程式中學到，因為通常只看到最後的結果，更何況 Developer 不太寫 Document 或Comments，所以必須實際參與開發才能體驗。最重要的是：

坑得自己踩過，才會知道有多痛！

例如，我們最近花了近一個月才解決在 Microsoft Azure Storage Gen2 上的一個效能性的問題，程式碼中只是多了一個 '*' 就會讓整體效能差 20 倍左右（當然，有一部分原因是因為 Azure 的 Bug）。

當然，這階段還是首重程式撰寫與實作，以上提到這些很多技能培養只是為了可以順利進升到下一階段。

第四階 — Architect

進入這階段的生物資訊工程師，不該再只以程式撰寫速度有多快以及開發出多高效能的演算法為主要技能，而是能根據產品或平台的發展方向，設計出一套最合適的架構，所以才會稱為架構師(Architect)，如同要蓋一棟防震的台北 101 大樓，就得採用如阻尼器這種設計 [12]，但蓋一般的房子並不需要。若連一般房子也使用阻尼器的設計，就會顯得 Over-Spec，不僅拖慢開發時程，又提高不少無謂的成本。

若你是身為生物資訊的軟體新創的 Architect，這時會遇到問題會有：

1. 產品要不要上 Cloud ？還是 On-Premises ？
E.g. 用 On-Premises 可以完全掌控，但產品對 Hardware failure 得花更多心力。上 Cloud 後設計重點會由 Hardware failure 轉為 Service Failure 的 Recovery，首重 Cost 及 Scalability。
2. 上 Cloud 要用那一家？
E.g. AWS 功能最完整，GCP 開 Instance 最快又常有些暗黑技術可用，Azure 針對 Enterprise 的需求有完整的支援。
3. 若使用某一家的雲端服務時，要不要使用他們提供的特殊服務？
E.g. 用了就被綁死了，不用就得花時間自己開發
4. 用 Open Source 還是自行開發？
E.g. 採用了 Open Source 就要有能力去改它，因為它可能無法支援 100% 的需求。
5. 是否要使用硬體加速？
E.g. 用了可以加速，但有時會縮小了客戶群。
6. 是否要採用分散式平台？
E.g. 用了加以加速，但增加了系統複雜度及開發的難度。
7. 是否需要「合規」(Regulation / Certification)？
E.g. 資料安全的 HIPAA 或資訊安全的 ISO27001 等。
… (skip) …
N. 隨著業務增長，是否要整個打掉重練？
E.g. 無時無刻都在想這件事！技術債什麼時候要還？該分期付款？還是一次還清？
N＋1. 今天中午要吃飯還是吃麵？
E.g. 壓力大到連這種小事都會是個問題！

這階段的重點應是以系統或平台的開發與運維、擴展性以及效能的優化為主。

小結一下，我想應該還會有更高層級的境界才是，以上只是我到目前為止經歷過或接觸過的生物資訊工程師而整理出來的分類。重點不是在幫大家貼標籤，而是讓大家根據自己的興趣，知道如何設定目標以及提升自我的能力，純粹僅供大家參考而己。

另外得再次補充說明，大型軟體開發應該是個團隊合作，不需要整個團隊成員都是 Architect！

換句話說，在實力堅強的團隊中，有位了解客戶需求的「串串」也是非常重要的角色，因為很多 Architect 是聽不太懂客戶需求的！

結論

我想所有身為生物資訊工程式的人都會希望自己寫的程式可以讓很多人使用，不過在寫程式前，建議應該先看看 Lior Pachter 寫的「The myths of bioinformatics software」[13] 才是，要先建立好正確的心態，才能開始步上生物資訊工程師的修練之路，否則很容易走火入魔。

用下面這張生物學家的梗圖來跟大家分享：「用對工具，你的人生才會是彩色的！」