爱吱声

标题: 吐槽一把，都是钱闹的 [打印本页]

作者: 喜欢喝冰茶 时间: 2015-7-11 04:34
标题: 吐槽一把，都是钱闹的
最近开始成批量的和全基因组较劲，起因在于一旦真到了临床诊断这一步，那可真是是骡子是马拉出来溜溜了。临床诊断要求之苛刻，把所有其它的测序protocol都打回了原形，只有高大上的全基因组看起来才是真金不怕火炼。

现在的技术，30x的WGS成本和200x的WES差不多了。就是这计算量嘛，得按天算，文件大小嘛，是按T算。如果一旦投入流水线操作，这等的时间和文件的存储可真是要了命了。

作者: MacArthur 时间: 2015-7-15 04:02
您这是。。。

作者: 喜欢喝冰茶 时间: 2015-7-15 04:30

MacArthur 发表于 2015-7-14 14:02
您这是。。。

http://www.ngscn.com/index.php/News/newslist/id/853

数据量太大，等时间太长，这要是上到临床诊断，流水线生产，崩溃中。

作者: 老兵帅客 时间: 2015-7-15 04:35
欢迎选购超级服务器阵列，性能保您满意，只要付得起钱。

作者: 喜欢喝冰茶 时间: 2015-7-15 09:20

老兵帅客发表于 2015-7-14 14:35
欢迎选购超级服务器阵列，性能保您满意，只要付得起钱。

我们本来用的就是商用的云计算系统，数据处理是专门优化滴了，只不过全基因组太大太慢了，相对于另外一种常用的protocol，话说学校里的超算就是个渣渣，除非我的用户级别极高才行。这不还是钱闹得嘛，现在保险公司不买单不是。

作者: eshark 时间: 2015-7-15 09:48

喜欢喝冰茶发表于 2015-7-15 09:20
我们本来用的就是商用的云计算系统，数据处理是专门优化滴了，只不过全基因组太大太慢了，相对于另外一种 ...

全闪存那是必须的，有个DSSD听说过哇，号称可以提供内存级的外部存储访问。

作者: 喜欢喝冰茶 时间: 2015-7-15 09:56

eshark 发表于 2015-7-14 19:48
全闪存那是必须的，有个DSSD听说过哇，号称可以提供内存级的外部存储访问。 ...

原始数据一旦调入应该还好，当然读取越快越好，主要是有大量的de bruijn图在里面。

作者: straw 时间: 2015-7-15 13:18
本帖最后由 straw 于 2015-7-15 13:20 编辑

这个最好还是超大内存单机组成的高性能计算集群, 并且要对blast等程序对大内存优化一下的，商用云计算那是用错了方向，根本不是你这种用途的。

作者: straw 时间: 2015-7-15 13:24
靠，华大的，好吧，我已经脱离这一行了

作者: eshark 时间: 2015-7-15 20:56

喜欢喝冰茶发表于 2015-7-15 09:56
原始数据一旦调入应该还好，当然读取越快越好，主要是有大量的de bruijn图在里面。 ...

如果随机小IO众多，机械磁盘肯定不行的。哪怕是VMAX和DS8000都搞不定，一定要全闪。大块连续的对象数据可以考虑Islon

作者: 喜欢喝冰茶 时间: 2015-7-16 00:08

straw 发表于 2015-7-14 23:24
靠，华大的，好吧，我已经脱离这一行了

华大似乎在美国市场还没做到诊断阶段吧。

作者: 喜欢喝冰茶 时间: 2015-7-16 00:09

eshark 发表于 2015-7-15 06:56
如果随机小IO众多，机械磁盘肯定不行的。哪怕是VMAX和DS8000都搞不定，一定要全闪。大块连续的对象数据可 ...

个人感觉小IO应该比较少

作者: 喜欢喝冰茶 时间: 2015-7-16 00:12

