HCIA-Big Data备考笔记：存储、计算与调度三条主线串讲

2月10号那天，我把HCIA - Big Data相关的笔记从头到尾重排了一遍。起因很直接：前一周做模拟题时，HDFS的写入流程我能背下来，但一问到“客户端写失败之后NameNode怎么处理租约”“YARN的Container申请和分配到底谁跟谁对话”，我就开始含糊。这种“能复述、不能推演”的状态，在HCIA - Big Data这类偏概念与原理的认证里是最危险的，因为题目不会照着教材原句问，它总要在某个环节拐个弯。所以我干脆把零散的知识点全部拆开，按“这份认证到底想确认你懂什么”重新拼了一遍。

这篇笔记写给两类人：一是正在准备HCIA - Big Data、手里有一堆课件但串不成线的人；二是已经在大数据岗位上干活、但底层组件原理一直靠“印象”撑着的人。我不会把官方大纲复述一遍，那东西你手上就有。我想讲的是，这套知识体系里哪些点是真正的主干、哪些是出题人爱挖的坑、哪些东西你背下来了但一到实验环境就露馅。中间会穿插我自己搭环境、跑作业时踩到的具体问题，以及几个我认为值得反复琢磨的参数和机制。

1. 先弄清这套认证在考什么：三条主线而不是一堆组件

很多人翻开目录的第一反应是“组件好多”：HDFS、MapReduce、YARN、Hive、HBase、Spark、Flink、Kafka、ZooKeeper、Flume、Sqoop……于是一路背下去，背到后面忘了前面。我在第一轮复习时就掉进这个坑，结果是每个组件都能说两句，但被问到“一个日志采集需求该用哪几个组件串起来”时，脑子是空的。

后来我换了个思路：这套知识体系的骨架其实只有三条主线，存储、计算、资源调度，其余组件都是这三条主线的延伸或者补充。

1.1 存储主线：数据放在哪，怎么放才可靠

存储主线的核心是HDFS，外挂一个HBase解决随机读写，再往下延伸出Hive的元数据和表结构。你只要抓住一个问题：一份数据在集群里存三份，怎么保证这三份不出错、不丢、读得快。HDFS的所有机制设计，本质上都在回答这个问题。

• 副本机制解决“丢了怎么办”，默认3副本，机架感知决定副本放在哪几个机架上。
• 块（Block）机制解决“大文件怎么切”，默认128MB一块，切完才能分布式存。
• 元数据机制解决“怎么找到块”，NameNode内存里存的是文件到块的映射，不是数据本身。
• 心跳与租约解决“谁还活着、谁还在写”，DataNode定期上报，客户端写文件时持租约。

把这四条摆开，HDFS那一章就不再是零散的配置项，而是一条有因果链的设计。考试里问“SecondaryNameNode的作用”，答“帮助NameNode合并editlog和fsimage，不能做热备”这种标准答案当然要会，但更关键的是你能说清为什么它不能做热备——因为它不实时同步元数据的变更。这个“为什么”才是把知识点钉死的钉子。

1.2 计算主线：任务怎么切、怎么并行、怎么汇总

计算主线的核心是MapReduce，往上延伸出Hive（把SQL翻译成计算任务）、Spark（把计算放到内存里跑）、Flink（把计算做成流式）。这条主线你要抓的问题是：一个大任务怎么拆成很多小任务并行跑，跑完怎么拼回去。

MapReduce的五个阶段——Input、Map、Shuffle、Reduce、Output——每一个阶段的边界条件都得清楚。尤其是Shuffle，它是最容易出问题也最爱考的地方：分区（Partitioner）决定数据去哪个Reduce，排序（Sort）决定Reduce端看到的顺序，合并（Combiner）在Map端做一次局部归约以减少网络传输。这三个动作在同一个阶段里发生，但不是同一件事，很多人笔记里把它们糊成一团。

