第七周假期进度报告（8.24 - 8.30）

一、本周做了什么？
本周延续了上周的Hadoop学习，但重点从环境搭建和命令行操作转向了对HDFS核心架构与原理的深入理解。日均学习时间稳定，代码实践侧重于验证和理解概念。
学习与探究：
学习时长： 保持 日均约2小时。
敲代码/实践： 日均 约1.5小时。核心活动是结合已搭建的完全分布式集群，深入探究HDFS的内部机制：
HDFS 核心概念与组成： 系统梳理了HDFS的架构组件及其职责。重点理解了 客户端 (Client)、主节点NameNode (NN) 和 从节点DataNode (DN) 三者之间的交互关系。明确了HDFS“一次写入，多次读取”的访问模式及其适用场景。
块大小 (Block Size) 深入理解： 不仅知道默认大小是128MB（Hadoop 3.x），更深入探究了其设计背后的权衡：减少磁盘寻道时间、减少NameNode内存消耗（元数据量与文件块数正相关）、简化存储子系统与适合数据局部性优化。同时也理解了块大小并非固定，可根据实际数据特性和集群规模进行配置。
NameNode 的核心作用剖析： 这是本周学习的重中之重。详细学习了NameNode作为“大脑”管理的 元数据 (Metadata) 的具体内容：
文件系统的命名空间（目录树结构、文件/目录信息）。
文件与数据块的映射关系（一个文件对应哪些块）。
每个数据块所在的DataNode列表（块的物理位置）。
镜像文件 (FsImage) 与编辑日志 (Edits) 工作机制： 深入理解了NameNode如何通过 FsImage（内存元数据的持久化检查点） 和 Edits（所有更改操作的日志记录） 这两个关键文件来协同工作，既保证了元数据的安全性，又提升了操作效率。通过查阅文档和配置，明确了 Secondary NameNode 或 CheckpointNode 的角色是定期合并FsImage和Edits，以辅助NameNode恢复，而非热备。
解决问题： 日均耗时 约0.5小时。问题多源于对理论概念的理解偏差：
初期混淆了HDFS的块大小与Linux文件系统的块概念。
理解FsImage和Edits的合并时机与过程时，需要反复对照架构图和时间线。
尝试通过配置文件查找相关参数（如块大小配置dfs.blocksize）以验证理解。
辅导任务： 持续进行 约3个下午 的辅导。
二、下周计划？
目标在理解HDFS原理的基础上，向MapReduce计算框架和资源管理深入。
学习/实践： 保持 日均2小时 学习。
MapReduce 原理深化： 系统学习MapReduce编程模型的工作流程，包括详细的Shuffle阶段（分区、排序、合并）、Combiner优化作用等。
YARN 资源调度： 深入理解YARN作为“集群操作系统”的角色，学习ResourceManager、NodeManager、ApplicationMaster三者如何协作来调度和管理集群资源（CPU、内存）。
实践验证： 在集群上运行更复杂的MapReduce示例程序，通过日志和Web UI观察Shuffle过程和资源分配情况，将理论与实际运行对应起来。
生态工具了解： 开始了解ZooKeeper在Hadoop集群中的作用（如高可用性HA实现）。
辅导： 预计继续 2-3个下午。
三、本周遇到的问题？
概念抽象性： 理解纯架构和原理性的知识（如元数据结构、内存镜像与磁盘日志的同步机制）比学习具体操作命令更为抽象，需要更多的思考和想象，有时需阅读多份资料才能形成清晰的认识。
理论与实践的对应： 虽然知道NameNode管理元数据，但最初很难将“元数据”这个抽象概念具体化为FsImage和Edits这两个物理文件及其内容格式。需要通过文档和示意图建立连接。
SecondaryNameNode 的角色误解： 很容易从其名称误解为NameNode的热备份节点。花费了一些时间才彻底弄清它实质上是执行检查点合并的辅助节点，与高可用性(HA)无关，HA需要通过设置Standby NameNode来实现。
块大小的权衡理解： 理解设置块大小背后的权衡（Trade-off） 是另一个难点。需要跳出“越大越好”或“越小越好”的简单思维，从系统设计角度思考其在不同场景下的优缺点。
学习方式转变： 本周学习方式从“动手做”更多转向了“动脑想”和“看图解”，需要更强的逻辑思维和架构理解能力，初期有些不适应。
总结： 第七周是Hadoop学习的“理论周”，深入研究了HDFS的架构思想、设计权衡与核心组件（特别是NameNode）的工作原理。核心体会：理解底层原理是进行高效运维和性能调优的基石；HDFS的诸多设计（如块大小、元数据管理）都体现了工程上的精巧权衡。下周将转向MapReduce和YARN的深入原理学习与实践，继续夯实大数据基础。潜心钻研！