【Reading】2014-01, 02

最新推荐文章于 2021-04-05 17:08:57 发布

原创最新推荐文章于 2021-04-05 17:08:57 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

Reading 专栏收录该内容

3 篇文章

订阅专栏

本文探讨了Hadoop及HBase的架构特点，包括HDFS的高可用性进展、HBase的master-slave机制差异及其扩展性原理，并对比了MapReduce与并行数据库管理系统在大规模数据分析中的性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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.youkuaiyun.com/slides/1227

这张PPT的看点是给出一个实际的例子，表明什么是Fact Table，什么是Dimension Table，两个数据仓库中的基本概念。

<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，这又可能带来不小的运行时开销。