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

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

  • 起因/背景
    • 软件获取:到官网sliverworkspace.com免费下载个人版,最新版本 2.0.277363
    • 几张图片
    • 下面进入正题,以具体个人工作经历为例,分析归纳出需求:
          • 实践问题一,图形化替代命令行脚本交互
          • 实践问题二,解决迁移部署问题
          • 实践问题三,解决环境搭建、软件安装问题
            • 需求:分析流程(pipeline)能够快速部署迁移
            • 技术实现:使用虚拟化技术:
          • 实践问题四:实现全流程自动化/提高效率降低成本
          • 最终软件架构设计如图:

起因/背景

从三年前开始,工作的原因接触到了NGS(二代测序)技术和相关的生信分析,在公司技术到临床应用转化过程中遇到一系列问题,遇到的坑多了,有了开发一套通用生信生产系统的想法,目前已经完成了第一个版本开发,有必要做一下记录并复盘:本文为本系列文章的第一篇。

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

几张图片

  1. 分析流程(pipeline)设计:基于文件输入输出的图形化工作流设计,适用所有分析流程
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第1张图片

  2. 分析结果保存:配置输出文件数据结构,可以直接保存进数据库
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第2张图片

  3. 配置分析流程(pipeline)自动运行:可以选择多长时间轮询一次,哪个时间点触发执行
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第3张图片

  4. 分析结果过滤:较为复杂的分析结果,可以人工过滤,并将过滤结果导出生成分析报告
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第4张图片

  5. 分析流程(pipeline)运行:可以中途停止,并在停止位置恢复运行,统计运行结果
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第5张图片

  6. 服务器性能监控:CPU、内存、网络、硬盘空间
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第6张图片

  7. 分析报告模板及输出结果:模板是word格式,便于自定义/DIY。
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第7张图片
    图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第8张图片

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

实践问题一,图形化替代命令行脚本交互
  • 我司技术上,陆陆续续完成了十几个项目,十几条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机型):
图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第9张图片

最终软件架构设计如图:

图形化开放式生信分析系统开发- 1基本需求分析及技术实现_第10张图片
您可以下载PPT或加QQ群:853718264讨论

你可能感兴趣的:(图形化开放式生信分析系统开发- 1基本需求分析及技术实现)