适用范围与学习目标
本文以 Apache Hadoop 3.4.1 的 HDFS 与 YARN 为基线，面向需要读懂集群拓扑、作业链路和故障影响的新成员。发行版可能改变目录、服务名和默认配置，现场应以实际版本、有效配置与部署清单为准。文中命令是待环境验证的只读示例，本文没有连接或验证真实集群，验证状态保持 PENDING。
学习目标是能把一次文件读取、一次计算提交和一次节点故障分别映射到责任组件。Hadoop 不是单个查询数据库；HDFS 提供文件存储，YARN 分配计算资源，MapReduce、Spark 等引擎负责计算。安装了 Hadoop 客户端也不意味着作业一定写入 HDFS，必须确认 URI 和实际存储连接器。
先划分存储、调度与计算职责
- 文件元数据：主要组件：NameNode；需要回答的问题：路径是否存在、权限是什么、数据块在哪里。
- 文件数据：主要组件：DataNode；需要回答的问题：块是否可读、磁盘是否健康、冗余是否足够。
- 资源调度：主要组件：ResourceManager、NodeManager；需要回答的问题：队列是否允许、容器放在哪里、资源是否可用。
- 应用执行：主要组件：ApplicationMaster、计算引擎进程；需要回答的问题：哪个任务运行、失败如何重试、结果如何提交。
YARN 中 ResourceManager 负责全局资源仲裁，NodeManager 管理节点上的容器，ApplicationMaster 为具体应用协调执行。容器表示获分配的资源与执行环境，并不必然是 Docker 容器。HDFS 和 YARN 可以部署在相同机器上，但服务健康及资源瓶颈需要分开判断。职责依据 Hadoop 3.4.1 YARN 架构。
从一次 HDFS 读取理解数据流
客户端先向 NameNode 请求文件元数据与块位置，再从 DataNode 获取数据；文件内容不经 NameNode 转发。因而“列目录很慢”和“顺序读取很慢”需要不同证据：前者优先关联元数据 RPC、权限和目录规模，后者还要看数据节点、网络及文件布局。
写入时，客户端依据 NameNode 分配的目标建立 DataNode 数据管道。副本数量与放置策略影响可用性和网络成本，不能把节点数量直接等同于故障域数量。采用纠删码的目录还要单独核实策略，不能用副本文件的容量公式解释所有数据。基础流程见 HDFS 架构。
从一次作业提交理解资源等待
业务提交应用后，YARN 需要为 ApplicationMaster 和执行任务安排资源。作业等待不一定意味着集群没有空闲：队列约束、用户限制、节点标签及单容器请求规格都可能阻止放置。计算引擎拿到容器后仍可能等待数据、依赖服务或下游提交，不能把整个耗时都记为调度延迟。
排查时保留 application ID，并把提交、AM 启动、首个任务开始、计算完成、结果可见五个时间点分开。若应用尚未进入实际计算，继续分析 SQL 算子或增大执行并行度通常没有针对性。详细流程可接着阅读 YARN 应用排队与资源瓶颈排查。
用有界只读检查确认实际入口
先从部署清单取得 nameservice、业务目录和应用 ID，替换占位符后再由操作人员按本地权限执行：
hdfs version
hdfs getconf -confKey fs.defaultFS
hdfs dfs -stat '%F %b %r' 'hdfs://REPLACE_WITH_NAMESERVICE/REPLACE_WITH_ONE_FILE'
hdfs dfsadmin -safemode getfs.defaultFS 表明未显式指定 URI 时的默认入口；显式 URI 可以覆盖它，因此两者均要核对。stat 中 %F、%b、%r 分别用于查看对象类型、文件字节数和副本数，示例只针对一份已知的副本存储文件。目录不是文件大小样本；纠删码文件也不能由 %r 推导真实冗余。安全模式结果描述 NameNode 状态，不等同于完整健康报告。命令定义见 Hadoop 文件系统 Shell。
将症状映射为下一份证据
- 已知路径不存在：优先查看：URI、目录归属、发布与删除记录；不能直接得出的结论：HDFS 丢块。
- 目录可见但文件读取失败：优先查看：对应块和 DataNode、客户端网络；不能直接得出的结论：NameNode 必须重启。
- 应用长时间未启动任务：优先查看：AM 状态、队列与请求资源；不能直接得出的结论：SQL 本身低效。
- 多个应用同时读慢：优先查看：数据节点与网络的同窗指标；不能直接得出的结论：扩容内存即可恢复。
这是一套收窄调查范围的方法，不是自动根因判定。对照同时间窗的正常目录或正常应用，可以避免把一份异常客户端配置解释成集群故障。每份证据都记录采样时间、目标身份和工具版本，访问被拒绝时保留原始错误，不将缺失数据填成健康值。
高可用与数据保护分别解决什么
NameNode 高可用降低元数据服务中断风险；DataNode 冗余保护块的可读性；备份和恢复流程处理误删除、损坏与跨故障域灾害。这三件事需要分别验收。副本可以同步保留错误写入，HA 也不能自动撤销业务删除。
SecondaryNameNode 不是可以直接接管的热备。在 QJM HA 部署中，Standby NameNode 跟踪共享 edits，自动切换还依赖 ZooKeeper 与 ZKFC 等机制。不要从进程名称推断已有可靠 HA。拓扑确认后再阅读 Hadoop 高可用与恢复规划，容量和块健康则使用 HDFS 容量与副本健康巡检。
常见误区与容量认识
第一，把 HDFS 当作适合大量随机小更新的本地文件系统。文件布局和访问模式影响性能，应用应明确是否以追加、批处理和分区读取为主。第二，认为磁盘剩余很多就没有扩容压力；大量文件和块还会增加 NameNode 元数据负担。第三，用“一台机器几个服务”绘图，却没有标出机架、网络和供电故障域，容易高估冗余效果。
容量计划同时记录逻辑数据量、物理存储、文件和块增长、恢复期间额外空间，以及计算高峰的资源需求。本文不提供通用安全百分比：保留余量应依据增长曲线、退役计划和恢复窗口制定。小文件问题另见 Hadoop 小文件治理。
验收、停止条件与回退边界
学习与巡检产出应包括一张实际入口图、组件责任表、代表性文件的读取链路和一个作业的阶段时间线。能解释“哪个组件失败会影响哪段业务”才是验收目标；只列出进程名称不够。命令结果只覆盖采样对象，不能宣告整个集群已验证。
只读检查没有数据回滚步骤；若扩大目录检查造成元数据延迟，应停止扩面并保留已有证据。涉及切换、清理、扩容和队列修改时，要在独立变更中定义恢复路径与业务验收，不把架构学习中的推断直接转成运行操作。