Hive那一章看起来是讲SQL，其实讲的是“SQL怎么落到MapReduce/Tez/Spark上执行”。你需要知道Hive自己不算数据，它只是一个把HQL翻译成分布式作业的编译器，元数据存在MetaStore里（通常落在关系型数据库），真实数据在HDFS上。这个认知一旦建立，Hive的很多行为就顺理成章了：为什么内部表删表会删数据、外部表不会？因为数据归属权不同。为什么分区字段不能随便选高基数的列？因为每个分区对应一个目录，分区太多会导致NameNode元数据膨胀。

1.3 调度主线：资源怎么分、任务怎么排队

资源调度这条线最容易被轻视，但它恰恰是把存储和计算串起来的那根绳。YARN的核心角色是ResourceManager（全局资源调度）、NodeManager（单节点资源管理）、ApplicationMaster（单个作业的管家）、Container（资源的抽象单位）。这四个角色的对话关系，是这一章的全部重点。

我整理笔记时画过一张最简对话图（虽然这里不能画图，但你可以自己在纸上画）：客户端提交作业 → RM分配第一个Container启动AM → AM向RM申请后续Container → RM让NM去启动 → NM拉起任务进程 → 任务向AM汇报进度 → 全部完成AM注销。这条链路你只要能口述出来，YARN那一章基本就通了。

调度器这块，FIFO、Capacity、Fair三种的差别要能说清适用场景。FIFO简单但会饿死小作业；Capacity把队列容量预分配，适合多团队共享；Fair让资源动态均衡，适合任务量波动大的场景。考试喜欢考“某场景下选哪种”，你光背特性不够，得理解每种调度器在解决什么矛盾。

把这张表贴在笔记第一页，后面每学一个组件，先问它属于哪条线、解决什么问题，再去看细节。这个顺序反过来，你会背得很痛苦。

2. HDFS的写入链路：从客户端到DataNode的每一步都可能被问

HDFS是这套认证里分量最重的组件之一，而写入流程是重灾区。我见过太多人能把“客户端向NameNode请求、NameNode返回DataNode列表、客户端写Pipeline”这段话背下来，但一旦题目改成“Pipeline中某个DataNode挂了会怎样”，就答不上来。

2.1 一次完整写入的六个动作

我把写入拆成六个动作，每个动作对应一个可能被追问的点：

1. 客户端调用create，向NameNode发起创建文件请求。
2. NameNode做检查，确认路径不存在、权限够、配额没超，然后返回一个可写的DataNode列表（按机架感知排序，通常第一个副本放在客户端所在节点或最近的机架）。
3. 客户端建立Pipeline，把数据块切成Packet依次发给第一个DataNode，第一个转发给第二个，第二个转发给第三个，形成一条链。
4. 三级确认反向上报，最后一个DataNode写完向上一级发ACK，逐级回传到客户端。
5. 块写满或关闭时做finalize，DataNode把临时块转正，向NameNode汇报块信息。
6. 客户端close，NameNode做持久化，文件变为可用状态。

这六步里，第3、4步是Pipeline机制的核心。为什么用Pipeline而不是客户端同时写三个DataNode？因为要避免客户端成为带宽瓶颈，同时保证三个副本写入顺序一致。这个“为什么”在面试和考试里都常被问。

2.2 Pipeline中途挂了一个节点怎么办

这是我最喜欢的一个考点，因为它能区分“背过”和“懂了”。假设三个DataNode组成Pipeline，写到一半第二个挂了，会发生什么？

• 客户端会收到ACK超时或错误。
• 客户端通知NameNode，NameNode把出问题的节点从Pipeline里移除。
• 剩下的两个DataNode重新组成Pipeline，客户端继续往新Pipeline里写。
• 已写入的数据不会丢，因为第一个和第三个节点上的数据是完整的。
• 后续这个块会按副本策略补足到三副本。

关键结论：写入过程是“尽力而为+事后补齐”，不是事务性的原子操作。这个认知很重要，因为它解释了为什么HDFS适合一次写入多次读取，而不适合频繁修改。

