企业官网建设流程全解析

简介：这份Hadoop综述PPT面向大数据入门学习者与分布式系统初学者，系统梳理Hadoop核心生态的三大支柱，帮助读者建立从存储到计算再到列式数据库的整体认知框架。资源为单个PPT文件，压缩包约1.03MB，内容以HDFS分布式文件系统、MapReduce计算模型与HBase简单介绍为主线，其中HDFS部分涵盖设计目标、数据块机制、NameNode与DataNode主从模型、命名空间映像与修改日志等要点，MapReduce部分涉及基础概念、数据流与工作原理，HBase部分则介绍数据模型及行、列、时间戳与API。目前已有32人学习浏览，适合作为课堂讲义或自学提纲，帮助读者快速把握Hadoop各组件的定位与协作关系，为后续深入实践打下概念基础。

1. 从一份 Hadoop 综述 PPT 说起：为什么它值得你花时间拆一遍

很多人第一次接触大数据，是从一份 Hadoop 综述 PPT 开始的。它不像官方文档那样铺满配置项，也不像源码那样劝退，而是用几十页把 HDFS、MapReduce、HBase 三大件串成一条线。我手里这份《Hadoop综述.ppt》就是典型：第一篇讲 HDFS 分布式文件系统，第二篇讲 MapReduce，第三篇简单介绍 HBase。它解决的不是“怎么装”，而是“这三块到底怎么咬合在一起”。适合谁？正在做 hadoop 课程设计、准备 hadoop 面试题、或者刚搭完 hadoop 伪分布式搭建却说不清内部机制的人。如果你只会敲 hdfs 常用命令，却答不上 hdfs 读写流程，这份 PPT 能帮你把概念补成体系。下面我按它的结构，把每一篇拆成能复现、能排错的实战笔记。

2. HDFS 篇：从 blocks 到 NameNode 持久化状态，把存储骨架讲透

2.1 为什么 HDFS 要按 block 切，而不是按文件存

PPT 里写得很直接：files in HDFS are broken into block-sized chunks，默认 64 MB。这个设计不是为了好看，而是为了三件事。第一，减少元数据量——NameNode 只记 block 到 DataNode 的映射，不用记整个文件。第二，有利于顺序读写，block 在磁盘上顺序存放，流式读为主，高吞吐量比低延迟更重要。第三，一个文件可以大于网络中任何单块磁盘，抽象单位是 block 而不是文件，存储子系统就简化了。

副本默认数目是 3，这是 HDFS 可靠性的底线。PPT 里提到“块进行复制的形式放置，按照块的方式随机选择存储节点”，实际生产中副本因子可以在创建文件时指定，但默认 3 是经过验证的平衡点。副本少了，节点故障就丢数据；副本多了，写放大和存储成本都上去。

提示：block 大小不是越大越好。64 MB 是这份 PPT 时代的默认值，后来社区常见 128 MB，但原理不变——大 block 减少寻址开销，小 block 提高并行度，选型要看你的平均文件大小。

2.2 NameNode 和 DataNode 的心跳机制与基本模型

PPT 把基本模型概括为 Master / Slaves / Client，对应实现是 NameNode、DataNodes、DFSClient。NameNode 管理文件系统命名空间，元数据包括文件信息、根目录 hdfs://master:9000/、每个文件对应的文件块信息、每个文件块在 DataNode 的信息。DataNode 是文件存储的基本单元，保存 block 的 Meta-data，周期性地将所有 Block 信息发送给 NameNode。

心跳机制是这套模型的命脉。DataNode 定期向 NameNode 发心跳，NameNode 靠心跳判断节点存活。PPT 里有一句关键：心跳信号传递信息（并不存储在硬盘）——一个文件包括哪些数据块，分布在哪些数据节点上，系统启动的时候从 Datanode 收集而成。这意味着 NameNode 重启后，block 位置信息是重新构建的，不是从磁盘读出来的。

查看块信息可以用 PPT 里提到的命令：

hadoop fsck / -files -blocks

这条命令会列出文件、块和块所在节点。逻辑说明：fsck是文件系统检查工具，-files显示文件级信息，-blocks显示块级信息。参数说明：路径/表示从根目录开始检查，生产环境建议指定具体路径，避免全盘扫描拖慢 NameNode。如果输出里出现 MISSING 或 UNDER_REPLICATED，说明副本有问题，需要查 DataNode 日志。

2.3 NameNode 的持久化状态：fsimage、edits 和 VERSION 文件

