关于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治理的元数据具备两种类型：

文件本身属性信息
文件名称、权限，批改工夫，文件大小，复制因子，数据块大小。
文件块地位映射信息
记录文件块和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. 模块功能模块

Overview
Overview是总揽模块，默认的主页面。展现了HDFS一些最外围的信息。
- Summary
- NameNode Journal Status
- NameNode Storage
- DFS Storage Types
Datanodes
Datanodes模块次要记录了HDFS集群中各个DataNode的相干状态信息
Datanode Volume Failures
此模块记录了DataNode卷故障信息。
Snapshot
Snapshot模块记录HDFS文件系统的快照相干信息，包含哪些文件夹创立了快照和总共有哪些快照。
Satartup progress
Startup Progress模块记录了HDFS集群启动的过程信息，执行步骤和每一步所做的事和用时。
Utilities
Utilities模块算是用户应用最多的模块了，外面包含了文件浏览、日志查看、配置信息查看等外围性能。
1. Browse the file system
该模块能够说是咱们在开发应用HDFS过程中应用最多的模块了，提供了一种Web页面浏览操作文件系统的能力，在某些场合下，比应用命令操作更加直观不便。
1. Logs、Log Level
1. 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. 具体流程

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

3. 默认3正本存储策略

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

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

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

2. 读数据流程

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

3. 角色职责概述

1. Namenode 职责

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

2. Datanode职责

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

4. Namenode 元数据管理

1. 元数据是什么

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

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

2. 元数据管理概述

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

1. 文件本身属性信息

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

2. 文件块地位映射信息

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

内存元数据
为了保障用户操作元数据交互高效，提早低，NameNode把所有的元数据都存储在内存中，咱们叫做内存元数据。内存中的元数据是最残缺的，包含文件本身属性信息、文件块地位映射信息。然而内存的致命问题是，断点数据失落，数据不会长久化。因而NameNode又辅助了元数据文件来保障元数据的平安残缺。
磁盘元数据
- fsimage 内存镜像文件
  是内存元数据的一个长久化的检查点。然而fsimage中仅蕴含Hadoop文件系统中文件本身属性相干的元数据信息，但不蕴含文件块地位的信息。文件块地位信息只存储在内存中，时由datanode启动退出集群的时候，向namenode进行数据块的汇报失去的，并且后续间断指定工夫进行数据块报告。长久化的动作是一种数据从内存到磁盘的IO过程。会对namenode失常服务造成肯定的影响，不能频繁的进行长久化。
- Edits log编辑日志
为了防止两次长久化之间数据失落的问题，又设计了Edits log编辑日志文件。文件中记录的是HDFS所有更改操作（文件创建，删除或批改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中。
加载元数据程序
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. 元数据相干文件

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进行工作，始终这样循环操作。
1. 触发机制
  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能够无效的解决以上问题，它能够把多个文件归档成为一个文件，归档成一个文件后还能够通明的拜访每一个文件。

创立 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集群。

查看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-域名:端口。

提取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,对应大的归档文件能够提高效率：

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

1. Sequence File

Sequence File介绍
Sequence File是Hadoop API提供的一种二进制文件反对。这种二进制文件间接将<key, value>键值对序列化到文件中。
Sequence File优缺点
1. 长处
  - 二级制格局存储，比文本文件更紧凑。
  - 反对不同级别压缩（基于Record或Block压缩）。
  - 文件能够拆分和并行处理，实用于MapReduce。
2. 局限性
  - 二进制格式文件不不便查看
  - 特定于hadoop，只有Java API可用于与之件进行交互。尚未提供多语言反对
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时，通常首选块压缩。