HCIA-Big Data 大数据组件最小知识集与关键参数速查

说实话，这份笔记最初只是为了应付考试才记的，但整理完才发现，HCIA-Big Data 这套大纲其实把大数据组件的“最小可用知识集”串得挺完整——从 HDFS 的块与副本，到 YARN 的资源调度，再到 Hive、HBase、Spark、Kafka 和流计算的分工。它解决的问题是：面对一堆组件名词，你到底该先学哪个、每个组件最关键的三个参数是什么、面试和上机时最常被问的坑在哪。适合两类人看，一类是刚转大数据、想把概念和配置对上的新手，另一类是有一定开发经验、但知识点零散、需要一个骨架把它们串起来的人。我这份笔记就是按“能跑起来、能算得出、能排得掉”的标准写的，不带一句背了也没用的定义。

1. 这份笔记的知识地图与取舍逻辑

1.1 考试大纲背后真正的主线

刚拿到大纲的时候我也有点懵，组件列表拉出来一串，HDFS、YARN、MapReduce、Hive、HBase、Spark、Flink、Kafka、Flume、Sqoop、ZooKeeper 全在里面，看上去像是要你把整个生态圈背一遍。但把大纲拆开看，它其实只讲了一条主线：数据怎么存下来、怎么算出来、怎么在组件之间流动。

存的部分是 HDFS 和 HBase，算的部分是 MapReduce、Spark、Flink，流动的部分是 Flume、Sqoop、Kafka。ZooKeeper 是那个“不直接干活但谁都离不开”的协调者。数据仓库建模、数据湖概念属于“知道概念、能说清区别”的层次，不会深挖到建模范式。这个判断很重要，因为它决定了你的时间怎么花：HDFS 和 YARN 的机制要吃透，因为后面所有组件都架在这两层之上；Flume、Sqoop 这类工具，知道它的定位和三个核心参数就够了。

我个人的复习比例大概是四三二一：四成时间给存储和资源调度（HDFS + YARN + HBase 基础），三成给计算引擎（MapReduce 原理 + Spark 核心），两成给数据集成与消息队列，一成留给概念性内容。这个比例不是官方给的，是我刷完题后回头总结的，题目密度基本就是这个分布。

1.2 为什么我坚持先啃 Hadoop 而不是直接上 Spark

身边不少人是直接跳到 Spark 的，理由是“MapReduce 已经过时了，学它浪费时间”。这个想法在开发场景下没太大问题，但在理解层面会留下一个坑：Spark 的 Stage 划分、窄依赖宽依赖、Shuffle 的代价，本质上是 MapReduce 那套 Shuffle 模型的延续和改良。你没弄明白 MapReduce 为什么要排序、为什么要溢写磁盘，就很难理解 Spark 为什么把reduceByKey和groupByKey区分得那么清楚。

打个生活化的比方，MapReduce 像是把一堆快递按目的地分拣：先每个人手里分一部分，贴上目的地标签，然后按目的地重新排队，最后每个目的地一个人统一签收。这个“重新排队”的过程就是 Shuffle，它必须发生在磁盘上，因为数据量可能大到你内存装不下。Spark 做的事情是尽量让数据留在内存里做局部聚合，能省一次磁盘往返就省一次。你要是不懂分拣那一步的痛，就不会懂 Spark 优化的爽点在哪。

所以我的建议是：MapReduce 不用会写完整程序，但一定要能手画一遍 Shuffle 的执行流程，能说出溢写、合并、拉取、归并这几个阶段各自发生了什么。这一步花两三个小时，后面省下的时间远不止这些。

1.3 复习排期与每天的实际投入

我当时的排期是这样的，仅供参考，因为每个人的底子差别很大：

注意这张表里“达标标准”那一列才是重点，时长只是参考。很多人复习的误区是把“看过”当成“会了”，我踩过这个坑：HDFS 写流程我看了三遍视频，自以为懂了，结果手画的时候卡在ack的应答顺序上，才发现自己一直理解反了。检验方式很粗暴——合上资料，拿张纸，把流程画出来讲给自己听，讲不顺的地方就是没懂的地方。

2. 存储底座：HDFS 与 YARN 的机制拆解

2.1 HDFS 的块、副本与机架感知