PPT 花了很大篇幅讲 NameNode 的持久化状态，这是 HDFS 最容易被忽略但面试最爱问的部分。对于任何对文件元数据产生修改的操作，NameNode 都使用一个称为 Editlog 的事务日志记录下来。比如在 HDFS 中创建一个文件（打开、关闭、重命名文件和目录），NameNode 就会在 Editlog 中插入一条记录；修改文件的 replication 因子也会往 Editlog 插入记录。整个文件系统的 namespace，包括 block 到文件的映射、文件的属性，都存储在称为 FsImage 的文件中。

NameNode 启动流程 PPT 写得很清楚：从映像文件 fsimage 中读取 HDFS 的状态，接着应用日志文件中的 edits 操作，新的 HDFS 状态写入 fsimage 中，然后使用一个空的 edits 文件开始正常操作。写操作成功之前，修改日志都会同步到文件系统。fsimage 是内存中的元数据在硬盘上的 checkpoint，NameNode 只有在启动阶段合并 fsimage 和 edits，所以日志文件会变大。

Namenode 文件夹结构里有个 VERSION 文件，是 java properties 文件，保存了 HDFS 的版本号。PPT 给出了具体字段：

PPT 里给了一个示例：namespaceID=1232737062，cTime=0，storageType=NAME_NODE，layoutVersion=-18。这些值在格式化 NameNode 时生成，如果 layoutVersion 不匹配，DataNode 会拒绝连接。常见做法是：集群升级时先确认所有节点的 layoutVersion 一致，否则会出现 DataNode 启动后立刻关闭的玄学问题。

2.4 DataNode 的文件夹结构和 block 元数据

DataNode 的文件夹结构 PPT 也给了：blk_ 保存的是 HDFS 的数据块，其中保存了具体的二进制数据；blk_ .meta 保存的是数据块的属性信息，包括版本信息、类型信息和 checksum。目录中数据块到达一定数量，会创建子文件夹。

这个设计是为了避免单目录文件过多导致性能下降。我一般会这样验证 DataNode 的存储结构：

# 进入 DataNode 数据目录，路径取决于 dfs.datanode.data.dir 配置 cd /opt/hadoop/data/dfs/data/current # 查看 block 文件和 meta 文件 ls -lh blk_* # 查看 meta 文件内容，确认 checksum 和版本 cat blk_1234567890.meta | head -c 200

逻辑说明：ls -lh列出 block 文件大小，cat查看 meta 文件头部。参数说明：blk_*通配符匹配所有块文件，head -c 200只取前 200 字节避免刷屏。如果 meta 文件缺失，DataNode 会认为块损坏，触发副本复制。常见坑是手动删除 blk 文件但忘了删 meta，导致 DataNode 报 checksum 错误。

3. MapReduce 篇：数据流和工作原理，别只背概念

3.1 MapReduce 基础：为什么需要移动计算而不是移动数据

PPT 第二篇标题是 MapReduce，下面分 MapReduce 基础、MapReduce 数据流、MapReduce 工作原理。基础部分的核心思想是移动计算。HDFS 设计里提到“移动计算”，Java 编写，在异构软硬件平台间可移植。MapReduce 把计算推到数据所在的节点，而不是把 TB 级数据拉到计算节点。

这个选择的原因很实在：网络带宽是稀缺资源，磁盘顺序读吞吐远高于跨机架网络传输。PPT 里 HDFS 设计目标写着“适合 MapReduce 框架，或者 web crawler”，就是因为 MapReduce 的输入通常是 HDFS 上的大文件，分片后每个 map 任务处理一个 block，尽量在本地读。

常见做法是：map 任务优先调度到数据所在节点，如果不行，退而求其次到同机架节点。这个调度策略在 Hadoop 里叫 data locality，是 MapReduce 性能的关键。如果你发现 map 任务耗时远大于预期，先查是不是数据本地化率太低。

3.2 MapReduce 数据流：从 InputSplit 到 OutputFormat

PPT 把数据流单独列为一节，说明它重要。MapReduce 数据流大致是：输入分片 InputSplit → RecordReader → map → partition → sort → spill → merge → reduce → OutputFormat。每一步都有可调参数。

我一般用 WordCount 来验证数据流是否正常：

# mapper.py import sys for line in sys.stdin: line = line.strip() words = line.split() for word in words: # 输出 key 和计数 1，key 和 value 用 tab 分隔 print(f"{word}\t1")

# reducer.py import sys from collections import defaultdict counts = defaultdict(int) for line in sys.stdin: word, count = line.strip().split("\t") counts[word] += int(count) for word, count in counts.items(): print(f"{word}\t{count}")

逻辑说明：mapper 逐行读取，拆分单词，输出word\t1；reducer 按 key 累加。参数说明：Hadoop Streaming 要求 key 和 value 默认用 tab 分隔，所以print里用\t。如果换成空格，reducer 解析会失败。运行命令：

