独家 | 一文读懂Hadoop（二）HDFS（下）

5.1 用户命令

hadoop集群用户的常用命令。

5.1.1 classpath

打印获取Hadoop jar和所需库所需的类路径。如果无参数调用，则打印由命令脚本设置的类路径，可以在类路径条目中包含通配符。其他选项在通配符扩展后打印类路径或将类路径写入jar文件的清单。后者在不能使用通配符且扩展的类路径超过支持的最大命令行长度的环境中非常有用。

5.1.2 dfs

HDFS允许以文件和目录的形式组织用户数据。它提供了一个称为FS shell的命令行界面，允许用户与HDFS中的数据交互。此命令集的语法类似于我们已经熟悉的shell。

FS shell是针对需要脚本语言以与存储的数据交互的应用程序。具体命令将在手把手教环节来详细讲解。

5.1.3 envvars

显示计算的Hadoop环境变量。

5.1.4 fetchdt

HDFS支持fetchdt命令来获取授权标识，并将其存储在本地文件系统的一个文件中。一个“非安全”的客户端可以用这个标识来访问受限的服务器（例如NameNode）。获取这个标识，采用RPC或HTTPS(over Kerberos)方式，然后，在获取之前需要提交Kerberos凭证（运行kinit来获得凭证）。HDFS fechedt命令不是一个Hadoop shell命令。它以bin/hadoop fetchdt DTfile方式运行。当你获得授权标识后，通过指定环境变量HADOOP_TOKEN_FILE_LOCATION为授权标识文件名，你就可以运行HDFS命令，而不需要Kerberros凭证了。

5.1.5 fsck

HDFS支持fsck命令来检查系统中的各种不一致状况。这个命令被设计来报告各种文件存在的问题，比如文件缺少数据块或者副本数目不够。不同于在本地文件系统上传统的fsck工具，这个命令并不会修正它检测到的错误。一般来说，NameNode会自动修正大多数可恢复的错误。HDFS的fsck不是一个Hadoop shell命令。它通过'bin/hadoop fsck'执行。

5.1.6 getconf

从配置目录获取配置信息。

5.1.7 groups

返回给定一个或多个用户名的组信息。

5.1.8 lsSnapshottableDir

获取快照目录的列表。当它作为超级用户运行时，它返回所有可快照目录。否则，它返回那些由当前用户拥有的目录。

5.1.9 jmxget

从服务转储JMX信息。

5.1.10 oev

Hadoop离线edits查看器。

5.1.11 oiv

Hadoop离线image查看器用于Hadoop 2.4或更高版本中的映像文件。

5.1.12 oiv_legacy

Hadoop的旧版本的Hadoop离线image查看器。

5.1.13 snapshotDiff

确定HDFS快照之间的差异。

5.1.14 version

打印版本。

5.2 管理命令

hadoop集群管理员常用的命令。

5.2.1 balancer

运行集群平衡工具。管理员可以简单的按Ctrl-C来停止平衡过程。

5.2.2 cacheadmin

HDFS缓存管理。

5.2.3 crypto

HDFS透明加密。

5.2.4 datanode

运行HDFS datanode。

5.2.5 dfsadmin

DFSAdmin命令集用于管理HDFS集群。这些是仅由HDFS管理员使用的命令。以下是一些示例/命令对：

5.2.6 diskbalancer

运行磁盘调度程序CLI。

5.2.7 erasurecode

运行ErasureCoding CLI。

5.2.8 haadmin

在带有NFS的HDFS HA或带有QJM的HDFS HA中使用。

5.2.9 journalnode

这个命令启动一个journalnode用于带有QJM的HDFS HA。

5.2.10 mover

运行数据迁移实用程序。

5.2.11 namenode

运行namenode。以及升级和回滚。

5.2.12 nfs3

这个comamnd启动NFS3网关用于HDFS NFS3服务。

5.2.13 portmap

这个comamnd启动RPC portmap用于HDFS NFS3服务。

5.2.14 secondarynamenode

运行HDFS辅助节点。

5.2.15 storagepolicies

列出所有/获取/设置/取消设置存储策略。

