圖形化開放式生信分析系統開發- 1基本需求分析及技術實作

• 起因/背景
• • 軟體擷取：到官網sliverworkspace.com免費下載下傳個人版，最新版本 2.0.277363
  • 幾張圖檔
  • 下面進入正題，以具體個人工作經曆為例，分析歸納出需求：
  • • • • 實踐問題一，圖形化替代指令行腳本互動
        • 實踐問題二，解決遷移部署問題
        • 實踐問題三，解決環境搭建、軟體安裝問題
        • • 需求：分析流程（pipeline）能夠快速部署遷移
          • 技術實作：使用虛拟化技術：
        • 實踐問題四：實作全流程自動化/提高效率降低成本
        • 最終軟體架構設計如圖：

起因/背景

從三年前開始，工作的原因接觸到了NGS（二代測序）技術和相關的生信分析，在公司技術到臨床應用轉化過程中遇到一系列問題，遇到的坑多了，有了開發一套通用生信生産系統的想法，目前已經完成了第一個版本開發，有必要做一下記錄并複盤：本文為本系列文章的第一篇。

軟體擷取：到官網sliverworkspace.com免費下載下傳個人版，最新版本 2.0.277363

幾張圖檔

1. 分析流程（pipeline）設計：基于檔案輸入輸出的圖形化工作流設計，适用所有分析流程

   

2. 分析結果儲存：配置輸出檔案資料結構，可以直接儲存進資料庫

   

3. 配置分析流程（pipeline）自動運作：可以選擇多長時間輪詢一次，哪個時間點觸發執行

   

4. 分析結果過濾：較為複雜的分析結果，可以人工過濾，并将過濾結果導出生成分析報告

   

5. 分析流程（pipeline）運作：可以中途停止，并在停止位置恢複運作，統計運作結果

   

6. 伺服器性能監控：CPU、記憶體、網絡、硬碟空間

   

7. 分析報告模闆及輸出結果：模闆是word格式，便于自定義/DIY。

   

   

下面進入正題，以具體個人工作經曆為例，分析歸納出需求：

實踐問題一，圖形化替代指令行腳本互動

• 我司技術上，陸陸續續完成了十幾個項目，十幾條pipeline，生信大佬們寫的那些500行的shell腳本，基本上要求使用運作人員處在一定技術水準（熟悉Linux系統，熟悉shell，perl，python，R程式設計中的一種），這就限制了使用範圍。後來公司基于腳本的基礎上也實作了部分自動化，但仍不能滿足以下情況：

1. 産品注冊：廣州燃石、諾禾緻源、廈門艾德、南京世和等都在進行并完成基于NGS技術的IVD（體外診斷試劑，醫療器械子分類）産品注冊。NMPA（原CFDA，國家藥監局）就要求這些軟體産品必須要有友好的互動界面；要求軟體産品經過嚴格的測試，從單元測試>內建測試>功能測試>性能&穩定性測試；并對分析結果進行臨床試驗驗證。IVD産品應用于臨床，須要嚴謹的驗證過程。各個公司的pipeline過不過的了這一關，是個疑問。
2. 産品投放：我司還有很多同行将開發完成的試劑盒、試驗過程、分析軟體作為一整套方案投放到醫院科室，出于使用者角度考慮，盡可能的實作整套方案的自動化，友善使用者使用。曾經聽過有的同行要求使用者輸入一條全自動分析腳本，對方三次都輸入錯誤，還怪使用者太笨的段子。
3. 内部營運：如果運作軟體的不要求熟悉Linux系統，shell，perl，python，R程式設計等專業技能，是否就能夠減少專業人員數量并降低了成本？這裡也可以通過自動化腳本實作。

• 結合以上，可以得出需求：

1. 圖形化互動界面（UI）優于指令行腳本，互動界面：B/S架構的優于C/S架構（更新維護友善）

2. 通用圖形界面優于非通用圖形界面，避免重複開發。

   圖形程式和分析流程是一對多關系，圖形程式能夠快速組裝分析流程由腳本工具到軟體産品生信分析流程抽象上來說其實是基于檔案的工作流，如果可以基于B/S實作工作流設計器，圖形的工作流能夠轉換為分析流程腳本運作，也就基本實作了通用化目标。

3. 自動化優于手動運作，圖形配置自動運作參數優于腳本配置

• 針對以上需求，并結合自身知識結構，做出技術選型如下：

1. 隔壁IT圈B/S技術，越來越多的采用前後端分離實作，前端（Browser端）：容易上手的vue+element / iview或者react + ant，vue學習曲線平滑，這裡選擇vue；前端需要長連接配接與後端通信，這裡引入websocket實作。

   後端（Server端）使用最常用的java微服務架構springboot2+mybatis+mysql/postgresql，使用的人多，文檔齊全，更新維護頻繁。資料庫熟悉pg強于mysql，這裡選擇pg。

2. 需要前端javascript實作圖形化的分析流程設計器，後面會詳細講，如圖1。
3. Springboot提供了計劃任務（定時任務）的功能，這裡使用vue+iview 前端表單+ 後端springboot自帶的Scheduling實作

實踐問題二，解決遷移部署問題

• 剛加入公司時候：公司美國團隊某跌落神壇的大佬寫的一套分析流程，部署在ubuntu14.04上，遷移到ubuntu16.04遇到問題，某些底層代碼或者庫不相容，具體原因不詳，簡單的說就是部署遷移成本高。

實踐問題三，解決環境搭建、軟體安裝問題

• 每一套分析流程（pipeline）都要安裝一大堆工具軟體，如bwa，samtools，gatk，annovar，snpeff等等；安裝配置過程相當痛苦。

需求：分析流程（pipeline）能夠快速部署遷移

技術實作：使用虛拟化技術：

A、 虛拟機技術Vmware，Virtualbox

B、 Docker

A、B 都可以滿足需求，經過比對，Vmware，Virtualbox這種比較“重”，Docker目前在隔壁IT圈已經大範圍使用，具有占用資源小，運作效率高等一系列優勢，這裡推薦Docker。無論是虛拟機還是Docker将部署好的pipeline作成鏡像，就可以部署、遷移了，不用每次都重新安裝、配置。導入Docker/虛拟機鏡像的友善程度遠遠高于全新安裝。如果不是因為那大幾百G的reference檔案，直接就可以做到全自動分發、部署。

實踐問題四：實作全流程自動化/提高效率降低成本

之前公司在公司資訊化上的投入很大，包括硬體和軟體。但是整個流程上還是有幾個點是靠人工完成：

1. 測序儀下機資料拆分，原因是購買的樣本系統和生信分析沒有完成對接
2. 拆分資料完成後，需要人工啟動分析流程，人工判斷需要運作什麼分析項目
3. 分析完成之後，輸出的報告，需要人工修改報告格式，這裡消耗很大人力，尤其是使用life測序系統

需求：實作從樣本錄入之後，測序儀拆分資料、啟動分析流程、到分析結果儲存、分析報告導出全流程自動化

實作：根據以上需求，總結得到自動運作結構如圖（Illumina機型）：

自動運作結構如圖（針對Illumina機型）：

最終軟體架構設計如圖：

您可以下載下傳PPT或加QQ群:853718264讨論