常用命令

设置名称配额
# max_number 为最大文件/目录数
# dirname 为指定的目录
hdfs dfsadmin -setQuota
# 设置空间配额
# bytes 为最大存储字节数
hdfs dfsadmin -setSpaceQuota
#查看目录的配额情况： hdfs dfs -count -q -v -h /tmp/hncscwc
# 显示结果 # 名称配额大小 名称配额剩余大小 空间配额大小 空间配额剩余大小 目录数 文件数 文件大小 目录路径
none inf 536870912 536870912 1 0 0 /tmp/hncscwc

查看真个hdfs的空间大小
hdfs dfs -df -h /apps/hive/warehouse/aie_kfcdelivery.db
Filesystem Size Used Available Use%
hdfs://yumcluster 4.8 P 3.1 P 1.7 P 64%

#查看指定目录/数据库的大小
# hdfs dfs -du -s -h /apps/hive/warehouse/aie_kfcdelivery.db
2.7 T 8.4 T /apps/hive/warehouse/aie_kfcdelivery.db (集群为3副本存储;2.7T为一个副本的存储空间，故8.4T为三个副本的空间)

清除配额： # 清除名称配额
hdfs dfsadmin -clrQuota # 清除空间配额额 hdfs dfsadmin -clrSpaceQuota

纠删码

资料来源：
https://hadoop.apache.org/docs/r3.1.0/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
https://blog.cloudera.com/introduction-to-hdfs-erasure-coding-in-apache-hadoop/

1. 什么是纠删码

HDFS默认的3副本策略，在存储空间和其他比如网络带宽上有200%的开销，因而副本策略是昂贵的。但是对于具有相对较低I/O的冷热数据集，在正常操作期间很少访问其他副本块，但仍然消耗与第一个副本相同的资源量。
因此，一种改进措施是使用纠删码（Erasure Code，EC）来替换副本策略。纠删码提供了与副本相同的容错能力，但使用较少的存储空间。在典型的纠删码中，存储开销不超过50%。纠删码文件的副本因子由于始终为1，无法通过-setrep命令更改，故没有意义。

1. 纠错码技术背景

在存储系统中，EC最显着的用途是廉价磁盘冗余阵列（RAID）。 RAID通过条带化实现EC，条带化将逻辑上连续的数据（例如文件）划分为较小的单元（例如位，字节或块），并将连续的单元存储在不同的磁盘上。将这种条带分布的单位称为条带化单元（或单元）。对于原始数据单元的每个条带，都会计算并存储一定数量的奇偶校验块，这个过程称为编码。可以通过剩余数据块和奇偶校验块的解码计算来恢复任何条带单元上的错误。
将EC与HDFS集成可以提高存储效率，同时提供与副本相同的容错能力。例如，一个具有6个块的3副本文件将占用6 * 3 = 18个磁盘空间；但使用EC（6个数据，3个奇偶校验）部署时，它将仅占用9个磁盘空间块。

1. 架构

在EC的背景下，条带化具有几个关键优势。首先，它启用在线EC（以EC格式实时写入数据），避免了转换阶段并立即节省了存储空间。 Online EC还通过并行利用多个磁盘主轴来增加I/O性能。对高并发网络的集群尤其理想；其次，它将一个小文件分发到多个DataNode，并且不需要将多个文件捆绑到一个编码组中。这极大地简化了例如删除、配额报告以及联合名称空间之间迁移等文件操作。
在典型的HDFS群集中，小文件可占总存储消耗的3/4以上。 为了更好地支持小文件，在第一阶段的工作中，HDFS支持带条带化的EC。 将来，HDFS也将支持连续的EC设计。有关更多信息，请参见设计文档和有关HDFS-7285（https://issues.apache.org/jira/browse/HDFS-7285）的讨论。

• NameNode扩展

条带HDFS文件在逻辑上由块组（block group）构成，每个块组包含一定数量的内部块。为了减少NameNode对这些块的内存消耗，引入了新的分层块命名协议。可以从其任何内部块的ID推断出块组的ID。这允许在块组而不是块的级别进行管理。

• 客户端扩展