5.2.16 zkfc

这个命令启动一个Zookeeper故障转移控制器过程与带有QJM的HDFS HA一起使用。

5.3 调试命令

有效的帮助管理员调试HDFS问题。这些命令仅适用于高级用户。

5.3.1verifyMeta

验证HDFS元数据和块文件。如果指定了块文件，我们将验证元数据文件中的校验和是否与块文件匹配。

5.3.2 computeMeta

从块文件计算HDFS元数据。如果指定了块文件，我们将从块文件计算校验和，并将其保存到指定的输出元数据文件。

注意：使用它是有风险的，如果块文件已损坏，并覆盖它的元文件，它将在HDFS中显示为“正常”，但却无法读取数据。当你100％确定块文件正常的时候才能使用。

5.3.3 recoverLease

在指定的路径上恢复租约。路径必须驻留在HDFS文件系统上。默认的重试次数为1。

6. 扩展阅读

6.1 档案存储，SSD和内存

归档存储是将增长的存储容量与计算能力分离的解决方案。具有使较高密度和具有低计算能力的较低成本存储器的节点变得可用，并且可以用作集群中的冷存储器。基于策略，来自热的数据可以被移动到冷。向冷存储中添加更多节点可以增加存储，而与集群中的计算能力无关。

异构存储和归档存储提供的框架将HDFS架构概括为包括其他种类的存储介质，包括SSD和存储器。用户可以选择将其数据存储在SSD或内存中以获得更好的性能。

6.1.1 存储类型

异构存储的第一阶段将datanode存储模型从单个存储（其可以对应于多个物理存储介质）改变为存储的集合，其中每个存储对应于物理存储介质。它还添加了存储类型的概念，DISK和SSD，其中DISK是默认存储类型。

添加了新的存储类型ARCHIVE，它具有高存储密度（PB级存储），但计算能力很低，用于支持存档存储。

添加了另一个新的存储类型RAM_DISK，用于支持在内存中写入单个副本文件。

6.1.2 存储策略

引入了存储策略的新概念，以便允许根据存储策略将文件存储在不同的存储类型中。

我们有以下存储策略：

• Hot：用于存储和计算。一直在使用的数据将保留在此策略中。当块经常被用到时，所有副本都存储在DISK中。
• Cold：仅适用于有限计算的存储。不再使用的数据或需要归档的数据将从热存储移动到冷存储。当块不经常被用到时，所有副本都存储在ARCHIVE中。
• Warm：部分热和部分冷的数据。当块热时，其一些副本存储在DISK中，其余的副本存储在ARCHIVE中。
• All_SSD：用于存储SSD中的所有副本。
• One_SSD：用于存储SSD中的一个副本。剩余的副本存储在DISK中。
• Lazy_Persist：用于在内存中写入单个副本的块。副本首先写入RAM_DISK，然后它被持久化在DISK中。

6.1.3 存储策略解析

创建文件或目录时，其存储策略未指定。可以使用“storagepolicies -setStoragePolicy”命令指定存储策略。文件或目录的有效存储策略由以下规则解决。

• 如果使用存储策略指定文件或目录，请返回；
• 对于未指定的文件或目录，如果它是根目录，请返回默认存储策略。否则，返回其父级的有效存储策略。

可以通过“storagepolicies -getStoragePolicy”命令检索有效的存储策略。

6.1.4 Mover新的数据迁移工具

添加了一个新的数据迁移工具，用于归档数据。该工具类似于Balancer。它定期扫描HDFS中的文件，以检查块布局是否满足存储策略。对于违反存储策略的块，它会将副本移动到不同的存储类型，以满足存储策略要求。

6.2 升级和回滚

当在一个已有集群上升级Hadoop时，像其他的软件升级一样，可能会有新的bug或一些会影响到现有应用的非兼容性变更出现。在任何有实际意义的HDSF系统上，丢失数据是不被允许的，更不用说重新搭建启动HDFS了。HDFS允许管理员退回到之前的Hadoop版本，并将集群的状态回滚到升级之前。HDFS在一个时间可以有一个这样的备份。在升级之前，管理员需要用bin/hadoop dfsadmin -finalizeUpgrade命令删除存在的备份文件。下面简单介绍一下一般的升级过程：

