# 《Hadoop大数据技术开发实战》知识点全解

> AI生成｜2026年10月29日｜codebuddy｜原书：张伟洋《Hadoop大数据技术开发实战》，清华大学出版社，2019-10-01
> **我的阅读**：进度 100%｜累计 3小时24分钟｜开始 2021-02-09｜最近 2021-02-20｜读完 2021-02-20

**一句话总结**：从一个空的 VMware 虚拟机开始，把"Hadoop 生态每个组件怎么装、怎么配、怎么用 API 调"这条从零到跑通的路径完整铺一遍，让没有大数据基础的人也能独立搭出一套可用集群并写出第一个作业。

**适合谁 / 前置知识**
- 适合：会一点 Linux 命令行、能看懂 Java 代码的开发者；需要从传统后端/数据库转大数据方向的人；要照着文档在自己机器上复现一套集群的自学者。
- 不适合：想深入读源码、研究调度算法与分布式理论推导的人；已有生产集群经验、只想要调优与故障排查手册的人。
- 前置：Linux 基础（cd/ls/vi/权限/tar）、Java SE 基础（类、接口、Maven 依赖概念）、SQL 基础（读 Hive 章节会轻松很多）。分布式理论不是前置，书里是"先跑起来再理解"的路线。

## 一、全书地图

全书的编排逻辑是**环境 → 内核 → 生态 → 实时**四段递进：先造机器（1–2 章），再装内核（3–7 章），然后铺数据存取与计算的外围组件（8–10 章），最后进入流式与内存计算（11 章起）。

| 阶段 | 章节 | 内容 | 在全书中的作用 |
|---|---|---|---|
| 造机器 | 第1章 | VMware 中安装 CentOS 7 | 提供可复制的实验载体，快照/克隆是后文多节点的基础 |
| 造机器 | 第2章 | CentOS 7 集群环境配置：系统环境、JDK、克隆虚拟机、主机 IP 映射 | 决定后面所有组件能否互相"看见"，是全书最容易翻车的地方 |
| 内核 | 第3章 | Hadoop 简介、YARN 架构与工作流程、SSH 无密钥登录、搭建 Hadoop 2.x 分布式集群 | 全书地基：资源管理层定型，后续组件都挂在这套集群上 |
| 内核 | 第4章 | HDFS 简介、命令行、Web 界面、Java API 读取数据 | 存储层，后面 HBase/Hive 的数据最终都落在它上面 |
| 内核 | 第5章 | MapReduce 简介、编写步骤、单词计数/数据去重/求平均分/二次排序、MRUnit 测试 | 计算层，也是理解 Shuffle 的唯一入口 |
| 内核 | 第6章 | ZooKeeper 简介、安装配置、命令行、Java API、监听服务器动态上下线 | 协调层，为第7章 HA 和后面的 HBase/Kafka 做前置 |
| 内核 | 第7章 | HDFS HA 搭建、YARN HA 搭建 | 把第3、4、6 章合起来做高可用，是"生产化"的第一步 |
| 存取 | 第8章 | HBase 概念、基本结构、数据模型、集群架构、安装、Shell、Java API、MapReduce 数据转移、备份恢复 | NoSQL 随机读写层，补 HDFS 不能改写的短板 |
| 存取 | 第9章 | Hive 概念、架构、三种运行模式、安装、属性配置、Beeline、表操作、查询、元数据表结构、自定义函数、JDBC、与 HBase 整合、搜狗日志分析 | SQL 化入口，把 MR 的门槛降下来 |
| 搬运 | 第10章 | Sqoop 概念、使用、导入/导出工具、安装配置、三类案例（MySQL↔HDFS、MySQL→HBase） | 关系库与大数据的桥，案例章是"闭环"的关键 |
| 实时 | 第11章 | Kafka 概念（目录至此截止） | 消息缓冲层，承上启下通向流处理 |
| 实时 | （目录未展开） | 简介提到的 Flume、Storm、Spark、Elasticsearch | 采集、流计算、内存计算、检索四个方向；具体章节号待核对 |

读法建议：1–2 章不要跳，环境不干净后面每一步都在还债；3–5 章必须动手；6、8、9 章可先读概念再补实操；10 章案例是全书唯一把三个组件串起来的练习，价值最高。

## 二、核心知识点

