星期一临下班时被老板叫入房间,说有一些紧急的数据需要被处理好以在周末前寄去美国﹔处理数据的程序已经就绪,只差源数据的格式不是预期的FASTA格式。所以我的第一个任务是把所有的源数据转换成FASTA格式。好的我开始构思,源数据是一个20G的压缩档,解压后有太约45G。心里略有定案,决定用Memory File Mapping 的放式把整个档案映射到一个unsigned char 的指针,然后所有的转换手续在记忆体完成,这样子的速度会快过从档案里读出、写入记忆体再转换。起初我还淡定的套用OOP的方式来分类、封装等。后来酲悟这是一个针对目前特定情况也许只用这么一回的程式,实在不需要顾虑易用、重用和维护性。再加上解压出来的源档案是一百多个,最大的不过3G。而且我也懒得实现用指针的方式寻找字串这类的低阶算法。决定转用高级语言脚本Phyton,现成的函数加上简易方便的语法,一小时左右就完成了,再花一些时间调试、修改后就丢进伺服器执行,预期第二天清晨可以拿到结果。事情没有这么顺利,第二天回到公司看见程式在转换到第一百多个档案时挂掉,原因是硬盘的储存空间用完了(如果我事先仔细做个评估就好了)后来换另一个硬盘空间做为输出,两个小时后顺利完成格式转换。心底暗为Phyton的威力赞叹,实在是简单好用的语言,而且多数Linux系统都是缺省安装,也可以当作Shell script来使唤。
然后是第二个程式,用来做一些数据的后期处理,也即是接受另一个程式的输出数据,处理后再输出。我继续用Phyton,测试后发觉Phyton的速度不足以应付3O0G的数据(费时太久,而我这Phyton初学者的功力不足以优化程式)。于是花了一些时间用传统的C语言写了相同的程式,速度快了将近五倍。毕竟脚本语言在处理如此庞大数据下无法比拟编译语言的速度。如果说脚本语言在处理1OOMB的数据比编译语言慢了3O秒,乍看之下也许没什么要紧,也不过是半分钟的差别,热腾腾的咖啡还在冒烟呢!就算是1G的数据也还只是等多五分钟而已。可是3O0G的话呢?所以那晚在公司呆到十一点半。
来到第四个程式已经是星期四的事情了。是一个简单的验证用途的程式,是要在第一个程式输出的数据里找出重复的数据单位(fasta header)。笨方法是用一个迥圈来检视每个单位,再用一个内迥圈来检视接下来的每一个单位是否和迥圈外的单位重复。如果数据不多的话两个迥圈都不会太久。可是目前数据有二千万个单位,我只好花时间想一个有效率的算法来处理。
无论如何,最终还是做完了这些紧急工作。伺服器开足马力处理着数据,期待明天早上能够拿到完整的结果,也算值得。
0 comments:
張貼留言