大数据面试题库 · 数据开发学习站

本章目标：用一套可复述的答题框架，覆盖数据开发实习的高频面试题，并能诚实说明自己的实操边界。前置知识：学过 SQL、数仓分层，跑过项目；大数据组件没有集群经验也可以学。

1. 答题方法

1.1 三段式

每道题按“是什么、解决什么、我的实操边界”回答。

是什么：一句话定义，先给结论。
解决什么：它为什么存在，解决什么业务或工程问题。
我的实操边界：做过什么、没做过什么。不会就承认，不要编。

面试官更看重结构清楚、边界诚实，而不是背得多。

1.2 时间控制

简单概念题：40 到 60 秒。
原理题：90 秒，先结论再展开两层。
场景题：先说思路，再写关键 SQL 或步骤，最后说边界。

被打断不一定是答错，可能只是面试官赶时间。停下来听问题，不要抢话。

1.3 不会怎么办

“这部分我只了解概念，没有实际做过。我的理解是……如果让我做，我会先…… ”

承认边界，再展示思路。比硬编一个错误答案安全。

1.4 题目分布

模块	题数	重点
数仓	8	分层、建模、拉链表、口径、质量
Hive	7	内外部表、分区分桶、动态分区、小文件、倾斜
Spark	7	shuffle、倾斜、cache、广播、惰性求值
Kafka	5	性能、可靠性、顺序、rebalance
Flink	5	流批、水位线、窗口、状态、精确一次
场景题	5	日活买家、首购 cohort 回购、TopN、对账、补数

2. 数仓

2.1 数仓为什么要分层？

问题：ODS、DWD、DWS、ADS 各层职责是什么？不分层会怎样？

答题要点：

是什么：ODS 原样落地，DWD 清洗建模，DWS 轻度汇总，ADS 面向场景出指标。
解决什么：分层解决口径分裂、重复清洗、性能浪费和问题难追溯。ODS 保真，DWD 保准，DWS 保复用，ADS 保好用。
实操边界：我在项目里用 DuckDB 实现了四层，能解释每层行数和口径；没有生产集群调度经验。

追问：小项目可以少分层吗？可以合并 DWS，但 ODS 和 DWD 的职责不要混，否则原始证据和清洗口径会纠缠在一起。

2.2 维度建模和范式建模有什么区别？

问题：数仓为什么常用维度建模，而不是完全按 3NF 建？

答题要点：

是什么：范式建模按实体关系拆表，减少冗余，适合 OLTP；维度建模分事实表和维度表，面向分析查询。
解决什么：分析场景需要简单、少 JOIN、易理解。维度建模牺牲部分存储冗余，换取查询性能和可读性。
实操边界：项目采用维度建模，订单明细是事实表，用户、商品、商家是维度表；我没有做过企业级总线矩阵。

追问：维度建模会不会数据不一致？会，所以要做一致性维度和统一口径，不能每个集市各建一套用户维度。

2.3 星型模型和雪花模型有什么区别？

问题：星型和雪花怎么选？

答题要点：

是什么：星型的维度表直接连事实表，维度不再拆；雪花的维度表继续规范化，拆成多级子维度。
解决什么：星型查询简单、JOIN 少、性能好；雪花节省存储、维度更规范，但 JOIN 层数多。
实操边界：项目更接近星型，并且把品类、城市、商家名退化进明细；没有做多级雪花维度。

追问：为什么实际数仓星型更多？因为分析查询对性能和易用性更敏感，维度冗余的成本通常可接受。

2.4 事实表有哪三种类型？

问题：事务型、周期快照、累积快照分别是什么？

答题要点：

是什么：事务型事实表一行一个业务事件，如订单明细；周期快照按固定周期记录状态，如每日库存；累积快照记录流程多个里程碑，如订单从下单到签收。
解决什么：事务型适合明细分析，周期快照适合存量指标，累积快照适合流程时长和漏斗。
实操边界：项目主要是事务型事实表；我没有落地过周期快照和累积快照。

追问：订单履约分析用哪种？累积快照更合适，一行订单记录下单、支付、发货、签收多个时间点。

2.5 拉链表怎么更新，怎么查历史？

问题：SCD2 拉链表的原理是什么？

答题要点：

是什么：每条维度记录带 start_date 和 end_date，记录状态有效期；未变化的记录保持，变化的关闭旧记录并插入新记录。
解决什么：支持查询任意历史日期的维度状态，比如“用户下单时是什么会员等级”。
实操边界：我理解更新和查询逻辑，也写过示例；项目没有落地拉链表，这是明确的改进项。

