徐葳:生物医学影像处理、分布式系统与数据共享平台

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介:



徐葳:谢谢组织者的邀请,我不是做图形图像的,我是做分布式系统的,这是我的简要经历。



我一方面在做科研,另一方面在做实践,我现在管着300台服务器,我的一些设计、想法都使得这些设备的运维变得更加容易。


首先看一个图,我们做计算机系统的人脑海中存在的系统是长成这个样子的。

今天讲影像我完全是客串,主要是因为我参加了三个跟影像有关的项目。我想让大家知道从外行的角度看我们怎么理解这件事情,我们希望能够从时间系统的角度来看怎么样帮助处理这些问题,然后我会从这些项目中引发出一个数据分享平台的想法跟大家探讨一下。


这是一个血管MRI的项目。清华影像中心收集了一批核磁共振的片子,并且请老师对片子中的血管壁进行了标注。带有标注的这类数据集是非常珍贵的,我们把这个边缘描出来,这个东西分辨率很低,而且总的数据量比较少,深度学习无法训练出有效的模型。


另一个角度讲,这个事情也比较简单,就是要识别一个圈,我们用feature学习的方法来解决。如果图中这个扇形区域覆盖了90%的亮度,我们就认为它是管壁。


后来再仔细想,这个图像也是计算机描述出来的一种影像。血管壁外侧的肌肉组织会产生一些噪声,我们发现这个噪声和血管壁的亮度是两个高斯分布,非常漂亮的高斯分布。这个feature非常简单。


从图中可以看出来训练的结果还行,他可以描述不同管壁的厚度,厚度的均匀程度也可以描述出来。


这个问题没有很大的技术含量,我也不认为这是一个非常难做的项目。但是它说明了一点,不见得任何问题都需要用深度学习来解决。feature学习非常快,结果准确率也不错。领域专家更容易想到有价值又简单的feature。而我们做计算机的,一般会想到更通用也更复杂的方法,未必能得到正确的思路。需要两方面更多交流。


三维电镜重构,通俗易懂的解释就是采集了蛋白分子各个方向的投影图像,再把这些图像重构成一个三维模型,这个系统最核心的问题有两个:一是速度太慢,用几十个核的CPU运行它,要好几天甚至一个星期;二是没有容错机制,挂掉一个进程,整个计算都失败了。


以运行的更快呢?系统本身是并行化的,图中是运行的效果。下面蓝色的部分是互相等待的时间,上面橙色的部分是运算的时间,平均每个核算的时间和平均每个核等的时间。大家可以看到从第二条线64核增加到第三条线128核之后,速度反而变慢了,这是由于CPU在等待的时间已经大大超过了运算的时间。我们对它的并行算法做了简单的优化,首先我们增加了同步数据时候的并行,这时我们得到了第四条线,蓝色的等待部分跟第二条线比减少了。我们进而减少了读写磁盘,改成了用网络同步,得到第五条线。我们可以看到,同样是128个CPU核,第五条线运行要快了不少。


优化速度之后,我们依然不满意,因为这个架构中挂掉一个机器,整个系统就瘫痪了。系统规模越大,坏掉一个机器的概率越高,运行时间越长,这个概率也会增加。


这引出一个更广泛的问题,大数据在系统方面有没有技术上的贡献?大家会普遍认为有。但是从技术层面说,大数据用的方法大家不知道吗?好像大家过去也知道,其中并没有什么特殊的方法创新。但是大数据系统用的是非常便宜的机器,系统内任何一个机器宕机都不会影响整体的运行,这是谷歌设计MapReduce系统的核心。因为只有设备便宜才能跑成规模,价值密度低是大数据的典型特性,成规模的廉价设备使得处理海量价值密度低的数据成为可能。


我们现在反过来,能不能把大数据系统这个低成本的优势扩展到其他领域,例如科学计算可不可以也在更便宜的硬件平台上运行,我们希望在这个方向上能有所改进。我们现在正在做的事情就是把这个架构从MPI推到SPARK架构,增加系统的容错性。


