图形化开放式生信分析系统开发 - 1 需求分析及技术实现V2（2020.7更新）

起因/背景

从2017年前开始，工作的原因接触到了NGS（高通量测序技术 High-throughput sequencing又称“下一代”测序技术"Next-generation" sequencing technology）技术和相关的生物信息学分析。

应用方向是肿瘤的临床诊断，几年间随着技术的快速迭代，应用范围和模式都发生了巨大变化：从最早的肿瘤组织石蜡切片样本过渡到血液样本ctDNA（circulating tumor DNA）的检测，从单一癌种十几个基因的小Panel分析过渡到范癌种几百个基因的大Panel分析，应用范围从单纯的从肿瘤组织切片分析指导靶向用药，到肿瘤的早期筛查>手术后监测全过程；作为“干试验”部分的生信分析的模式也相应的经历了巨大的变化，从单台工作站十几分钟分析一个样本（单一癌种石蜡切片样本）到大规模样本的队列分析，从单一工作站/服务器到大Panel范癌种分析的服务器集群。生信分析所需要的计算能力也快速上升，形式也多种多样，为了解决衍生出来的各种需求，如何管理各种分析流程和计算资源，提供强大的灵活性与扩展能力，也是SliverWorkspace生信分析系统/平台开发的起因。

以下的需求不是一开始就设想好的，是开发过程中逐步增加到现在的样子的，在与用户接触中归纳总结，一步一步添加上去的，现在这篇文章作为一个总结，便于日后复盘，正如本文是第二个更新版本一样。

需求归纳

归纳出的需求，对于生信分析应该具有广泛通用性，不仅仅适用于肿瘤一个方向。

1. 作为计算资源的控制端：支持单台工作站到服务器集群的扩展能力，并可以对其任意组合使用；

• 早期公司针对单癌种开发的各种分析流程（pipeline），运行在单台服务器上，并对外投放部署。这是首先要满足的需求，这类产品进行医疗器械（IVD）注册也有同样的要求。
• 后期随着范癌种样本量增大，很多公司都部署了服务器集群（SGE/Torque/PBS/Slurm），这要和前面的单台服务器统一纳入控制端管理。

2. 从架构设计上解决：分析流程 > 运行环境 > 计算资源（服务器）三者耦合关系，显著降低部署、迁移成本,如下图：

• 由控制端负责分析流程的运行：发送运行命令，检查分析结果，统计运行时间；运行的分析流程脚本保存在控制端。
• 由运行环境提供分析流程的软件/工具/以及用到的各种reference和数据库文件，基于docker来构建确保开发、部署环境一致性。
• 服务器物理机上部署基于docker的运行环境，可以灵活配置环境所占资源大小，便于调度、扩展。
• 兼容现有环境/系统：服务器物理机已有的运行环境，可以直接接入系统，不需要重新安装配置。

3. 使用 "变量+图形化设计器" 替代传统的基于shell分析流程（shell变量+pipeline）脚本

• 使用图形化设计器替代传统的shell脚本，1、能够快速的搭建分析流程；2、能够将现有流程导入/导出为文件；

• 使用软件变量替换shell变量（不污染运行环境），分为三个作用域等级，按作用域从大大小：服务器变量>分析流程变量>样本变量；按变量值优先级计算：样本变量>分析流程变量>服务器变量。对于提供的变量，能够做辅助验证，文件是否存在，程序是否具有运行权限，目录是否存在等等。

4. 基于图形化的分析流程，实现对分析流程的过程控制

• 能够手动启动、停止分析流程（停止分析流程之后，所有正在运行的程序要全部退出，释放服务器资源。包括集群系统Torque/PBS/Slurm已经投递的job等）。
• 能够对任务输出结果做出判断，是否继续下一步。
• 能够对任务运行时间做出统计，便于参数优化。
• 能够保存分析输出日志，便于调试。
• 能够实时显示分析状态，如一共多少任务，运行到哪一步，当前的状态等。
• 能够保存分析结果，如下载分析输出文件，或者将分析结果直接保存进数据库，便于后续人工审核/渲染报告。

5. 实现从测序仪下机数据到分析结果全过程自动化

• 自动扫描、触发分析流程：根据样本编号和分析流程输入设置，自动匹配服务器目录中的样本数据触发分析流程运行。
• 分析流程扫描任务：可配置扫描周期，秒、分、小时。
• 自动拆分数据：与Illumina测序仪对接，能够根据样本信息生成samplesheet完成下机数据拆分。
• 拆分数据扫描任务：可配置扫描周期，秒、分、小时。
• 能够实现拆分数据与分析流程联动，实现从测序仪到最终分析结果全自动完成。

6. 多账户、多角色灵活配置、业务数据灵活授权，便捷的团队协作

• 作为一套软件系统，必备的功能就是多账户协作，用B/S架构较为合理。
• 能够针对不同的用户配置不同的权限组合，以实现团队分工和协作。
• 能够针对不同的业务数据设置访问权限，比如：配置哪些用户能够使用哪些服务器，哪些用户能够访问哪些分析流程（pipeline）。哪些用户能够访问的样本信息，哪些用户能够看到分析结果等等。

7. 对于管理的服务器资源能够能够做到基本的性能监控：CPU负载、内存占用、网络传输、硬盘空间

• 能够监控接入服务器的基本性能：CPU，内存、网络、硬盘空间。
• 监控功能部分足够简单，不消耗服务器资源。
• 对于服务器性能设置监控阈值，超过阈值能够提示报警。
• 性能监控任务：可配置扫描周期，秒、分、小时。
• 能够应急使用服务器的web shell终端，便于处理一些意外情况。
• 提供简洁的文件管理器，能够对接入服务器指定目录做简单的文件管理：上传、下载、重命名、删除等。

技术选型

为了适应各种部署方式（一体工作站，内部生产系统），方便远程管理甚至将业务放在互联网上，软件架构整体选择B/S架构，开发采用前后端分离的模式。技术选型如下：

1. IT圈的前端技术近几年又完成了技术迭代，主流的是react/vue/angular框架了：朋友圈用的最多的是vue+element / iview或者react + ant，vue学习曲线平滑，这里选择vue+ivew；
2. 后端（Server端）使用最常用的java微服务架构springboot2+mybatis+mysql/postgresql，使用的人多，文档齐全，更新维护频繁。数据库熟悉postgresql强于mysql，这里选择postgresql。
   • 前端需要长连接与后端实时通信，这里引入websocket实现。
   • Springboot提供了计划任务（定时任务）的功能，这里使用vue+iview 前端表单+ 后端springboot自带的Schedule实现

功能实现：Talk is cheap. Show me the ...

• 服务器账户接入

• 分析流程设计

• 分析过程状态监控

• 分析流程启动和停止

• 服务器性能监控

现状：经过1年多开发，几百个版本(SVN)，200天以上的稳定性测试。。。。