追问：怎么查某天的历史状态？WHERE dt BETWEEN start_date AND end_date；更新时用 MERGE 或全量对比后覆盖分区。

2.6 指标口径怎么设计？

问题：一个 GMV 指标，需要写清哪些内容？

答题要点：

是什么：原子指标、派生指标、修饰词、时间粒度。GMV 要写清公式、过滤条件、时间范围和币种。
解决什么：避免同一个指标多种算法。口径要落文档、落常量，全链路只认一份。
实操边界：项目 GMV 定义为有效明细 price * quantity + freight，排除取消单和未来日期，截止日写成常量；我负责了这份口径文档。

追问：含不含运费？两种都可以，但必须固定并写清。项目整体 GMV 含运费，品类占比用不含运费商品金额。

2.7 怎么保证数据质量？

问题：数据开发如何做质量校验？

答题要点：

是什么：探查、清洗、校验、监控四道关。常用规则有主键唯一、外键完整、金额非负、行数守恒、指标一致、波动监控。
解决什么：让“数据可信”可验证、可复现，而不是靠感觉。
实操边界：项目实现了前几类校验并随构建自动执行；没有接入生产告警平台。

追问：检查失败怎么办？先定位影响范围，再修复重跑，最后补规则；不能直接改基准值让检查变绿。

2.8 全量同步和增量同步怎么选？

问题：什么时候全量，什么时候增量？

答题要点：

是什么：全量每次拉完整数据，增量只拉新增或变更。增量常用时间戳、自增 ID、binlog 或 CDC。
解决什么：全量简单但成本高；增量省资源，但要处理迟到、重复、删除和幂等。
实操边界：项目数据量小，采用全量重跑；我理解增量分区和补数流程，没有维护过生产同步任务。

追问：增量怎么保证不重复？按业务主键去重，写入用 MERGE 或覆盖分区，并记录同步位点。

3. Hive

3.1 内部表和外部表有什么区别？

问题：DROP TABLE 时两者有什么不同？ODS 为什么用外部表？

答题要点：

是什么：内部表由 Hive 管理数据和元数据；外部表只管理元数据，数据在指定 LOCATION。
解决什么：内部表删除会连数据一起删；外部表只删元数据。ODS 是原始证据，必须防止误删。
实操边界：我写过 Hive 风格外部表和分区 DDL，跑过本地模拟；没有生产 Hive 集群经验。

追问：外部表删了怎么恢复？重建外部表指向原目录，再 MSCK REPAIR TABLE 修复分区。

3.2 分区和分桶有什么区别？

问题：分区和分桶分别解决什么问题？

答题要点：

是什么：分区按字段值建目录，如 dt=2018-08-01；分桶按哈希把文件分成固定数量，如 CLUSTERED BY (customer_unique_id) INTO 16 BUCKETS。
解决什么：分区用于裁剪扫描范围；分桶用于采样、桶内 JOIN 和均衡数据。
实操边界：项目用过按天分区；分桶只了解原理，没有实际建过。

追问：分区字段怎么选？选查询过滤频繁、基数适中的字段；基数太高会产生大量小文件和元数据压力。

3.3 动态分区怎么写？有什么坑？

问题：Hive 动态分区的语法和注意事项。

答题要点：

是什么：分区值由 SELECT 最后一列动态产生，不需要手写每个分区。
解决什么：一次写入多个日期分区，适合按天增量。
实操边界：我在 Hive 演示脚本里写过动态分区，理解开关和列顺序要求；没有在生产集群跑过。

追问：报错怎么查？先看是否执行了 set hive.exec.dynamic.partition=true 和 nonstrict，再看分区列是否在最后一列，最后看分区数是否超过上限。

3.4 小文件问题怎么解决？

问题：Hive 表为什么会产生小文件？有什么影响？

答题要点：

是什么：大量小于块大小的文件，通常来自频繁写入、分区过细、Reduce 数过多。
解决什么：小文件增加 NameNode 元数据压力和任务启动开销，降低扫描效率。
实操边界：项目数据量小，没有实际处理过小文件；我了解合并和参数调优思路。

追问：怎么处理？写入前控制 Reduce 数，开启小文件合并，定期 INSERT OVERWRITE 重写分区，或使用 Hive ACID 合并。