2.3 SecondaryNameNode的定位，别再搞混

这个组件名字起得太有误导性，很多人第一反应是“备用的NameNode”。不是。它的作用是定期把NameNode的editlog和fsimage合并，减少NameNode重启时的加载时间。它不做实时同步，所以NameNode挂了它顶不上。

真正解决NameNode单点问题的是HA架构：两个NameNode（Active和Standby），靠JournalNode共享editlog，靠ZooKeeper做选举和故障切换（ZKFC进程监控）。这套架构里，Standby会实时读取JournalNode上的editlog，所以切换时元数据基本不丢，只可能有极短的延迟。

我在实验环境里配过一次HA，踩的坑是：格式化NameNode的顺序搞反了，导致两个节点元数据不一致，启动后一直处于standby状态无法切换。后来才明白，HA模式下要先格式化JournalNode，再分别格式化两个NameNode，且第二个要用-clusterid参数对齐。这类实操细节，课件上通常一句话带过，但你不动手就永远记不住。

提示：考试里如果问“SecondaryNameNode能否实现高可用”，答案是不能；如果问“HA架构中谁负责故障切换”，答案是ZooKeeper配合ZKFC，别只写ZooKeeper。

2.4 块大小为什么是128MB

这个数字不是拍脑袋定的。块太小，元数据条目多，NameNode内存压力大；块太大，单个节点的磁盘IO成为瓶颈，且任务并行度上不去。128MB是在当时的硬件条件下，寻址时间（约10ms）与传输时间（约100MB/s下1秒多）之间的一个平衡点。你可以记一个粗略的换算：希望传输时间远大于寻址时间，通常是100倍左右，所以块大小≈100×10ms×100MB/s≈100MB，取整到128MB。

这个推导过程考试不考，但它能帮你在被问到“块大小能不能改、改了有什么影响”时给出有依据的回答，而不是干巴巴一句“默认128MB”。

3. Hive不是数据库：搞清楚它到底翻译了什么

Hive这一章最容易被误解成“学SQL”。SQL那部分你本来就会，真正要学的是Hive如何把你写的HQL变成分布式作业。这个视角一换，分区、分桶、内部表外部表、数据倾斜这些概念就都有了归属。

3.1 元数据、数据、计算三者的分离

Hive的架构可以概括成三句话：元数据在MetaStore（背后通常是MySQL这类关系库），数据在HDFS，计算交给MapReduce/Tez/Spark。Hive自己只做一件事——解析、优化、生成执行计划。

这个分离带来一个很实际的后果：你删了Hive表，数据可能还在。内部表（Managed Table）删表时会把HDFS上的数据目录一起删掉；外部表（External Table）删表只删元数据，数据目录原封不动。生产环境里几乎都用外部表，因为数据往往由上游采集程序写入，不能被一个误操作带走。

我在早期做练习时，用内部表存了一份跑了两小时的清洗结果，后来手滑drop了一下，数据直接没了，只能重跑。那次之后我养成习惯：除了临时中间表，一律建外部表，并且建表时就显式指定location。

3.2 分区和分桶，解决的不是同一个问题

这两个概念经常被放在一起讲，但它们的目的完全不同。

• **分区（Partition）**解决的是“减少扫描量”。按日期、地区这类低基数字段分区，查询时带上分区条件，Hive只扫对应目录。
• **分桶（Bucket）**解决的是“数据均匀打散”。按某个字段的哈希值取模分到固定数量的文件里，主要用于抽样和Map端Join。

分区字段是目录结构（/table/dt=2024-02-10/），分桶是文件层面的切分。分区数量过多会让NameNode压力变大，因为每个分区都是一个目录；分桶数量一旦建表时定下，后期改动很麻烦。

一个常见的错误是拿高基数字段做分区，比如用用户ID分区，结果产生几百万个目录，NameNode直接扛不住。这种字段适合做分桶。

3.3 数据倾斜：Hive调优绕不开的那道坎