**1. 集群环境基线（第2章）**
是什么：给每台机器固定 hostname、静态 IP、`/etc/hosts` 映射，关闭防火墙与 SELinux，配置 NTP 时钟同步，装好 JDK 并设 `JAVA_HOME`。
为什么重要：Hadoop 各守护进程之间靠**主机名**互相寻址，配置里写的是 `master`、`slave1`，解析失败时表现为"进程起来了但连不上"，报错信息往往指向超时而非解析，极难排查。
怎么用：先 `hostname` 与 `hostname -i` 双向验证，再 `ping master`、`ping slave1`；`date` 对比三台机器时间。
常见误区：只改 `hostname` 不写 hosts；用 `127.0.0.1` 做映射导致 DataNode 注册到回环地址；克隆虚拟机后忘记改 IP 和 hostname，两台机器同名同 IP。

**2. SSH 无密钥登录（3.4）**
是什么：`ssh-keygen` 生成密钥对，把公钥追加到目标机 `~/.ssh/authorized_keys`，实现免密。
为什么重要：Hadoop 的启停脚本本质是"在一台机器上循环 ssh 到各节点执行命令"，没有免密就只能一台台手起，脚本全部失效；HA 场景下主备切换也依赖它。
怎么用：先本机 `ssh localhost` 自测，再分发到各节点；`ssh-copy-id` 或手动 `cat id_rsa.pub >> authorized_keys` 后注意 `chmod 600`。
常见误区：只做 master→slave 单向。实际搭建时应让节点之间**互相**免密，否则后续 HA、ZooKeeper 集群、HBase 的跨机操作都会卡住。另一个坑是 `.ssh` 目录权限过大被 sshd 拒绝。

**3. Hadoop 2.x 的架构拆分（第3章）**
是什么：Hadoop 1.x 里 JobTracker 同时干"资源管理"和"作业调度"两件事，规模一大就成瓶颈；2.x 把它拆成 YARN（只管资源）和 MapReduce（只管计算）。
为什么重要：这次拆分是整个生态能长出来的前提——Spark、Storm 能跑在同一个集群上，就是因为资源层被独立出来了。
怎么用：理解"一个集群，多种计算框架共享资源"这句话，配置时 `yarn-site.xml` 与 `mapred-site.xml` 是两个独立维度。
常见误区：把 YARN 当成"MapReduce 的一部分"。它是独立资源管理器，MR 只是它的一个应用类型。

**4. YARN 组件与工作流程（3.2、3.3）**
是什么：ResourceManager（全局资源仲裁）+ NodeManager（单机资源与容器）+ ApplicationMaster（每个应用一个，负责向 RM 要资源、向 NM 要容器、监控任务）+ Container（CPU/内存的抽象）。
流程：客户端提交 → RM 分配第一个容器启动 AM → AM 向 RM 注册并申请资源 → RM 返回可用容器 → AM 在对应 NM 上启动任务 → 任务向 AM 汇报 → 完成后 AM 注销。
为什么重要：所有"作业卡在 ACCEPTED""容器被杀"的问题，都要按这条链路定位卡在哪一环。
常见误区：以为 AM 跑在 RM 进程里。AM 是跑在某个 NodeManager 的容器里的普通进程，所以节点挂掉会导致整个应用重试。

**5. HDFS 架构与 NameNode 的元数据（4.1）**
是什么：NameNode 存元数据（目录树、块到 DataNode 的映射），DataNode 存真实块（默认 128MB 一块、3 副本）；SecondaryNameNode 定期把 edits 合并进 fsimage。
为什么重要：NameNode 内存里放的是"文件→块→位置"的映射，块数量直接决定内存上限，这也是小文件问题的根源。
怎么用：`hdfs-site.xml` 调副本数，`core-site.xml` 配 `fs.defaultFS`。
常见误区：把 SecondaryNameNode 当热备。它**不承接故障切换**，只做 edits 合并，NameNode 挂了它救不了场——这正是第7章 HA 要解决的问题。

**6. HDFS 读写与副本放置（4.1）**
是什么：写时客户端先写第一个 DataNode，再由它串行转发给下一个，形成 pipeline，全部确认才算写完；副本按机架感知放置（本机架一个、另一机架一个、再随机一个）。
为什么重要：pipeline 意味着**最慢的那个 DataNode 决定写入速度**；机架感知解释了为什么"机器都在同一机架"时容灾能力其实很弱。
常见误区：认为写完 `put` 成功就一定三副本齐全——实际是异步复制，短暂不一致是正常的。