HDFS 最基础也最容易被轻视的概念是“块”。默认块大小在新版本里是 128MB，老版本是 64MB，这个数字不是随便定的。它的设计逻辑是：让磁盘的寻址时间占传输时间的比例足够小。假设一次磁盘寻址大约 10ms，传输速率 100MB/s，那么传输 100MB 需要 1 秒，寻址时间占比约 1%，这个量级是可以接受的。如果把块设成 1MB，寻址 10ms、传输 10ms，一半时间都在找位置，效率就崩了。

所以块不能太小。但也不能无限大，因为块太大意味着一个任务的并行度上不去，而且失败重试的代价变高。128MB 是这两者之间的一个平衡点，实际部署时如果磁盘顺序读性能很好，调到 256MB 也常见。

副本数默认 3，这是可用性和存储成本的折中。3 副本意味着存储开销是原始数据的 3 倍，但能容忍两个节点同时挂掉。副本放置遵循机架感知策略：第一个副本放在客户端所在节点（如果客户端不在集群内，就随机选一个不那么满的节点），第二个副本放在另一个机架的不同节点上，第三个副本放在与第二个副本同机架的另一个节点上。这个策略的目的是：既要防节点故障，也要防整个机架断电。

提示：机架感知不是自动生效的，需要配置拓扑映射脚本或者手动指定节点与机架的对应关系。很多实验环境里所有节点都算在同一个默认机架下，这时候三副本其实全在一个机架里，机架感知形同虚设。做实验时这个点不用纠结，但面试被问到要能说清。

2.2 NameNode 的内存账本：一次真实的容量估算

这是我觉得整个认证里最有价值的一个知识点，因为它把“理论”变成了“能算的数”。NameNode 把所有元数据放在内存里，每条元数据大约占用 150 字节，这个数字是业界长期实践得出的经验值，包含对象头、引用和字段开销。需要计入的对象有三类：文件、目录、块。

估算公式可以写成：

NameNode 内存 ≈ (文件数 + 目录数 + 块数) × 150 字节 实际配置堆内存 ≈ 上述结果 × 1.5（预留 GC 与突发空间）

举个具体的例子。假设集群要存 1 亿个文件，平均每个文件 100MB，块大小 128MB，那么每个文件基本只占 1 个块（小于块大小的文件也占 1 个块）。

• 文件对象：1 亿 × 150B = 15GB
• 块对象：1 亿 × 150B = 15GB（每个块通常对应两条记录，粗略按 1.5 倍算更保守）
• 目录数：假设平均每 1000 个文件一个目录，约 10 万个 × 150B ≈ 15MB，可忽略但别忘

合计约 30GB 出头，再乘 1.5 的冗余系数，堆内存至少要 45GB 左右。这就是为什么大集群的 NameNode 动辄配 128GB 内存。

反过来推，如果一台 NameNode 配了 64GB 堆内存，按 150 字节、1.5 系数算：

可管理对象数 ≈ 64GB × 1024 × 1024 × 1024 / (150 × 1.5) ≈ 3.05 亿个对象

也就是说理论上能撑住约 1.5 亿个文件（每个文件对应文件对象 + 块对象，约两个对象）。这个计算过程建议你亲手算一遍，考试里类似的估算题出现频率不低。

顺带引出小文件问题：如果 1 亿个文件每个只有 1MB，存储上只占 100TB，但元数据开销和 1 亿个 100MB 的文件一模一样。这就是为什么生产环境要做小文件合并，通常用archive归档或者写入时做合并。小文件之痛不在于存储，在于 NameNode 内存和后续任务的切片数量。

2.3 YARN 的资源账本：NodeManager 内存怎么配

YARN 的模型可以用一句话概括：ResourceManager 管全局资源账本，NodeManager 管单机资源，ApplicationMaster 是每个应用自己派出的“包工头”，Container 是实际干活的“工位”。

配置里最容易出错的是yarn.nodemanager.resource.memory-mb，它表示这台 NodeManager 最多能支配多少内存给 Container。常见错误是直接填物理内存总量，结果系统本身、其他进程一挤，节点直接 OOM 或者被系统杀掉进程。

正确做法是先预留：操作系统本身要留 4~8GB，如果有 DataNode、NodeManager 之外的常驻服务（比如 HBase 的 RegionServer），还要再扣掉。业界常见的经验比例是可用内存的 75%~80%。

举个具体配置。一台 128GB 内存、32 核的机器，同时跑 DataNode、NodeManager、RegionServer：

• 系统预留：8GB
• RegionServer 预留：24GB
• 剩余：96GB，按 80% 给 YARN，约 76GB，取整配 76800MB