大数据的算法有一些特殊的优化,大数据算法的优化一般是让他怎么样跑的更快。现在有一些Mini-batch的算法,你不要每次都加载很多数据。我们还在做更为细致的实验,但我们认为这个方法在很多领域都是可以用的,在电镜图像重构这个领域也可以用。


上面是我介绍的第二个项目,在这个项目中我考虑的是大数据的基础架构能不能用在其他领域。这些领域不是典型的大数据领域,其数据量也不是很大,但是大数据提出的架构和设计思想怎么样能在这些领域中结合。

我要给大家讲的第三个案例是一个有关果蝇的项目,这是我们和加州大学伯克利分校以及美国能源部劳伦斯国家实验室合作的。果蝇是非常重要的生物学模型,很多实验室都拿它做实验。


这个项目的本身的想法非常生物学,但是其中遇到的问题完全是操作系统管理和软件工程方面的事情。


关于果蝇的生长已经研究的非常清晰了。随着成长果蝇的不同器官会顺序发育出来。果蝇的卵最初是是均质的,为什么会发育出不同的器官?上世纪八十年代科学家发现,这些相同的物质所处的地方不同会发育成不同的器官。如果使用激光把中间某一部位烧掉,这一部分对应的器官就不会长出来。右侧的图叫做Fate Map。Fate Map大家早就知道,但是产生这个图的原因至今还不清楚。


基因在不同阶段表达的位置是不一样的。


下面我要说的是一项非常值得尊敬的科学工作,做这个项目的实验室大概有二十个人,他们大概花了十多年的时间,一种一种基因染色,染色完了在显微镜下照出来,一种一种基因地做。过了十年之后,现在已经做到7971种基因,照了12万多张图片,12万多张是手工选出来的,每一种基因挑出看的稍微清晰一点的,可以从各个角度看的,这是一个非常珍贵的数据集。现在他们的工作加快了速度,因为他引入了机器人,机器人会自动筛选出比较好的照片。


这里大家可以看到一些基因表达的位置。不同颜色代表了这种基因表达的多少。现在生物学家的问题是:这些东西有什么用?能不能从这些照片中找出一些规律?


如果这个基因在这里表达,那么它是不是这三个pattern呢?其他基因也有这个pattern,这个pattern可能跟今后的器官发展有关吗?


后来伯克利的团队使用非负矩阵分解的方法来处理这些图像,他们有很多的Factorization,每一种基因导致了Factorization有不同的线性组合,最终组合出如下图像。


结果是一共产生21种pattern,这些pattern是有对应关系的,这些对应关系都具有物理含义。



这个项目是由一个跨学科合作团队来承担。包含了统计、生物学以及计算机系统方向。这三个方向缺一不可。


刚才他说的这个东西为什么复杂?为什么需要计算机系统的团队来协助? 我们认为有以下三个主要问题。


第一个原因是数据的预处理。我们看图像处理或者计算机视觉的文章,它们一般会把预处理的部分省略掉。实际上这些文章的大部分时间是花在数据的与预处理上的,但是这些庞杂的预处理工作没有办法在文章上说。


例如这个项目的另一个研究题目中,需要尝试不同的预处理用来找到superpixels。这个工作面对两个挑战:第一,太慢。第二,预处理的结果不能共享。

第二个挑战是数据实验的管理。做过实验的人都知道,实验不是做一次就能成功的,每一个成功的实验背后都有无数次的尝试和结果的比对。哪个实验的结果更好是预先不知道的,这不但需要我们对每一组实验进行记录和标记,并且能够重现。例如上边讲的实验,里边的21是怎么来的?那是尝试了很多参数配置之后得出来的。如何管理这一次一次的实验,让这些实验变成可重复的,实验方法变成可重用可共享的?这也是我们需要解决的难题。


