【读书笔记】Data warehousing and analytics infrastructure at facebook

这好像是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.