项目总结人脑组织库数字化管理平台

最新推荐文章于 2024-10-16 10:13:45 发布

Cykang...

最新推荐文章于 2024-10-16 10:13:45 发布

阅读量722

点赞数 26

文章标签： java

本文链接：https://blog.csdn.net/cykangkk/article/details/139036440

版权

人脑组织库数字化管理平台

属于科技创新2030-“脑科学与类脑研究”重大项目，由中科软牵头。主要目的建立高效运行的人脑库数字化管理平台及研究数据库。此平台收集并整理全国各大医学合作单位汇总的人脑捐献者生前病史等临床信息。这里面主要解决的几个难点是针对大型脑切片图像的上传、标注、保存、加载。目前已经在北京协和医院上线部署，国内如同济医院还有医学院校在使用该系统上传数据。

首先是展示的方式：

一张图片很大，如果直接加载到前端页面那必然是不可行的，浏览器加载图片如果要使得用户具有良好的浏览体验一般就是不要超过几M。而我们的图片普遍就是几G的，然后我首先想到的就是将图片分割成小块。我最开始并没有考虑到划分不同层级的分辨率，只是做了个测试简单分割了下图片，但是后面发现如果只是划分小块并没有实质性解决问题，用户打开看的时候，如果是全局视窗的情况下，依旧需要将所有的小块加载，虽然http2.0开始支持长连接以及多路复用但是加载效果还是比较缓慢。然后我们进行了相关的调研，找到一篇类似应用场景的论文，他的思路差不多也是将图片分割，但同时还提到了要将图片划分成不同的分辨率层级。也就是说在全局的视窗下我们可以先加载较低分辨率的层级图片，较低分辨率层级划分成的小块比较少所以不会出现局部缺失的情况。当放大观看局部就可以加载较高分辨率的局部图片切片，这要需要加载的图片块也不会很多。这其实就是一种懒加载的思路。后面我们也是使用了一种开源js插件openSeadragon他能够根据你展示的视窗比例以及位置计算出需要从你划分好层级的切片文件中加载那一层级哪些方位的图像切片并生成访问连接去获取。

上传解决思路：

原始方案使用的是，ajax 发送文件借助于js内置对象FormData。出现的问题：

首先ajax本身不支持断点续传的，当出现网络波动或出现中断就容易导致上传失败，其次服务器或者云防护考虑资源占用以及安全风险等因素一般会设置超时限制，这就导致了上传的文件过大时间久了会出现超时浏览器报504等错误。简单的解决办法就是在web服务器以及云防护中将超时限制时间设置得更长，这是会存在一定安全风险的。当然这种传输方式呢对客户端的浏览器以及服务端都会占用不小的资源。后面我们采用文件的分片传输，避免了超时导致的响应挂起。同时结合了异步传输接口fetch来利用其逐步读取流的特点，保证上传质量，减少对内存的占用。

保存：最开始选择的是HFDS分布式存储系统，但是后面考虑到对数据后续维护的便利，选择了更加注重用户友好性和简易性，具有更高的封装性和易用性华为云OBS。而且OBS相较于HFDS有个的优势就是同一个目录下对文件的数量没有限制的。数据存储和计算分离，集群存储成本低.

由于的图片非常大，为了在前端页面流畅的加载以及阅览。我们在将图片元数据上传至OBS之前将图片做了分层和分片处理。将图片进行了不同分辨率层级降采样，同时将每一层的图片以固定长宽进行分块然后上传到obs中存放。

我们使用openslide，一种对图像处理的开源软件库，只不过源码是 C的，在我们需要编译后进行接口绑定，原本该软件库对于具有分层信息的图片能够直接读取到相应分辨率层级的图片，然而，我们用户上传的图片来自全国各家单位，图片格式不同一，有的图片是单层的，所以一开是自己实现了对一些单层图像的降采样操作，当然也存在一定的问题，图片过大，没法将这些数据一次性加载到堆内存中，最开始我们对jvm进行了调整勉强实现了部分图片的处理，但并不是长久之计，用户又给了一张高达10G的图片。与此同时在测试过程中，我们的测试人员还发现一些原本并不是很大的图片openslide依然会抛出异常。这短时间我在找解决方案的同时呢也是有机会跟开发过类似平台的团队交流过，不过他们做的是一个本地侧的桌面应用，他们的技术路线部分跟我们一致，也使用了openslide这个软件，并且他们还跟openslide开发团队交流过，从他们那里得知该软件有部分设备采集的图像无法使用，但是具体原因他们也不了解，因为他们的应用只用于了一家单位，他们的图片格式也直接是多层结构的图片，不会出现还需要我们自己调整分辨率的情况，采集的设备也是明确适配openslide软件库的。我对比了多张图片但是每张图片或多或少都有一些差异，所以后面我研究了一下openslide的C源码，并编译了可执行文件一步一步走了一遍调试，找到了具体的抛出异常的原因。

简单来说就是tiff格式有的图片当中是存有瓦片信息以及分层信息的，openslide底层原理就是根据图片格式中提供的分层信息以及瓦片信息读取到相应层级中对应位置的瓦片图像。但并不是所有的tiff格式都具有该类结构。

进一步我在源代码中找到了该软件库支持的几种格式，他是存放在一个枚举类中的，其中有个叫generic tiled tiff。我根据该格式名称查询有没有相关的转换办法，后面找到了一款高速、内存有效率的图像处理库，libvips。它能够快速的将tiff格式进行转换，并添加瓦片信息。至此该问题才算彻底解决。

后期优化：

sendfile on;：启用sendfile系统调用来进行文件传输。sendfile是一种高效的数据传输方式，可以在内核态和用户态之间直接传输文件内容，而无需通过用户缓冲区。
aio on;：启用异步文件I/O操作。异步I/O可以让NGINX在处理文件读取时不会阻塞工作进程，从而提高处理请求的并发能力和效率。
directio 1024m;：启用直接I/O模式，并设置每次I/O操作的最大字节数为1024MB。直接I/O避免了操作系统内核缓冲区和NGINX自身缓冲区之间的数据复制，从而提升文件传输的效率和性能。

这些配置特别适用于处理大文件（如视频文件）的传输，能够显著提高NGINX处理这类请求时的效率和吞吐量。