惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
P
Proofpoint News Feed
宝玉的分享
宝玉的分享
MyScale Blog
MyScale Blog
The GitHub Blog
The GitHub Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
月光博客
月光博客
量子位
博客园 - 司徒正美
V
V2EX
I
InfoQ
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Vercel News
Vercel News
H
Hackread – Cybersecurity News, Data Breaches, AI and More
美团技术团队
N
Netflix TechBlog - Medium
L
LangChain Blog
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Stack Overflow Blog
Stack Overflow Blog
A
About on SuperTechFans
Microsoft Azure Blog
Microsoft Azure Blog

博客园 - 完美de幸福

给你一个团队,你能怎么管-读后感-凝聚力和执行力(1) Lync 2010 存档服务器配置 学习笔记(9) Lync 2010 监控服务器配置 学习笔记(8) 云计算 学习笔记(3) Google 集群系统 & Hadoop 云计算 学习笔记(2) 分布式的一些基础概念 云计算 学习笔记(1) Hadoop简介 CMMI学习系列(7)-组织过程库,预评估,正式评估。 CMMI学习系列(6)-项目试点 CMMI学习系列(5)-CMMI3过程规范制定 CMMI学习系列(4)-CMMI3认证流程各阶段介绍&项目管理 CMMI学习系列(3)-CMMI3认证流程 CMMI学习系列(2)-CMMI3简介 CMMI学习系列(1)-CMMI简介及证书介绍 Lync 2010 Lync客户端测试 学习笔记(7) Lync 2010 标准版 搭建Lync服务器 学习笔记(6) Lync 2010 标准版 Lync服务器准备 学习笔记(5) Lync 2010 标准版 CA证书服务搭建 学习笔记(4) Lync 2010 标准版 AD控制器搭建 学习笔记(3) Lync 2010 系统架构 学习笔记(2)
云计算 学习笔记(4) HDFS 简介及体系结构
完美de幸福 · 2012-12-02 · via 博客园 - 完美de幸福

       HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB,GB以及TB,并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改,则并不是十分适合。

        目前HDFS支持的使用接口除了Java的还有,Thrift、C、FUSE、WebDAV、HTTP等。HDFS是以block-sized chunk组织其文件内容的,默认的block大小为64MB,对于不足64MB的文件,其会占用一个block,但实际上不用占用实际硬盘上的64MB,这可以说是HDFS是在文件系统之上架设的一个中间层。之所以将默认的block大小设置为64MB这么大,是因为block-sized对于文件定位很有帮助,同时大文件更使传输的时间远大于文件寻找的时间,这样可以最大化地减少文件定位的时间在整个文件获取总时间中的比例 。

    HDFS基本概念

   1、数据块

HDFS默认的最基本的存储单位是64M的数据块,这个数据块可以理解和一般的文件里面的分块是一样的

   2、元数据节点和数据节点

元数据节点(namenode)用来管理文件系统的命名空间,它将所有的文件和文件夹的元数据保存在一个文件系统树中。

数据节点(datanode)就是用来存储数据文件的。

       构成HDFS主要是Namenode(master)和一系列的Datanode(workers)。Namenode是管理HDFS的目录树和相关的文件元数据,这些信息是以”namespace image”和”edit log”两个文件形式存放在本地磁盘,但是这些文件是在HDFS每次重启的时候重新构造出来的。Datanode则是存取文件实际内容的节点,Datanodes会定时地将block的列表汇报给Namenode。

       由于Namenode是元数据存放的节点,如果Namenode挂了那么HDFS就没法正常运行,因此一般使用将元数据持久存储在本地或远程的机器上,或者使用secondary namenode来定期同步Namenode的元数据信息,secondary namenode有点类似于MySQL的Master/Salves中的Slave,”edit log”就类似”bin log”。如果Namenode出现了故障,一般会将原Namenode中持久化的元数据拷贝到secondary namenode中,使secondary namenode作为新的Namenode运行起来。

  系统架构

image

文件读取

reading data from hdfs

文件读取的过程如下:

  1. 使用HDFS提供的客户端开发库,向远程的Namenode发起RPC请求;
  2. Namenode会视情况返回文件的部分或者全部block列表,对于每个block,Namenode都会返回有该block拷贝的datanode地址;
  3. 客户端开发库会选取离客户端最接近的datanode来读取block;
  4. 读取完当前block的数据后,关闭与当前的datanode连接,并为读取下一个block寻找最佳的datanode;
  5. 当读完列表的block后,且文件读取还没有结束,客户端开发库会继续向Namenode获取下一批的block列表。
  6. 读取完一个block都会进行checksum验证,如果读取datanode时出现错误,客户端会通知Namenode,然后再从下一个拥有该block拷贝的datanode继续读。
写入文件

writing data to hdfs

写入文件的过程比读取较为复杂:

  1. 使用HDFS提供的客户端开发库,向远程的Namenode发起RPC请求;
  2. Namenode会检查要创建的文件是否已经存在,创建者是否有权限进行操作,成功则会为文件创建一个记录,否则会让客户端抛出异常;
  3. 当客户端开始写入文件的时候,开发库会将文件切分成多个packets,并在内部以”data queue”的形式管理这些packets,并向Namenode申请新的blocks,获取用来存储replicas的合适的datanodes列表,列表的大小根据在Namenode中对replication的设置而定。
  4. 开始以pipeline(管道)的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode,该datanode把该packet存储之后,再将其传递给在此pipeline中的下一个datanode,直到最后一个datanode,这种写数据的方式呈流水线的形式。
  5. 最后一个datanode成功存储之后会返回一个ack packet,在pipeline里传递至客户端,在客户端的开发库内部维护着”ack queue”,成功收到datanode返回的ack packet后会从”ack queue”移除相应的packet。
  6. 如果传输过程中,有某个datanode出现了故障,那么当前的pipeline会被关闭,出现故障的datanode会从当前的pipeline中移除,剩余的block会继续剩下的datanode中继续以pipeline的形式传输,同时Namenode会分配一个新的datanode,保持replicas设定的数量。