straw 发表于 2015-7-14 23:18
这个最好还是超大内存单机组成的高性能计算集群, 并且要对blast等程序对大内存优化一下的，商用云计算那是 ...

太绝对了吧，cluster和商用系统有什么本质上的区别。如果不能把jobqueue和pipeline整合在一起，根本就快不了。华大有个gpu做这个很快，但是公开的据说是老版本的。

作者: 冰蚁 时间: 2015-7-16 00:58

喜欢喝冰茶发表于 2015-7-15 11:12
太绝对了吧，cluster和商用系统有什么本质上的区别。如果不能把jobqueue和pipeline整合在一起，根本就快 ...

我记得前段时间看过一个文章里讲某牛人转行开发化学研发专用计算机，用于化学过程模拟什么的。这种计算机的出现极大地缩短了模拟时间，从多少天减到多少个小时就有结果。从而使得化学仿真可以得到极大的应用。所以直观感觉是你这行可能也需要类似的机器，不然速度搞不定。

作者: eshark 时间: 2015-7-16 09:24

喜欢喝冰茶发表于 2015-7-16 00:09
个人感觉小IO应该比较少

那就考虑Islon吧，看起来你们的应用和数字视频的非线性编辑比较像，文件大，连续数据读写多，非常适合Data Lake的架构。还是基于以太网的，便宜哈。

作者: straw 时间: 2015-7-16 10:54

喜欢喝冰茶发表于 2015-7-16 00:08
华大似乎在美国市场还没做到诊断阶段吧。

抱歉抱歉,只是顺着你给的网页看到华大参与了

作者: straw 时间: 2015-7-16 11:01

喜欢喝冰茶发表于 2015-7-16 00:12
太绝对了吧，cluster和商用系统有什么本质上的区别。如果不能把jobqueue和pipeline整合在一起，根本就快 ...

我已经脱离这个行当满久了, 不知道现在的情况. 不知道你们需要超算是进行哪一步，图像识别这一步我不了解，但是序列比对，拼接基本都是用的隐马算法，大内存对这个算法的作用很大。而一般商用云计算基本都是虚拟机，内存不完全是直接访问的。我想你们是把单一序列分开进行计算，然后再整合起来。如果任务数量减少的话，对你们的处理应该是有很大的帮助的吧。

作者: straw 时间: 2015-7-16 11:04
以前就听说有人把算法做成PLC进行计算。速度会快很多，不知道这个是否有帮助。

作者: 喜欢喝冰茶 时间: 2015-7-16 23:05

冰蚁发表于 2015-7-15 10:58
我记得前段时间看过一个文章里讲某牛人转行开发化学研发专用计算机，用于化学过程模拟什么的。这种计算机 ...

该不是D.E.Shaw开发的那个可以直接硬件算氢键的用于MD Simulation的玩意儿吧。那东西确实挺快，不过用的人不是应该不很多，离应用有点远，不知道药厂有没有买的。反正他们家有钱，烧就是了。

作者: 喜欢喝冰茶 时间: 2015-7-16 23:10

eshark 发表于 2015-7-15 19:24
那就考虑Islon吧，看起来你们的应用和数字视频的非线性编辑比较像，文件大，连续数据读写多，非常适合Da ...

文件大不假，连续数据读写不应该算多。这个问题不是硬盘快不快的问题，而是算法的问题，那玩意是个NP complete的问题。

作者: 喜欢喝冰茶 时间: 2015-7-16 23:14

straw 发表于 2015-7-15 21:01
我已经脱离这个行当满久了, 不知道现在的情况. 不知道你们需要超算是进行哪一步，图像识别这一步我不了解 ...

对于NGS来讲，HMM在aligment里是很少使用的，虽然在protein里用的相对多一些。至于blast这种东西，只在一些非常少的特别的project会用。无论是DNA－seq还是RNA－seq都需要genome assembly或者transcriptome assembly，这是一个NP－complete的问题，只不过相对于整个human genome来说，大约是1%－2%的量级。