核数方面，yarn.nodemanager.resource.cpu-vcores一般配置成物理核数的 1~2 倍（考虑超线程），这里 32 核可以配 64。那么内存与 vcore 的比例就是 76800/64 = 1200MB 每核。这个比例没有标准答案，但要和yarn.scheduler.minimum-allocation-mb、maximum-allocation-mb对得上。

假设最小分配 1024MB，最大分配 8192MB，那么：

• 一台机器最多能起的 Container 数 = 76800 / 1024 = 75 个（受内存限制）
• 单个 Container 最大能申请 8192MB，如果一个任务要 16GB，会直接报“超出最大分配”的错误

这个报错我遇到过不止一次，本质是maximum-allocation-mb配小了，而不是集群资源不够。新手很容易往“资源不足”的方向查，白折腾半天。

注意：yarn.nodemanager.resource.memory-mb改小之后，已经在跑的 Container 不会自动缩容，需要重启 NodeManager。而且如果 ApplicationMaster 提交时申请的资源超过队列上限，会在 RM 层就被拒，错误信息里会出现队列名，看到队列名就该往调度器配置上想。

2.4 部署实操：从伪分布式到完全分布式的关键配置

实验环境我建议先跑伪分布式，把配置项认全，再上三节点的完全分布式。伪分布式的核心就四个配置文件，全在etc/hadoop下：

core-site.xml里指定默认文件系统地址，hdfs-site.xml里指定副本数和 NameNode、DataNode 的本地目录，mapred-site.xml指定用 YARN 跑 MapReduce，yarn-site.xml配置 RM 地址和辅助服务。

关键的一步很多人会漏：workers（老版本叫slaves）文件里要写 DataNode 的主机名，一行一个；同时hdfs-site.xml里的dfs.replication在伪分布式下必须改成 1，否则会因为凑不齐 3 个副本一直报副本不足的警告。

完全分布式另外要做三件事：

1. 所有节点的core-site.xml里用主机名而不是 IP，并且/etc/hosts要能解析
2. 配置 SSH 免密，NameNode 到所有 DataNode 要能免密登录，否则启动脚本会卡在输入密码
3. 第一次启动前必须格式化 NameNode，且只能格式化一次，重复格式化会导致 clusterID 不一致，DataNode 起不来

第三条是经典坑。如果你改了配置想“重新来一遍”，正确做法是先把所有节点的数据目录清空，再格式化，而不是直接再执行一次格式化命令。clusterID 不一致的报错信息很明确，会提示 DataNode 的 clusterID 和 NameNode 对不上，看到这个就说明该清目录了。

启动顺序也有讲究：先起 HDFS（start-dfs.sh），用jps确认 NameNode、DataNode、SecondaryNameNode 都在，再起 YARN（start-yarn.sh），确认 ResourceManager 和 NodeManager。如果先起 YARN 再起 HDFS，有些版本的 NodeManager 会因为拿不到 HDFS 上的资源目录而报错。

3. 计算层：从 MapReduce 到 Spark 的演进逻辑

3.1 Shuffle 为什么是性能杀手

MapReduce 的 Shuffle 分两端。Map 端把输出先写进环形缓冲区，默认 100MB（mapreduce.task.io.sort.mb），当缓冲区占用达到 80%（mapreduce.task.io.sort.spill.percent）时触发溢写，溢写前会按 key 做一次排序，溢写文件写到本地磁盘。所有溢写文件达到 10 个（mapreduce.task.io.sort.factor）时做一次归并，合并成一个大文件。Reduce 端通过 HTTP 拉取属于自己的分区数据，拉取并发默认 5（mapreduce.reduce.shuffle.parallelcopies），拉下来之后再归并排序，最后交给 reduce 函数。

整个链路里有两处必须落盘：Map 端的溢写、Reduce 端的拉取。这就是为什么 Shuffle 阶段往往是作业耗时的绝对大头。业界的经验是 Shuffle 能占到整个作业时间的 60% 以上，数据量大时更夸张。

理解了这一点，很多优化手段就顺理成章了：增大缓冲区减少溢写次数、提高归并因子减少磁盘往返、用 Combiner 在 Map 端提前聚合减少传输量。Combiner 本质上是一次“迷你 reduce”，前提是你的聚合逻辑满足结合律和交换律，求和可以，求平均值就不行——这点经常被问到。

3.2 Spark 的 DAG 与血缘：为什么它快