3.5 Hive 数据倾斜怎么处理？

问题：分组或 JOIN 时少数 key 特别慢，怎么办？

答题要点：

是什么：某些 key 数据量远大于其他 key，落到同一个 Reduce 或 Spark 分区。
解决什么：常见原因是空值集中、热点商品、JOIN 键分布不均。解法有过滤空值、热点 key 加盐、小表广播、拆分大 key、提高并行度。
实操边界：项目数据量小，没有真实集群倾斜案例；我理解原理和常见参数，但没有调过生产任务。

追问：空值导致倾斜怎么办？无业务意义就过滤；有业务意义就给空值加随机后缀打散，聚合后再合并。

3.6 lateral view 是干什么的？

问题：lateral view explode 怎么用？

答题要点：

是什么：把数组或 Map 列展开成多行，常配合 explode 使用。
解决什么：处理一行包含多个元素的数据，比如订单商品数组、用户标签数组。
实操边界：项目数据是扁平 CSV，没有实际使用；我理解语法和典型场景。

追问：举个例子？SELECT order_id, item FROM orders LATERAL VIEW explode(items) t AS item，一行订单会按商品展开成多行。

3.7 order by、sort by、distribute by、cluster by 有什么区别？

问题：Hive 四种排序/分布写法怎么区分？

答题要点：

是什么：ORDER BY 全局排序，通常一个 Reduce；SORT BY 每个 Reduce 内部排序；DISTRIBUTE BY 按字段哈希分发；CLUSTER BY 等于 DISTRIBUTE BY 加 SORT BY。
解决什么：全局排序代价高，大数据量下常用局部排序和分布来平衡性能。
实操边界：项目用 DuckDB 的 ORDER BY 和窗口排序；Hive 四种写法只了解语义，没有大数据量调优经验。

追问：要全局有序但数据量大怎么办？先分区裁剪，再控制输出规模；必须全局排序时接受单 Reduce 的代价或改用分布式排序方案。

4. Spark

4.1 shuffle 为什么是性能瓶颈？

问题：Spark 的 shuffle 做了什么？为什么慢？

答题要点：

是什么：宽依赖需要把数据按 key 重新分发，产生磁盘写、网络传输和反序列化。
解决什么：shuffle 支撑 groupByKey、reduceByKey、JOIN 等跨分区操作，但代价高。
实操边界：项目用 DuckDB，没有跑过大规模 Spark shuffle；我理解宽窄依赖和常见优化。

追问：怎么减少 shuffle？提前聚合、广播小表、按分区键设计、避免不必要的 repartition，并控制分区数。

4.2 Spark 数据倾斜怎么处理？

问题：少数 task 处理大量数据，怎么定位和解决？

答题要点：

是什么：key 分布不均，导致少数分区远大于其他分区。
解决什么：加盐打散热点 key、广播小表、拆分大 key、过滤异常空值、提高并行度，Spark 3 可开 AQE。
实操边界：我没有生产 Spark 倾斜调优经验；项目数据量小，只理解原理和常见手段。

追问：怎么确认是倾斜？看 Spark UI 的 task 输入大小、shuffle read 和运行时间分布，少数 task 明显偏大。

4.3 cache 和 persist 什么时候用？

问题：cache() 和 persist() 的区别？什么时候不该用？

答题要点：

是什么：cache() 默认 MEMORY_AND_DISK，persist() 可选存储级别；都是惰性的，遇到 action 才真正缓存。
解决什么：同一份数据被多次复用时，避免重复计算。
实操边界：项目没有 Spark 缓存调优；我理解适用场景和 unpersist 的必要性。

追问：什么时候不该缓存？只使用一次、数据量过大、缓存后内存不足导致频繁溢写时，不该缓存。

4.4 broadcast join 适用什么场景？

问题：广播 JOIN 的原理和风险。

答题要点：

是什么：把小表广播到每个 Executor，避免大表 shuffle。
解决什么：小表 JOIN 大表时显著减少网络传输和 shuffle。
实操边界：我了解 broadcast() 提示和阈值配置，没有在生产任务上调过。

追问：小表多大算小？没有固定值，通常几十 MB 到几百 MB，要看 Executor 内存；广播过大可能 driver 或 executor OOM。

4.5 Spark 的惰性求值是什么？

问题：为什么写了 filter 不立刻执行？

答题要点：