数据倾斜的本质是某个key对应的数据量远超其他key，导致一个Reduce任务拖慢整个作业。典型场景是Join时某个热门商品ID、某个默认值（null或空串）占了绝大部分记录。

处理手段我在笔记里总结了四条，按使用频率排序：

1. 过滤异常key：如果倾斜来自null或空值，Join前先过滤掉，或者在Join条件里给null赋一个随机值。
2. Map端Join：小表足够小（默认25MB以内）时，把它广播到每个Map任务，直接避免Shuffle。
3. 加盐打散：给倾斜key拼接随机前缀，让它分散到多个Reduce，之后再聚合回来。这个方法会多一次作业，但能救命。
4. 调参数：hive.exec.reducers.bytes.per.reducer调整每个Reduce处理的数据量，hive.groupby.skewindata开启倾斜时的负载均衡（会生成两个MR作业）。

这里有个经验：不要一上来就调参数。先看执行计划，确认倾斜发生在哪个Stage、是Join倾斜还是GroupBy倾斜，再对症下药。参数是兜底手段，不是第一选择。

3.4 HQL到作业的翻译过程，值得手动跟一遍

我建议你至少手动跑一次explain，看一条简单SQL是怎么被拆成多个Stage的。比如一个带Join和GroupBy的查询，通常会生成两到三个MapReduce作业：第一个做Join前的数据准备，第二个做Join，第三个做聚合。理解了Stage的划分，你才能明白为什么有些SQL写起来简单、跑起来很慢。

比如select count(distinct uid) from t，很多人以为是一个作业，实际上distinct会被翻译成“先GroupBy去重再count”，中间可能产生额外的Shuffle。想优化成select count(1) from (select uid from t group by uid) tmp，因为后者可以用更少的阶段完成同样的去重。这类改写技巧在数据量大时差别非常明显。

4. HBase的读写路径：RowKey设计决定一切

HBase是这套认证里最“反直觉”的组件。关系库你按行存、按索引查，HBase你只有RowKey这一个索引，其他字段想查只能全表扫。这个限制逼着你在设计阶段就把查询模式想清楚。

4.1 LSM树与写入路径

HBase的写入不是直接落盘，而是先写WAL（预写日志）保证不丢，再写MemStore（内存），MemStore满了刷成StoreFile（HFile）落盘。这个结构叫LSM树，特点是写快读慢——写入都是顺序追加，读取要合并多个文件。

这个设计决定了HBase的适用场景：写多读少、按RowKey随机读写。如果你需要复杂的多条件查询，HBase不是好选择，Hive或者搜索引擎更合适。

读取时，HBase会先查MemStore，再查BlockCache，最后查StoreFile。为了加速“某个RowKey在不在这个文件里”的判断，可以用布隆过滤器（BloomFilter），代价是额外内存。这个开关在列族级别配置，考试里偶尔会问。

4.2 RowKey设计的三条铁律

RowKey设计是HBase里唯一真正需要“设计”的部分，我总结成三条：

• 长度要短：RowKey会冗余存储在每个单元格里，太长会显著增加存储开销。一般建议不超过16字节。
• 散列要均匀：避免热点。常见做法是加盐（前缀随机数）、哈希（对RowKey取md5）、反转（把时间戳倒序）。
• 排序要符合查询：HBase按RowKey字典序排列，所以你要把“最常用的查询前缀”放在最前面。比如查询“某用户某时间段的数据”，RowKey应该是userId + timestamp，而不是反过来。

一个真实的反例：有人用时间戳做RowKey前缀记录日志，结果所有写入都集中在一台RegionServer上，因为时间戳是单调递增的，永远落在最后一个Region。这就是典型的“写入热点”，解决办法是加盐或反转。

4.3 Region分裂与预分区

HBase的表按RowKey范围切分成多个Region，每个Region由一个RegionServer管理。表刚建时只有一个Region，随着数据增长会分裂。分裂本身没问题，但分裂瞬间会有短暂的不可用，而且自动分裂的边界不可控。