Spark 快的核心不是“内存计算”这么一句口号，而是它把整个作业组织成一张 DAG，然后按宽依赖切分成多个 Stage，Stage 内部可以流水线执行，不需要像 MapReduce 那样每个 Map 和 Reduce 之间都强制落盘一次。

RDD 的血缘（lineage）记录的是“我是从哪个 RDD 经过什么变换来的”。这个设计的好处是容错：某个分区的数据丢了，不需要像 MapReduce 那样重跑整个上游任务，只要按血缘往上追溯到最近的一个可用分区，重算那一小块就行。代价是血缘链太长时重算成本高，所以关键节点要做checkpoint或persist。

宽依赖和窄依赖的区分是必须掌握的。窄依赖指父 RDD 的一个分区只对应子 RDD 的一个分区，比如map、filter、union，可以流水线执行。宽依赖指父 RDD 的一个分区会被多个子分区使用，比如groupByKey、reduceByKey、join，需要 Shuffle，会切分 Stage。

一个常见的实操问题：repartition和coalesce有什么区别。前者一定触发 Shuffle，可以把数据均匀打散；后者默认不 Shuffle，只能减少分区数，可能造成数据倾斜。如果你要把分区数从 200 减到 20，用coalesce(20)就够了；如果是从 20 扩到 200，必须用repartition。

3.3 算子选型的三个真实准则

第一，能用reduceByKey就别用groupByKey。前者会在 Map 端做局部聚合（相当于自带 Combiner），后者会把所有 value 原封不动地拉到一个节点上再聚合。数据量一大，groupByKey的内存压力和网络传输量都高一个量级。这个道理和 MapReduce 的 Combiner 是一回事。

第二，大表 join 小表优先用广播。默认情况下spark.sql.autoBroadcastJoinThreshold是 10MB，小于这个阈值的表会被自动广播到每个 Executor，避免 Shuffle。如果你的小表刚好 15MB 被卡在阈值外，可以把阈值调大，但注意别调太狠，广播变量存在 Executor 内存里，表太大反而会 OOM。

第三，数据倾斜优先用加盐而不是无脑调大并行度。倾斜的典型表现是某个 Task 处理的数据量是其他 Task 的几十倍，日志里能看到个别 Task 拖尾。加盐的做法是给倾斜的 key 拼一个随机前缀，把它打散成 N 份，聚合完再拆掉前缀做二次聚合。这个方案比单纯增加分区数有效得多，后者只是把倾斜摊薄，治标不治本。

3.4 一段可以复现的 Spark 统计实操

下面这段是我做词频统计时的最小可运行代码，用来验证环境是否正常：

from pyspark import SparkContext, SparkConf conf = SparkConf().setAppName("wordcount_demo").setMaster("local[4]") sc = SparkContext(conf=conf) rdd = sc.textFile("hdfs:///tmp/input/sample.txt") counts = (rdd.flatMap(lambda line: line.split()) .map(lambda w: (w, 1)) .reduceByKey(lambda a, b: a + b) .sortBy(lambda x: x[1], ascending=False)) for word, cnt in counts.take(10): print(word, cnt) sc.stop()

跑之前确认三件事：输入路径在 HDFS 上真实存在、setMaster用的是local[4]方便本地调试、输出用take而不是collect，避免把全量数据拉回驱动端。我见过有人直接collect一个几千万条的结果，驱动端内存瞬间打满。

4. 存储与查询：Hive、HBase 与数仓分层

4.1 Hive 的分区、分桶和文件格式选择

Hive 的本质是把 SQL 翻译成分布式计算任务，数据仍然存在 HDFS 上。它的三个核心概念是表、分区、分桶，理解它们的区别就理解了 Hive 的性能关键。

分区是在目录层面做切分，每个分区对应 HDFS 上的一个子目录。查询时带上分区条件可以只扫对应目录，这就是所谓“分区裁剪”。分区字段的选择原则是基数适中、查询中高频作为过滤条件，比如日期、地区。千万别拿用户 ID 这种高基数字段做分区，否则会产生海量小目录，NameNode 直接遭殃。

分桶是在文件层面做切分，按某个字段的哈希值把数据分到固定数量的桶文件里。分桶的好处是采样快、join 时可以只对对应的桶做匹配。分桶字段一般用 join 键，桶数是集群规模的整数倍比较合适，业界常见的是 2 的幂次。

