图形化开放式生信分析系统开发 - 1 需求分析及技术实现

起因/背景

从三年前开始，工作的原因接触到了NGS（二代测序）技术和相关的生信分析，在公司技术到临床应用转化过程中遇到一系列问题，在问题中挣扎、解决问题的过程中逐渐有了开发一套通用生信分析系统的想法，到目前已经完成了由想法到产品的转化，有必要做一下记录以便复盘：本文为系列文章的第一篇。

几张图片

软件获取：到官网sliverworkspace.com免费下载个人版，最新版本 2.0.277363

1. 分析流程（pipeline）设计器：基于文件输入输出的图形化工作流设计器

1需求分析及技术实现_1.png

1. 分析流程（pipeline）运行过程：可以手动停止，并在停止位置恢复运行，计算运行结果

1需求分析及技术实现_2.png

1. 分析结果保存：配置输出文件数据结构，保存进数据库便于回归分析和数据挖掘

1需求分析及技术实现_3.png

1. 配置分析流程（pipeline）自动运行：可以选择运行间隔、触发运行时间

1需求分析及技术实现_4.png

1. 分析结果过滤：较为复杂的分析结果，可以人工过滤，并将过滤结果导出生成分析报告

1需求分析及技术实现_5.png

1. 分析报告模板定制及输出结果

1需求分析及技术实现_6-1.png

1需求分析及技术实现_6-2.png

1. 服务器性能监控：CPU、内存、网络、硬盘空间

1需求分析及技术实现_7.png

下面进入正题，以具体个人工作经历为例，分析归纳出需求：

实践问题一：图形化替代命令行脚本交互

一、之前工作过的公司，在技术上陆陆续续完成了十几个项目研发，十几条pipeline，生信大佬们写的那些500行的shell脚本，基本上要求使用/运行人员处在一定技术水平（熟悉Linux系统，熟悉shell，perl，python，R编程中的一种），这就限制了使用范围。后来公司基于脚本的基础上也实现了部分自动化，仍不能满足以下情况：

i. 产品注册：广州燃石、诺禾致源、厦门艾德、南京世和 等公司相继完成了基于NGS技术的IVD（体外诊断试剂，医疗器械子分类）产品注册。NMPA（原CFDA，国家药监局）就要求这些软件产品必须要有友好的交互界面；要求软件产品经过严格的测试，从单元测试>集成测试>功能测试>性能&稳定性测试；并对分析结果进行临床试验验证。IVD产品应用于临床，须要严谨的验证过程。各个公司的pipeline过不过的了这一关，是个疑问。

ii. 产品投放：我司还有很多同行将开发完成的试剂盒、试验过程、分析软件作为一整套方案投放到医院科室，出于用户角度考虑，尽可能的实现整套方案的自动化，方便用户使用。曾经听过有的同行要求用户输入一条全自动分析脚本，对方三次都输入错误，还怪用户太笨的段子。

iii. 内部运营：如果运行软件的不要求熟悉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）能够快速部署迁移

技术实现：使用虚拟化技术：

1. 虚拟机技术Vmware，Virtualbox
2. Docker

1/2都可以满足需求，经过比对，Vmware，Virtualbox这种比较“重”，Docker目前在隔壁IT圈已经大范围使用，具有占用资源小，运行效率高等一系列优势，这里推荐Docker。无论是虚拟机还是Docker将部署好的pipeline作成镜像，就可以部署、迁移了，不用每次都重新安装、配置。导入Docker/虚拟机镜像的方便程度远远高于全新安装。如果不是因为那大几百G的reference文件，直接就可以做到全自动分发、部署。

综上，整体软件架构设计如图：

1需求分析及技术实现_架构.png

实践问题四：实现全流程自动化/提高效率降低成本

之前公司在信息化上的投入很大，但是整个流程上还是有几个点是靠人工完成：

1. 测序仪下机数据拆分，原因是购买的样本系统和生信分析没有完成对接
2. 拆分数据完成后，需要人工启动分析流程，人工判断需要运行什么分析项目
3. 分析完成之后，输出的报告，需要人工修改报告格式，这里消耗很大人力，尤其是使用life测序系统

需求：实现从样本录入之后，测序仪拆分数据、启动分析流程、到分析结果储存、分析报告导出全流程自动化

实现：根据以上需求，总结得到自动运行结构如图（Illumina机型）：