大数据领域 Hadoop 的集群性能评估指标：从“体检报告”看集群健康度

关键词：Hadoop集群、性能评估、HDFS、YARN、吞吐量、延迟、资源利用率

摘要：本文将带你像“给Hadoop集群做体检”一样，拆解大数据领域最核心的Hadoop集群性能评估指标。我们会从HDFS存储层、YARN计算层、集群整体健康度三个维度，用“快递站”“工厂流水线”等生活案例，解释吞吐量、延迟、CPU/内存利用率等关键指标的含义、测量方法及相互影响，并通过实战案例教你如何用这些指标诊断集群瓶颈，最终让你掌握一套“看指标→找问题→做优化”的完整方法。

---

背景介绍

目的和范围

当你管理一个Hadoop集群时，可能遇到这些困惑：
“为什么凌晨的ETL任务突然变慢了？”
“花大价钱扩容了节点，吞吐量怎么没提升？”
“YARN总是报错资源不足，是配置问题还是硬件瓶颈？”
这些问题的答案，都藏在“集群性能评估指标”里。本文将覆盖Hadoop核心组件（HDFS存储层、YARN计算层）的关键指标，以及集群整体健康度的评估方法，帮助你从“被动救火”转向“主动优化”。

预期读者

• 大数据工程师（需优化集群性能）
• 运维人员（需监控集群健康）
• 数据平台架构师（需规划集群扩容）
• 刚接触Hadoop的开发者（建立性能评估全局观）

文档结构概述

本文将按照“核心概念→指标拆解→实战诊断→未来优化”的逻辑展开：

1. 用“快递站”比喻HDFS，“工厂流水线”比喻YARN，理解Hadoop集群的运行逻辑；
2. 拆解存储层（HDFS）、计算层（YARN）、集群整体的12个核心指标；
3. 通过“日志分析集群变慢”的实战案例，演示如何用指标定位问题；
4. 总结指标间的关联关系，给出优化方向。

术语表

术语	通俗解释
HDFS	Hadoop分布式文件系统，相当于大数据的“云盘”，负责存储海量数据
YARN	Hadoop资源调度器，相当于“工厂调度中心”，负责分配CPU/内存给计算任务
NameNode	HDFS的“管理员”，管理文件元数据（如文件存放在哪个节点）
DataNode	HDFS的“书架”，实际存储文件数据块
Container	YARN分配的“资源容器”，每个任务运行在一个Container里（包含一定CPU/内存）
吞吐量	单位时间能处理的数据量（如“每小时处理10TB日志”）
延迟	任务从开始到完成的时间（如“提交任务后5秒开始运行”）

---

核心概念与联系：用“快递站”和“工厂”理解Hadoop集群

故事引入：一个快递站的运作难题

假设你开了一家“大数据快递站”，每天要处理百万个包裹（数据）：

• 存储区（类似HDFS）：有一个“总调度室”（NameNode）记录每个包裹存放在哪个货架（DataNode），真正的包裹堆在货架上；
• 处理区（类似YARN）：有一个“任务调度中心”（ResourceManager），根据包裹类型（计算任务）分配搬运工（CPU）和推车（内存），搬运工在“操作间”（Container）里处理包裹。

某天，你发现：

• 包裹积压（任务超时），但搬运工（CPU）却在摸鱼；
• 新货架（扩容节点）加了，但取包裹（读HDFS）还是慢；
• 调度中心（ResourceManager）总报错“推车不够”（内存不足）。

要解决这些问题，你需要像“快递站体检”一样，测量存储区的“货架存取速度”、处理区的“搬运工效率”、以及整体的“调度是否合理”——这就是Hadoop集群的性能评估。

核心概念解释（像给小学生讲故事）

概念一：HDFS（分布式文件系统）——大数据的“云盘”

HDFS就像一个超级大的“云盘”，但和你手机里的云盘不同：

• 它把一个大文件切成很多“小数据块”（默认128MB），分散存放在很多台机器（DataNode）的“货架”上；
• 有一个“管理员”（NameNode）专门记笔记：“文件A的块1在机器3，块2在机器5，块3在机器7”。

类比生活：你有一本1000页的书，拆成10本100页的小册子，分别放在你家、邻居家、同学家的书架上，而你手机里存了一张“地址清单”（NameNode的元数据），需要看某一页时，根据清单去对应的家里取。