• 升级Hadoop软件之前，请检查是否已经存在一个备份，如果存在，可执行相应操作删除这个备份。通过dfsadmin -upgradeProgress status命令能够知道是否需要对一个集群执行该操作；
• 停止集群并部署新版本的Hadoop；
• 使用-upgrade选项运行新的版本（bin/start-dfs.sh -upgrade）；
• 在大多数情况下，集群都能够正常运行。一旦我们认为新的HDFS运行正常（也许经过几天的操作之后），就可以对之执行删除存在的备份文件操作；
• 如果需要退回到老版本。

停止集群并且部署老版本的Hadoop。

在namenode（bin /hdfs namenode -rollback）上运行rollback命令。

用回滚选项启动集群（bin/start-dfs.h -rollback）。

当升级到新版本的HDFS时，有必要重命名或删除在新版本的HDFS中保留的任何路径。如果NameNode在升级期间遇到保留路径，它将打印如下错误：

/.reserved是保留路径，.snapshot是此版本的HDFS中的保留路径组件。请回滚并删除或重命名此路径，或使用-rename Reserved [键值对]选项升级以在升级期间自动重命名这些路径。

指定-upgrade -renameReserved [可选键值对]使NameNode自动重命名启动期间找到的任何保留路径。例如，要将名为.snapshot的所有路径重命名为.my-snapshot并将.reserved重命名为.my-reserved，用户将指定-upgrade –rename Reserved .snapshot = .my-snapshot，.reserved = .my-reserved。

如果没有使用-renameReserved指定键值对，NameNode将使用<LAYOUT-VERSION> .UPGRADE_RENAMED。

这个重命名过程有一些注意事项。如果可能，建议在升级之前先引用hdfs dfsadmin -saveNamespace。这是因为如果编辑日志操作引用自动重命名文件的目标，则可能导致数据不一致。

6.3 HDFS滚动升级

HDFS滚动升级允许升级单个HDFS守护进程。例如，可以独立于数据节点升级数据节点。一个namenode可以独立于其他namenode升级。可以独立于datanode和journal节点升级namenode。

6.3.1 升级

在Hadoop v2中，HDFS支持高可用性（HA）namenode服务和线路兼容性。这两个功能使升级HDFS成为可能，而不会导致HDFS停机。为了在不停机的情况下升级HDFS集群，必须使用HA设置集群。

如果在新软件版本中启用了任何新功能，升级后可能无法使用旧软件版本。在这种情况下，升级应通过以下步骤完成：

• 禁用新功能；
• 升级集群；
• 启用新功能。

请注意，滚动升级仅受Hadoop-2.4.0及更高版本的支持。

6.3.1.1 无停机升级

在HA群集中，有两个或更多NameNode（NN），许多DataNodes（DN），一些JournalNodes（JN）和一些ZooKeeperNodes（ZKN）。JNs相对稳定，在大多数情况下升级HDFS时不需要升级。无停机升级仅考虑NN和DN，JN和ZKN不是。升级JN和ZKN可能会导致集群停机。

6.3.1.2 随着停机时间升级

对于非HA群集，无法在不停机的情况下升级HDFS，因为需要重新启动namenode。但是，datanode仍然可以滚动方式升级。

6.3.2 降级和回滚

当升级版本不受欢迎时，或者在某些情况下，升级失败（由于较新版本中的错误），管理员可以选择将HDFS降级回升级前版本，或者将HDFS回滚到升级前版本，升级前的状态。

6.3.2.1 降级

降级将软件恢复到升级前版本，并保留用户数据。假设时间T是滚动升级开始时间，升级通过降级终止。然后，在T之前或之后创建的文件在HDFS中仍然可用。在T之前或之后删除的文件在HDFS中保持删除。

只有在这两个版本之间不更改namenode布局版本和datanode布局版本时，较新版本才可降级到升级前版本。

6.3.2.2 回滚