生产环境通常用预分区：建表时就根据RowKey的分布范围预先切好多个Region。比如按用户ID哈希取模，预先建16个Region。这样写入从一开始就是分散的，不会出现“先热后分裂”的抖动。

预分区的split key怎么定？简单办法是按业务已知的取值范围均分，复杂一点先用抽样数据算出分位数。这个细节考试不会深究，但你在实验里建表时如果忘了预分区，后面导入数据会明显感觉到前期写入集中在一个节点上。

5. Spark、Flink、Kafka：三条技术路线的边界在哪

到了这一层，知识点开始交叉，也最容易混。我的处理办法是：不背组件特性，而是背“什么场景该选谁”。选型的判断依据，比组件参数更有价值。

5.1 Spark的RDD与宽窄依赖

Spark的核心抽象是RDD，一个不可变、可分区、可并行操作的数据集合。RDD之间的依赖分两种：窄依赖（一个父分区只对应一个子分区，比如map、filter）和宽依赖（一个父分区对应多个子分区，比如groupByKey、join）。

宽依赖会触发Shuffle，Shuffle是Spark作业里最贵的操作。所以Spark优化的核心思路就是：能不用Shuffle就不用，非用不可就尽量减少数据量。

• reduceByKey优于groupByKey，因为前者在Map端先做局部聚合。
• 大表Join小表时用广播变量（Broadcast Join），把Shuffle变成Map端操作。
• 多次复用的RDD要cache()或persist()，但要选对存储级别，内存不够时用MEMORY_AND_DISK。

Stage的划分就是以宽依赖为界：遇到一个宽依赖就切一个新Stage。这个规则你要能自己画出来，因为考试里给一段代码问“有几个Stage”是很常见的题型。

5.2 Flink的流批一体与时间语义

Flink和Spark最大的理念差别是：Spark以批为第一公民，流是微批模拟；Flink以流为第一公民，批是流的有界特例。这个差别体现在编程模型上就是：Flink的DataStream API可以处理无界流，DataStream也可以处理有界数据。

Flink的时间语义是重点：Event Time（事件发生时间）、Ingestion Time（进入系统时间）、Processing Time（处理时间）。生产上几乎都用Event Time，因为Processing Time受网络延迟和系统负载影响，结果不可重现。

但用Event Time就必然面对乱序问题，于是有了Watermark：一个表示“这个时间点之前的数据应该都到齐了”的标记。Watermark的生成策略有两种，周期性和标点式。窗口触发条件就是Watermark越过窗口结束时间。这块逻辑如果不理解，题一变形就懵。

5.3 Kafka的角色：不是消息队列那么简单

Kafka经常被放在大数据组件列表的最后，容易被当成“顺带一提”。实际上它在实时链路里是枢纽：上游采集写进来，下游Spark/Flink消费出去，起到削峰和解耦的作用。

核心概念：Topic（逻辑分类）、Partition（物理分片，决定并行度）、Replica（副本，决定可靠性）、Offset（消费位点）、Consumer Group（消费组，组内每个分区只被一个消费者消费）。

考试常考的点：

• 生产者ack机制：acks=0不等确认，最快但可能丢；acks=1等Leader确认，折中；acks=all等所有ISR确认，最安全但最慢。
• ISR（In-Sync Replicas）：与Leader保持同步的副本集合，Leader挂了从ISR里选新Leader。如果ISR缩到只剩Leader，acks=all就退化成acks=1。
• 消费者位移提交：自动提交简单但可能重复消费或丢消息，手动提交可控但代码要写对。

我个人的判断习惯是：先看数据有没有界。有界且要求吞吐，选Spark；无界且要求低延迟，选Flink。两者不是替代关系，很多架构里是并存的。

6. 实验环境和备考节奏：纸面知识和能跑起来是两回事