概念二：YARN（资源调度器）——工厂的“任务调度中心”

YARN是Hadoop的“大管家”，负责给各种计算任务（如MapReduce、Spark）分配资源：

• 它有一个“总调度室”（ResourceManager），记录集群里所有机器的CPU/内存总量；
• 每个机器有一个“现场主管”（NodeManager），汇报当前机器剩余多少CPU/内存；
• 当你提交一个任务（比如“统计日志里的错误次数”），ResourceManager会根据任务需求，分配若干个“操作间”（Container），每个操作间有固定的CPU核数和内存大小。

类比生活：工厂有100个工人（CPU核）和200辆推车（内存），调度中心（YARN）接到“组装1000台手机”的任务后，会分配50个工人+100辆推车给这个任务，确保工人不闲置、推车不浪费。

概念三：性能评估指标——集群的“体检报告”

性能评估指标就像给集群做“体检”的各项参数，比如：

• 存储区（HDFS）的“货架存取速度”（读写吞吐量）；
• 处理区（YARN）的“工人效率”（CPU利用率）；
• 整体的“是否生病”（是否有节点宕机）。

类比生活：你去医院体检，医生会测血压（类似延迟）、血常规（类似资源利用率）、心电图（类似节点健康），通过这些指标判断你是否健康——Hadoop集群的“体检”同理。

核心概念之间的关系：快递站的“存储-处理-健康”三角

• HDFS和YARN的关系：HDFS是“仓库”，YARN是“工厂”。工厂要加工产品（计算任务），必须从仓库（HDFS）取原材料（数据）；如果仓库存取慢，工厂再快也没用；如果工厂效率低，仓库存再多也浪费。
• 性能指标与HDFS/YARN的关系：指标是“体检参数”，用来诊断仓库（HDFS）和工厂（YARN）的问题。比如“HDFS读延迟高”可能是仓库货架（DataNode）的硬盘慢；“YARN容器等待时间长”可能是工厂调度中心（ResourceManager）分配资源不合理。

类比生活：快递站的存储区（HDFS）和处理区（YARN）就像超市的“仓库”和“收银台”。仓库进货慢（HDFS写吞吐量低），收银台再快（YARN处理快）也会没货可卖；收银台排队长（YARN任务延迟高），仓库货再多（HDFS存储量大）也卖不出去。

核心概念原理和架构的文本示意图

Hadoop集群架构（简化版）
├─ HDFS存储层
│  ├─ NameNode（管理员：管理元数据）
│  └─ DataNode（货架：存储数据块，副本机制保证可靠性）
├─ YARN计算层
│  ├─ ResourceManager（总调度：分配集群资源）
│  └─ NodeManager（现场主管：管理单个节点的Container）
└─ 性能评估指标（体检参数）
   ├─ HDFS指标（存储效率）
   ├─ YARN指标（计算效率）
   └─ 集群整体指标（健康度）

Mermaid 流程图：Hadoop任务执行与指标关联

---

核心指标拆解：从存储到计算，12个关键评估点

一、存储层（HDFS）的核心指标：仓库的“存取效率”

HDFS的主要职责是存储和读取数据，评估它的性能，就像评估一个仓库的“进货速度”“出货速度”和“货架可靠性”。

1. 读写吞吐量（MB/s）

定义：单位时间内HDFS能写入或读取的数据量（比如“写吞吐量100MB/s”表示每秒能存100MB数据）。
为什么重要：如果写吞吐量低，ETL任务（比如从数据库导数据到HDFS）会变慢；读吞吐量低，计算任务（如Spark SQL查询）会卡在“等数据”上。
如何测量：

• 用HDFS自带命令：hdfs dfs -put testfile /path（写测试），hdfs dfs -get /path/testfile（读测试），记录耗时并计算吞吐量（文件大小/时间）。
• 用基准测试工具hadoop fs -benchmark -write 10 1024（生成10个1GB文件，测写吞吐量）。

类比生活：仓库的“进货口”每秒能搬多少箱货物（写吞吐量），“出货口”每秒能搬多少箱（读吞吐量）。如果进货口只能搬10箱/秒，而你有1000箱要存，就需要100秒，这显然太慢了。

2. 读写延迟（ms）