文件格式上，生产环境基本是 ORC 或 Parquet 二选一。它们都是列式存储，压缩比高，查询时只读需要的列。相比之下 TextFile 可读性好但体积大、解析慢，适合做中间过渡。我在实验环境里对比过同一份数据，TextFile 大概 1.2GB，转成 ORC 加压缩后不到 200MB，查询扫描量差距非常直观。

4.2 HBase 的 RowKey 设计：热点是怎么来的

HBase 是按 RowKey 字典序排列的，数据按 RowKey 范围划分成 Region，每个 Region 由一个 RegionServer 负责。这个设计带来一个直接后果：如果你用连续递增的 ID 作为 RowKey，所有新写入都会落到最后一个 Region 上，其他机器全部闲着。这就是所谓的写热点。

我在实验环境里踩过一次，用时间戳作为 RowKey 前缀，连续写入时监控面板上 RegionServer 的请求量极度不均，一台机器 CPU 跑满，其他几台几乎为零。

解决思路有三种，按优先级排：

• 加盐（Salting）：在 RowKey 前拼一个随机前缀，比如 0~9 的随机数，把写入打散到 10 个 Region。代价是读的时候要按前缀扫 10 次再合并。
• 哈希：对主键做 MD5 取前几位作为前缀。优点是确定性，同一个 ID 永远落同一个前缀；缺点是前缀无业务含义，范围查询不方便。
• 反转：把 ID 倒序。适合 ID 递增但访问模式是“按 ID 精确查询”的场景，简单有效。

另外两个经验值：RowKey 长度建议控制在 16 字节以内，因为 RowKey 会在每个单元格中冗余存储一份，太长会导致存储膨胀；列族数量控制在 2~3 个以内，因为列族是在 Region 层面一起刷盘的，列族太多会导致大量小文件和不必要的 IO。

4.3 数仓分层：为什么非要拆成四层

数仓分层的经典做法是 ODS、DWD、DWS、ADS 四层。很多人第一次看到会觉得这是“过度设计”，一张表能搞定的事为什么要拆四张表。实际做过之后会发现，分层的价值不在当下，而在需求变化的时候。

ODS 层贴源，几乎不做加工，保留原始数据的完整面貌。它的作用是“有问题能回溯”，当上游数据口径变了，你还能拿 ODS 重算。

DWD 层做清洗和规范化，去重、补空、统一编码，把不同来源的数据对齐到同一个口径。这一层的工作量往往最大，但也是最值钱的，因为它决定了后面所有指标的可信度。

DWS 层按主题做轻度汇总，比如按天、按用户维度做宽表。它的作用是避免 ADS 层重复计算，多个报表要用同一个口径时直接复用。

ADS 层面向具体应用，直接对接报表和接口。

分层带来的一个隐性成本是数据冗余和链路变长，所以小团队或者数据量不大的场景，常常简化成三层甚至两层。我的看法是：分层不是目的，口径一致和数据可回溯才是，只要这两点能满足，层数可以谈。

5. 实时链路：Kafka 与流计算的关键参数

5.1 Kafka 的分区数怎么算才不拍脑袋

Kafka 的核心概念里，分区数是最需要量化决策的一个。分区决定了并行度上限，消费者数量超过分区数时，多出来的消费者会空闲。

一个可用的估算方法是：

分区数 = max(目标吞吐 / 单分区吞吐, 目标消费者并行度) 单分区吞吐经验值：普通磁盘 10~50 MB/s，SSD 可以更高

假设目标写入吞吐是 200MB/s，单分区实测能跑 20MB/s，那么至少 10 个分区。如果下游有 20 个消费线程，那就得开到 20。这两个条件取最大值。

分区数不是越多越好。分区多了，每个 broker 上要维护的文件句柄变多，副本同步的压力也变大，而且分区数增加后不可逆（减少分区会丢数据语义），所以宁可一开始估算保守一点，留出扩展空间。

副本方面，生产环境一般replication.factor=3，配合min.insync.replicas=2和生产者端acks=all。这三个参数是一组：acks=all表示所有 ISR 都确认才算成功，min.insync.replicas=2表示至少要两个副本在线才接受写入。如果 ISR 数量掉到 2 以下，写入会直接失败——这个设计是故意的，宁可不可写也不能丢数据。

5.2 Checkpoint 与状态：流计算的可靠性底线

流计算里最容易糊涂的是时间语义和状态。事件时间指的是数据本身携带的时间，处理时间指的是机器处理它的时间。真实场景里数据会乱序、会延迟，所以需要 Watermark 来界定“什么时候可以认为这个时间窗口的数据到齐了”。