回滚将软件恢复到升级前版本，但还会将用户数据恢复为升级前状态。假设时间T是滚动升级开始时间，并且通过回滚终止升级。在T之前创建的文件在HDFS中保持可用，但在T之后创建的文件变得不可用。在T之前删除的文件在HDFS中保持删除，但在T之后删除的文件将恢复。

始终支持从较新版本回滚到预升级版本。然而，它不能以滚动方式完成。它需要集群停机。

6.4 HDFS配额指南

6.4.1 概述

HDFS允许管理员为使用的命名和每个个人的文件夹设置配额。命名配额和空间配额独立操作，但是这两种情况的管理和实现是连接紧密的。

6.4.2 命名配额

命名配额是一个在这个文件夹下文件和文件夹的数目。如果超过限额那么文件和文件夹的创建会失败，重命名后命名配额仍然起作用。如果重命名操作违反配额的限制，那么重命名会失败。新创建的目录中没有配额的限制。Long.Max_Value表示最大限额。如果配额为1那么这个文件夹会强制为空。(一个目录也占用自己的配额)。

配额被持久化在fsimage中，当启动后，如果fsimage 马上违反了配额限制（由于fsimage偷偷的改变），这是会打印警告。设置或删除配额会创建一个空的日志。

6.4.3 空间配额

空间配额是设置一个文件夹的大小。如果超过那么块写入会失败。副本也算配额中的一部分。重命名文件夹后配额还是起作用，如果已经违反了配额，那么重命名操作会失败。新创建的文件夹不会有配额的限制，Long.Max_Value可以设置最大的配额。配额设置为0还是运行文件创建，但是不能向文件中写入块。文件夹不使用主机文件系统不计算在空间配额里面，主机文件系统用来记录文件源数据的数据不算在配额中。

配额被持久化在fsimage中，当启动后，如果fsimage 马上违反了配额限制（由于fsimage会慢慢的改变），这是会打印警告。设置或删除配额会创建一个空的日志。

6.4.4 存储类型配额

存储类型配额是对目录中根目录的树中的文件对特定存储类型（SSD，DISK，ARCHIVE）的使用的限制。它在许多方面类似于存储空间配额，但对群集存储空间使用提供细粒度控制。要在目录上设置存储类型配额，必须在目录上配置存储策略，以便允许根据存储策略将文件存储在不同的存储类型中。

存储类型配额可以与空间配额和名称配额组合，以有效地管理群集存储使用。例如：

• 对于配置了存储策略的目录，管理员应为资源约束存储类型（如SSD）设置存储类型配额，并为其他存储类型保留配额，并使用限制较少的值或默认无限制总空间配额。HDFS将根据存储策略和总空间配额从两种目标存储类型中扣除配额；
• 对于未配置存储策略的目录，管理员不应配置存储类型配额。即使特定存储类型不可用（或可用但未正确配置存储类型信息），也可以配置存储类型配额。但是，在这种情况下，建议使用总空间配额，因为存储类型信息对于存储类型配额强制不可用或不准确；
• DISK上的存储类型配额使用有限，除非DISK不是主要的存储介质。（例如，主要具有ARCHIVE存储的集群）。

6.5 HDFS短路本地读

在HDFS中，读取通常通过DataNode。因此，当客户端请求DataNode读取文件时，DataNode从磁盘读取该文件，并通过TCP将数据发送到客户端。所谓的“短路”读取就是绕过DataNode，允许客户端直接读取文件。显然，这仅在客户端与数据位于同一位置的情况下是可能的。短路读数为许多应用提供了实质性的性能提升。

6.6 HDFS中的集中式缓存管理

集中式缓存管理在HDFS是一个明确的缓存机制，允许用户指定路径由HDFS进行缓存。NameNode将与在磁盘上具有所需块的DataNode通信，并指示它们在堆外高速缓存中缓存块。

HDFS中的集中式缓存管理具有许多显着的优点：