定义：从发起读/写请求到完成的时间（比如“读延迟50ms”表示点一下“下载”，50ms后数据开始传输）。
为什么重要：低延迟是实时计算（如实时日志分析）的关键。比如你想实时统计“最近1分钟的错误日志”，如果读HDFS延迟很高，统计结果就会滞后。
如何测量：

• 用hdfs dfs -cat /path/smallfile（读小文件测延迟），用time命令记录耗时（如time hdfs dfs -cat /test/small.txt）。
• 观察NameNode日志（/var/log/hadoop-hdfs/hadoop-hdfs-namenode-*.log），其中FsImage或EditLog的操作时间可反映元数据操作延迟。

类比生活：你去仓库找一个小箱子（小文件），如果管理员（NameNode）查笔记（元数据）要10秒，然后跑去找货架（DataNode）要20秒，总延迟就是30秒——这比“搬大货”（大文件吞吐量）更影响体验。

3. 副本复制时间（s）

定义：当DataNode宕机或数据块损坏时，HDFS会自动复制副本到其他节点，复制所需的时间。
为什么重要：副本复制是HDFS高可用的核心机制。如果复制时间过长，集群在节点故障时可能长时间处于“不可靠状态”，甚至导致数据丢失。
如何测量：

• 手动模拟节点故障（如停掉一个DataNode），观察HDFS日志中BlockManager的replicateBlock操作时间。
• 通过HDFS Web UI（http://namenode:50070）查看“Under-replicated blocks”（欠副本块）的数量和恢复时间。

类比生活：仓库规定每个货物必须有3个备份（HDFS默认副本数3）。如果一个货架（DataNode）塌了，需要把货物复制到另外两个货架，这个复制过程的时间就是“副本复制时间”。如果复制太慢，新的订单（计算任务）可能因为“找不到足够的副本”而失败。

4. DataNode磁盘利用率（%）

定义：单个DataNode已用磁盘空间占总空间的比例（如“80%”表示磁盘用了80%）。
为什么重要：磁盘利用率过高（>90%）会导致写操作变慢（磁盘碎片增加），甚至触发HDFS的“节点不可用”机制（防止磁盘写满）。
如何测量：

• HDFS Web UI的“Datanodes”页面，查看每个节点的“Used”和“Capacity”。
• 用命令hdfs dfsadmin -report，输出中“DFS Used%”即为整体磁盘利用率。

类比生活：仓库每个货架（DataNode）的“已用空间”不能超过90%，否则新货物（数据块）没地方放，或者找货物（读数据）时因为货架太挤，速度变慢。

---

二、计算层（YARN）的核心指标：工厂的“流水线效率”

YARN负责调度CPU、内存等资源给计算任务，评估它的性能，就像评估工厂的“工人效率”“流水线是否堵塞”。

5. 任务调度延迟（ms）

定义：从任务提交到YARN分配第一个Container的时间（比如“调度延迟2秒”表示任务提交后2秒才开始运行）。
为什么重要：高调度延迟会导致任务整体耗时增加，尤其是短任务（如Ad-hoc查询）的体验变差。
如何测量：

• YARN Web UI（http://resourcemanager:8088）的“Application Timeline”页面，查看“Submitted”到“Running”的时间差。
• 查看ResourceManager日志（/var/log/hadoop-yarn/yarn-yarn-resourcemanager-*.log）中的ApplicationMaster启动时间。

类比生活：工厂接到订单（任务）后，调度中心（ResourceManager）需要分配工人（CPU）和推车（内存）。如果调度中心查库存（可用资源）太慢，或者工人都在忙其他订单，新订单就会“排队”，导致延迟。

6. Container资源利用率（CPU%/内存%）

定义：每个Container中CPU和内存的使用比例（如“CPU利用率80%”表示Container的CPU核有80%在工作）。
为什么重要：

• CPU利用率低（<30%）：说明资源浪费，任务没充分用CPU，可能是任务逻辑简单或并行度不够；
• 内存利用率高（>90%）：可能导致OOM（内存溢出）错误，任务失败。
  如何测量：
• YARN Web UI的“Application”详情页，查看每个Container的“CPU Used”和“Memory Used”。
• 用命令yarn application -status <app_id>，输出中“Allocated MB-seconds”和“Allocated vcore-seconds”可计算平均利用率。