理论背得再熟，集群起不来一样白搭。HCIA - Big Data虽然偏概念，但实验部分能帮你把知识点从“记忆”转成“理解”。我用的是一台16G内存的机器开了三个虚拟机，伪分布式跑HDFS和YARN，单机跑Hive和HBase。

6.1 搭环境时最容易翻车的四个地方

• 主机名和hosts：三台机器的主机名必须能互相解析，否则DataNode注册不上。我图省事用过IP，结果Hive的MetaStore连接串写IP没问题，但HBase的RegionServer注册用的是主机名，直接报错。
• 免密登录：启动脚本依赖SSH，没配好免密会卡在输密码。生成密钥后用ssh-copy-id分发，别忘了本机也要能免密登录自己。
• 时间同步：集群节点时间差超过阈值会导致认证失败和任务异常。用时间同步服务把三台机器对齐，这个小细节坑过我不止一次。
• 内存分配：YARN的yarn.nodemanager.resource.memory-mb默认值往往偏大，虚拟机内存小的时候容器起不来，日志里只报“Container exited”，看不到根因。调小这个值，同时调小mapreduce.map.memory.mb。

格式化NameNode这一步也有讲究：只在第一次搭建时执行，重复格式化会导致clusterID不一致，DataNode拒绝启动。真遇到了，要么清空数据目录重来，要么手动对齐clusterID。

6.2 参数不要死记，记住它在调什么

考试里出现参数题，很多人靠死背。我更建议记住“这个参数影响什么维度”。

• dfs.replication：副本数，影响可靠性和存储开销。
• dfs.blocksize：块大小，影响并行度和元数据量。
• mapreduce.job.reduces：Reduce个数，影响输出文件数和单任务数据量。
• hive.exec.dynamic.partition.mode：动态分区模式，默认strict要求至少一个静态分区，改成nonstrict才能全动态。
• spark.sql.shuffle.partitions：Shuffle后分区数，默认200，小数据量下这个值太大会产生大量小文件。

记住“影响什么”，题目换个说法你也能对上。死记数字，题干一变就废。

6.3 复习节奏：三轮而不是一遍到底

我的安排是三轮，每轮目标不同：

• 第一轮（约两周）：过一遍全部知识点，不求记住，只求建立索引。看完一章就在笔记上写三行：这章解决什么问题、核心组件是谁、最容易错的地方在哪。
• 第二轮（约一周）：按三条主线横向串。比如把HDFS、HBase、Hive的存储相关部分放一起对比，把MapReduce、Spark、Flink的计算模型放一起对比。横向对比最能暴露理解漏洞。
• 第三轮（约三到五天）：刷题加回看错题。错题不要只看正确答案，要写下“我为什么选错”，是概念不清还是审题问题。这一步的收益比再刷一百道新题都高。

刷题时我有个习惯：凡是做错的题，回到笔记里找到对应章节，用一句话把这个知识点重新表述一遍。如果表述不出来，说明那一章得重看。这个方法很土，但确实能把“似懂非懂”揪出来。

还有一点，做题时注意题干里的限定词。“默认情况下”“最优方案”“最直接的原因”，这些词决定了答案的方向。同一个知识点，问“是什么”和问“为什么”答案完全不同。我在模拟题里栽过好几次，明明知道原理，但因为没看清问的是“根本原因”而选了表面现象。

最后分享一个小技巧：把这套知识体系里的组件按“数据流向”串成一条线，从采集（Flume/Sqoop）到存储（HDFS/HBase）到计算（MapReduce/Hive/Spark/Flink）到消息（Kafka）到协调（ZooKeeper），在纸上画一遍。画得出来，说明你脑子里有的是一张网，而不是一堆散点。画不出来的地方，就是下一轮该重点看的地方。我自己画到第三遍时，才真正把YARN的调度和Spark的资源申请对上号——原来Spark on YARN模式下，Spark的Executor就是跑在YARN的Container里的，Driver可能跑在客户端也可能跑在集群里，这个对应关系一清楚，两章的知识就合并成一章了。