热门标签 | HotTags
当前位置:  开发笔记 > 运维 > 正文

hadoop深入研究:(一)hdfs介绍

转载请注明出处:blog.csdn.netlastsweetoparticledetails8992505hdfs设计原则1.非常大的文件:这里的非常大是指几百MB,GB,TB.雅虎的hadoop集群已经可以存储PB级别的数据2.流式数据访问:基于一次写,多次读。3.商用硬件:????hdfs的

转载请注明出处: http://blog.csdn.net/lastsweetop/article/details/8992505 hdfs设计原则 1.非常大的文件: 这里的非常大是指几百MB,GB,TB.雅虎的hadoop集群已经可以存储PB级别的数据 2.流式数据访问: 基于一次写,多次读。 3.商用硬件: ? ? ? ?hdfs的

转载请注明出处: http://blog.csdn.net/lastsweetop/article/details/8992505

hdfs设计原则

1.非常大的文件:

这里的非常大是指几百MB,GB,TB.雅虎的hadoop集群已经可以存储PB级别的数据

2.流式数据访问:

基于一次写,多次读。

3.商用硬件: ? ? ?

?hdfs的高可用是用软件来解决,因此不需要昂贵的硬件来保障高可用性,各个生产商售卖的pc或者虚拟机即可。

hdfs不适用的场景

1.低延迟的数据访问 ??

hdfs的强项在于大量的数据传输,递延迟不适合他,10毫秒以下的访问可以无视hdfs,不过hbase可以弥补这个缺陷。


2.太多小文件 ? ? ? ? ? ? ?

?namenode节点在内存中hold住了整个文件系统的元数据,因此文件的数量就会受到限制,每个文件的元数据大约150字节

?1百万个文件,每个文件只占一个block,那么就需要300MB内存。你的服务器可以hold住多少呢,你可以自己算算


3.多处写和随机修改 ??

目前还不支持多处写入以及通过偏移量随机修改

hdfs block

为了最小化查找时间比例,hdfs的块要比磁盘的块大很多。hdfs块的大小默认为64MB,和文件系统的块不同,

hdfs的文件可以小于块大小,并且不会占满整个块大小。

查找时间在10ms左右,数据传输几率在100MB/s,为了使查找时间是传输时间的1%,块的大小必须在100MB左右

一般都会设置为128MB


有了块的抽象之后,hdfs有了三个优点:


1.可以存储比单个磁盘更大的文件

2.存储块比存储文件更加简单,每个块的大小都基本相同

3.使用块比文件更适合做容错性和高可用

namenodes和datanodes

hdfs集群有两种类型的节点,一种为master及namenode,另一种为worker及datanodes。


namenode节点管理文件系统的命名空间。它包含一个文件系统的树,所有文件和目录的原数据都在这个树上,这些

信息被存储在本地磁盘的两个文件中,image文件和edit?log文件。文件相关的块存在哪个块中,块在哪个地方,这些

信息都是在系统启动的时候加载到namenode的内存中,并不会存储在磁盘中。


datanode节点在文件系统中充当的角色就是苦力,按照namenode和client的指令进行存储或者检索block,并且周期性

的向namenode节点报告它存了哪些文件的block


namenode节点如果不能使用了,那么整个hdfs就玩完了。为了防止这种情况,有两种方式可供选择

1.namenode通过配置元数据可以写到多个磁盘中,最好是独立的磁盘,或者NFS.

2.使用第二namenode节点,第二namenode节点平时并不作为namenode节点工作,它的主要工作内容就是定期根据编辑

日志(edit log)合并命名空间的镜像(namespace image),防止编辑日志过大,合并后的image它自己也保留一份,等着

namenode节点挂掉,然后它可以转正,由于不是实时的,有数据上的损失是很可能发生的。


hdfs Federation

namenode节点保持所有的文件和块的引用在内存中,这就意味着在一个拥有很多很多文件的很大的集群中,内存就成为了一个

限制的条件,hdfs federation在hadoop 2.x的被实现了,允许hdfs有多个namenode节点,每个管hdfs的一部分,比如一个管/usr,

另一个管/home,每个namenode节点是相互隔离的,一个挂掉不会影响另外一个。


hdfs的高可用

不管namenode节点的备份还是第二namenode节点都只能保证数据的恢复,并不能保证hdfs的高可用性,一旦namenode节点挂掉

就会产生单点故障,这时候要手动去数据备份恢复,或者启用第二节点,新的namenode节点在对外服务器要做三件事:

1.把命名空间的镜像加载到内存中

2.重新运行编辑日志

3.接受各个datanode节点的block报告

在一个大型一点的hdfs系统中,等这些做完需要30分钟左右。


2.x已经支持了高可用性(HA),通过一对namenode热备来实现,一台挂掉,备机马上提供无中断服务

要实现HA,要做三点微调:

1.namenode节点必须使用高可用的共享存储。

2.datanode节点必须象两个namenode节点发送block报告

