关于hadoop:Hadoop-入门笔记-十四-HDFS架构原理

一. HDFS 架构分析

1. HDFS 整体概述

HDFS 是 Hadoop Distribute File System 的简称，意为：Hadoop 分布式文件系统。是 Hadoop 外围组件之一，作为大数据生态圈最底层的分布式存储服务而存在。HDFS 解决的问题就是大数据如何存储, 它是横跨在多台计算机上的文件存储系统并且具备高度的容错能力。

HDFS 集群遵循主从架构 。每个群集包含一个主节点和多个从节点。在外部，文件分为一个或多个块，每个块依据复制因子存储在不同的从节点计算机上。 主节点存储和治理文件系统名称空间 ，即无关文件块的信息，例如块地位，权限等。 从节点存储文件的数据块。主从各司其职，互相配合，独特对外提供分布式文件存储服务。当然外部细节对于用户来说是通明的。

2. 角色介绍

1. 概述

HDFS 遵循主从架构 。每个群集包含一个主节点和多个从节点。其中：
NameNode 是主节点，负责存储和治理文件系统元数据信息，包含 namespace 目录构造、文件块地位信息等；DataNode 是从节点，负责存储文件具体的数据块。
两种角色各司其职，独特协调实现分布式的文件存储服务。
SecondaryNameNode 是主角色的辅助角色，帮忙主角色进行元数据的合并。

2. Namenode

NameNode 是 Hadoop 分布式文件系统的外围 ，架构中的主角色。它保护和治理文件系统元数据，包含 名称空间目录树结构、文件和块的地位信息、拜访权限等信息。基于此，NameNode 成为了拜访 HDFS 的惟一入口。

外部通过内存和磁盘两种形式治理元数据 。其中 磁盘上的元数据文件包含 Fsimage 内存元数据镜像文件和 edits log（Journal）编辑日志。

3. Datanode

DataNode是 Hadoop HDFS 中的从角色，负责具体的数据块存储。DataNode 的数量决定了 HDFS 集群的整体数据存储能力。通过和 NameNode 配合保护着数据块。

4. Secondarynamenode

除了 DataNode 和 NameNode 之外，还有另一个守护过程，它称为 secondary NameNode。充当 NameNode 的辅助节点，但不能代替 NameNode。
当 NameNode 启动时，NameNode 合并 Fsimage 和 edits log 文件以还原以后文件系统名称空间。如果 edits log 过大不利于加载，SecondaryNameNode 就辅助 NameNode 从 NameNode 下载 Fsimage 文件和 edits log 文件进行合并。

3. HDFS 重要个性

1. 主从架构

HDFS 采纳 master/slave 架构。个别一个 HDFS 集群是有一个 Namenode 和肯定数目的 Datanode 组成。Namenode 是 HDFS 主节点，Datanode 是 HDFS 从节点，两种角色各司其职，独特协调实现分布式的文件存储服务。

2. 分块机制

HDFS 中的文件在物理上是分块存储（block）的，块的大小能够通过配置参数来规定，参数位于 hdfs-default.xml 中：dfs.blocksize。默认大小是 128M（134217728）。

3. 正本机制

为了容错，文件的所有 block 都会有正本。每个文件的 block 大小（dfs.blocksize）和正本系数（dfs.replication）都是可配置的。应用程序能够指定某个文件的正本数目。正本系数能够在文件创建的时候指定，也能够在之后通过命令扭转。
默认 dfs.replication 的值是 3，也就是会额定再复制 2 份，连同自身总共 3 份正本。

4. NameSpace

HDFS 反对传统的档次型文件组织构造。用户能够创立目录，而后将文件保留在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统相似：用户能够创立、删除、挪动或重命名文件。

Namenode 负责保护文件系统的 namespace 名称空间，任何对文件系统名称空间或属性的批改都将被 Namenode 记录下来。

HDFS 会给客户端提供一个对立的形象目录树，客户端通过门路来拜访文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

5. 元数据管理

在 HDFS 中，Namenode 治理的元数据具备两种类型：

1. 文件本身属性信息
   文件名称、权限，批改工夫，文件大小，复制因子，数据块大小。