• 显式锁定可防止频繁使用的数据从内存中逐出。当工作集的大小超过主存储器的大小时，这是特别重要的，这对于许多HDFS工作负载是常见的；
• 由于DataNode缓存由NameNode管理，因此应用程序可以在进行任务放置决策时查询缓存的块位置集合。将任务与缓存的块副本共置可提高读取性能；
• 当块由DataNode缓存时，客户端可以使用一个新的，更高效的零拷贝读取API。由于缓存数据的校验和验证由DataNode完成，因此客户端在使用此新API时可能会产生基本上为零的开销；
• 集中式缓存可以提高整体集群内存利用率。当依赖每个DataNode的OS缓冲区缓存时，重复读取一个块将导致该块的所有n个副本都被拉入缓冲区缓存。通过集中式缓存管理，用户可以明确地仅定位n个副本中的m个，从而节省nm内存。

6.7 HDFS NFS网关

NFS网关支持NFSv3，并允许将HDFS作为客户端本地文件系统的一部分加载。当前NFS网关支持并启用以下使用模式：

• 用户可以通过NFSv3客户端兼容操作系统上的本地文件系统浏览HDFS文件系统；
• 用户可以将文件从HDFS文件系统下载到本地文件系统；
• 用户可以将文件从本地文件系统直接上传到HDFS文件系统；
• 用户可以通过挂载点直接将数据流传输到HDFS。支持文件追加，但不支持随机写入。

NFS网关机器需要相同的东西来运行HDFS客户端，如Hadoop JAR文件，HADOOP_CONF目录。NFS网关可以与DataNode，NameNode或任何HDFS客户端位于同一主机上。

6.8 HDFS中的扩展属性

扩展属性（缩写为xattrs）是一种文件系统功能，允许用户应用程序将其他元数据与文件或目录相关联。与系统级inode元数据（如文件权限或修改时间）不同，扩展属性不由系统解释，而是由应用程序用于存储有关inode的附加信息。扩展属性可以用于例如指定纯文本文档的字符编码。

6.8.1 HDFS扩展属性

HDFS中的扩展属性是在Linux中扩展属性之后建模的。扩展属性是名称/值对，具有字符串名称和二进制值。Xattrs名称也必须用一个前缀的命名空间。例如，在用户命名空间中名为myXattr的xattr 将被指定为user.myXattr。多个xattrs可以与单个inode关联。

6.8.2 命名空间和权限

在HDFS中，有五个有效的命名空间：user，trusted，system，security和raw。这些命名空间中的每一个都有不同的访问限制。

用户的命名空间通常是由客户端应用程序使用的命名空间。在用户命名空间中对扩展属性的访问由相应的文件权限控制。

这个命名空间通常不能通过用户空间方法访问。这个xattr只能对文件设置，并且会阻止超级用户读取文件的内容。超级用户仍然可以读取和修改文件元数据，例如所有者，权限等。此xattr可以由任何用户设置和访问，这个xattr也是一次写，一旦设置就不能删除。此xattr不允许设置值。

6.9 HDFS中的透明加密

6.9.1 概述

Hadoop Key Management Server（KMS）是一个基于HadoopKeyProvider API编写的密钥管理服务器。他提供了一个client和一个server组件，client和server之间基于HTTP协议使用REST API通信。Client是一个KeyProvider的实现，使用KMS HTTP REST API与KMS交互。KMS和它的client有内置的安全机制，支持HTTP SPNEGO Kerberos认证和HTTPS安全传输。KMS是一个Java Web应用程序，运行在与Hadoop发行版绑定在一起的预先配置好的Tomcat服务器上。

HDFS 实现透明，端到端加密。配置完成后，用户往hdfs上存储数据的时候，无需用户做任何程序代码的更改（意思就是调用KeyProvider API ，用于在数据存入到HDFS上面的时候进行数据加密，解密的过程一样）。这意味着数据加密和解密由客户端完成的。HDFS 不会存储或访问未加密的数据或数据加密密钥（由kms管理）。

6.9.2 背景介绍

越来越多的用户关注安全问题，都在寻找一种有效的，方便的加密方式。hadoop提供了几种不同形式的加密，最底层的加密，加密所有节点数据，有效地保护了数据，但是却缺乏更细粒度的加密；

kms 透明加密可以做到更细粒度的加密；

