hadoop学习笔记二——hadoop文件系统，

和通数据库htsjk.Com2019-12-25 22:08 来源:未知阅读:15611 评论 108 热度2

标签：

hadoop学习笔记二——hadoop文件系统，

- HDFS系统的设计：
- 当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区，并存储到若干台单独的计算机上，管理网络中跨平台计算机存储的文件系统称为分布式文件系统，该系统架构在网络之上，势必会引入网络编程的复杂性。因此分布式文件系统比普通磁盘文件系统更加复杂。例如：使文件系统能够容忍节点故障且不丢失任何数据，就是一个极大的挑战。
- Hadoop有一个称为HDFS的分布式系统，即Hadoop Distributed Filesystem. 在非正式文档或旧文档以及配置文件中，有时称为DFS。HDFS实际上是一个综合性文件系统的抽象，
- HDFS的设计：
  - 以“流式数据”访问模式来存储“超大型文件”。
    - 概念详解：
      - 超大文件：超大文件这里指几百MB，几百GB，几百TB的文件
      - 流式数据访问：HDFS的构建思路是这样的：一次写入，多次读取是最高效的访问模式。数据集通常由数据源生成或由数据源复制而来，接着长时间在此数据集上进行各种分析，每次分析都将涉及该数据集的大部分数据，甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更加重要。
      - 商用硬件：就是一般的普通硬件，因此对于庞大集群来说，节点故障的概率还是相当高的。HDFS遇到上述故障时，被设计成能够继续运行且不感觉到明显的中断。
      - 低时间延迟的数据访问：要求低时间延迟的数据不适合在Hadoop上访问，HBase是一种更好的选择。
      - 大量的小文件：由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。
      - 根据经验，每个文件，目录，和数据块的存储信息大约占150字节，如果有一百万个文件就需要300Mb内存，存储上百万个是可行的，但是存储数十亿个文件就超出了当前硬件的能力。
      - 多用户写入，任意修改文件。HDFS不支持多用户写入，而且写入数据总是被添加到文件的末尾，它不支持多个写入者的操作，也不支持在文件的任意位置进行修改。
- HDFS的概念
  - 数据块（概念的横向平移）{
  - 磁盘上都有默认的数据块，这是磁盘进行数据读写的最小单位，构建在单个磁盘之上的文件系统，通过磁盘块来管理该文件系统中的块。
  - HDfS中也有块的概念（超越物理磁盘的文件管理单位）默认为64MB,与单一磁盘上的文件系统相似（HDFS)上的文件系统HDFS的文件也被划分成块大小的多个分块，作为独立存储单元，但与其他文件系统不同的是一个块大小的文件不会占用整个块的空间。
    - 块设置的这么大原因主要在于这样可以减小寻址的消耗。但这个块的大小又不宜过大，否则会使任务数过少，不利于利用hadoop的分布集群结构
  - 对分布式文件系统中块进行抽象有很多好处，首先就是文件的大小可以具有任意性。第二个好处就是，使用抽象块作为存储单元，大大简化了系统的设计，*可以将元数据与实际数据分开保存。（这一点，我并不明白是什么意思）
  - namenode 与datanode： HDFS集群有两类节点，管理者和工作者：
    - namenode是一个主管，它管理着手下的一票datanode, 整个文件系统树以及整棵树内的所有文件和目录。这些信息保存在磁盘上的两个文件内：命名空间镜像文件和编辑日志文件。namenode也存储着块的数据信息，但是这些信息在系统启动时由数据节点重建。
    - client 代表用户通过与namenode和datanode交互来访问整个文件。客户端提供一个类似*POSIX（可移植操作系统界面）的文件系统接口，因此用户在编程时无需知道namenode与datanode也可实现功能。（如果将来不做架构师的话，掌握到如何写mapReduce就可以了。
    - datanode是文件系统的工作节点，他们根据需要存储并检索数据块（收到客户端或者namenode调度）并定期向namenode发送他们所存储的块的列表。
    - 没有namenode,文件系统将无法使用，我们将丢失所有文件以及块的位置信息，因此对namenode进行容错性设计是很有必要的。
      - *hadoop为这个问题提供了两种机制：
        略
        略
  - 联邦HDFS（这个用到的时候，文件系统一定已经很大了，每个namenode只负责一个维护一个命名空间卷）
  - HDFS的高可用性，在2.x版本中Hadoop支持备用namenode机制（需要做一些特殊的配置（略））
  - Hadoop命令行接口：
    - 首先是配置Hadoop伪分布模式
    - （文件系统具有一系列的基本操作，可以读取文件，可以新建目录，移动文件，删除数据）
    - 可以将本地文件复制到HDFS
    - 可以观察文件是如何在列表中显示的。
  - ：

Hadoop 的文件系统结构	URL方案	Java实现	描述
local	file	**	本地磁盘文件系统
HDFS	hdfs	**	Hadoop分布式文件系统，可跟MapReduce结合使用
HFTP	Hftp	**	一个HTTP上对HDFS提供只读访问的文件系统
HSFTP

文件系统（以上省略若干们可以参看原书）

接口：Hadoop是用Java写的，通过Java API 可以调用所有的Hadoop文件系统的交互操作。文件系统的命令解释器是一个Java 应用，使用Java的FileSystem类来提供文件系统操作。这些接口通常与HDFS一同使用。因为Hadoop中的其他文件系统都有基本文件系统的工具。
HTTP接口
C语言
FUSE用户文件系统
JAVA接口：Hadoop的FileSystem类，提供了对Hadoop某一文件系统进行交互的API。虽然我们主要聚焦于HDFS实例，但是还是应该集成FileSystem的抽象类，使其在不同的文件系统中进行移植。
- 读取数据
- 写入数据
- 删除数据
- （这些式Hadoop可以进行的操作，对API的介绍，但在这里，我不想详细看因为我想知道什么地方会用到这个功能，到时候再返回来看这一切。
数据流：
- 剖析文件读取：
- 我们希望了解到HDFS与namenode以及datanode之间的数据流是什么样的：
- 客户端通过调用FileSystem对象的open()方法来打开希望读取的文件，对于HDFS来说，这个对象是分布式文件系统的一个实例。
- DistributedFileSystem通过使用RPC来调用namenode,以确定起始块的位置。对于每一个块namenode返回存有该块副本的datanode地址。这是文件流的读取结构。
- 这些datanode根据它们与客户端的距离来排序（相关资料参见网络拓扑与Hadoop)数据流对象直接对接到数据流对象上，数据流对象连接到Datanode上然后对数据进行直接读取。
- （这个设计的重点在于namenode告知客户端每个块中的最佳的datanode）并让客户端直接连接到该datanode检索数据。由于数据流分散在集群中的所有datanode上所以这种设计能使HDFS扩展到大量的并发客户端。同时namenode只需要相应块位置的请求，无需响应数据请求。
- 剖析文件写入：文件写入实际上是一个差不多的过程，在DataNode上建立管道，在文件系统的内部会形成队列进行存取。
- 通过外部工具对数据进行导入，工具分别是（Flume和Sqoop)以及distcp:
  - 简单阐释这几种方法的应用：
    - Flume：从另一个系统中收集日志数据
    - Sqoop将数据从结构化存储设备中批量导入到HDFS中
    - distcp在两个HDFS集群之间传输数据
    - **注意保持HDFS集群的均衡
  - Hadoop的存档：
    - 使用Hadoop存档工具，archive工具，将文档进行存档。