类比生活：工厂给每个订单分配了10个工人（CPU核）和20辆推车（内存）。如果订单实际只用了3个工人（CPU利用率30%），说明工人闲置；如果用了19辆推车（内存利用率95%），可能下一秒就会因为推车不够（内存不足）而停工。

7. 任务失败率（%）

定义：一定时间内失败的任务数占总任务数的比例（如“失败率5%”表示100个任务有5个失败）。
为什么重要：高失败率可能是资源分配不合理（如内存不足）、数据损坏（HDFS块丢失）或任务逻辑错误（如代码bug）。
如何测量：

• YARN Web UI的“Applications”页面，统计“FAILED”状态的任务数。
• 结合HDFS的“Under-replicated blocks”和YARN的“Container killed”日志（如Container killed by YARN for exceeding memory limits）分析原因。

类比生活：工厂订单（任务）总是失败，可能是因为：

• 推车（内存）太小，装不下货物（数据）；
• 工人（CPU）太少，干不完活（计算量太大）；
• 原材料（HDFS数据）缺斤少两（块丢失）。

8. 资源碎片率（%）

定义：集群中无法被分配的“小资源块”占总资源的比例（如“碎片率20%”表示20%的资源因为太小，无法满足任何任务的需求）。
为什么重要：资源碎片会导致“有资源但分不出去”的情况。例如，集群有10GB内存，但被分成5个2GB的碎片，而任务需要4GB，就会无法分配。
如何测量：

• 计算方式：碎片率 = 1 - (最大连续可用资源 / 总可用资源)。
• 通过ResourceManager的REST API（http://resourcemanager:8088/ws/v1/cluster/metrics）获取总可用资源，结合NodeManager的资源汇报（http://nodemanager:8042/node）分析碎片。

类比生活：工厂有100辆推车，但被分成了10个10辆的组（碎片）。如果订单需要15辆推车，就会因为没有连续的15辆而无法开工——虽然总共有100辆，但实际可用的是“最大的连续组”（10辆）。

---

三、集群整体健康度指标：快递站的“是否生病”

除了存储和计算的效率，集群的“健康状态”也至关重要，就像人体的“体温”“心跳”，异常可能预示严重问题。

9. 节点存活数（个）

定义：当前正常运行的DataNode和NodeManager数量（HDFS默认需要至少1个NameNode+多个DataNode，YARN需要1个ResourceManager+多个NodeManager）。
为什么重要：节点宕机（存活数下降）会导致：

• HDFS数据不可用（如果宕机的DataNode包含唯一副本）；
• YARN无法分配资源（任务排队或失败）。
  如何测量：
• HDFS Web UI的“Datanodes”页面，查看“Live Nodes”数量；
• YARN Web UI的“Nodes”页面，查看“Active Nodes”数量。

类比生活：快递站的货架（DataNode）和搬运工（NodeManager）如果突然病倒（宕机），仓库可能没地方放货（HDFS写失败），或者没人搬货（YARN任务无法运行）。

10. GC时间占比（%）

定义：JVM垃圾回收（GC）时间占总运行时间的比例（如“GC占比20%”表示20%的时间在清理内存垃圾）。
为什么重要：Hadoop的NameNode、ResourceManager等组件基于Java，GC时间过长会导致服务响应变慢（如NameNode处理元数据请求延迟）。
如何测量：

• 查看组件日志（如NameNode的hadoop-hdfs-namenode-*.log）中的GC日志，用gceasy.io等工具分析。
• 关键指标：Full GC次数（频繁Full GC是严重问题）、GC暂停时间（单次GC导致的服务停顿）。

类比生活：工厂的调度中心（ResourceManager）需要定期清理办公室（JVM内存）的废纸（无用对象）。如果清理时间太长（GC占比高），调度员（线程）就没时间处理新订单（任务请求），导致延迟。

11. 网络带宽利用率（%）

定义：集群节点间网络传输的带宽占用比例（如“带宽利用率80%”表示网络有80%的带宽在传输数据）。
为什么重要：HDFS数据块复制、YARN Container间通信都需要网络。带宽不足会导致：

• HDFS副本复制慢；
• MapReduce的shuffle阶段（数据从Map端传到Reduce端）延迟高。
  如何测量：
• 用iftop或nload工具监控节点的网络接口（如eth0）；
• Hadoop的NodeManager日志中，Container的“Network Usage”指标可反映任务的网络消耗。