**7. HDFS 命令行与 Java API（4.2–4.4）**
是什么：`hadoop fs -ls/-put/-get/-cat/-mkdir/-rm/-mv/-chmod/-du/-count/-text`；Java 侧通过 `FileSystem.get(new URI(...), conf, "user")` 拿文件系统对象，再 `open()`/`create()` 读写流。
为什么重要：命令行的参数顺序与 Linux 相反（`hadoop fs -put 本地 目标`），API 则是所有上层组件（HBase、Spark）落地的通道。
怎么用：调试先用 `-ls` 和 `-cat` 确认路径，再用 API 复现；写代码时注意 `FileSystem` 要 `close()`，否则连接泄漏。
常见误区：路径不带 scheme 时读的是本地目录；以 root 身份跑作业导致 HDFS 上文件属主是 root，后续用普通用户跑任务报权限错。

**8. MapReduce 编程模型与 Shuffle（第5章）**
是什么：InputFormat 切分数据 → Mapper 输出 `(k,v)` → Shuffle（分区、排序、合并、可选的 Combiner）→ Reducer 归并 → OutputFormat 落盘。
为什么重要：Shuffle 是 MR 的性能黑洞（磁盘 IO + 网络传输 + 排序），几乎所有优化都在这一环：加 Combiner、调分区数、避免数据倾斜。
怎么用：单词计数是最小完整例子——map 输出 `(word,1)`，reduce 求和；数据去重利用 reduce 的 key 唯一性；求平均分用"分组 key + 遍历求均值"。
常见误区：以为 map 输出直接进 reduce。中间必然经过分区与排序，所以 reduce 收到的 key 是有序的、且同一个 key 一定进同一个 reduce。

**9. 二次排序的实现套路（5.6）**
是什么：既要按第一列排、第一列相同再按第二列排。做法是自定义组合 key（实现 `WritableComparable`，`compareTo` 里写两级比较）+ 自定义 Partitioner（只按第一列分区）+ 自定义分组比较器（只按第一列分组）。
为什么重要：这是 MR 里"控制框架行为"的经典范例，把排序、分区、分组三件事拆开理解，之后写任何复杂聚合都不慌。
常见误区：只改 `compareTo` 不做分组比较器，导致第一列相同的记录被当成不同 key 而进不了同一个 reduce。另外注意 `write()`/`readFields()` 必须与字段顺序严格一致。

**10. MRUnit 测试（5.7）**
是什么：在本地 JVM 里对 Mapper/Reducer 单独做单元测试，不需要起集群。
为什么重要：MR 作业的调试成本极高（打包、上传、提交、看日志一轮几十分钟），把逻辑下沉到单元测试能省掉大部分往返。
常见误区：把需要集群环境的逻辑（如读取 HDFS 上的大文件、依赖分布式缓存）塞进 MRUnit，导致测试变成集成测试。

**11. ZooKeeper 的 znode 与 watch（第6章）**
是什么：类文件系统的树形命名空间，节点分持久/临时/顺序；客户端可对节点设 watch，节点变更时收到**一次性**通知；集群靠 ZAB 协议选主，**过半即存活**，所以节点数应为奇数（3/5）。
为什么重要：它是整个生态的"分布式协调底座"——HDFS HA 的选主、HBase 的 RegionServer 心跳、Kafka 的元数据（旧版本）都建在它上面。
怎么用：案例"服务器动态上下线"就是这个模型的最小实现——服务启动时创建**临时节点**，客户端 watch 父节点，节点消失即代表机器下线。
常见误区：以为 watch 会持续生效（实际触发一次就要重新注册）；认为节点越多越可靠（4 节点并不比 3 节点更耐故障，反而降低可用概率）。

**12. HDFS / YARN 高可用（第7章）**
是什么：两个 NameNode（Active/Standby）+ JournalNode 集群共享 edits + ZooKeeper 做选主 + ZKFC 监控与自动切换；YARN 侧则是两个 ResourceManager 同样的主备模型。
为什么重要：第5点说过 SecondaryNameNode 不是热备，HA 才是真正的故障自动接管方案，也是"单机实验集群"和"能上生产"的分水岭。
怎么用：核心是 `dfs.nameservices` 逻辑名 + `ha.zookeeper.quorum` 配置，客户端通过逻辑名访问而不是具体主机。
常见误区：只配了两个 NN 却没配 ZKFC 自动切换，故障时仍需手动；JournalNode 只部署一台，等于把单点换了个地方。

