关于 Dhanji R. Prasanna 的一篇博文

有朋友推荐我看到一篇前 Google Wave team 的员工的博客。其中对于 Google 工作环境的评价,让我很自卑。进入 Wave team 是当时好多中国工程师梦寐以求的,老外自由度就是高,进去了还能挑三拣四的。

其中对于 Google 软件技术的部分评价,我实在不敢苟同。原文如下:

Protocol Buffers, BigTable and MapReduce are ancient, creaking dinosaurs compared to MessagePack, JSON, and Hadoop. And new projects like GWT, Closure and MegaStore are sluggish, overengineered Leviathans compared to fast, elegant tools like jQuery and mongoDB. Designed by engineers in a vacuum, rather than by developers who have need of tools.

这里提到的有些技术确实不怎么的,比如 MegaStore。有些技术我不了解,比如 GWT 和 jQuery。但是要说 Protocol Buffers 不如 MessagePack,是有问题的。MessagePack 在他的主页上说,serialization 和 deserializtion 的速度是 Protocol Buffers 的四倍,而且提供了强大的 RPC 机制。(Google Protocol Buffers 的开源项目中没有 RPC 功能,有很多其他开源项目作为 Protocol Buffers 的扩展,加上了RPC 功能。)但是 MessagePack 好像没有 versioning 功能,而这个才是 Google Protocol Buffers 的核心设计思路 —— 要能支持大规模系统,大到我们不能保证其中所有涉及通信的模块能同时更新;而 serialization 不是什么神妙的东西 —— 从 MFC 和 Java 的 serialization,到 XML、JSON、BSON 都在搞这个。你要是不喜欢,自己做一套自己的也不难。

MapReduce 不如 Hadoop,这个就更不靠谱了。 Hadoop 才应该是博客原文中所说的“恐龙”。用 Java 实现 —— 在并行计算中放弃效率去追求莫名其妙的“可移植性” —— 现在谁家搞 datacenter 还去找些 MIPS 处理器的机器混合着 Intel 机器来用啊?!过分复杂的设计(各种 readers、writers)来追求支持各种文件格式 —— MapReduce 相对于 MPI和BSP 的最根本优势就是“限制很多、可定制程度很低、不给程序员出错的机会”,从而提程序员遮掩并行程序设计的复杂性。Google 这么多年里做了这么多产品,而 MapReduce 只支持四种文件格式:初学者好玩用 text、需要支持 key-value pairs 用 SSTable、不需要则用 Record file、要扫描数据库则使用和 BigTable 的接口。而且 Google 是个代码公开的公司,鼓励大家修改代码;如果这些文件格式不够用、可以自己从标准的 reader、writer base classes 派生支持其他格式。但是却没有人真的这么做。

最后说一点最关键的:Google MapReduce 的每个并行计算作业(job)有自己的 master 调度和控制作业;而 Hadoop 在一个 datacenter 上的所有 jobs 共享一个master(称为 JobTracker),只要这个 JobTracker 挂了,整个 datacenter 就得重启 —— 这种shi一样的设计,何先进之有啊?!在 Apache Hadoop 的官方博客上,赫然写着“下一代Hadoop计划”是让每个 job 有自己的 master,并且要学习 Google 用一个专门的分布式操作系统来管理机群硬件的做法。