hadoop学习之路----HDFS原理与基本架构总结（第二讲）

最新推荐文章于 2021-06-01 17:12:29 发布

礼彬fly

最新推荐文章于 2021-06-01 17:12:29 发布

阅读量1.7k

点赞数 1

分类专栏： Bigdatda-Hadoop1.0 文章标签： hadoop学习之路----HDFS原理

Bigdatda-Hadoop1.0 专栏收录该内容

47 篇文章 0 订阅

订阅专栏

hadoop学习之路----HDFS原理与基本架构总结（第二讲）

第二讲主要内容如下
1.HDFS特点（也就是HDFS适用什么场景）
2.HDFS缺点（也就是HDFS不适用什么场景）
3.HDFS基本架构
4.HDFS工作原理
5.下一代HDFS介绍
下面主要聊聊其中的各个部分
1.HDFS特点（主要出自PPT）
主要有以下五点
高容错性
   数据自动保存多个副本
   副本丢失后，自动恢复
            我们都知道在HDFS上数据是根据默认配置的3份副本，那么着三份副本该如何进行选择，下面就来简单的介绍

            Hadoop默认副本存放策略是在运行客户端的节点上放第1个复本（如果客户端在集群之外，就随机选择一个节点，不过系统会避免那些存储太满或太忙的节点），第2个复本放在与第1个不同且随机另外选择的机架中节点上（离架）第3个复本同第2个复本放在相同的机架，且随机选择另外一个节点。其他复本放在集群中随机选择的节点上（多余3份副本，会尽量避免相同机架放太多的副本）。上面的图很好的展示了，这个过程。
            下面还将介绍一下Hadoop的网络拓扑和机架感知

            在hadoop中还需要考虑的因素就是网络距离还在，海量数据处理中，其主要限制因素是节点之间数据的传输速率（也就是带宽）这里的想法是两个节点的带宽作为距离衡量的标准，在下面一些场景中带宽依次递减
            同一节点中的进程
            同一机架上的不同节点
            同一数据中心不同机架上的节点
            不同数据中心的节点
            假设，数据中心为d1，机架r1，节点n1，某个节点可以表示为/d1/r1/n1
            distance(/d1/r1/n1, /d1/r1/n1)= 0 (同一节点中的进程)
            distance(/d1/r1/n1, /d1/r1/n2)= 2 (同一机架上的不同节点)
            distance(/d1/r1/n1, /d1/r2/n3)= 4 (同一数据中心不同节点)
            distance(/d1/r1/n1, /d2/r3/n4)= 6 (不同数据中心的节点)
            上面就是Hadoop判断网络距离的方式，但是Hadoop是不能自己获取网络结构的（默认在同一个机架下面）下面我们将展示一个具体的配置也就是Hadoop的机架感知
            具体过程如下：
1.修改core-site.xml文件

<property>
<name>topology.script.file.name</name>
<value>/opt/modules/hadoop/hadoop-0.20.203.0/Utility/RackAware.py</value>
</property>

复制代码

2.编写 RackAware.py 脚本

#!/usr/bin/python
#-*-coding:UTF-8 -*-
import sys
rack = {"hadoopnode-176.tj":"rack1",
"hadoopnode-178.tj":"rack1",
"hadoopnode-179.tj":"rack1",
"hadoopnode-180.tj":"rack1",
"hadoopnode-186.tj":"rack2",
"hadoopnode-187.tj":"rack2",
"hadoopnode-188.tj":"rack2",
"hadoopnode-190.tj":"rack2",
"192.168.1.15":"rack1",
"192.168.1.17":"rack1",
"192.168.1.18":"rack1",
"192.168.1.19":"rack1",
"192.168.1.25":"rack2",
"192.168.1.26":"rack2",
"192.168.1.27":"rack2",
"192.168.1.29":"rack2",
}
if __name__=="__main__":
print "/" + rack.get(sys.argv[1],"rack0")

复制代码

3.执行命令：chmod +x RackAware.py
4.重新启动机器
            这样做的好处有以下几点
            1.可靠性：block存储在两个机架上
            2.写带宽：写操作仅仅穿过一个网络交换机
            3.读操作：选择其中得一个机架去读
            4.block分布在整个集群上。

适合批处理
   移动计算而非数据（基于Host选择算法，待补充）
   数据位置暴露给计算框架