2. 文件块地位映射信息
   记录文件块和 DataNode 之间的映射信息，即哪个块位于哪个节点上

6. 数据库存储

文件的各个 block 的具体存储管理由 DataNode 节点承当。每一个 block 都能够在多个 DataNode 上存储。

2. HDFS Web Interfaces

1. Web Interfaces 介绍

除了命令行界面之外，Hadoop 还为 HDFS 提供了 Web 用户界面。用户能够通过 Web 界面操作文件系统并且获取和 HDFS 相干的状态属性信息。

HDFS Web 地址是 http://nn_host:port/, 默认端口号 9870。

2. 模块功能模块

1. Overview
   Overview 是总揽模块，默认的主页面。展现了 HDFS 一些最外围的信息。
   

   • Summary
   • NameNode Journal Status
   • NameNode Storage
   • DFS Storage Types

2. Datanodes
   Datanodes 模块次要记录了 HDFS 集群中各个 DataNode 的相干状态信息
   
3. Datanode Volume Failures
   此模块记录了 DataNode 卷故障信息。
   
4. Snapshot
   Snapshot 模块记录 HDFS 文件系统的快照相干信息，包含哪些文件夹创立了快照和总共有哪些快照。
   
5. Satartup progress
   Startup Progress 模块记录了 HDFS 集群启动的过程信息，执行步骤和每一步所做的事和用时。
   

6. Utilities
   Utilities 模块算是用户应用最多的模块了，外面包含了文件浏览、日志查看、配置信息查看等外围性能。
   

   1. Browse the file system

   该模块能够说是咱们在开发应用 HDFS 过程中应用最多的模块了，提供了一种 Web 页面浏览操作文件系统的能力，在某些场合下，比应用命令操作更加直观不便。
   

   2. Logs、Log Level

   
   

   3. Configruation

   该模块能够列出以后集群胜利加载的所谓配置文件属性，能够从这里来进行判断用户所设置的参数属性是否胜利加载失效，如果此处没有，须要查看配置文件或者重启集群加载。
   

3. HDFS 读写流程

因为namenode 保护治理了文件系统的元数据信息，这就造成了不论是读还是写数据都是基于 NameNode 开始的，也就是说 NameNode 成为了 HDFS 拜访的惟一入口。入口地址是：http://nn_host:8020。

1. 写数据流程

1. Pipeline 管道、ACK 应答响应

Pipeline，中文翻译为管道。这是 HDFS 在上传文件写数据过程中采纳的一种数据传输方式。客户端将数据块写入第一个数据节点，第一个数据节点保留数据之后再将块复制到第二个数据节点，后者保留后将其复制到第三个数据节点。艰深形容 pipeline 的过程就是：Client->A->B->C

为什么 datanode 之间采纳 pipeline 线性传输 ，而不是一次给三个 datanode 拓扑式传输呢？因为数据以管道的形式， 程序的沿着一个方向传输，这样可能充分利用每个机器的带宽，防止网络瓶颈和高提早时的连贯，最小化推送所有数据的延时。在线性推送模式下，每台机器所有的进口宽带都用于以最快的速度传输数据，而不是在多个接受者之间调配宽带。