客户端读取和写入路径得到了增强，可以并行处理块组中的多个内部块。在输出/写入路径上，DFSStripedOutputStream管理着一组数据流，每个数据节点一个，在当前块组中存储一个内部块。这些流通常异步工作。协调器负责整个块组的操作，包括结束当前块组、分配新的块组等。在输入/读取路径上，DFSStripedInputStream将请求的逻辑字节数据转换为存储在DataNodes上的内部块。然后并行发出读取请求。当发生故障时，它将发出其他读取请求以进行解码。

• 数据节点扩展

数据节点运行附加ErasureCodingWorker（ECWorker）任务，用于后台恢复失败的纠删码块。 NameNode检测到失败的EC块，然后选择一个DataNode进行恢复工作。恢复任务以心跳响应方式进行传递。此过程类似于采用复制策略恢复丢失的数据块。
重建执行三个关键任务：
（1）从源节点读取数据
使用专用线程池从源节点并行读取输入数据。基于EC策略，它计划对所有源数据进行读取请求，并仅读取最少数量的输入块以进行重建。
（2）解码数据并生成输出数据
从新数据和奇偶校验块解码成原始数据。所有丢失的数据和奇偶校验块一起解码。
（3）将生成的数据块传输到目标节点
解码完成后，恢复的数据块将传输到目标DataNodes。

• 纠删码策略

为了适应异步的工作负载，我们允许HDFS集群中的文件和目录具有不同的复制和纠删码策略。纠删码策略封装了如何对文件进行编码/解码。
每个策略由以下信息定义：
EC模式：这包括EC组（例如6 + 3）中的数据块和奇偶校验块的数量，以及纠删码算法（例如Reed-Solomon，XOR）。条带单元的大小。 这确定了条带读取和写入的粒度，包括缓冲区大小和编码工作。策略被命名为编解码器-数据块数-奇偶校验块-单元大小。当前，支持六种内置策略：RS-3-2-1024k，RS-6-3-1024k，RS-10-4-1024k，RS-LEGACY-6-3-1024k，XOR-2-1- 1024k和复制（REPLICATION）。有多少个校验块就最多可容忍多少个块（包括数据块和校验块）丢失。
复制是一项特殊政策，它只能在目录上设置，以强制目录采用3倍复制方案，而不继承其原始的纠删码策略。此策略可以使3x复制方案目录与纠删码目录交错。REPLICATION策略始终处于默认开启状态。对于其他内置策略，默认情况下禁用。与HDFS存储策略类似，在目录上设置纠删码策略。创建文件后，它将继承其最近祖先目录的EC策略。目录级EC策略仅影响目录中创建的新文件。创建文件后，可以查询其纠删码策略，但不能更改。如果将纠删码文件重命名为具有其他EC策略的目录，则该文件将保留其现有的EC策略。将文件转换为其他EC策略需要重写该数据。通过复制文件（例如，通过distcp）而不是重命名来做到这一点。
我们允许用户通过XML文件配置自己的EC策略，该文件必须包含以下三个部分：
1. 布局版本：这表示EC策略XML文件格式的版本；
2. 模式：这包括所有用户定义的EC模式；
3. 策略：这包括所有用户定义的EC策略，每个策略都由架构ID和条带化单元的大小（cellsize）组成。
Hadoop conf目录中有一个名为user_ec_policies.xml.template的示例EC策略XML文件，用户可以参考该文件。

个人实践：

CDH配置：

Hdfs ec命令：
查看当前支持及启用的纠删码策略
hdfs ec -listPolicies

启用纠删码策略
hdfs ec -enablePolicy -policy XOR-2-1-1024k

查看及设置目录的纠删码策略
hdfs ec -getPolicy -path /user/xuanzhiang/test_ec

hdfs ec -setPolicy -policy XOR-2-1-1024k -path /user/xuanzhiang/test_ec

以测试环境为例，测试环境设置为1个机架，3个dataNode，只能设置为XOR-2-1-1024k，
该策略代表每两个block数据块会产生一个奇偶校验块，也就是3个块数据，比对三副本策略6个block块数据节约50%空间，对比双副本策略4个block节约25%空间。
如图：

使用fsck命令查看采用纠删码策略的block块信息：
hdfs fsck /user/xuanzhiang/test_ec/data_warehouse-2.0.jar -files -blocks -locations

HDFS-HA