适合大数据处理
   GB、TB、甚至PB级数据
   百万规模以上的文件数量
   10K+节点规模
流式文件访问（推荐阅读里有比较好的资料）
   一次性写入，多次读取
   保证数据一致性
可构建在廉价机器上
   通过多副本提高可靠性（主要靠副本存储策略）
   提供了容错和恢复机（见下面block恢复机制）
HDFS缺点
低延迟数据访问
   比如毫秒级
   低延迟与高吞吐率
            HDFS的强项在于大量的数据传输，低延迟不适合它，不过HBase可以弥补这个缺陷
小文件存取
   占用大量NameNode存储空间
   寻到时间超过读取时间
            整个文件系统的元数据，因此文件的数量就会受到限制，每个文件的元数据大约150字节（无论文件大小），1百万个文件，那么就需要300MB内存
并发写入，文件随机修改
      一个文件只能有一个写入者
      仅支持追加
HDFS基本架构（下面这个架构讲的非常经典没有之一，如果你没看过那就太可惜了，那你在对HDFS理解和别人有着非常的差别）
下面是HDFS文件读取和写入的过程，（我在这里只是抛砖引玉）
http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/

HDFS原理
HDFS Block块概
Hadoop权威指南读写过程供大家参考
HDFS文件读取

   1.首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例
   2.DistributedFileSystem通过rpc获得文件的第一批个block的locations，同一block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面.
   3.前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode并连接（参考第一小节）。
   4.数据从datanode源源不断的流向客户端。
   5.如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。
   6.如果第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。

HDFS读取发生异常处理
   如果在读数据的时候，DFSInputStream和datanode的通讯发生异常，就会尝试正在读的block的排第二近的datanode,并且会记录哪个datanode发生错误，剩余的blocks读的时候就会直接跳过该datanode。DFSInputStream也会检查block数据校验和，如果发现一个坏的block,就会先报告到namenode节点，然后DFSInputStream在其他的datanode上读该block的镜像
HDFS读操作设计思考
   设计考虑就是客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode，namenode仅仅处理block location的请求，这些信息都加载在namenode的内存中，hdfs通过datanode集群可以承受大量客户端的并发访问。

HDFS文件写入

   1.客户端通过调用DistributedFileSystem的create方法创建新文件    2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前，namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，namenode就会记录下新文件，否则就会抛出IO异常.
   3.前两步结束后会返回FSDataOutputStream的对象，象读文件的时候相似，FSDataOutputStream被封装成DFSOutputStream.DFSOutputStream可以协调namenode和datanode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列data quene。
   4.DataStreamer会去处理接受data quene，他先问询namenode这个新的block最适合存储的在哪几个datanode里（参考第二小节），比如重复数是3，那么就找到3个最适合的datanode，把他们排成一个pipeline.DataStreamer把packet按队列输出到管道的第一个datanode中，第一个datanode又把packet输出到第二个datanode中，以此类推。
   5.DFSOutputStream还有一个对列叫ack quene，也是有packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时akc quene才会把对应的packet包移除掉。
   6.客户端完成写数据后调用close方法关闭写入流
   7.DataStreamer把剩余得包都刷到pipeline里然后等待ack信息，收到最后一个ack后，通知datanode把文件标示为已完成

HDFS文件写入失败
   如果在写的过程中某个datanode发生错误，会采取以下几步：
   1.pipeline被关闭
   2.为了防止防止丢包ack quene里的packet会同步到data quene
   3.把产生错误的datanode上当前在写但未完成的block删
   4.block剩下的部分被写到剩下的两个正常的datanode
   5.namenode找到另外的datanode去创建这个块的复
   这些操作对客户端来说是无感知的。
   (客户端执行write操作后，写完得block才是可见的，正在写的block对客户端是不可见的，只有调用sync方法，客户端才确保该文件被写操作已经全部完成，当客户端调用close方法时会默认调用sync方法。是否需要手动调用取决你根据程序需要在数据健壮性和吞吐率之间的权衡。)

对于block块的恢复详细信息可以查看如下blog
http://blog.csdn.net/macyang/article/details/7983188
HadoopHA的原理文档
http://blog.csdn.net/chenpingbupt/article/details/8026735
Hadoop相关配置文档
https://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-High-Availability-Guide/CDH4-High-Availability-Guide.html

原文地址：http://bbs.chinahadoop.cn/forum.php?mod=viewthread&tid=5673