是什么：map、filter、join 等 transformation 只构建 DAG，遇到 count、collect、write 等 action 才触发计算。
解决什么：让 Spark 看到完整链路后做合并、裁剪和优化，避免逐步执行。
实操边界：我理解 transformation 与 action 的区别，项目里主要用 DuckDB，没有做 Spark 执行计划调优。

追问：cache 为什么也不立刻生效？它也是惰性的，第一次 action 时才缓存。

4.6 driver 和 executor 分别做什么？

问题：driver 和 executor 的职责和常见 OOM 原因。

答题要点：

是什么：driver 负责解析、调度、维护 DAG 和结果；executor 负责执行 task、缓存数据和读写 shuffle。
解决什么：分工让计算分布式执行，driver 不承担大数据计算。
实操边界：我了解本地模式和集群模式的区别，没有在生产集群排查过 OOM。

追问：collect 大结果为什么会 OOM？结果会拉到 driver，数据量超过 driver 内存就崩；应改用写文件或聚合后再取。

4.7 repartition 和 coalesce 有什么区别？

问题：什么时候用哪个？

答题要点：

是什么：repartition 会全量 shuffle，可增可减分区；coalesce 通常只合并分区，避免 shuffle。
解决什么：repartition 适合调整并行度和打散数据；coalesce 适合写出前减少小文件。
实操边界：我理解语义和代价，没有大规模 Spark 调参经验。

追问：coalesce 减分区会数据倾斜吗？可能，因为它是把相邻分区合并，不是均匀重分布；需要均匀时用 repartition。

5. Kafka

5.1 Kafka 为什么快？

问题：Kafka 高吞吐的原因有哪些？

答题要点：

是什么：顺序写磁盘、页缓存、零拷贝、批量发送与压缩、分区并行。
解决什么：用顺序 I/O 和批量传输降低磁盘与网络开销，支撑高吞吐。
实操边界：我了解架构和原理，没有在生产 Kafka 集群调优；项目未接入 Kafka。

追问：零拷贝是什么？数据从页缓存直接送到网卡，减少用户态和内核态之间的复制。

5.2 Kafka 怎么保证不丢消息？

问题：生产者、Broker、消费者三层怎么防丢？

答题要点：

是什么：生产者 acks=all、重试、幂等；Broker 多副本、min.insync.replicas；消费者手动提交 offset。
解决什么：每一层都可能丢，必须分别配置可靠性。
实操边界：我理解配置含义，没有实际搭过 Kafka 集群或处理过丢消息故障。

追问：acks=all 有什么代价？延迟和资源开销增加，需要在可靠性和吞吐之间权衡。

5.3 Kafka 怎么保证消息顺序？

问题：Kafka 能保证全局有序吗？

答题要点：

是什么：Kafka 只保证单分区内有序，不保证全局有序。
解决什么：同一业务 key 发到同一分区，就能保证该 key 的顺序。
实操边界：我了解分区和 key 的语义，没有生产消费经验。

追问：怎么保证全局顺序？只能单分区，但会牺牲并行度；通常按业务主键保证局部顺序即可。

5.4 什么是 rebalance？

问题：消费者组什么时候 rebalance？有什么影响？

答题要点：

是什么：消费组内分区重新分配的过程，由 coordinator 协调。
解决什么：消费者增减、订阅变化、心跳超时都会触发，保证分区被合理分配。
实操边界：我了解触发条件和影响，没有处理过生产 rebalance。

追问：怎么减少无谓 rebalance？合理设置 session.timeout.ms 和心跳，避免消费线程长时间阻塞，使用 cooperative rebalance，保证消费者稳定。

5.5 消费组和 offset 是什么？

问题：多个消费者如何分工？offset 有什么作用？

答题要点：

是什么：同一消费组内一个分区只分给一个消费者；offset 记录消费位置。
解决什么：消费组实现水平扩展，offset 支持断点续传和重复消费控制。
实操边界：我理解消费组模型，未在生产环境维护过 consumer group。

追问：提交 offset 太早或太晚有什么问题？太早会丢消息，太晚可能重复消费；通常处理完业务再提交，并保证幂等。

6. Flink

6.1 Flink 流处理和批处理有什么区别？

问题：流批一体的核心区别是什么？

答题要点：

是什么：流处理面对无界数据，持续计算；批处理面对有界数据，一次算完。
解决什么：流处理低延迟，批处理吞吐高、实现简单。Flink 用统一引擎支持两种模式。
实操边界：我了解流批概念和水位线，没有在生产 Flink 上开发过任务。