hadoop jar /opt/hadoop/share/hadoop/tools/lib/hadoop-streaming-*.jar \ -input /user/input/words.txt \ -output /user/output/wordcount \ -mapper mapper.py \ -reducer reducer.py \ -file mapper.py \ -file reducer.py

参数说明：-input指定 HDFS 输入路径，-output指定输出路径且必须不存在，-mapper和-reducer指定脚本，-file把脚本分发到集群节点。常见坑是输出目录已存在，Hadoop 会直接报错退出，不会覆盖。

3.3 MapReduce 工作原理：shuffle 是黑匣子也是性能瓶颈

PPT 把工作原理单独一节，核心在 shuffle。map 输出先写入环形缓冲区，默认 100 MB，达到阈值 spill 到磁盘，spill 前按 partition 和 key 排序。reduce 阶段拉取对应 partition 的数据，归并排序后交给 reduce 函数。

shuffle 是黑匣子，也是血泪经验最多的地方。常见调优参数：

如果 reduce 卡在 shuffle 阶段，先看是不是数据倾斜——某个 key 的记录数远超其他 key。PPT 里没展开数据倾斜，但这是 MapReduce 编程实例里最常见的翻车点。解决办法是在 map 端加随机前缀打散 key，或者用 combiner 预聚合。

4. HBase 篇：数据模型和行列时间戳，别把它当关系库用

4.1 HBase 简介：面向列的分布式数据库

PPT 第三篇是 HBase 简单介绍，分简介、数据模型、行、列、时间戳、API。HBase 建立在 HDFS 之上，提供随机读写能力，弥补 HDFS 不支持随机写的短板。它面向列，适合稀疏数据，表可以很大，行数可以上亿。

HBase 和关系库的核心区别：关系库强调范式、join、事务；HBase 强调列族、row key 设计、水平扩展。如果你拿 HBase 当 MySQL 用，设计 join 查询，一定会踩坑。常见做法是：先确定 row key，再确定列族，列族数量控制在 1 到 3 个，因为列族多了会影响 flush 和 compaction。

4.2 HBase 数据模型：行、列、时间戳和 API

PPT 把数据模型拆成行、列、时间戳、API。行由 row key 唯一标识，按字典序排序。列归属于列族，列族是存储和权限的基本单位。时间戳是版本号，默认取当前时间，每个单元格可以保留多个版本。

用 Java 操作 HBase 的典型代码：

// 创建 HBase 配置 Configuration conf = HBaseConfiguration.create(); // 指定 ZooKeeper 地址，HBase 依赖 ZooKeeper 做协调 conf.set("hbase.zookeeper.quorum", "master,slave1,slave2"); conf.set("hbase.zookeeper.property.clientPort", "2181"); // 获取连接 Connection connection = ConnectionFactory.createConnection(conf); // 获取表对象 Table table = connection.getTable(TableName.valueOf("student")); // 构造 Put 对象，row key 为 001 Put put = new Put(Bytes.toBytes("001")); // 列族 info，列 name，值 zhangsan put.addColumn(Bytes.toBytes("info"), Bytes.toBytes("name"), Bytes.toBytes("zhangsan")); // 写入 table.put(put); // 关闭资源 table.close(); connection.close();

逻辑说明：先建配置，指定 ZooKeeper 集群，再拿连接和表，构造 Put 写入。参数说明：hbase.zookeeper.quorum是 ZooKeeper 节点列表，hbase.zookeeper.property.clientPort默认 2181。常见坑是 ZooKeeper 地址写错或端口不通，报 Connection refused。HBase 端口清单里，Master 默认 16000，RegionServer 默认 16020，ZooKeeper 默认 2181，排查时先 telnet 这些端口。

4.3 HBase 表设计和 row key 设计：头歌实验里最容易丢分的地方

头歌 HBase 表设计和数据操作答案里，高频考点是 row key 设计。row key 按字典序排序，所以设计时要考虑查询模式。比如查询某学生某科成绩，row key 可以是学生ID+科目，这样同一学生的记录连续存储，scan 效率高。

常见反模式：用时间戳做 row key 前缀，导致热点写入——所有新数据都写到同一 Region。解决办法是加盐或哈希前缀。PPT 里没展开，但这是 HBase 开发使用 Java 操作 HBase 时必须知道的。

注意：HBase 的列族名和列名在 Java API 里都是 byte 数组，用Bytes.toBytes()转换。直接传字符串会编译报错，这是新手最常见的翻车点。

5. 避坑与排查：HDFS、MapReduce、HBase 联调时最容易翻车的五件事

5.1 现象：DataNode 启动后立刻关闭，日志报 layoutVersion 不匹配