加密可以在不同的层级进行，包括软件/软件堆栈，选择不同的加密层级各有优缺点：

• 应用程序级加密。这是最安全、最灵活的方法。该应用程序可以极大地控制加密的内容，并可以精确地反映用户的需求。但是，编写应用程序是很难的。对于不支持加密的现有应用程序的客户，这也不是一个选择；
• 数据库级加密。与其属性相似的应用级加密。大多数数据库供应商提供某种形式的加密。但是，可能会出现性能问题。一个例子是索引不能被加密；
• 文件系统级进行加密。此选项提供高性能，应用程序透明度，通常易于部署。但是，它无法建模一些应用程序级策略。例如，多租户应用程序可能希望基于最终用户进行加密。数据库可能需要对单个文件中存储的每个列进行不同的加密设置；
• 磁盘级别加密。容易部署和高性能,但也很不灵活。

HDFS级加密适用于此堆栈中的数据库级和文件系统级加密。这有很大的积极作用。HDFS加密能够提供良好的性能，现有的Hadoop应用程序能够透明地运行加密数据。在制定政策决策时，HDFS还具有比传统文件系统更多的上下文。

HDFS级别的加密还可以防止在文件系统级别及以下的攻击（所谓的“操作系统级攻击”）。操作系统和磁盘只与加密的字节进行交互，因为数据已被HDFS加密。

6.10 HDFS支持多宿主网络

在多宿主网络中，集群节点连接到多个网络接口。这样做可能有多种原因。

• 安全性：安全性要求可能决定集群内业务被限制在与用于将数据传入和传出集群的网络不同的网络中。
• 性能：集群内流量可能使用一个或多个高带宽互连，如光纤通道，Infiniband或10GbE。
• 故障转移/冗余：节点可能有多个网络适配器连接到单个网络以处理网络适配器故障。

6.11 HDFS中的内存存储支持

HDFS支持写入由数据节点管理的堆外存储器。数据节点会将内存中的数据异步刷入磁盘，从而从性能要求比较高的IO路径中去掉磁盘IO和校验和计算，因此我们称这种写入为Lazy Persist写入。HDFS为Lazy Persist 写入提供持久性保证。在将副本保留到磁盘之前，在节点重新启动的情况下，可能会发生数据丢失。应用程序可以选择使用Lazy Persist写入来折衷一些持久性保证，以减少延迟。

此功能从Apache Hadoop 2.6.0开始提供。

目标使用案例是将受益于以低延迟写入相对少量的数据（从几GB到几十GB，取决于可用存储器）的应用。内存存储用于在集群中运行并与HDFS数据节点并置的应用程序。我们已经观察到，网络复制的延迟开销抵消了写入内存的好处。

使用Lazy Persist 写入的应用程序将继续工作，如果内存不足或未配置，则回到DISK存储。

6.12 HDFS纠删码

6.12.1 概述

随着大数据技术的发展，HDFS作为Hadoop的核心模块之一得到了广泛的应用。为了系统的可靠性，HDFS通过复制来实现这种机制。但在HDFS中每一份数据都有两个副本，这也使得存储利用率仅为1/3，每TB数据都需要占用3TB的存储空间。随着数据量的增长，复制的代价也变得越来越明显：传统的3份复制相当于增加了200%的存储开销，给存储空间和网络带宽带来了很大的压力。因此，在保证可靠性的前提下如何提高存储利用率已成为当前HDFS应用的主要问题之一。针对这些问题，英特尔和Cloudera开始引入纠删码（Erasure Coding，EC）技术，在保证数据可靠性的同时大幅降低存储开销。

Erasure coding纠删码技术简称EC，是一种数据保护技术。最早用于通信行业中数据传输中的数据恢复，是一种编码容错技术。他通过在原始数据中加入新的校验数据，使得各个部分的数据产生关联性。在一定范围的数据出错情况下，通过纠删码技术都可以进行恢复。

6.12.2 纠删码（Erasure Code）与 Reed Solomon码