作者: 冰蚁 时间: 2015-7-16 23:17
本帖最后由冰蚁于 2015-7-16 10:18 编辑

喜欢喝冰茶发表于 2015-7-16 10:05
该不是D.E.Shaw开发的那个可以直接硬件算氢键的用于MD Simulation的玩意儿吧。那东西确实挺快，不过用的 ...

好象是那个。我的意思是能不能借鉴那个思路，发展专用计算工具（包括数据专用存储格式之类），也许做几个层次算法模板，整个数据文件一次读入，模板一层层覆盖后直接出结果。

作者: 喜欢喝冰茶 时间: 2015-7-16 23:36

冰蚁发表于 2015-7-16 09:17
好象是那个。我的意思是能不能借鉴那个思路，发展专用计算工具（包括数据专用存储格式之类），也许做几个 ...

计算工具和文件格式都是专用的，不像一般的超算，用的商用云计算pipeline是可以编程的，它将cluster上的jobqueue系统和pipeline整合起来，自动的会根据pipeline和系统资源来调整，效率已经比较高了。至于用硬件来实现区域基因组的组装或者转路组的组装，这个现在看起来还是个挑战，不过如果能做出来的话，至少DNA－seq和RNA－seq会大大加速。

作者: 冰蚁 时间: 2015-7-17 00:13
本帖最后由冰蚁于 2015-7-16 11:18 编辑

喜欢喝冰茶发表于 2015-7-16 10:36
计算工具和文件格式都是专用的，不像一般的超算，用的商用云计算pipeline是可以编程的，它将cluster上的j ...

直观感觉就是开发一些 asic 芯片的事情。做出来了，也许就是几个目前手持设备大小的东西。瞎说说。

作者: eshark 时间: 2015-7-17 13:11

喜欢喝冰茶发表于 2015-7-16 23:10
文件大不假，连续数据读写不应该算多。这个问题不是硬盘快不快的问题，而是算法的问题，那玩意是个NP com ...

除非你的内存可以一次性load所有数据，并且中间结果也能在内存里hold住，否则一般优化后台存储可以提高30%-50%的应用性能。比较相对于cpu的内存访问，机械磁盘的响应速度慢了几百倍。

作者: 水风 时间: 2015-7-17 19:08
一看就是算法问题。商业的云计算根本就不是干这个的。你们不知道也就罢了，你们头不知道就是个奇葩了。

作者: 喜欢喝冰茶 时间: 2015-7-17 22:21
本帖最后由喜欢喝冰茶于 2015-7-17 10:27 编辑

水风发表于 2015-7-17 05:08
一看就是算法问题。商业的云计算根本就不是干这个的。你们不知道也就罢了，你们头不知道就是个奇葩了。 ...

商业云计算只是提供个平台而已，并不都是AWS模式。专用的云计算平台多了去了，而且都是针对性的。算法问题？嘿嘿，谁都知道是算法问题，这么多年了，您不妨告诉我哪里有更好的。至于懂不懂，只有呵呵了。

作者: 喜欢喝冰茶 时间: 2015-7-17 22:21

eshark 发表于 2015-7-16 23:11
除非你的内存可以一次性load所有数据，并且中间结果也能在内存里hold住，否则一般优化后台存储可以提高30 ...

我们有的确实是把整个基因组调进内存的，跑那个玩意儿，至少32G吧

作者: 水风 时间: 2015-7-18 03:03

喜欢喝冰茶发表于 2015-7-17 22:21
商业云计算只是提供个平台而已，并不都是AWS模式。专用的云计算平台多了去了，而且都是针对性的。算法问 ...