类比生活：快递站的“内部道路”（网络）如果堵车（带宽利用率高），货车（数据）从货架（DataNode）到处理区（YARN Container）的时间就会变长，整个快递站效率下降。

12. 磁盘IOPS（次/秒）

定义：磁盘每秒能处理的输入输出操作数（如“IOPS 100”表示每秒能读写100次）。
为什么重要：HDFS的DataNode依赖磁盘存储数据块，YARN的Container日志也存磁盘。低IOPS会导致：

• DataNode写数据块慢（HDFS写延迟高）；
• NodeManager写Container日志慢（任务日志丢失或延迟）。
  如何测量：
• 用iostat工具（如iostat -x 1）查看磁盘的r/s（读次数）和w/s（写次数）；
• 结合DataNode的dfs.datanode.handler.count配置（处理IO的线程数），如果线程数不足，会导致IO请求排队。

类比生活：仓库货架（DataNode）的“取货窗口”每秒能处理多少个取货请求（IOPS）。如果窗口每秒只能处理10个请求，而同时有100个取货需求，就会排长队（延迟高）。

---

数学模型与公式：用数字量化性能

吞吐量与延迟的关系

吞吐量（Throughput）和延迟（Latency）是一对“跷跷板”，通常满足：
$$Throughput=\frac{DataSize}{Latency}$$
举例：一个任务读取100MB数据，耗时2秒，则读吞吐量为：
$$\frac{100MB}{2s}=50MB/s$$

资源利用率的计算

CPU利用率（CPU%）和内存利用率（Memory%）的计算公式：
$$CPU\%=\frac{UsedCPU}{TotalCPU}\times 100\%$$
$$Memory\%=\frac{UsedMemory}{TotalMemory}\times 100\%$$
举例：某节点有8核CPU，当前有6核在运行任务，则CPU利用率为：
$$\frac{6}{8}\times 100\%=75\%$$

碎片率的数学表达

资源碎片率（Fragmentation%）反映资源的连续性，公式为：
$$Fragmentation\%=\left(1-\frac{MaxContiguousResource}{TotalAvailableResource}\right)\times 100\%$$
举例：集群可用内存100GB，但最大连续可用内存是20GB，则碎片率为：
$$\left(1-\frac{20}{100}\right)\times 100\%=80\%$$

---

项目实战：日志分析集群变慢的诊断

场景描述

某公司的Hadoop集群用于处理每天100TB的日志数据，最近用户反馈“日志统计任务从30分钟延长到1小时”，需要通过性能指标定位问题。

步骤1：收集核心指标（工具推荐）

• HDFS指标：用HDFS Web UI查看读写吞吐量（50MB/s→30MB/s）、DataNode磁盘利用率（平均85%→92%）、副本复制时间（5分钟→15分钟）；
• YARN指标：用YARN Web UI查看任务调度延迟（2秒→10秒）、Container CPU利用率（70%→40%）、任务失败率（1%→5%）；
• 集群整体：用iostat发现DataNode磁盘IOPS（200→100），用iftop发现网络带宽利用率（60%→90%）。

步骤2：指标关联分析

• HDFS写吞吐量下降：DataNode磁盘利用率超90%，磁盘碎片增加，导致写IO变慢；
• YARN调度延迟增加：部分NodeManager内存不足（任务失败率上升），ResourceManager需要频繁重新分配Container；
• 网络带宽高：HDFS在自动复制副本（因为磁盘满导致部分DataNode不可用），占用了大量带宽，影响计算任务的shuffle阶段。

步骤3：优化措施

• HDFS层面：扩容DataNode节点，降低磁盘利用率（从92%→70%）；调整dfs.datanode.du.reserved参数（预留磁盘空间防止写满）；
• YARN层面：调整yarn.scheduler.minimum-allocation-mb（最小内存分配），减少资源碎片；增加yarn.nodemanager.resource.memory-mb（单节点内存总量）；
• 网络层面：限制HDFS副本复制的带宽（通过dfs.datanode.balance.bandwidthPerSec参数），优先保证计算任务的网络需求。

步骤4：效果验证

优化后：

• HDFS读吞吐量从30MB/s恢复到80MB/s；
• YARN调度延迟从10秒降到2秒；
• 任务耗时从1小时缩短到25分钟，失败率回到1%以下。

---

实际应用场景