原因：NameNode 格式化后 layoutVersion 变了，DataNode 的 VERSION 文件还是旧版本。解决：删除 DataNode 数据目录重新格式化，或者统一集群所有节点的 Hadoop 版本。PPT 里 VERSION 文件字段 layoutVersion 是负整数，格式版本号不一致就会拒绝连接。

5.2 现象：MapReduce 任务卡在 map 100% 或 reduce 100% 不动

原因：map 100% 通常是 shuffle 没开始，reduce 拉不到数据；reduce 100% 通常是输出阶段卡住。先看 JobTracker 或 ResourceManager 日志，再查网络和磁盘。常见做法是调大mapreduce.reduce.shuffle.parallelcopies，或者检查是否有数据倾斜。

5.3 现象：HBase 写入报 RegionTooBusyException

原因：单个 Region 写入压力过大，通常是 row key 设计导致热点。解决：重新设计 row key，加随机前缀或哈希，让写入分散到多个 Region。PPT 里 HBase 数据模型强调行按字典序排序，热点问题就出在这里。

5.4 现象：hdfs 常用命令执行报 SafeModeException

原因：NameNode 处于安全模式，通常是启动后等待 DataNode 上报块信息。解决：等待自动退出，或者手动hdfs dfsadmin -safemode leave。如果一直不退出，查 DataNode 是否全部启动，块副本是否达到最小阈值。

5.5 现象：Hadoop 伪分布式搭建后，hdfs 和 mapreduce 综合实训跑不通

原因：伪分布式下 DataNode 和 NameNode 在同一节点，但配置里dfs.replication默认 3，实际只有 1 个 DataNode，副本永远达不到 3。解决：伪分布式把dfs.replication改成 1。这是头歌 HDFS 和 MapReduce 综合实训里最常见的配置坑。

6. 进阶技巧：用 distcp 做集群间数据迁移，以及验证 HDFS 读写流程

6.1 hadoop distcp 参数说明和实战

PPT 没提 distcp，但这是 HDFS 运维的必备工具。集群间迁移数据用 distcp，底层是 MapReduce 任务，并行复制。

hadoop distcp \ -m 20 \ -bandwidth 100 \ -log /user/logs/distcp.log \ hdfs://source-cluster:9000/user/data \ hdfs://target-cluster:9000/user/data

逻辑说明：-m 20指定 20 个 map 任务并行复制，-bandwidth 100限制每个 map 的带宽为 100 MB/s，-log指定日志路径。参数说明：-m越大并行度越高，但会占更多网络和磁盘 IO；-bandwidth单位是 MB/s，不设则不限速。常见坑是源和目标集群的 Hadoop 版本不一致，distcp 会报错，需要加-skipcrccheck或升级版本。

6.2 验证 HDFS 读写流程是否正常

PPT 里 HDFS 读写流程没展开，但验证方法可以自己补。写流程：客户端向 NameNode 请求创建文件，NameNode 返回可写 DataNode 列表，客户端写第一个 DataNode，第一个转发给第二个，第二个转发给第三个，形成 pipeline。读流程：客户端向 NameNode 请求读文件，NameNode 返回块位置，客户端直接读最近的 DataNode。

验证方法：

# 写入一个测试文件 hdfs dfs -put /etc/hostname /test/hostname.txt # 读取文件 hdfs dfs -cat /test/hostname.txt # 查看块信息，确认副本分布 hdfs fsck /test/hostname.txt -files -blocks -locations

逻辑说明：-put触发写流程，-cat触发读流程，fsck查看块和副本位置。参数说明：-locations显示块所在 DataNode。如果副本数少于配置值，检查 DataNode 数量和dfs.replication配置。

6.3 一个具体技巧：用 fsimage 和 edits 分析 NameNode 元数据

PPT 里 NameNode 持久化状态部分提到 fsimage 和 edits。进阶用法是用hdfs oiv和hdfs oev把这两个文件转成可读格式，分析元数据。

# 转换 fsimage 为 XML hdfs oiv -i /opt/hadoop/data/dfs/name/current/fsimage_0000000000000000001 \ -o /tmp/fsimage.xml -p XML # 转换 edits 为 XML hdfs oev -i /opt/hadoop/data/dfs/name/current/edits_0000000000000000001 \ -o /tmp/edits.xml -p XML

逻辑说明：oiv是 Offline Image Viewer，oev是 Offline Edits Viewer。参数说明：-i输入文件，-o输出文件，-p指定处理器类型。这个技巧在 NameNode 启动慢或元数据异常时特别有用，能直接看到 namespace 里有什么。

从那以后我每次搭完 hadoop 集群，都强制走一遍fsck和oiv，确认块副本和元数据没问题再跑任务。希望帮到你。

本文还有配套的精品资源，点击获取