我当年跟人合作过，不过我们那个时候没有这么牛，做不到全基因组。就测了一条最短的染色体的长臂。
我不是搞计算方面的，是测序部分的。具体的算法细节，我也不清楚。但算法问题也是吐糟了好久，到头也没解决掉。我们最后的法子是严重偷工减料版的。就是只检测已知的基因的编码序列，而且不是全部，只是已经报道过的那些点突变和缺失突变。这就把工作量减少了3－4个数量级，总算是能够让计算能够在一天内完成了。然后随机检测了十几个基因的全序列。也就应付过去了。反正最后发的文章好像还很不错。

这个就跟您一说。这个策略肯定是能够解决您目前的问题的。但严重缩水。

您在国内阿，也难怪了。呵呵。

作者: 喜欢喝冰茶 时间: 2015-7-18 05:21
本帖最后由喜欢喝冰茶于 2015-7-17 15:22 编辑

水风发表于 2015-7-17 13:03
我当年跟人合作过，不过我们那个时候没有这么牛，做不到全基因组。就测了一条最短的染色体的长臂。
我不 ...

不知道您当时用的什么方式，sanger？08年那会儿NGS是还不很完善，无论是实验还是计算部分。所以那会儿也就Chip－Seq还能用。不过这东西一日千里的发展，很多曾经接触过的还想当然的以为瓶颈在alignment上，这东西根本就不是个事儿，NIH前两年就不再支持这类工具，因为太多。一个全基因组大约1个Billion对的reads，我们六个node的系统五个小时搞定，有什么可抱怨的。至于Mutants的准确性，至少 Whole Exome Seq和NIST的标准以及SNP array两个平台的重合度是达到诊断量级的，要不自去年下半年开始，TCGA的文章就已经开始对临床提出分型建议了。其实我们的问题有两个，一个简单些，因为pipeline是可以在任何一点重启的，就必须保留太多的中间文件，一个样本大约2个多TB，把node的硬盘用完了，另一个比较麻烦。现在的DNA和RNAseq都需要assembly，这个才是要了命的。这个云计算系统还是非常高效的，六个node的系统，处理六个200x－300x的WES数据，四五个小时，进去fastq，出来是annotated文件了。

别小看国内，一年前新搞得的基于CUDA的variants detection速度提高了好多，把按天算的搞成按小时算，可以说是个巨大的进步，倒真想回国内用用他们的东西。

作者: 水风 时间: 2015-7-18 10:18

喜欢喝冰茶发表于 2015-7-18 05:21
不知道您当时用的什么方式，sanger？08年那会儿NGS是还不很完善，无论是实验还是计算部分。所以那会儿也 ...

是自动测序仪，应该是sanger原理的。当时还没有上市的型号，我老板人头熟，公司送给我们免费试用的。当时chip才刚有文章出来。你测个基因没问题，但是要测染色体，那远远不够。
看起来assemble的问题始终没有解决阿。但重复序列这个的确也难为你们了。当时人类基因组都99.9%了。剩下的重复序列就是对不上。那可是集中了全球最顶尖的科学家，几千号人。好久没有追踪这个了，不知道到了100%了没有。也不知道他们最后的算法是什么。
我可没小瞧国内。他们当年把水稻基因组发表，我就知道国内已经至少在这方面赶上来了。据说最关键的assemble是用的北大生科院党委书记的策略。当时是眼镜碎了一地。没想到一个政工干部，还这么牛。

我是偏生物功能这一派的。重复序列里面，除非大规模的片段插入或者缺失，包含的影响生物功能的变化很少。所以，当年我是力主简化的。为了这0.1%的可能突变，去占用了99.9%的计算资源，在我看来完全是浪费。不过时代不同了，我也早不干这个了，或许行业标准已经变了。

作者: 水风 时间: 2015-7-18 10:19

喜欢喝冰茶发表于 2015-7-18 05:21
不知道您当时用的什么方式，sanger？08年那会儿NGS是还不很完善，无论是实验还是计算部分。所以那会儿也 ...

作者: 喜欢喝冰茶 时间: 2015-7-18 12:39