在存储系统中，纠删码技术主要是通过利用纠删码算法将原始的数据进行编码得到校验，并将数据和校验一并存储起来，以达到容错的目的。其基本思想是将ｋ块原始的数据元素通过一定的编码计算，得到ｍ块校验元素。对于这ｋ+ｍ块元素，当其中任意的ｍ块元素出错（包括数据和校验出错），均可以通过对应的重构算法恢复出原来的ｋ块数据。生成校验的过程被成为编码（encoding），恢复丢失数据块的过程被称为解码（decoding）。

Reed-Solomon（RS）码是存储系统较为常用的一种纠删码，它有两个参数k和m，记为RS(k，m)。如图1所示，k个数据块组成一个向量被乘上一个生成矩阵（Generator Matrix）GT从而得到一个码字（codeword）向量，该向量由k个数据块和m个校验块构成。如果一个数据块丢失，可以用(GT)-1乘以码字向量来恢复出丢失的数据块。RS(k，m)最多可容忍m个块（包括数据块和校验块）丢失。

6.12.3 块组（BlockGroup）

对HDFS的一个普通文件来说，构成它的基本单位是块。对于EC模式下的文件，构成它的基本单位为块组。块组由一定数目的数据块加上生成的校验块放一起构成。以RS(6，3)为例，每一个块组包含1-6个数据块，以及3个校验块。进行EC编码的前提是每个块的长度一致。如果不一致，则应填充0。图2给出三种不同类型的块组及其编码。

6.12.4 连续布局（Contiguous Layout）VS条形布局（Striping Layout）

数据被依次写入一个块中，一个块写满之后再写入下一个块，数据的这种分布方式被称为连续布局。在一些分布式文件系统如QFS和Ceph中，广泛使用另外一种布局：条形布局。条（stripe）是由若干个相同大小单元（cell）构成的序列。在条形布局下，数据被依次写入条的各个单元中，当条被写满之后就写入下一个条，一个条的不同单元位于不同的数据块中。

6.12.5 Erasure Coding技术的优劣势

6.12.5.1 优势

纠删码技术作为一门数据保护技术，自然有许多的优势，首先可以解决的就是目前分布式系统，云计算中采用副本来防止数据的丢失。副本机制确实可以解决数据丢失的问题，但是翻倍的数据存储空间也必然要被消耗，这一点却是非常致命的。EC技术的运用就可以直接解决这个问题。

6.12.5.2 劣势

EC技术的优势确实明显，但是他的使用也是需要一些代价的，一旦数据需要恢复，他会造成2大资源的消耗：

• 网络带宽的消耗，因为数据恢复需要去读其他的数据块和校验块；
• 进行编码，解码计算需要消耗CPU资源；
• 概况来讲一句话，就是既耗网络又耗CPU，看来代价也不小。所以这么来看，将此用于线上服务可能会觉得不够稳定，所以最好的选择是用于冷数据集群，有下面2点原因可以支持这种选择；
• 冷数据集群往往有大量的长期没有被访问的数据，体量确实很大，采用EC技术，可以大大减少副本数；
• 冷数据集群基本稳定，耗资源量少，所以一旦进行数据恢复，将不会对集群造成大的影响。

出于上述2种原因，冷数据集群无非是一个很好的选择。

6.13合成负载生成器

合成负载生成器（SLG）是用于在不同客户端负载下测试NameNode行为的工具。用户可以通过指定读取和写入的概率来生成读取、写入和列表请求的不同混合。用户通过调整工作线程的数量和操作之间的延迟的参数来控制负载的强度。当负载生成器正在运行时，用户可以配置和监视NameNode的运行。当Load Generator退出时，它会打印一些NameNode统计信息，如每种操作的平均执行时间和NameNode吞吐量。

本期独家内容“一文读懂Hadoop”系列文章将根据先介绍Hadoop，继而分别详细介绍HDFS、MAPREDUCE、YARN的所有知识点的框架，分为四期内容在近几天推送。敬请关注后续内容。

一文读懂Hadoop系列往期回顾：

独家 | 一文读懂Hadoop（一）：综述

宋莹，数据派研究部志愿者，北京中软融鑫ETL工程师。喜爱数学和计算机，酷爱大数据分析、大数据挖掘、机器学习。