ACK (Acknowledge character）即是确认字符，在数据通信中，接管方发给发送方的一种传输类控制字符。示意发来的数据已确认接管无误。在 pipeline 管道传输数据的过程中，传输的反方向会进行 ACK 校验，确保数据传输平安。

2. 具体流程

1. HDFS 客户端通过 对 DistributedFileSystem 对象调用 create()申请创立文件
   2. DistributedFileSystem 对 namenode 进行 RPC 调用，申请上传文件。namenode 执行各种查看判断：指标文件是否存在、父目录是否存在、客户端是否具备创立该文件的权限。查看通过，namenode 就会为创立新文件记录一条记录。否则，文件创建失败并向客户端抛出 IOException。
2. DistributedFileSystem 为客户端返回 FSDataOutputStream 输入流对象 。由此 客户端能够开始写入数据。FSDataOutputStream 是一个包装类，所包装的是 DFSOutputStream。
3. 在客户端写入数据时 ，DFSOutputStream 将它分成一个个数据包（packet 默认 64kb）, 并写入一个称之为数据队列（data queue）的外部队列。DFSOutputStream 有一个外部类做 DataStreamer，用于申请 NameNode 挑选出适宜存储数据正本的一组 DataNode。这一组 DataNode 采纳 pipeline 机制做数据的发送。默认是 3 正本存储。
4. pipeline 传递数据给 DataNode, DataStreamer 将数据包流式传输到 pipeline 的第一个 datanode, 该 DataNode 存储数据包并将它发送到 pipeline 的第二个 DataNode。同样，第二个 DataNode 存储数据包并且发送给第三个（也是最初一个）DataNode。
5. DFSOutputStream 也保护着一个外部数据包队列来期待 DataNode 的收到确认回执，称之为确认队列（ack queue）, 收到 pipeline 中所有 DataNode 确认信息后，该数据包才会从确认队列删除。
6. 客户端实现数据写入后，将在流上调用 close()办法敞开。该操作将残余的所有数据包写入 DataNode pipeline，并在分割到 NameNode 告知其文件写入实现之前，期待确认。
7. 因为 namenode 曾经晓得文件由哪些块组成（DataStream 申请调配数据块），因而它仅需期待最小复制块即可胜利返回。
8. 数据块最小复制是由参数 dfs.namenode.replication.min 指定，默认是 1

3. 默认 3 正本存储策略

默认正本存储策略是由 BlockPlacementPolicyDefault 指定。策略如下：
第一块正本：优先客户端本地，否则随机

第二块正本：不同于第一块正本的不同机架。

第三块正本：第二块正本雷同机架不同机器。

2. 读数据流程

1. 客户端通过调用 DistributedFileSystem 对象上的 open() 来关上心愿读取的文件
2. DistributedFileSystem 应用 RPC 调用 namenode 来确定文件中前几个块的块地位 。对于每个块，namenode 返回具备该块正本的 datanode 的地址， 并且 datanode 依据块与客户端的间隔进行排序。留神此间隔指的是网络拓扑中的间隔。比方客户端的自身就是一个 DataNode，那么从本地读取数据显著比跨网络读取数据效率要高。
3. DistributedFileSystem 将 FSDataInputStream（反对文件 seek 定位读的输出流）返回到客户端以供其读取数据。FSDataInputStream 类转而封装为 DFSInputStream 类，DFSInputStream 治理着 datanode 和 namenode 之间的 IO。
4. 客户端在流上调用 read()办法 。而后，已存储着文件前几个块 DataNode 地址的 DFSInputStream 随即连贯到文件中第一个块的最近的 DataNode 节点。 通过对数据流重复调用 read()办法，能够将数据从 DataNode 传输到客户端。
5. 当该块快要读取完结时，DFSInputStream 将敞开与该 DataNode 的连贯，而后寻找下一个块的最佳 datanode。这些操作对用户来说是通明的。所以用户感觉起来它始终在读取一个间断的流
6. 客 户端从流中读取数据时，块是依照关上 DFSInputStream 与 DataNode 新建连贯的程序读取的 。它也会依据须要询问 NameNode 来检索下一批数据块的 DataNode 地位信息。一旦客户端实现读取，就对 FSDataInputStream 调用 close() 办法
7. 如果 DFSInputStream 与 DataNode 通信时遇到谬误，它将尝试该块的下一个最靠近的 DataNode 读取数据。并将记住产生故障的 DataNode，保障当前不会重复读取该 DataNode 后续的块。此外，DFSInputStream 也会通过校验和（checksum）确认从 DataNode 发来的数据是否残缺。如果发现有损坏的块，DFSInputStream 会尝试从其余 DataNode 读取该块的正本，也会将被损坏的块报告给 namenode

3. 角色职责概述

1. Namenode 职责

1. NameNode 是 HDFS 的外围，集群的主角色，被称为 Master。
2. NameNode 仅存储管理 HDFS 的元数据：文件系统 namespace 操作保护目录树，文件和块的地位信息。
3. NameNode 不存储理论数据或数据集。数据自身理论存储在 DataNodes 中
4. NameNode 晓得 HDFS 中任何给定文件的块列表及其地位。应用此信息 NameNode 晓得如何从块中构建文件
5. NameNode 并不长久化存储每个文件中各个块所在的 DataNode 的地位信息，这些信息会在系统启动时从 DataNode 汇报中重建
6. NameNode 对于 HDFS 至关重要，当 NameNode 敞开时，HDFS / Hadoop 集群无法访问
7. NameNode 是 Hadoop 集群中的单点故障
8. NameNode 所在机器通常会配置有大量内存（RAM）

2. Datanode 职责

1. DataNode 负责将理论数据存储在 HDFS 中。是集群的从角色，被称为 Slave。
2. DataNode 启动时，它将本人公布到 NameNode 并汇报本人负责持有的块列表
3. 依据 NameNode 的指令，执行块的创立、复制、删除操作
4. DataNode 会定期（dfs.heartbeat.interval 配置项配置，默认是 3 秒）向 NameNode 发送心跳，如果 NameNode 长时间没有承受到 DataNode 发送的心跳，NameNode 就会认为该 DataNode 生效
5. DataNode 会定期向 NameNode 进行本人持有的数据块信息汇报，汇报工夫距离取参数 dfs.blockreport.intervalMsec, 参数未配置的话默认为 6 小时
6. DataNode 所在机器通常配置有大量的硬盘空间。因为理论数据存储在 DataNode 中

4. Namenode 元数据管理

1. 元数据是什么

元数据（Metadata），又称中介数据，为形容数据的数据（data about data），次要是形容数据属性（property）的信息，用来反对如批示存储地位、历史数据、资源查找、文件记录等性能。

在 HDFS 中，元数据次要指的是文件相干的元数据，由 NameNode 治理保护。从狭义的角度来说，因为 NameNode 还须要治理泛滥 DataNode 节点，因而 DataNode 的地位和衰弱状态信息也属于元数据。

2. 元数据管理概述

在 HDFS 中，文件相干元数据具备两种类型：

1. 文件本身属性信息

文件名称、权限，批改工夫，文件大小，复制因子，数据块大小。

2. 文件块地位映射信息

记录文件块和 DataNode 之间的映射信息 ，即哪个块位于哪个节点上。
按存储模式分为内存元数据和磁盘元数据文件两种，别离存在内存和磁盘上。

1. 内存元数据
   为了保障用户操作元数据交互高效，提早低，NameNode 把所有的元数据都存储在内存中，咱们叫做内存元数据。内存中的元数据是最残缺的，包含文件本身属性信息、文件块地位映射信息 。然而内存的致命 问题是，断点数据失落，数据不会长久化。因而 NameNode 又辅助了元数据文件来保障元数据的平安残缺。

2. 磁盘元数据

   • fsimage 内存镜像文件
     是内存元数据的一个长久化的检查点 。然而 fsimage 中仅蕴含 Hadoop 文件系统中文件本身属性相干的元数据信息，但 不蕴含文件块地位的信息。文件块地位信息只存储在内存中，时由 datanode 启动退出集群的时候，向 namenode 进行数据块的汇报失去的，并且后续间断指定工夫进行数据块报告。长久化的动作是一种数据从内存到磁盘的 IO 过程。会对 namenode 失常服务造成肯定的影响，不能频繁的进行长久化。
   • Edits log 编辑日志

   为了防止两次长久化之间数据失落的问题，又设计了 Edits log 编辑日志文件 。文件中 记录的是 HDFS 所有更改操作（文件创建，删除或批改）的日志，文件系统客户端执行的更改操作首先会被记录到 edits 文件中。

3. 加载元数据程序
   fsimage 和 edits 文件都是通过序列化的，在 NameNode 启动的时候，它会将 fsimage 文件中的内容加载到内存中，之后再执行 edits 文件中的各项操作，使得内存中的元数据和理论的同步，存在内存中的元数据反对客户端的读操作，也是最残缺的元数据。
   当客户端对 HDFS 中的文件进行新增或者批改操作，操作记录首先被记入 edits 日志文件中 ，当客户端操作胜利后，相应的元数据会更新到内存元数据中。因为 fsimage 文件个别都很大（GB 级别的很常见），如果所有的更新操作都往 fsimage 文件中增加，这样会导致系统运行的非常迟缓。
   HDFS 这种设计实现着手于： 一是内存中数据更新、查问快，极大缩短了操作响应工夫；二是内存中元数据失落危险颇高（断电等），因而辅助元数据镜像文件（fsimage）+ 编辑日志文件（edits）的备份机制进行确保元数据的平安。
   NameNode 保护整个文件系统元数据。因而，元数据的精确治理，影响着 HDFS 提供文件存储服务的能力。

   3. 元数据管理相干目录文件

   1. 元数据存储目录

   在 Hadoop 的 HDFS 首次部署好配置文件之后，并不能马上启动应用，而是先要对文件系统进行格式化操作:hdfs namenode -format
   在这里要留神两个概念，一个是 format 之前，HDFS 在物理上还不存在；二就是此处的 format 并不是指传统意义上的本地磁盘格式化，而是一些革除与筹备工作 。其中就会创立元数据本地存储目录和一些初始化的元数据相干文件。
   namenode 元数据存储目录由参数：dfs.namenode.name.dir 指定，格式化实现之后，将会在 $dfs.namenode.name.dir/current 目录下创立如下的文件：
   
   其中的 dfs.namenode.name.dir 是在 hdfs-site.xml 文件中配置的，默认值如下：
   
   dfs.namenode.name.dir 属性能够配置多个目录，各个目录存储的文件构造和内容都齐全一样，相当于备份，这样做的益处是当其中一个目录损坏了，也不会影响到 hadoop 的元数据，特地是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即便你这台机器损坏了，元数据也失去保留。

2. 元数据相干文件

1. Version
   

   • namespaceID/clusterID/blockpoolID
     这些都是 HDFS 集群的惟一标识符。标识符被用来避免 DataNodes 意外注册到另一个集群中的 namenode 上。这些标识在联邦（federation）部署中特地重要。联邦模式下，会有多个 NameNode 独立工作。每个的 NameNode 提供惟一的命名空间（namespaceID），并治理一组惟一的文件块池（blockpoolID）。clusterID 将整个集群联合在一起作为单个逻辑单元，在集群中的所有节点上都是一样的。
   • storageType
     阐明这个文件存储的是什么过程的数据结构信息, 如果是 DataNode，storageType=DATA_NODE。
   • cTime
     NameNode 存储系统创立工夫，首次格式化文件系统这个属性是 0，当文件系统降级之后，该值会更新到降级之后的工夫戳；
   • layoutVersion
     HDFS 元数据格式的版本。增加须要更改元数据格式的新性能时，请更改此数字。以后的 HDFS 软件应用比以后版本更新的布局版本时，须要进行 HDFS 降级

   4. SecondaryNamenode

   1. SNN 职责概述

   
   NameNode 职责是治理元数据信息，DataNode 的职责是负责数据具体存储，那么 SecondaryNameNode 的作用是什么？对很多初学者来说是十分蛊惑的。它为什么会呈现在 HDFS 中。从它的名字上看，它给人的感觉就像是 NameNode 的备份。但它实际上却不是。
   当 HDFS 集群运行一段事件后，就会呈现上面一些问题：

   • edits logs 会变的很大，fsimage 将会变得很旧；
   • namenode 重启会破费很长时间，因为有很多改变要合并到 fsimage 文件上
   • 如果频繁进行 fsimage 长久化，又会影响 NameNode 失常服务，毕竟 IO 操作是一种内存到磁盘的耗精力操作

   因而为了克服这个问题，须要一个易于治理的机制来帮忙咱们减小 edit logs 文件的大小和失去一个最新的 fsimage 文件，这样也会减小在 NameNode 上的压力。
   SecondaryNameNode 就是来帮忙解决上述问题的，它的 职责是合并 NameNode 的 edit logs 到 fsimage 文件中。

   2. SNN checkpoint 机制

   1. 概述
      Checkpoint 外围是把 fsimage 与 edits log 合并以生成新的 fsimage 的过程。此过程有两个 益处：fsimage 版本不断更新不会太旧、edits log 文件不会太大。
   2. 流程
   • 当触发 checkpoint 操作条件时，SNN 产生申请给 NN 滚动 edits log。而后 NN 会生成一个新的编辑日志文件：edits new，便于记录后续操作记录。
   • 同时 SNN 会将 edits 文件和 fsimage 复制到本地（应用 HTTP GET 形式）。
   • SNN 首先将 fsimage 载入到内存，而后一条一条地执行 edits 文件中的操作，使得内存中的 fsimage 不断更新，这个过程就是 edits 和 fsimage 文件合并。合并完结，SNN 将内存中的数据 dump 生成一个新的 fsimage 文件。
   • SNN 将新生成的 Fsimage new 文件复制到 NN 节点。
   • 至此刚好是一个轮回，期待下一次 checkpoint 触发 SecondaryNameNode 进行工作，始终这样循环操作。
   3. 触发机制
      Checkpoint 触发条件受两个参数管制，能够通过 core-site.xml 进行配置

   dfs.namenode.checkpoint.period=3600  // 两次间断的 checkpoint 之间的工夫距离。默认 1 小时
   dfs.namenode.checkpoint.txns=1000000 // 最大没有执行 checkpoint 事务的数量，满足将强制执行紧急 checkpoint，即便尚未达到检查点周期。默认 100 万事务数量。

   从下面的形容咱们能够看出，SecondaryNamenode 基本就不是 Namenode 的一个热备，只是将 fsimage 和 edits 合并。

   5. Namenode 元数据恢复

   1. NameNode 存储多目录

   namenode 元数据存储目录由参数：dfs.namenode.name.dir 指定。
   dfs.namenode.name.dir 属性能够配置多个目录，各个目录存储的文件构造和内容都齐全一样，相当于备份， 这样做的益处是当其中一个目录损坏了，也不会影响到 hadoop 的元数据，特地是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即便你这台机器损坏了，元数据也失去保留。

2. 从 SecondaryNameNode 复原

SecondaryNameNode 在 checkpoint 的时候会将 fsimage 和 edits log 下载到本人的本机上本地存储目录下。并且在 checkpoint 之后也不会进行删除。
如果 NameNode 中的 fsimage 真的出问题了，还是能够用 SecondaryNamenode 中的 fsimage 替换一下 NameNode 上的 fsimage，尽管曾经不是最新的 fsimage，然而咱们能够将损失减小到起码！

5 . HDFS 小文件解决方案

1. Hadoop Archive 归档

HDFS 并不善于存储小文件，因为每个文件起码一个 block，每个 block 的元数据都会在 NameNode 占用内存，如果存在大量的小文件，它们会吃掉 NameNode 节点的大量内存。
Hadoop Archives 能够无效的解决以上问题，它能够把多个文件归档成为一个文件，归档成一个文件后还能够通明的拜访每一个文件。

1. 创立 Achive
   Usage: hadoop archive -archiveName name -p <parent> <src>* <dest>
   其中 -archiveName 是指要创立的存档的名称。比方 test.har，archive 的名字的扩展名应该是 *.har。- p 参数指定文件存档文件（src）的相对路径。
   举个例子：-p /foo/bar a/b/c e/f/g，这里的 /foo/bar 是 a /b/ c 与 e /f/ g 的父门路，所以残缺门路为 /foo/bar/a/b/ c 与 /foo/bar/e/f/g。

例如：如果你只想存档一个目录 /smallfile 下的所有文件:

hadoop archive -archiveName test.har -p /smallfile /outputdir

这样就会在 /outputdir 目录下创立一个名为 test.har 的存档文件。
留神：Archive 归档是通过 MapReduce 程序实现的，须要启动 YARN 集群。

2. 查看 Archive

   • 查看归档之后的样子

   首先咱们来看下创立好的 har 文件。应用如下的命令：
   hadoop fs -ls /outputdir/test.har

   • 查看归档之前的样子

   在查看 har 文件的时候，如果没有指定拜访协定，默认应用的就是 hdfs://，此时所能看到的就是归档之后的样子。
   此外，Archive 还提供了本人的 har uri 拜访协定。如果用 har uri 去拜访的话，索引、标识等文件就会暗藏起来，只显示创立档案之前的原文件：
   Hadoop Archives 的 URI 是：
   har://scheme-hostname:port/archivepath/fileinarchive
   scheme-hostname 格局为 hdfs- 域名: 端口。

3. 提取 Archive
   按程序解压存档（串行）：

   hadoop fs -cp har:///user/zoo/foo.har/dir1  hdfs:/user/zoo/newdir
   
   [root@node1 ~]# hadoop fs -mkdir /smallfile1
   [root@node1 ~]# hadoop fs -cp har:///outputdir/test.har/* /smallfile1
   [root@node1 ~]# hadoop fs -ls /smallfile1
   

   要并行解压存档，请应用 DistCp, 对应大的归档文件能够提高效率：

4. Archive 应用注意事项

   • Hadoop archives 是非凡的档案格局。一个 Hadoop archive 对应一个文件系统目录。Hadoop archive 的扩展名是 *.har；
   • 创立 archives 实质是运行一个 Map/Reduce 工作，所以应该在 Hadoop 集群上运行创立档案的命令；
   • 创立 archive 文件要耗费和原文件一样多的硬盘空间；
   • archive 文件不反对压缩，只管 archive 文件看起来像曾经被压缩过；
   • archive 文件一旦创立就无奈扭转，要批改的话，须要创立新的 archive 文件。事实上，个别不会再对存档后的文件进行批改，因为它们是定期存档的，比方每周或每日；
   • 当创立 archive 时，源文件不会被更改或删除；

1. Sequence File

1. Sequence File 介绍
   Sequence File 是 Hadoop API 提供的一种二进制文件反对。这种二进制文件间接将 <key, value> 键值对序列化到文件中。
   

2. Sequence File 优缺点

   1. 长处

      • 二级制格局存储，比文本文件更紧凑。
      • 反对不同级别压缩（基于 Record 或 Block 压缩）。
      • 文件能够拆分和并行处理，实用于 MapReduce。

   2. 局限性

      • 二进制格式文件不不便查看
      • 特定于 hadoop，只有 Java API 可用于与之件进行交互。尚未提供多语言反对

3. Sequence File 格局
   Hadoop Sequence File 是一个由二进制键 / 值对组成的。依据压缩类型，有 3 种不同的 Sequence File 格局：未压缩格局、record 压缩格局、block 压缩格局。
   Sequence File 由一个 header 和一个或多个 record 组成。以上三种格局均应用雷同的 header 构造，如下所示：
   
   前 3 个字节为 SEQ，示意该文件是序列文件，后跟一个字节示意理论版本号（例如 SEQ4 或 SEQ6）。Header 中其余也包含 key、value class 名字、压缩细节、metadata、Sync marker。Sync Marker 同步标记，用于能够读取任意地位的数据。

   • . 未压缩格局

   未压缩的 Sequence File 文件由 header、record、sync 三个局部组成。其中 record 蕴含了 4 个局部：record length（记录长度）、key length（键长）、key、value。
   每隔几个 record（100 字节左右）就有一个同步标记
   

   • . 基于 record 压缩格局

   基于 record 压缩的 Sequence File 文件由 header、record、sync 三个局部组成。其中 record 蕴含了 4 个局部：record length（记录长度）、key length（键长）、key、compressed value（被压缩的值）。
   每隔几个 record（100 字节左右）就有一个同步标记。
   

   • . 基于 block 压缩格局

   基于 block 压缩的 Sequence File 文件由 header、block、sync 三个局部组成。
   block 指的是 record block，能够了解为多个 record 记录组成的块。留神，这个 block 和 HDFS 中分块存储的 block（128M）是不同的概念。
   Block 中包含：record 条数、压缩的 key 长度、压缩的 keys、压缩的 value 长度、压缩的 values。每隔一个 block 就有一个同步标记。
   block 压缩比 record 压缩提供更好的压缩率。应用 Sequence File 时，通常首选块压缩。