【Reading】2014-01, 02
2014-01-19 14:16
267 查看
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,这又可能带来不小的运行时开销。
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,这又可能带来不小的运行时开销。
相关文章推荐
- NYOJ-32 组合数 AC 分类: NYOJ 2014-01-02 22:21 112人阅读 评论(0) 收藏
- 流水账2014 02/01~02/03
- 软件工程结对开发作业01-02
- STL源码解析-02配置器-01使用
- 写作_01-02_templatev1.0
- Java语言介绍(04)开源项目(02)Web框架(01)Spring
- [BZOJ]3597: [Scoi2014]方伯伯运椰子 01分数规划+spfa
- 20161220L05-02和L05-04老男孩Linux运维实战培训-硬盘的基础知识介绍01和02
- headfirst python 01~02
- (3) PHP 随笔---Smarty模板引擎技术基础+MiniSmarty 01-02
- cocoscreate 官方例子说明 01_graphics_02_particle_AutoRemoveParticle by:adady
- JAVA高级02_01 File类 2011-4-22
- cocoscreate 官方例子说明 02_ui_01_widget_WidgetAlign by:adady
- day_01至day_02
- [转载] 百科全说——何裕民:补品大调查(11-02-01)
- 【架构师】【数据库基础】【笔记 01】快速了解数据库系统的重要概念02
- 【笔记】2014-01<—>2014-02
- Java笔记02-Java语法基础01
- IOS开发笔记-02 图片浏览&amp;Tom 猫-01.放大缩小 02.首尾式动画 03.位移形变
- android_常用UI控件_02_EditText_01添加图片到edittext中