3.客户端做改动可以在故障时切换到可用的namenode节点上,而且要对用户是无感知的


failover和fencing

将备份namenode激活的过程就叫failover,管理激活备份namenode的系统叫做failover controller,

zookeeper就可以担当这样的角色,可以保证只有一个节点处于激活状态。

必须确认原来的namenode已经真的挂掉了,很多时候只是网络延迟,如果备份节点已经激活了,

原来的节点又可以提供服务了,这样是不行的,防止原来namenode活过来的过程就叫fencing。

可以用STONITH实现, STONITH可以做到直接断电把原namenode节点fencing掉




作者:lastsweetop 发表于2013-5-31 15:31:20 原文链接

阅读:104 评论:0 查看评论

推荐阅读
  • 本文详细分析了Hive在启动过程中遇到的权限拒绝错误,并提供了多种解决方案,包括调整文件权限、用户组设置以及环境变量配置等。 ... [详细]
  • Hadoop入门与核心组件详解
    本文详细介绍了Hadoop的基础知识及其核心组件,包括HDFS、MapReduce和YARN。通过本文,读者可以全面了解Hadoop的生态系统及应用场景。 ... [详细]
  • HBase运维工具全解析
    本文深入探讨了HBase常用的运维工具,详细介绍了每种工具的功能、使用场景及操作示例。对于HBase的开发人员和运维工程师来说,这些工具是日常管理和故障排查的重要手段。 ... [详细]
  • 本文详细介绍了 Java 中的 org.apache.hadoop.registry.client.impl.zk.ZKPathDumper 类,提供了丰富的代码示例和使用指南。通过这些示例,读者可以更好地理解如何在实际项目中利用 ZKPathDumper 类进行注册表树的转储操作。 ... [详细]
  • Hadoop发行版本选择指南:技术解析与应用实践
    本文详细介绍了Hadoop的不同发行版本及其特点,帮助读者根据实际需求选择最合适的Hadoop版本。内容涵盖Apache Hadoop、Cloudera CDH等主流版本的特性及应用场景。 ... [详细]
  • 全面解析运维监控:白盒与黑盒监控及四大黄金指标
    本文深入探讨了白盒和黑盒监控的概念,以及它们在系统监控中的应用。通过详细分析基础监控和业务监控的不同采集方法,结合四个黄金指标的解读,帮助读者更好地理解和实施有效的监控策略。 ... [详细]
  • 深入解析BookKeeper的设计与应用场景
    本文介绍了由Yahoo在2009年开发并于2011年开源的BookKeeper技术。BookKeeper是一种高效且可靠的日志流存储解决方案,广泛应用于需要高性能和强数据持久性的场景。 ... [详细]
  • 本文详细介绍了使用ZooKeeper构建高可用集群的方法,包括必要的软件环境准备、配置文件调整及集群启动等关键步骤。通常,一个ZooKeeper集群由奇数个节点组成,以确保Leader选举的有效性。 ... [详细]
  • 本文探讨了Hive中内部表和外部表的区别及其在HDFS上的路径映射,详细解释了两者的创建、加载及删除操作,并提供了查看表详细信息的方法。通过对比这两种表类型,帮助读者理解如何更好地管理和保护数据。 ... [详细]
  • 本文探讨了2012年4月期间,淘宝在技术架构上的关键数据和发展历程。涵盖了从早期PHP到Java的转型,以及在分布式计算、存储和网络流量管理方面的创新。 ... [详细]
  • 本文详细介绍了如何搭建和配置ZooKeeper集群,包括环境变量设置、配置文件调整、主机映射关系配置及启动验证等关键步骤。 ... [详细]
  • 深入解析Spark核心架构与部署策略
    本文详细探讨了Spark的核心架构,包括其运行机制、任务调度和内存管理等方面,以及四种主要的部署模式:Standalone、Apache Mesos、Hadoop YARN和Kubernetes。通过本文,读者可以深入了解Spark的工作原理及其在不同环境下的部署方式。 ... [详细]
  • 优化使用Apache + Memcached-Session-Manager + Tomcat集群方案
    本文探讨了使用Apache、Memcached-Session-Manager和Tomcat集群构建高性能Web应用过程中遇到的问题及解决方案。通过重新设计物理架构,解决了单虚拟机环境无法真实模拟分布式环境的问题,并详细记录了性能测试结果。 ... [详细]
  • Zookeeper面试常见问题解析
    本文详细介绍了Zookeeper中的ZAB协议、节点类型、ACL权限控制机制、角色分工、工作状态、Watch机制、常用客户端、分布式锁实现、默认通信框架以及消息广播和领导选举的流程。 ... [详细]
  • 深入理解Kafka架构
    本文将详细介绍Kafka的内部工作机制,包括其工作流程、文件存储机制、生产者与消费者的具体实现,以及如何通过高效读写技术和Zookeeper支持来确保系统的高性能和稳定性。 ... [详细]
author-avatar
福州-台江_616
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有