追问：Spark Streaming 和 Flink 的本质区别？Spark Streaming 早期是微批，Flink 是真正的流式处理，延迟和状态管理更细。

6.2 水位线是什么？

问题：Flink 的 watermark 解决什么问题？

答题要点：

是什么：水位线表示事件时间进度的标记，用来触发窗口计算和处理迟到数据。
解决什么：事件时间乱序时，系统需要知道“什么时候可以认为数据到齐了”。
实操边界：我理解 watermark 和 allowed lateness，没有实际调过并行 source 的空闲分区。

追问：水位线延迟太久怎么办？会增大结果延迟；太短会丢迟到数据。要结合业务乱序程度和延迟要求设置。

6.3 Flink 有哪些窗口？

问题：滚动、滑动、会话窗口的区别？

答题要点：

是什么：滚动窗口不重叠，滑动窗口有步长，会话窗口按活动间隔切分。
解决什么：不同业务需要不同聚合方式，比如每分钟统计、每小时滑动、用户会话分析。
实操边界：我了解窗口类型和事件时间，没有 Flink 项目经验。

追问：窗口结果什么时候输出？由 watermark 和触发器决定；迟到数据可配置 allowed lateness 再补算。

6.4 Flink 的状态是什么？

问题：Keyed State 和 Operator State 的区别？

答题要点：

是什么：Keyed State 按 key 维护，只能用于 keyed stream；Operator State 按算子实例维护，常用于 source/sink。
解决什么：状态让流任务记住历史，支持聚合、去重、窗口和会话。
实操边界：我了解 state backend 和 checkpoint，没有生产状态调优经验。

追问：状态越来越大会怎样？checkpoint 变慢、恢复变久、内存压力增大；要用 TTL、增量 checkpoint 和合理的状态后端。

6.5 Flink 怎么做到 Exactly-Once？

问题：端到端精确一次依赖什么？

答题要点：

是什么：checkpoint 保存状态和 source offset，sink 用两阶段提交或幂等写入，保证故障恢复后不重不漏。
解决什么：流任务失败恢复时，避免重复输出或丢数据。
实操边界：我理解 barrier、checkpoint 和两阶段提交的原理，没有在生产 Flink 上配置过。

追问：所有 sink 都支持吗？不是。Kafka 有事务支持，文件 sink 可以用幂等或临时文件提交；不支持的 sink 只能做到至少一次。

7. 场景题

7.1 怎么算日活买家？

问题：给定订单表，计算每天有有效下单的去重买家数和 7 日移动平均。

答题要点：

是什么：按天对下单的 customer_unique_id 去重，再用窗口帧算移动平均。
解决什么：衡量每天有多少人真正下单，移动平均平滑周末波动。
实操边界：Olist 没有登录和浏览日志，只能算“日活买家”，不能叫 DAU。分析窗口内 602 个有订单日的日均买家 161.1，峰值 1,151（2017-11-24 黑五）。

写法要点：

先过滤有效订单（排除 canceled / unavailable），按 order_date 对 customer_unique_id 去重计数。
再对结果开 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW。
日期有缺口时先补日期维表，或用 RANGE 窗口；ROWS 的“前 6 行”不等于“前 6 天”。

在线练习： 1141 查询近 30 天活跃用户数；移动平均可参考 1321 餐馆营业额变化增长。

追问：为什么不能叫 DAU？没有登录、浏览、点击日志，只有下单行为；口径写在指标字典里，避免和产品侧的 DAU 混用。

7.2 没有登录日志，怎么算留存？

问题：只有订单表，怎么衡量用户有没有回来？

答题要点：

是什么：按 customer_unique_id 的首次下单月份分 cohort，看后续月份是否再次下单，得到“首购月 cohort 回购率”。
解决什么：没有 D1/D7 行为日志时，用购买行为近似留存，衡量用户是否回来复购。
实操边界：项目 2017-01 首购的 752 个买家里有 31 人在后续月份再次下单，回购率 4.12%；整体复购率只有 3.04%。面试被问次日留存时要主动说明数据不支持。

写法要点：

first_order：每个 customer_unique_id 的 MIN(date_trunc('month', order_date))。
buyer_month：DISTINCT customer_unique_id, first_month, order_month。
分子是 order_month > first_month 的去重买家，分母是该 cohort 的全部买家。
这是“后续月是否回购”，不是“次日是否登录”；口径不同，不能混着叫留存。

