hadoop Namenode和DataNode架构分析
2012-11-28 18:57
579 查看
从架构角度而言,hadoop HDFS 是一个master/slave架构的系统。
![](http://images.cnblogs.com/cnblogs_com/reckzhou/201203/201203222133153934.gif)
NameNode类似于master的身份,负责管理文件系统的名字空间(namespace)以及客户端对文件meta信息的访问。所谓meta信息,就是指文件存储路径,复制因子,名称等信息以及修改日志等。同时NameNode还通过侦听客户端发送过来的心跳信息,维护整个hadoop Cluster的节点状态。
HDFS中的实际数据则由DataNode负责存储和维护,DataNode是一个slave身份。
向HDFS写入一个文件数据时,默认情况下hadoop系统Block Szie=64MB,将当前文件切分成多个数据块。除了该文件的最后一个数据块可能小于64MB之外,其他均等于64MB。hadoop HDFS的replication机制则根据文件复制因子数量,将该文件切分的Block复制多份,分别复制到其它DataNode。
HDFS Replication机制有点类似于cassandra的机制,不过比起cassandra仍然逊色不少。例如cassandra默认首先向远程datacenter复制一份,然后向同一个机房的另外一个机架复制。而Hadoop HDFS仅仅向另外一个机架进行数据复制。当出现硬件错误时,通过这种策略尽可能的减少数据丢失的风险。
当然还会记录其校验信息,用于验证数据完整性。默认使用CRC32算法。不过根据taobao相关技术人员说法,认为自带的crc32算性能较差。
DataNode在分布式环境中基本都是每台机器一个jvm进程。而NameNode则始终只分布在一台机器,只有一个JVM进程。
当客户端进行HDFS数据访问时,首先需要访问NameNode,获取访问目标文件的meta信息以及block分布信息,对于实际数据的IO,则直接通过DataNode进行。因此HDFS Master/Slave架构中的Master,如果设计优化,即便是海量数据,IO的压力仍然相对会比较小。
而真正进行数据访问时,主要是DataNode负责并行读写,因此虽然单台机器的硬盘假设读写90MB/s,如果1000台机器,则读写IO每秒可以达到90*1000的吞吐量。因此对于互联网公司例如taobao接近3000台的hadoop cluster规模,每秒IO超过250G还是非常轻松的。对于类似集群,处理1T数据,延迟大多数都小于2分钟。显然对于这种离线型的海量数据分析,显然具有很大的应用前景。
影响NameNode一个最终要的因素主要是小文件数量以及文件更改,迁移等操作影响,这个我们将在后面介绍
![](http://images.cnblogs.com/cnblogs_com/reckzhou/201203/201203222133153934.gif)
NameNode类似于master的身份,负责管理文件系统的名字空间(namespace)以及客户端对文件meta信息的访问。所谓meta信息,就是指文件存储路径,复制因子,名称等信息以及修改日志等。同时NameNode还通过侦听客户端发送过来的心跳信息,维护整个hadoop Cluster的节点状态。
HDFS中的实际数据则由DataNode负责存储和维护,DataNode是一个slave身份。
向HDFS写入一个文件数据时,默认情况下hadoop系统Block Szie=64MB,将当前文件切分成多个数据块。除了该文件的最后一个数据块可能小于64MB之外,其他均等于64MB。hadoop HDFS的replication机制则根据文件复制因子数量,将该文件切分的Block复制多份,分别复制到其它DataNode。
HDFS Replication机制有点类似于cassandra的机制,不过比起cassandra仍然逊色不少。例如cassandra默认首先向远程datacenter复制一份,然后向同一个机房的另外一个机架复制。而Hadoop HDFS仅仅向另外一个机架进行数据复制。当出现硬件错误时,通过这种策略尽可能的减少数据丢失的风险。
当然还会记录其校验信息,用于验证数据完整性。默认使用CRC32算法。不过根据taobao相关技术人员说法,认为自带的crc32算性能较差。
DataNode在分布式环境中基本都是每台机器一个jvm进程。而NameNode则始终只分布在一台机器,只有一个JVM进程。
当客户端进行HDFS数据访问时,首先需要访问NameNode,获取访问目标文件的meta信息以及block分布信息,对于实际数据的IO,则直接通过DataNode进行。因此HDFS Master/Slave架构中的Master,如果设计优化,即便是海量数据,IO的压力仍然相对会比较小。
而真正进行数据访问时,主要是DataNode负责并行读写,因此虽然单台机器的硬盘假设读写90MB/s,如果1000台机器,则读写IO每秒可以达到90*1000的吞吐量。因此对于互联网公司例如taobao接近3000台的hadoop cluster规模,每秒IO超过250G还是非常轻松的。对于类似集群,处理1T数据,延迟大多数都小于2分钟。显然对于这种离线型的海量数据分析,显然具有很大的应用前景。
影响NameNode一个最终要的因素主要是小文件数量以及文件更改,迁移等操作影响,这个我们将在后面介绍
相关文章推荐
- Hadoop源码分析之读文件时NameNode和DataNode的处理过程
- Hadoop源码分析之读文件时NameNode和DataNode的处理过程
- Hadoop之HDFS架构(NameNode和DataNode)
- hadoop2.0的DataNode与NameNode交互机制相关代码分析
- hadoop中NameNode、DataNode和Client三者之间协作关系及通信方式介绍
- hadoop HA 集群启动发现现datanode没有启动,namenode clusterID与datanode clusterID不兼容,不匹配。
- hadoop启动后通过jps查看进程datanode或namenode不存在问题解决
- Hadoop的HDFS中namenode和datenode内容分析
- 端口被其他进程占用导致hadoop namenode,datanode,jobTracker,taskTracker,secondnamenode无法启动
- hadoop源代码解读namenode高可靠:HA;web方式查看namenode下信息;dfs/data决定datanode存储位置
- Hadoop之 NameNode---DataNode---SecondaryNameNode
- Hadoop 2.7.x NameNode重新格式化后导致DataNode无法启动问题
- 记一次hadoop datanode进程问题分析
- Hadoop源码分析之DataNode的启动与停止
- 端口被其他进程占用导致hadoop namenode,datanode,jobTracker,taskTracker,secondnamenode无法启动
- Hadoop DataNode 无法连接到主机NameNode
- hadoop多次格式化namenode造成datanode无法启动问题解决
- Hadoop之 NameNode---DataNode---SecondaryNameNode
- hadoop学习笔记之start-all.sh 无法启动NameNode,DataNode
- hadoop的hdfs中的namenode和datanode知识总结