【Reading】2014-01, 02

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

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





评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值