Hadoop分布式文件系统.docVIP

翻译原文地址 /165162897/blog/1260375360 第三章 Hadoop分布式文件系统（一） 编辑 | 删除 | 权限设置 | 更多▼ 更多▲ 设置置顶 推荐日志 转为私密日志 开心延年 ?? 发表于2009年12月06日 01:40 阅读(12) 评论(0) 分类： 搜索与存储 权限: 公开 当你的数据突破了单台物理极其的存储能力后，将数据存储在一些列的其他机器上是必须的。通过网络来组织的跨越物理机器的文件系统被称为分布式文件系统。首先他们是基于网络的，通过分布式文件系统处理来自网络所有的并发处理，就像实用本地文件系统一样。举例来说，其中最大的挑战就是对数据的容灾处理。 Haddop的分布式文件系统叫做HDFS（在就的文档中，曾经叫过DFS），HDFS是HADOOP的核心，也是本章讲解的主要焦点。Hadoop的分布式文件按照通用文件系统做了抽象，跟我们平时实用的其他存储系统(比如说本地文件系统和Amazon0 S3). ? HDFS的设计 HDFS用于设计成基于流数据访问模式，超大文件，运行在由普通硬件环境组成的集群上的文件系统。让我们进一步解释这些特性。 ? 超大的文件 这里所说的超大文件至的是上百M和G，或上百T大小的数据。如今的hadoop已经存储了PB级的数据了。 ? 基于流模式的数据访问 HDFS的构建通常是围绕着这种思想，大多数的数据处理通常是写入一次，但是要从源生成或拷贝，这样就会被被读很多次（write once ,read many times）,随着时间的推移进行着各种分析。每次分析都有可能用到这些数据中相当大的比例，所以读取整个数据文件通常要比延迟读取第一条记录更重要。 ? 普通的硬件环境 Hadoop并不需要昂贵，高性能的硬件环境去执行。他被设计成由一些普通的硬件环境组成的集群来降低节点的失效影响。HDFS用于设计当硬件中断对用户的影响最小。 ? 当然这里也要列出一些值得注意的那些HDFS并不适合或目前来说工作并不是很好的应用场景，也许将来我们会改变。 ? 低延迟的数据访问 如果应用需要低延迟(微妙级)的数据访问，HDFS对这种应用支持的并不是很好。HDFS还是致力于提供高吞吐能力的数据，这在某些方面是以数据的延迟为代价的。HBase目前是一个比较好的解决方案来应对低延迟的数据访问。 大量的小文件 目前保存文件系统数据信息的名字节点信息是存储在内存中的。所以内存的使用量是跟随着文件系统的名字节点namenode的数量上升而上升。假如每个文件，每个目录，和块将要实用150字节，那么如果你有1百万的文件，每个占用一个数据块，你就至少要实用300M的内存，百万级的也许是可行的，但是十亿级的在当前硬件环境下是不可行的。 多重的写文件或修改文件 HDFS中的文件，通常之允许一个单独的写，每次写总是追加到文件的末尾。多个写是不会被支持的或者通过设置偏移量来修改文件（也许将来会支持，但实现的优先级可能会放低） ? HDFS的概念 Blocks（块） 一块磁盘会有一个块的大小，表示他能够读或写的最小的数据，文件系统都是一块单独的磁盘上在块的基础上进行处理的，数据处理的但与都是基于磁盘处理块的整数倍。磁盘的通常是512字节，典型的文件系统的块通常都是几KB，这些都取决于文件系统的普通用户所操作的文件大小。通常会有df和fsck这些命令来统计文件系统的块使用的情况。 ? HDFS同样也有块的概念，但是相比之下这个块要大的很多----默认是64M，跟普通磁盘的文件系统一样，HDFS中的文件也是由这些独立的块单元来组成的。与普通文件系统不同的是在底层存储中HDFS中的文件，也许根本占用不到一个整块的大小。 ? 为什么HDFS中的块这么大？ HDFS中的块比文件系统中的块相比要大很多，这样做的原因是降低寻址的代价，如果一个块足够大，更多的时间就会用在数据传输上，而不是在寻找块的地址上。这样大文件的操作就能提高多个块的的传输比率。 一个计算显示，块的寻址时间通常是在10MS左右，数据传输的比率是100M/s,这样的话我们节省了1%的寻址时间，我们选中块的大小在100MB左右，默认我们实用64M，但也有很多HDFS应用实用128MB，这取决于磁盘驱动器传输速度的增长。 也许没必要把话题扯得怎么远，但是MapRecude中的Map任务通常是一次只操作一个BLOCK所以如果你有很少的tasks(集群中的机器不多)，你的jobs将会比其他的运行的慢点。 ? ? 分布式文件系统通过这种块的抽象带来了很多好处。首先最大的益处就是通过网络一个文件可以比任何其他的单独的文件系统都要大，同样一个块也不是必须被存储在同样一块硬盘上，以便更能充分利用集群的优势。实际上，在HDFS集群中存储一个独立的