Watermark 的本质是一个延迟容忍度。设 Watermark 延迟 5 秒，意思是“我等到事件时间推进到当前最大时间减 5 秒，才认为更早的窗口可以触发计算”。这个值设太小，迟到数据会被丢弃；设太大，结果输出会延迟。

状态的可靠性靠 Checkpoint 保证。开启 Checkpoint 后，系统会定期把算子状态做快照存到持久化存储上，作业失败时从最近一次快照恢复。这里有个权衡：间隔太短，快照本身的开销大；间隔太长，故障恢复时重算的数据多。常见配置是 1~5 分钟一次，具体看数据量和能容忍的重复处理量。

要做到端到端的精确一次，还需要下游支持事务或者幂等写入。两阶段提交的思路是：Checkpoint 完成时，把这一批数据一次性提交到下游。很多数据库连接器都实现了这套机制，但需要确认目标端是否支持事务——比如往文件系统写，一般只能做到至少一次，靠文件名或分区覆盖来实现幂等。

5.3 一条最小实时链路的搭建步骤

我用一个“日志采集到实时计数”的链路来验证各部分能否串起来，步骤大致如下：

1. 数据源产生日志，写入消息队列的某个 Topic，Topic 设 3 个分区，副本 2
2. 流计算作业从该 Topic 消费，按事件时间开 1 分钟滚动窗口做计数
3. 开启 Checkpoint，间隔 60 秒，状态后端用文件系统
4. 结果写入下游存储，采用覆盖写实现幂等
5. 用监控面板观察消费延迟和 Checkpoint 时长

这里最容易出问题的是第 2 步的时间语义。如果日志里没有可靠的时间字段，只能用处理时间，那么结果会受作业重启影响，不是严格准确的。这个问题在实验环境里不明显，但生产环境里会被业务方追着问。

另外一个实操细节是消费位点的提交方式。手动提交配合 Checkpoint 是更稳的做法，自动提交在作业失败时可能丢一批或者重复一批。这个取舍要看业务能不能接受重复。

6. 实验环境与排查实录

6.1 实验环境准备的清单式核对

我把每次搭环境都会核对的项目整理成一张表，照着过一遍基本不会漏：

时钟同步这一条特别容易被忽略。分布式系统里很多机制依赖时间单调性，节点时间偏差大了之后会出现各种莫名其妙的认证失败，报错信息还完全指不到时间上。建议在搭环境的第一步就把时间同步做掉。

6.2 报错速查：几个高频问题的定位路径

下面这几个是我实际遇到过、并且在社区里被问得最多的：

排查的通用思路是“从下往上”：先看进程在不在（jps），再看端口通不通，再看日志里第一个 ERROR，最后才看配置。很多人一上来就怀疑配置，结果发现是进程压根没起来。日志里第一个 ERROR 往往才是根因，后面的报错都是连锁反应。

6.3 我踩过的三个坑和对应心得

第一个坑是容量估算只看存储不看元数据。早期规划集群时我按数据总量除以单机磁盘算节点数，完全没考虑 NameNode 内存和小文件问题，结果文件数一多，NameNode 成为瓶颈。后来养成习惯：规划存储时同时列出“数据总量”和“文件数量”两个指标，后者决定 NameNode 规格。

第二个坑是盲目调大并行度。任务慢的时候第一反应是把分区数从 200 调到 2000，结果任务更慢了。原因是每个分区的启动开销和小文件写入开销叠加，反而拖垮了整体。后来我的做法是先看 Spark UI 里的 Task 耗时分布，如果大部分 Task 都很快、个别极慢，那是倾斜问题，调并行度没用；如果所有 Task 都均匀地慢，才考虑扩并行度。

第三个坑是把“至少一次”当成“精确一次”。流处理作业重启后发现有重复数据，查了半天才发现下游写入是追加模式，没有做幂等。这件事让我记住一个原则：可靠性是端到端的概念，链路上任何一环不满足，整条链路就不成立。评估方案时不能只看计算引擎支不支持，要一路看到最终的存储。

最后分享一个我自己的复习小技巧：把每个组件的关键参数写成一张卡片，正面写参数名，背面写默认值、作用、调大调小的影响。考前一周每天翻一遍，比重新看视频效率高得多。参数背后的逻辑通了，概念题和场景题基本就是同一套东西换个问法。