我和同事两人干了一件有趣的事情，我们把自己的Map-Reduce/DFS系统与Hadoop，以及另外一套某搜索引擎使用的Map-Reduc/DFS做了较为深入的分析和性能/功能测试。测试的结果非常符合我们的期望，NEMR/DFS的组合从文件的存取效率，Map-Reduce的任务分发/容错/易用性等都要明显好于Hadoop与另一套系统。当然，这三个系统的定位并不一致。

四月份，我接到的任务是重新整理DFS的Java接口，除了整理了一下包结构与异常机制，我基本没有做什么有价值的事情。原有的Java代码有较深的C/C++风格，另外，代码结构虽然凌乱但能完美的工作，我有些无从下手。当把整理完的结果commit，并关掉任务的时候，我有一种深深的负罪感。

我们组与其他部门开始合作一个应用于廉价存储设备的支持大文件的分布式文件系统（大文件意味着整个系统的元数据基本很小）。支持大文件的分布式系统开发其实比较简单，这是一个C++的项目，作为一个不是很称职的Java程序员，刚开始做C++项目的时候充满了惊奇的体验。我只负责一些边缘的开发工作，比如为这个文件系统做一个shell, 并参与了部分系统对外接口的开发，做为一个C++初学者都算不上的家伙，我在这个项目里每写一行代码都十分的小心，倒也没有出什么问题。

我一直期望把分布式文件系统的接口做的不让人惊奇。处理DFS里的文件像本地文件那样open/write/read/close/unlink，支持流式写入等。（最近开始全面接手上面的项目，可以对其好好改造啦！嘿嘿）

6月份开始了一个较大的项目，我们组开始做一个全新的支持廉价设备的(且低碳省电的)大量小文件存储的分布式文件系统。我负责开发文件的对外Java接口，以及文件系统的存储节点(C++)。其他同事开发管理工具和master。由于考虑到自己只是一个C++新人，我有意识的只使用C++的一个子集来开发系统以避免额外的复杂性。虽然在一开始就约束自己不要重做轮子，可是到了最后，还是造了很多基础设施（线程安全的集合, BlockingQueue, ThreadPool, Runnable, DailyRollingLog等等),  Hacker了一个库的部分代码。可能是因为没有找到简单，可靠的C++实用库吧。这次开发感觉很顺利，我想很大程度上要归功于我们使用了一个非常酷的通信/rpc框架，它引起的麻烦远远要小于它所克服的麻烦。

之后的精力花在了大量线上数据的迁移/线上系统的维护上面，大概有10000亿个线上文件需要迁移到新开发的文件系统。