http://blog.cloudera.com/blog/2012/01/an-update-on-apache-hadoop-1-0/
Cloudera Blog上的这篇文章描述了Apache Projects通常的branching策略。回顾了Hadoop因为没有严格遵照这种策略而造成版本混乱的历史。
http://blog.cloudera.com/blog/2009/07/file-appends-in-hdfs/
这篇2009年的文章介绍了HDFS Append特性的早期发展历史。作者为大名鼎鼎的《Hadoop Definitive》的作者Tom White
http://hadoop.apache.org/docs/current2/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithNFS.html
http://blog.cloudera.com/blog/2012/03/high-availability-for-the-hadoop-distributed-file-system-hdfs/
Hadoop 2.0已经支持HDFS HA,参考第一篇。下面这篇是2012的文章,更加细致地介绍了HA开发细节和进展。当然,在当时还没有实现Automatic Failover,现在已经出来了。
http://blog.cloudera.com/blog/2013/04/how-scaling-really-works-in-apache-hbase/
这篇文章解释了HBase的master/slave分工机制。它与HDFS的master/slave有差别:
- HDFS Master负责管理和提供两类metadata,namespace和block locations(block-dataNode mapping)。因此,HDFS File create/delete, read/writer操作都要先咨询Master。
- HBase Master仅仅管理table metadata,而region-regionServer mapping由系统文件META提供,直接被client读取。因此,HBase Table create/delete操作需要经过master,而put/get操作完全不需要经过master,client直接联系相关的region server。
http://share.csdn.net/slides/1227
这张PPT的看点是给出一个实际的例子,表明什么是Fact Table,什么是Dimension Table,两个数据仓库中的基本概念。
<A Comparison of Approaches to Large-Scale Data Analysis>
<The Performance of MapReduce: An Indepth Study>
以上两篇论文比较了Hadoop MR与parallel DBMS之间的性能,结果在一些分析任务基准测试中,Hadoop比parallel DBMS要慢3~6倍。其中讨论了MR因为提供以下几点特性而影响任务运行性能:
- storage independent: streaming IO。MR被设计成一个独立的processing system,不绑定固定的storage system。在Hadoop中,MR可以基于HDFS,也可以基于其他存储系统如local fs, Database等。因此,MR只能采取streaming IO方式读取输入文件。streaming IO指的是任务执行进程(tasktracker)需要从另一个进程(datanode)读取输入,而不是直接从磁盘读取文件(direct IO)。如果是direct IO,执行进程可以利用DMA,把数据异步地读取到它的内存空间。
- fault-tolerance: intermediate file。假设其中某个reduce task失败了,MR系统不需要重新执行整个Job,而只是将失败的reduce task分配到其他节点执行。这是因为每个map output都是写入到一个中间文件中,而reducer将文件fetch到本地。这是pull方式,区别于parallel dbms的push方式(直接将中间结果push到下一个任务)
- elastic scalability: runtime scheduling。MR Job启动很慢的一个直接原因是一个job划分成多个task,每个task分配给哪个node去执行,是动态调度的。master等待slaves来要任务,而不是事先分配好了。slaves给master发送heartbeat是有时间间隔的,再者若同时有多个slaves要任务,master只能一个一个顺序分配。但是,这种设计的好处在于系统很有弹性,可以随时动态地分配/撤销node而不影响job运行。
- schema-on-read:MR处理的文件可以是任何format任何schema,区别于DBMS的write-on-schema。但是,这意味着MR运行时需要解析文件,将文件内容转换成相应的key/value,这又可能带来不小的运行时开销。