在线练习： 1454 活跃用户 🔒（连续登录）、 1097 游戏玩法分析 V 🔒（留存），用来练通用模板。

追问：分母为什么要限定首购 cohort？留存的分母是同一批新用户，不是当天全部活跃用户；分子和分母必须来自同一 cohort。

7.3 怎么取分组 TopN？

问题：每个品类 GMV 前 3 的商品，怎么写？

答题要点：

是什么：先用窗口函数按分组排序编号，再筛编号。
解决什么：避免每组单独查询，也避免全局排序后取错。
实操边界：项目做过品类排行和商家 Top10，处理过并列排名。

写法要点：

先按 category, product_id 聚合出 GMV。
再用 ROW_NUMBER() OVER (PARTITION BY category ORDER BY gmv DESC) 编号。
最后筛 rn <= 3；要保留并列改用 RANK()，结果可能超过 3 条。

在线练习： 185 部门工资前三高的所有员工。

追问：ROW_NUMBER 和 RANK 怎么选？要固定 3 条用 ROW_NUMBER；并列都保留用 RANK，可能超过 3 条。

7.4 两张表对不上怎么排查？

问题：明细层 GMV 和订单层 GMV 不一致，怎么定位？

答题要点：

是什么：从行数、主键、关联、聚合四步排查。
解决什么：快速定位是丢行、重复、过滤还是聚合口径问题。
实操边界：项目用 6 类检查定位过行数和 GMV 差异，误差控制在 1 元内。

排查顺序：

比行数：明细 112,101、订单 98,199 是否符合漏斗。
查主键：订单和明细主键是否重复。
查外键：明细是否有孤儿订单。
查金额：明细 SUM(item_amount_with_freight) 是否等于订单 SUM(order_amount)。
查过滤：是否漏了取消单、负价或未来日期。

追问：金额差很小怎么办？先排除浮点误差，再看是否有四舍五入；差值固定时查重复行或缺失行。

7.5 怎么补数？

问题：某个分区数据错了或上游晚到，怎么补？

答题要点：

是什么：按分区重跑，用覆盖写保证幂等，再验证行数和指标。
解决什么：修正历史数据，同时避免重复写入。
实操边界：项目是全量重跑，天然幂等；我没有在生产调度平台执行过补数。

步骤：

确认影响分区和上游数据是否到齐。
重跑 DWD、DWS、ADS 对应日期，使用 INSERT OVERWRITE。
对比补数前后的行数、GMV、主键。
记录补数原因、范围和结果。

追问：补数会影响下游报表吗？会，要通知下游并安排重跑；补数窗口尽量避开报表出数时间。

8. 自测清单

能不看资料讲清下面每一项，才算准备好。

能用一句话解释 ODS、DWD、DWS、ADS 的职责。
能画出四层架构，并说出每层行数变化。
能解释维度建模、星型、雪花、事实表三种类型。
能讲清拉链表的更新和查询，并说明项目没做。
能写清一个 GMV 口径，包括过滤条件和分母。
能说出 6 类数据质量检查。
能区分内部表、外部表、分区、分桶。
能写动态分区 SQL，并说出两个注意事项。
能说出小文件问题的成因和三种解法。
能说出数据倾斜的三种成因和对应解法。
能解释 Spark shuffle、宽窄依赖、惰性求值。
能解释 cache、broadcast join、repartition 与 coalesce。
能说清 driver 和 executor 的分工。
能说出 Kafka 高吞吐的四个原因。
能说出 Kafka 不丢消息的三层配置。
能解释 Kafka 为什么只能保证分区内有序。
能解释 rebalance 的触发条件和影响。
能区分流处理和批处理。
能解释水位线、窗口、状态和 Exactly-Once。
能现场写出日活买家、首购 cohort 回购、分组 TopN 的 SQL 框架。
能说出对账和补数的步骤。

9. 本章验收

能按“是什么、解决什么、实操边界”回答任意 10 道题，不跑题。
能现场写出日活买家、首购 cohort 回购、分组 TopN 三条 SQL 的主体逻辑。
能解释拉链表、数据倾斜、shuffle、水位线四个高频难点。
能在回答中主动区分“项目做过”和“只了解原理”。
能说出自己项目里至少 5 个具体数字，并与题库答案一致。
完成自测清单 21 项中的至少 16 项，并能录音复述。