同乐学堂Hadoop分布式文件系统：hdfs
一、
hdfs的设计：1、可以存储超大文件。（包含PB级别以上数据。）
2、流式数据访问（构建思路：一次写入，多次读取最高效的模式。）
3、设计应用在普通商业硬件上，故障率高，遇到故障时能够继续运行，不被用户感觉到明显的中断。
4、低时间延迟的数据访问：HDFS是高数据吞吐应用优化的，会提供时间延迟代价。对于低延迟的访问需求请使用hbase。 5、大量的小文件:由于namenode将文件系统的元数据存储在内存中，所以最大能存储文件的总数受限于 namenode的内容容量每个文件、目录和数据存储快的信息大约占150字节。如果有一百万个文件，且每个文件占一个数据块，至少要300MB的内存。
6、多用户写入，任意修改文件：HDFS文件只有一个writer，写操作将数据添加文件的末尾，
不支持多个写入者的操作，也不支持在文件的任意位置修改。
二、
数据块：
普通文件系统块一般为几千字节，磁盘块为512字节。
HDFS文件系统，同样也有块的概念，比普通文件系统大的多 。默认为64MB.
与其他文件系统不同的是，HDFS中的小于一个块大小的文件不会占据整个块的空间。
一、为何HDFS中的块会设计的如此之大？但是这个数也不会设置过大。
答：目的是减少最小化寻址开销。Map任务通常一次只处理一个块中的数据、任务量太少并少于集群中节点的数量，作业的速度就会变得很慢。
详解： 在HDFS里面，data node上的块大小默认是64MB(或者是128MB或256MB)
HDFS设计前提是支持大容量的流式数据操作，所以即使是一般的数据读写操作，涉及到的数据量都是比较大的。假如数据块设置过少，那需要读取的数据块就比较多，由于数据块在硬盘上非连续存储，普通硬盘因为需要移动磁头，所以随机寻址较慢，读越多的数据块就增大了总的硬盘寻道时间。当硬盘寻道时间比io时间还要长的多时，那么硬盘寻道时间就成了系统的一个瓶颈、
Map崩溃问题：
系统需要重新启动，启动过程需要重新加载数据，数据块越大，数据加载时间越长，系统恢复过程越长
监管时间问题：
主节点监管其他节点的情况，每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔，主节点记录下这个节点状态 为死亡，并把分配给这个节点的数据发到别的节点。对于这个“预设的时间间隔”，这是从数据块的角度大概估算的。假如是对于64MB的数据块，我可以假设你10分钟之内无论如何也能解决了吧，超过10分钟也没反应，那就是死了。可对于640MB或是1G以上的数据，我应该要估算个多长的时间内？估算的时间短了，那就误判死亡了，分分钟更坏的情况是所有节点都会被判死亡。估算的时间长了，那等待的时间就过长了。所以对于过大的数据块，这个“预设的时间间隔”不好估算。
三、 对分布式文件系统的块进行抽象会带来很多好处：
1、一个文件的代销可以大于网络中任意一个磁盘的容量、
2、使用抽象块而非整个文件作为存储单元大大简化了存储子系统的设计。
3、非常适合用户数据备份而提供的数据容错能力而提高可用性。将每个块复制到少数几个独立机器上（摸默认为3个） 。
4、hdfs总fsck指令可以显示块信息。
hadoop fsck / -files -bloxks
详解：http://lxw1234.com/archives/2015/08/452.htm
四、namenode 和datanode
大数据中，HDFS集群以Master-Slave模式运行，主要有两类节点：一个Namenode(即Master)和多个Datanode(即Slave)。Namenode管理者文件系统的Namespace。它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata)
HDFS Architecture：
Namenode
Namenode 管理者文件系统的Namespace。它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata)。管理这些信息的文件有两个，分别是Namespace 镜像文件(Namespace image)和操作日志文件(edit log)，这些信息被Cache在RAM中，当然，这两个文件也会被持久化存储在本地硬盘。Namenode记录着每个文件中各个块所在的数据节点的位置信息，但是他并不持久化存储这些信息，因为这些信息会在系统启动时从数据节点重建。
Namenode结构图课抽象为如图：
客户端(client)代表用户与namenode和datanode交互来访问整个文件系统。客户端提供了一些列的文件系统接口，因此我们在编程时，几乎无须知道datanode和namenode，即可完成我们所需要的功能。
Datanode
Datanode是文件系统的工作节点，他们根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。
Namenode容错机制
没有Namenode，HDFS就不能工作。事实上，如果运行namenode的机器坏掉的话，系统中的文件将会完全丢失，因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此，namenode的容错机制非常重要，Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统。
第二种方式是运行一个辅助的Namenode(Secondary Namenode)。 事实上Secondary Namenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，Secondary Namenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。
五、联邦HDFS
namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这
意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向
扩展的瓶颈。在2.x发行版本系列中引人的联邦HDFS允许
系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名
空间中的二都分。例如，二个nainenode可能管理/user目录下的所有文件，
而另一个namenode可能管理/share目录下的所有文件。
在联邦环境下，每个namenode维护一个命名空间卷(namespace volume)，
包括命名空间的源数据和在该命名空间下的文件的所有数据块的数据块
池。命名空间卷之间是相互独立的，两两之间并不相互通信，甚至其中
个namenode的失效也不会影响由其他namenode维护的命名空间的可用 性。
数据块池不在进行切分，因此集群中的datanode 需要注册到每个namenode，并且存储着来自多个数据块池中的数据块。要想访问联邦HDFS集群，客户端需要使用客户端挂载数据表将文件路径映射到namenode。
该功能可以通过viewFileSystem 和viewfs://uri 进行配置和管理。
传统架构hadoop1 版本 http://blog.csdn.net/u013527419/article/details/51043452
联邦架构 hadoop2版本 :http://www.cnblogs.com/meiyuanbao/p/hadoop2.html
六、HDFS的高可用性
hadoop2.x 发行版，针对hadoop1.x版本的Namenode单点失效的问题（会造成hadoop无法提供服务。直到新的namenode上线。）
2.x中配备了一个备用的namenode，当活动的namenode失效是否，备用的namenode直接接管并开始服务作业。不会有任何明显的中断。
实现这一部门需要改动如下：
1、namenode之间需要通过高可用的共享存储实现，编辑日志的共享。（构建zookeeper智商的bookkeeper这样的系统）
单备用namenode接管之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的同步。
2、datanode 需要同时向两个namenode发送数据库块处理报告，因为数据块的映射信息存储在namenode的内存中，而非磁盘。
3、客户端需要使用特定的机制来处理namenode的失效问题。
紧急情况：备用的都失效了，管理员可以申明一个备用的namenode来实现冷启动。
七、故障切换与规避
http://fire7758.blog.51cto.com/993821/1373892/（hadoop集群之namenode故障切换）
http://blog.csdn.net/xuekunlu/article/details/50510740(hadoop2解决 NameNode 单点故障问题的 高可用集群配置)
一个称为故障转移控制器(failover_controller)的系统中有一个新实体管理着将活动namenode转移为备用namenode的转换过程。故障转移控制器是可插拔的，但其最初的实现是基于ZooKeeper的并由此确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器，其工作就是监视宿主namenode是否失效(通过一个简单的心跳机制实现)并在namenode失效时进行故障切换。
管理员也可以手动发起故障转移，例如在进行日常维护时。这称为“平稳的故障转移”，因为故障转移控制器可以组织两个namenode有序切换角色。
但在非平稳故障转移的情况下，无法确切知道失效namenode是否已经停止运行。例如，在网速非常慢或者网络被分割的情况下，同样也可能激发故障转移，但是先前的活动namenode依然运行着并且依旧是活动namenode。高可用实现做了更进一步的优化，以确保先前活动的namenode不会执行危害系统并导致系统崩溃的操作——该方法称为“规避”(fencing)。系统引入了一系列的规避机制，包括杀死namenode进程，收回访问共享存储目录的权限(通常使用供应商指定的NFS命令)，通过远程管理命令以屏蔽相应网络端口。诉诸的最后手段是，先前活动namenode可以通过一个相当形象的称为STONITH(shoottheothernodeinthehead)的技术进行规避，该方法主要通过一个特定的供电单元对相应主机进行断电操作。
客户端的故障切换通过客户端类库实现透明处理。最简单的实现是通过客户端的配置文件实现故障切换的控制。HDFSURI使用一个逻辑主机名，该主机名映射到一对namenode地址(在配置文件中设置)，客户端类库会访问每一个namenode地址直至处理完成。
微信扫一扫，打赏作者吧～
