2012-09-12

昨天下午突然被通知,周四搬到村里去上班。说实话,我真的很沮丧。一是某公司有强制加班(不是因为工作没完成)又不付加班费的习惯,二是上班大大的远了,且不说现在的房子何时到期,总之在中关村附近想找个交通方便又住的舒服的地方,很难。

最近的工作重心依然放在kafka和hadoop上。为了让调试代码方便,我自己改了改kafka的SimpleConsumer的代码,让它支持socks代理。但是SimpleConsumer是针对单个broker的单个consumer的。如何从zookeeper中获取topic的partition信息,我还不甚清楚。我之前以为如果有两个broker,那么每个topic会自动分摊到这两个broker上,现在看来似乎不是的。(update: 这是kafka的bug https://issues.apache.org/jira/browse/KAFKA-278)

elephant-bird 让我耗了很久时间。我本来是写了一个程序,利用elephant-bird的ProtobufBlockWriter写入hadoop,然后拿com.twitter.elephantbird.pig.load.ProtobufPigLoader 载入,然后再在pig中dump出来。但是执行dump的时候,每次都是在准备阶段就失败了。map/reduce的task count都是0,最终的输出也是空。而且,我看不到任何错误日志。愤怒!

最后我看了看代码,ProtobufPigLoader是从LzoBaseLoadFunc继承的,于是我感觉似乎是要求这个file必须用lzo压缩。好吧,开始搞lzo的东西,可惜了,hadoop-gpl-compression 在windows下似乎是编译不过去的。liblzo2可以。由于压缩效果还是挺明显的,所以我觉得不压缩是不道德的,于是就乖乖的去折腾hadoop-gpl-compression 了。这东西在CentOS的官方的yum源里面就有,如果自己编译的话,hadoop-gpl-compression 要求liblzo2非得编译成动态库,不能是静态库。另外这个库还必须放在LIB_LIBRARY_PATH中,光用java.library.path指定还不行。于是我乖乖的去求运维人员了,我没root权限。

随着把lzo搞定,在pig中dump终于成功了。

我在网上找了找关于LZO和snappy的对比,发现在压缩比例上LZO并没有明显的优势,但snappy的解压缩速度要远远高于LZO,而且不存在版权问题,而且snappy已经被hadoop内置了。所以,相比于lzo,我更喜欢snappy。但是twitter的这些代码,既没有一页文档,也没有多少注释,我还没看懂,不知道怎么改。还有,elephant-bird对protobuf只支持2.3.0,不支持2.4.x。

linkedin的http://sna-projects.com 网站 被重定向到 http://data.linkedin.com/ 了。

此博客中的热门博文

在windows下使用llvm+clang

少写代码,多读别人写的代码

tensorflow distributed runtime初窥