分布式文件系统HadoopHDFS与传统文件系统LinuxFS的比较与分析-论文总结_第1页
分布式文件系统HadoopHDFS与传统文件系统LinuxFS的比较与分析-论文总结_第2页
分布式文件系统HadoopHDFS与传统文件系统LinuxFS的比较与分析-论文总结_第3页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

1、1 许春玲，张广泉. 分布式文件系统Hadoop HDFS与传统文件系统Linux FS的比较与分析J.苏州:苏州大学学报（工科版）, 2010，30(4)：6-9.一、 HDFS实现分布式的关键技术分析1. 用户群空间和物理空间的彼此独立：通过添加Block层来实现l Map1: ;l Map2: ;(以上两组映射封装在B locksMap 以哈希映射实现, 作为描述Block 的重要元数据Blockinfo封装了该Block相关的INode、DataNode。)l Map3: (Map1逆向), 作为目录树的最底层存放在FSImage;l Map4: (Map2逆向), DataNodeD

2、escr iptor中定义的Block List。2. 数据块映射BlockMap从HDFS目前的设计架构来看, 前面的Map1、Map2通过Java的Map界面实现, 而Hadoop基于MapReduce范式也实现了自己的应用程序界面Mapper、Rducer。JavaMap以整个集合为操作对象, 不利于任务的分解和并行处理, 因此HDFS仅在数据的存储上实现分布式, 对算法和操作的实现依旧是集中式的。这样的设计, 造成集群过分依赖NameNode, 当文件系统越来越庞大、目录树的结构越来越复杂时, NameNode的处理能力将成为HDFS的瓶颈。也许正是考虑到HDFS整个集群目录的操作都集

3、中在一台NameNode上, 所以出现了前面HDFS设计的两个重点, 努力简化目录树结构以减少空间占用。即便如此, 从长远来看日益庞大的集群(甚至可能在将来出现涵盖整个互联网的唯一集群)使简化的目录树无法从根本上解决问题, 而一旦NameNode崩溃, 则意味着集群的瘫痪。3. NameNode瓶颈解决思路：将MapReduce范式引入HDFS统一空间中的Block有两个属性: 所属的文件( INodefile)和所属的DataNode, 第一个属性可能为空。相应的Map产生两个键值对 、 , 如果将两个键封装在一起INodeF ile, DataNode 则有 。对于 , 假设Reduce 表示先根据INodeFile做Reduce, 再根据DataNode做Reduce, 则可以据此找出每个文件(由INodefile代表)存储在哪些DatatNode, 过程类似于SQL中有两个键值的Group By。以一次读操作为例, 参考图6先执行Map3将INodeFile映射到Block, 再执行Reduce2将同一个DataNode的Block聚集在一起; 反向则先执行Map4将DataNode映射到Block, 再执行Reduce1将同一个文件的Block聚集起来。其中Map3与Reduce1互逆, Map4与

人人文库> 全部分类> 行业资料 > 管理策划

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论