Tag Archives: Google App Engine

重读Google老三篇

  昨晚会议结束得太晚,没赶上末班地铁,只好打车回家,俺的银子呀wuwu~

  最近在读文献。上周过了几篇蛋白基因组学(proteogenomics)的天书,实在抓狂。这周的主题回到软件领域:大规模分布式计算。昨晚是Google老三篇(GFSMapReduceBigTable)的文献讲评,瓶子哥顺便讲了讲Google Cluster,我又带了几句Chubby论文。讨论很热烈,结果就说多了。

  我负责主讲BigTable,这次细读,发现以前读的时候忽略了很多细节。

  比如,BigTable使用bloom filter算法进行元数据cache加速。bloom filter有单边特性(它说不存在的,必然不存在;它说存在的,也许有小概率错误),这的确最适合cache这种场合。

  再如,google的分布式锁服务Chubby,在GFS和BigTable中都起到关键作用。在同步控制方面,GFS和BigTable设计思路几乎一致,都是用Chubby对master节点的元数据条目加锁,但具体数据服务节点(GFS叫chunk seriver,而bigtable叫tablet server)的同步正确性,需要客户端自己来保证。这样设计的目的很明确:尽可能保证全局服务的简洁高效,防止master节点成为瓶颈,这对大规模的分布式场景是非常重要的;当然,副作用就是客户端程序的要求更高。

  BigTable的一个重要应用是Google Analytics。另外进展很快的个性化搜索也用BT来存储用户历史和参数。之前发布的Google App Engine的python存储API,有很明显的BigTable痕迹。

  身边已经开始有人从Amazon和Google租用云计算能力了,新概念被接受的速度超出我的想象。

Google App Engine开放了

  好消息是,登录Google App Engine后,终于不再显示请等待审批的提示。开通帐号需要手机短信确认。

  坏消息是,兴冲冲建立第一个应用时,发现joyfire、我自己的姓名、pBuild和pLabel这些标识都已被抢了,我只抢回了pFind。哇啦哇啦。

  说到这个,感觉第二次网络创业热潮开始降温了。之前一两年,总有域名中介联系我,希望购买lehuo.comlehuo.net系列,单域名价格最高谈到三万。但是从今年春节以后,我就没有再接到这种电话了。看样子机会真来了,追求财务自由的虫子们,准备逢低吸纳

Google App Engine视频

  Google App Engine不顾俺三番五次申请,就是不给试用帐号。郁闷呀。

  这里有一段视频,演示了简单的Google App Engine开发步骤。尤其是用GQL调用传说中的MapReduce海量分布式存储,看得俺直掉口水。趋势不可逆转,很快多数软件都会以ASP(Application Service Provider)方式提供服务。我很想知道微软首席架构师Ray Ozzie看到这东西是什么感觉。

  按一般观点,类似俺们pFind这种计算密集型应用,核心模块必须使用C/C++ API,否则慢得难以忍受。然而,一旦基础架构的分布式规模达到Google所谓的“云计算”这种级别,就算有几十万张谱,也可以充分地分而治之,被分解到巨大的PC Farm里,让集群节点一对一PK,甚至进一步按蛋白数据库再细分任务。这种情况下,即使单个节点的线性效率稍差,也可以接受,可能用Python就够了(对比:按我们现在的经验,没经过精心优化的Matlab代码鉴定一张质谱大约5分钟,当然可以进一步采用各种优化加速手段,例如psyco)。到时候,最主要的速度限制也许就来自网络带宽,上传多少即时鉴定多少。

  未来某天的软件创业故事:逃课的小孩在大学宿舍里编写了一款网路游戏(比如,也许是跑在iPhone或Android上的多人联机MMORPG),上传到Google App Engine,再到常去的论坛发个帖子,邀请大家来试玩,结果这个游戏一炮而红,Google和中国电信作为基础服务提供商,对利润进行分成。这个故事不会很快变成现实,但是也不会很慢,技术演化总是被低估。