场景	关键指标	优化方向
实时日志分析	HDFS读延迟、YARN调度延迟	降低HDFS读延迟（缓存小文件）、优化YARN调度策略（优先短任务）
批量ETL数据导入	HDFS写吞吐量、DataNode磁盘利用率	提高写吞吐量（调整块大小、多线程写入）、避免磁盘过满
机器学习训练	YARN Container内存利用率、网络带宽	分配大内存Container（避免OOM）、保证shuffle阶段带宽
集群扩容规划	节点存活数、资源碎片率	预测资源增长（如CPU/内存需求）、选择合适的节点配置（平衡磁盘/内存）

---

工具和资源推荐

类别	工具/资源	功能描述
指标监控	Ambari	Hadoop集群可视化监控（HDFS/YARN指标一目了然）
	Ganglia	轻量级集群监控（实时绘制CPU/内存/网络图表）
	Prometheus+Grafana	自定义指标监控（可结合Hadoop Exporter采集指标）
基准测试	HDFS Benchmark	测HDFS读写吞吐量、延迟（hadoop fs -benchmark）
	YARN Load Generator	模拟YARN任务压力（测调度延迟、资源利用率）
日志分析	Logstash+Elasticsearch	聚合Hadoop组件日志（快速定位GC、节点宕机问题）
调优文档	Hadoop官方文档（YARN Scheduler）	学习CapacityScheduler/FairScheduler配置

---

未来发展趋势与挑战

• 云原生Hadoop：随着Hadoop上云（如AWS EMR、阿里云E-MapReduce），性能指标将增加“云资源”维度（如EC2实例类型、云盘IOPS）；
• AI驱动调优：通过机器学习预测集群负载（如“今晚8点ETL任务量会增加30%”），自动调整YARN资源分配策略；
• 异构计算支持：GPU/TPU加入Hadoop集群，需要新增“GPU利用率”“计算任务与GPU匹配度”等指标。

---

总结：学到了什么？

核心概念回顾

• HDFS：大数据的“云盘”，关键指标是读写吞吐量、延迟、副本复制时间；
• YARN：资源调度的“工厂”，关键指标是调度延迟、Container利用率、资源碎片率；
• 集群健康：节点存活数、GC时间、网络/磁盘IOPS是“体检的生命体征”。

概念关系回顾

• HDFS和YARN是“存储-计算”的协作关系，存储慢会拖慢计算，计算资源不足会浪费存储；
• 性能指标是“诊断工具”，通过关联分析（如“磁盘利用率高→写吞吐量低→任务延迟”）可定位瓶颈。

---

思考题：动动小脑筋

1. 如果你发现HDFS读吞吐量低，但DataNode磁盘IOPS正常，可能的原因是什么？（提示：考虑网络或NameNode）
2. YARN的Container内存利用率总是100%，但任务没报错，这是好事还是坏事？应该如何调整？（提示：内存溢出风险）
3. 集群扩容后，HDFS写吞吐量没提升，可能是哪些指标没优化到位？（提示：DataNode数量、网络带宽）

---

附录：常见问题与解答

Q：HDFS的NameNode CPU利用率100%，怎么办？
A：NameNode负责元数据操作（如创建文件、删除文件），高CPU可能是元数据操作频繁（如大量小文件）。优化方法：合并小文件（用hadoop archive）、调整dfs.namenode.handler.count（增加处理线程数）。

Q：YARN任务总是报“Container killed by YARN for exceeding memory limits”，怎么办？
A：这是内存溢出错误。解决方法：

1. 调大Container内存（yarn.app.mapreduce.am.resource.mb）；
2. 优化任务逻辑（如减少中间数据量）；
3. 检查是否有内存泄漏（如循环中未释放对象）。

Q：如何判断集群瓶颈是CPU、内存还是磁盘？
A：用“指标三角法”：

• CPU利用率高（>80%）、内存利用率低（<50%）→ CPU瓶颈；
• 内存利用率高（>90%）、Swap使用增加→ 内存瓶颈；
• 磁盘IO等待时间（iostat的%await）高→ 磁盘瓶颈。

---

扩展阅读 & 参考资料

• 《Hadoop权威指南（第4版）》——Tom White（HDFS/YARN核心原理）
• Hadoop官方文档：HDFS Metrics、YARN Metrics
• 博客：《Hadoop集群性能调优实战》——大数据技术社区（案例解析）