**13. HBase 的数据模型与 RowKey 设计（第8章）**
是什么：表 → 列族 → 列限定符 → 版本（时间戳）；RowKey 按**字典序**排列，表按 RowKey 范围水平切成 Region，由 RegionServer 承载，HMaster 管分配与负载，元数据存 ZooKeeper。
为什么重要：RowKey 决定数据分布。单调递增的 RowKey（如时间戳、自增 ID）会让写入全部压到最后一个 Region，形成热点。
怎么用：常用解法是加盐（hash 前缀）、反转、或组合 `业务ID+时间`；读多写少场景按查询模式设计 RowKey。
常见误区：以为 HBase 支持 SQL 式条件查询（只能按 RowKey 与范围、或全表扫）；列族开太多（每个列族是独立的 Store，过多会拖垮性能，一般 1–3 个）。

**14. Hive 的本质与表类型（第9章）**
是什么：把 SQL 翻译成 MR/Tez/Spark 作业，元数据存在关系库（如 MySQL）里由 MetaStore 管理；分内部表（删表删数据）与外部表（删表只删元数据）；分区（目录级剪枝）与分桶（文件级哈希）。
为什么重要：它把"写 Java 写 MR"变成"写 SQL"，是数据分析岗的日常入口；但它是**批处理**，天生不适合事务与毫秒级查询。
怎么用：日志类数据用外部表 + 按日期分区，避免误删；`PARTITION` 字段在查询里要作为过滤条件才会触发剪枝。
常见误区：把 Hive 当 MySQL 用（没有行级更新、没有严格事务、小查询延迟以分钟计）；分区字段名与表字段重复导致数据错列；建表不指定分隔符，查询结果全是 NULL。

**15. Sqoop 的导入导出与切分（第10章）**
是什么：基于 JDBC 的关系库↔Hadoop 搬运工具，导入用 `--split-by` 指定切分列、`--m` 指定并行度，导出走 `export` 子命令。
为什么重要：它是"存量数据入湖"和"结果回流业务库"的唯一常规通道，案例里 MySQL→HDFS→Hive→HBase 的链路就是典型数仓雏形。
怎么用：`--split-by` 选分布均匀的数值/时间列，`--m` 不要超过实际可用资源；增量导入靠 `--check-column` + `--last-value`。
常见误区：`--split-by` 选了个严重倾斜的列，导致个别 map 跑几小时；导出时目标表主键冲突直接失败；忘记目标表已存在会覆盖/报错。

## 三、关键概念速查表

| 概念 | 一句话解释 | 用在哪儿 |
|---|---|---|
| NameNode | 存元数据的"目录服务器"，不存真实数据 | HDFS 单点/HA 的核心 |
| DataNode | 存真实数据块的工人，定期向 NN 报块 | 扩容、坏盘排查 |
| SecondaryNameNode | 合并 edits 的助手，不是备份 | 冷备时代的产物，HA 后弱化 |
| JournalNode | 多台共享 edits 日志的小集群 | HDFS HA 的元数据同步 |
| ZKFC | 监控 NN 健康并触发主备切换 | HA 自动故障转移 |
| ResourceManager | 全局资源仲裁者 | YARN 入口 |
| NodeManager | 单机资源与容器管理者 | 节点扩容、内存配置 |
| ApplicationMaster | 每个应用一个的"项目经理" | 作业卡住时的第一现场 |
| Container | CPU/内存的资源封装 | 调 `yarn.nodemanager.resource.memory-mb` |
| Shuffle | map 输出到 reduce 输入之间的分区排序搬运 | 所有 MR 性能问题 |
| Combiner | map 端的"迷你 reduce" | 求和类聚合的免费加速 |
| znode | ZooKeeper 的树节点，可持久/临时/顺序 | 选主、配置、注册中心 |
| watch | 一次性事件通知 | 动态上下线监听 |
| Region | HBase 表按 RowKey 切出的水平分片 | 热点与预分区 |
| RowKey | HBase 的行主键，字典序排列 | 表设计的全部功夫 |
| MetaStore | Hive 的元数据库服务 | 多客户端共享表结构 |
| 内部表/外部表 | 删表是否连数据一起删 | 日志接入的默认选择 |
| 分区/分桶 | 目录级剪枝 / 文件级哈希 | 查询加速 |
| Sqoop `--split-by` | 决定并行切分的列 | 导入性能与倾斜 |
| Topic/Partition | Kafka 的逻辑队列与物理分片 | 吞吐与顺序性权衡 |

## 四、可复用的方法/框架