水风发表于 2015-7-17 20:18
是自动测序仪，应该是sanger原理的。当时还没有上市的型号，我老板人头熟，公司送给我们免费试用的。当时 ...

严格意义上，第二代大规模以荧光为基础的测序仪都可以说是sanger原理的，问题是有多深，有多快，准确率如何，你那个可能还不算商用的NGS，公认的NGS大规模商用在2007年，现在常用的数据分析方法大约在08，09年开始出现。至于重复片段，现在有的测序仪可以产生几千base的片段。但是就mutant而言，重复片段的影响非常小，事实上做序列的大部分人并没有特别在乎重复片段，除非做植物。呵呵，diagnosis可比screening要求苛刻的多得多。

assembly所使用的计算机算法是NP－complete的，有点像做神经的几乎对高级神经活动也没什么好的办法一样。至于DNA和RNA seq的assembly并不需要组装完整的基因组，因为这两种属于resequencing，大部分reads都是相对没什么错误或者很少错误的。只有那些带有相对多错误的部分才需要assembly，问题在于如果只有一两百base的片段，谁也不知道它是来自于带有很多突变的片段还是另外一个相对少的地方，这不是算法能解决的。

我原来也是做生物出身的，后来觉得很多时候也是忽悠，还不如作点实际的东西，至少计算机算法和数学还更靠谱些，当然统计这东西里面trick很多。做这一行比较厉害的基本上都是生物出身的，加上不错计算training的。让一个医生和一个计算科学的人聊聊，估计鸡同鸭讲了。

作者: 水风 时间: 2015-7-20 04:07

喜欢喝冰茶发表于 2015-7-18 12:39
严格意义上，第二代大规模以荧光为基础的测序仪都可以说是sanger原理的，问题是有多深，有多快，准确率如 ...

你还真是干这行的老手了。
我那篇文章是07年初发的，工作主要是05－06年做的。因为是合作，我过后就转做别的了。对于测序行业后来的发展就完全摸不着头脑了。

但是我用基因测序方法检测病人突变的工作，做了很长时间。所以，你们的基本操作原理估计还是那套。一般说来，大家都是从已经发表过的有突变的基因开始找起，先看有没有插入或者缺失，有些时候单基因删除也会造成单基因功能性不足，从而引发问题。没有的话，就看编码序列，编码没有问题，就看剪切，尤其是选择性剪切的。再没有，看RNA前后的非编码序列。最后看该基因表达的水平。当年就是拿病理组织切块做northern。现在手段多了去了。这些都找过了，没有的话，就看同一信号传导链上的基因或者功能伙伴，然后是结合蛋白。基本上跟病理相关的这些别人都做过了。去找出来一一看过。最后什么都没发现的话，就打入另册。

你们所做的，无非就是看到RNA的非编码序列。有可能连选择性剪切后各种异切体的丰度看一看，不知道你们能不能看表达，但是后面的步骤，不是测序就能够解决了的。必须要有生物学实验，最好是老鼠的动物模型，当然，一个小突变，如果很重要的话就是一篇不小的文章了。

所以，我一直认为，纯粹的测序检测，只能看已经知道突变的基因。估计你们就是发现了相关的新基因，都不会报道的。因为这必须要有生物学证据才行。这么说起来，你们的全基因组测序，其实也就是测个几百个就足够了。人类的25000多基因，你们根本就是测了也是浪费。

生物里面当然忽悠是很多，但要走下去，还是要靠真本事。当然忽悠也是本事的一部分。你是生物出身，好好干吧。我看好你阿。说不定啥时候，我们就有个合作了。

作者: 冰蚁 时间: 2015-8-4 00:45
建议写科普文吧～～～

作者: ekid 时间: 2015-8-4 10:21

冰蚁发表于 2015-8-4 00:45
建议写科普文吧～～～

支持科普！

欢迎光临爱吱声 (http://www.aswetalk.net/bbs/)