第三点是我们需要,需要解决的问题是友好的交互界面。大家对比一下难学难用的大数据系统,和Excel的简洁界面,就不难看出为什么Excel真正的促进了跨学科跨领域以及商业上的交流了。


现在大家所说的数据共享,基本上是指将数据放在一个平台上,大家都可以下载。这种数据的共享只是共享了数据,但是并没有共享数据处理的算法,比如说我可以下载一个APP,让这个APP能够提供数据处理的功能。不论哪个学科,他可以根据需要将不同算法组织起来,通过调整参数的方法解决数据处理的需求。


另一个关键问题是共享的层次。要给什么人共享,算法的灵活的是多少,这些都是问题。这将决定共享的内容有哪些人喜欢,哪些人不喜欢。


数据标签的共享也是非常重要的,这些标签能不能共享,标注的经验能不能积累,这也是需要考虑的问题。


讲讲我们具体的解决方案。我们首先需要一个代码管理和数据管理的运行环境。



数据的历史可以共享,代码的变化和数据的变化都需要记录,另外需要提供在线编辑的功能。



第一,我们做系统的人希望做一个系统促进大数据领域的人互相交流。具体怎么交流是数据院的事,我提供技术的解决方案。第二,深度学习之前的时代和深度学习之后的时代,计算机的分析对系统的依赖是不同的,现在我们在探索深度学习的方法,也希望跟大家多沟通,看看需要什么样的系统架构的支持。


原文发布时间为:2016-01-22

本文来自云栖社区合作伙伴“大数据文摘”,了解相关信息可以关注“BigDataDigest”微信公众号

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
1月前
|
消息中间件 监控 数据可视化
Apache Airflow 开源最顶级的分布式工作流平台
Apache Airflow 是一个用于创作、调度和监控工作流的平台,通过将工作流定义为代码,实现更好的可维护性和协作性。Airflow 使用有向无环图(DAG)定义任务,支持动态生成、扩展和优雅的管道设计。其丰富的命令行工具和用户界面使得任务管理和监控更加便捷。适用于静态和缓慢变化的工作流,常用于数据处理。
Apache Airflow 开源最顶级的分布式工作流平台
|
1月前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
39 5
|
1月前
|
存储 缓存 算法
分布式缓存有哪些常用的数据分片算法?
【10月更文挑战第25天】在实际应用中,需要根据具体的业务需求、数据特征以及系统的可扩展性要求等因素综合考虑,选择合适的数据分片算法,以实现分布式缓存的高效运行和数据的合理分布。
|
2月前
|
JSON 分布式计算 前端开发
前端的全栈之路Meteor篇(七):轻量的NoSql分布式数据协议同步协议DDP深度剖析
本文深入探讨了DDP(Distributed Data Protocol)协议,这是一种在Meteor框架中广泛使用的发布/订阅协议,支持实时数据同步。文章详细介绍了DDP的主要特点、消息类型、协议流程及其在Meteor中的应用,包括实时数据同步、用户界面响应、分布式计算、多客户端协作和离线支持等。通过学习DDP,开发者可以构建响应迅速、适应性强的现代Web应用。
|
2月前
|
存储 缓存 NoSQL
分布式架构下 Session 共享的方案
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求、系统架构和性能要求等因素,选择合适的 Session 共享方案。同时,还需要不断地进行优化和调整,以确保系统的稳定性和可靠性。
|
4月前
|
数据采集 分布式计算 并行计算
Dask与Pandas:无缝迁移至分布式数据框架
【8月更文第29天】Pandas 是 Python 社区中最受欢迎的数据分析库之一,它提供了高效且易于使用的数据结构,如 DataFrame 和 Series,以及大量的数据分析功能。然而,随着数据集规模的增大,单机上的 Pandas 开始显现出性能瓶颈。这时,Dask 就成为了一个很好的解决方案,它能够利用多核 CPU 和多台机器进行分布式计算,从而有效地处理大规模数据集。
248 1
|
4月前
|
运维 安全 Cloud Native
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
|
4月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
76 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
下一篇
DataWorks