**A. 搭任何分布式组件的五步法**（书里反复出现的隐式套路）
1. 环境基线：hostname、hosts、防火墙、时钟、JDK —— 先验证，再往下。
2. 解压与目录规划：统一安装路径、统一用户，避免 root 与普通用户混用。
3. 改配置：先只改"必须改"的三五项（地址、端口、数据目录），跑通再加高级项。
4. 分发与启动：`scp`/`rsync` 分发，按角色顺序启动（ZK → NN → DN → RM → NM）。
5. 验证：`jps` 看进程、Web UI 看状态、日志看异常，三者缺一不可。

**B. 组件排障的判断顺序**
进程在不在（`jps`）→ 端口通不通（`netstat`/`telnet`）→ 名字解析对不对（`ping`/`hostname -i`）→ 配置读的是不是你以为的那份（`grep` 实际 xml）→ 日志最后 100 行。**先排除环境，再怀疑代码**，能省掉八成时间。

**C. 选型判断清单**
- 要随机读写单行、低延迟 → HBase；要全量扫描做统计 → Hive/HDFS。
- 数据要"存进去就不改" → HDFS 足够；要频繁更新 → 别硬上 HDFS。
- 延迟要求秒级以下、持续流入 → Kafka + 流计算；按天/小时出报表 → Hive 批处理。
- 关系库与大数据的双向搬运 → Sqoop；持续增量日志采集 → Flume。

**D. 设计 HBase 表的自检四问**
RowKey 会不会单调递增造成热点？查询是否只靠 RowKey 与范围？列族能否压到 3 个以内？Region 是否需要预分区？

**E. MR 作业的优化顺序**
先加 Combiner → 再查数据倾斜（看各 reduce 耗时）→ 再调分区数/并行度 → 最后才考虑换框架。

## 五、我的阅读轨迹

| 项目 | 数据 |
|---|---|
| 进度 | 100% |
| 累计阅读 | 3小时24分钟 |
| 开始阅读 | 2021-02-09 |
| 最近阅读 | 2021-02-20 |
| 读完时间 | 2021-02-20 |

按 3 小时 24 分钟读完 16 章的量级推算，当时应是"快速通读 + 少量动手"的读法：概念和流程记住了，但集群实操的肌肉记忆大概率没留下。复习建议：

1. **优先重做第 2、3、7 章**——环境、集群、HA 是全书的承重墙，也是最容易随时间遗忘的部分；只读不做的收益极低。
2. **第 4、5、8、9 章做"最小可运行"复现**：各写一个 Java API 读写、一个 MR 作业、一次 HBase CRUD、一段 Hive 分区查询，四件事各半小时即可唤回。
3. **第 10 章案例当毕业设计**：MySQL→Sqoop→HDFS→Hive→HBase 跑通一次，等于把前 9 章串成一条线。
4. **第 11 章及之后的 Flume/Kafka/Storm/Spark/Elasticsearch 目录未完整展开**，复习时按主题补，不必强求对应章节号。

## 六、行动清单

- 重建一套三节点集群，把 hostname/hosts/免密/时钟四项写成一份可复用的初始化脚本。
- 用 `jps` + Web UI 各截一次图，建立"正常状态长什么样"的基线认知。
- 手写一遍单词计数，不使用 IDE 模板，确保能独立写出 Mapper/Reducer/Driver 三段。
- 用自定义 Partitioner + 分组比较器实现二次排序，跑通后再回头读第 5 章。
- 搭一次 HDFS HA，故意 `kill` 掉 Active NameNode，观察自动切换耗时与日志。
- 设计一张 HBase 表并说明 RowKey 为什么这样选，写出防热点的理由。
- 建一张按日期分区的 Hive 外部表，用 `EXPLAIN` 确认分区剪枝生效。
- 跑通 Sqoop 导入导出各一次，记录 `--split-by` 与 `--m` 改变前后的耗时差。

## 七、延伸阅读

1. **《Hadoop权威指南》**（Tom White）—— 本书是"怎么做"，它是"为什么这样设计"。建议顺序：先用本书跑通集群，再读它补 HDFS/YARN 的设计细节与调优原理。
2. **《Hive编程指南》** —— 本书第 9 章只有一章的篇幅，这本把 SQL 语义、分区分桶、UDF 讲透。建议在本书第 9 章之后立刻接上，趁热打铁。
3. **《Spark快速大数据分析》** —— 本书对 Spark 着墨有限（目录亦未完整展开），而 Spark 已是 MR 之后的主流计算引擎。建议放在最后，前提是已经理解 Shuffle 与分区，否则会学成"只会调 API"。

补充：若想补分布式协调的理论底子，可在读完第 6、7 章后看 ZooKeeper 相关专著；若目标是离线数仓，可接《大数据之路》一类的工程实践书。