这好像是sigmod2010上的paper。
读了之后做了以下几点记录:
1. facebook的hadoop cluster分成
scribe hadoop cluster: scribe servers将web service的log汇总然后存到HDFS上。通常会有带宽成为bottleneck的问题,这时候可以考虑压缩,但是一个副作用就是在buffer待压缩的数据的同时导致latency增大;
production-hive hadoop cluster:通常处理schedule好的,有严格deadline的任务;
Adhoc hive hadoop cluster:优先级较低的批处理任务或者adhoc的用户分析任务;
2. 提到了一个减少磁盘存储空间的办法:将HDFS通常的replica为3降到2.2——用2份copy+2份datacorrect codes;或者考虑 HDFS RAID。另外,facebook广泛用gzip压缩要存在hdfs里的data。还有基于PAX的row columnar压缩技术,可以在gzip的基础上减少10%到30%的空间;
3. 通常在end of day才会把HDFS里的raw data导入到hive的table里面,为了解决这种情况下用户及时使用这些data,就引入了Hive的external table。(这个我还不了解)
4. NameNode的scalability方面,adhoc hive的hadoop cluster的namenode使用的是48GB的内存。facebook除了优化namenode数据结构外尝试做的几件事:combine files into one archive;开发了HiveCombinedFileInputFormat,这玩意的好处是一个maptask可以读在这个node上的不同文件的block。(传统的map task的InputFormat只处理一个文件里的block吧。)
5. hive方面:开发很多工具方便hive查询,大大提高效率(否则写mapreduce程序对熟悉sql的开发人员来说过于复杂)。还有就是能够isolate一些用户写的很差的hive查询(这些查询没准会导致机器crash)。
6. 对periodical batch job和ad hoc job的处置;这会牵涉到resource sharing的问题,facebook为job tracker引入了fair shedular;
7. cluster资源的监控cpu、memory、network、jvm等等,load balance的监控等等。。。
7.