在一个典型的HA集群中，2个单独的机器被配置为NameNode。任意时间点，一个NameNode是Active状态，另一个是Standy状态。集群中客户端发来的请求都会由Active NameNode来负责，而Standby节点只是一个简单从节点，保存集群中的状态数据来作为故障切换时备用。
为了让Standy 节点和Active节点的状态同步，2个节点都同时和一组单独的称为JournalNodes（JNs）的后台程序进行通信。当Active 节点的任意命名空间被更改时，一条描述本次更改的持久化的日志就会被写入大部分的JNs。Standby节点能够读取JNs的这些edit，周期性的查看edit log的变化，一旦Standby节点查看到edit，就立刻应用到自己的命名空间。当故障发生时，Standby在自己变成Active 状态之间能够保证从JounalNodes 读完所有的edits，这样就能保证命名空间的状态跟故障发生之前完全同步。
为了提供一个快速的故障切换，Standy节点必须包含集群中文件块的最新的位置信息，为了实现这一目的，DataNode会和2个NameNode都配置好，同时向2个NameNode发送心跳和文件块位置信息。
任意时刻一个HA集群中只有一个NameNode是至关重要的，否则命名空间会在2个节点之间快速分割，导致数据丢失或者造成不正确的结果。为了保证这一特性避免发生所谓的“split-brain scenario”，JournalNodes 只允许同一时间只有一个NameNode是写状态。当故障发生主备切换时，即将变成active的NameNode就会很容易接管向JournalNodes 的写权限，同时阻止另一个NameNode继续维持Active状态，这样就能够保证安全的切换到新的Active节点。
HA集群角色：
① NameNode 机器 — 需要运行Active /Standy NameNode的机器需要各自拥有同等的硬件，2台机器之间硬件完全独立，并且和non-HA集群的机器条件大致等同。
② JournalNode 机器 — 这些机器将用来运行JournalNode。JournalNode 后台程序是非常轻量级的。所以这些后台程序可以和其他hadoop的后台程序合理的分配到一起，例如NameNodes, the JobTracker, or the YARN ResourceManager。Note:因为edit log需要写入多数派的JNs，所以至少需要3个JournalNode 后端程序，这样就能让系统避免单一机器引发的错误。你也可以运行多于3个JournalNode ，但是为了增加系统可以容忍的错误数目，你可以使用奇数数目的JNs（例如3,5,7等等）。当运行N个JournalNode ，系统最多可容忍 (N - 1) / 2个故障并且不影响工作。
需要注意的是，在一个HA集群中，Standby NameNode一样会执行命名空间的checkpoint操作，因此在HA集群中不需要运行Secondary Namenode、CheckpointNode。
如果HDFS NameNode开启了HA的话，checkpoint过程会直接交给standby NameNode来负责。active NameNode会将edits文件同时写到本地与共享存储（比如QJM方案就是JournalNode集群）上去，standby NameNode从JournalNode集群拉取edits文件，和从active NameNode拉取的fsimage进行合并，并保持fsimage文件与active NameNode的同步。
故障转移：
ZookeeperFailoverController ( ZKFC )是一个新的组件，它是一个ZooKeeper客户端，也监视和管理NameNode的状态。运行NameNode的每台计算机也运行一个ZKFC，并且ZKFC负责:
① 运行状况监控
ZKFC定期ping本地NameNode，使用运行状况检查命令进行查验。只要NameNode是健康状态并及时响应，ZKFC就会认为NameNode正在正常运行。如果节点已崩溃、冻结或以其他方式进入不正常状态，运行状况监控器将其标记为不正常。
② ZooKeeper 会话管理
当本地NameNode健康运行，ZKFC会和ZooKeeper保持一个打开的会话。如果本地NameNode处于Active 状态，则它还持有特殊的“锁”znode。此锁使用ZooKeeper对“ephemeral”节点的支持；如果会话过期，将自动删除锁定节点。
③ 基于ZooKeeper的选择
如果本地NameNode运行正常，并且ZKFC发现当前没有其他节点持有znode的锁，则它将自己尝试获取锁。如果成功，它将“赢得选举”，并负责运行故障切换以使其本地NameNode处于Active状态。
故障切换过程:首先，如有必要，前一个Active NameNode将被隔离，然后本地NameNode将转换到Active状态。

HDFS调优

查看DataNode节点内存配置及使用情况
Jps查看Datanode的进程号：

jmap -heap 18153查看堆内存情况：