第5周：大数据技术栈

本日概要

大数据不是「数据很多」，而是单机的存储、计算或时效性其中之一被突破后，必须改用分布式方案的一类工程问题。判断是否需要它，要看具体数字：数据总量与增长速度、单次查询要扫描多少、结果需要多快可用、有多少并发。Lambda 架构用批处理层保证最终正确、用速度层提供近实时结果、用服务层合并两者，代价是同一套业务逻辑要维护两份实现；Kappa 架构用单一流式管道加重放来消除这份重复，代价是对流处理框架和消息保留期的要求更高。先算清数字再选架构，否则容易为了「上大数据」而引入不必要的运维负担。

学习目标

• 能用数据量、扫描量、时效性与并发四组数字判断一个场景是否真的需要分布式方案
• 能画出 Lambda 架构的批处理层、速度层与服务层，并说明每层的一致性承诺
• 能对比 Lambda 与 Kappa 架构的重复实现成本与重放要求
• 能区分「离线报表」「近实时看板」「实时决策」三类需求对应的不同技术路径

核心讲解

实践任务

为一个具体业务场景画出 Lambda 架构图，逐层标注数据来源、处理方式、延迟目标与一致性承诺，并说明改用 Kappa 架构后哪些部分会消失、哪些成本会上升。

• 选定一个具体场景（如电商订单分析），写出数据总量、日增量、单次查询扫描量、延迟目标与并发数五个数字，标明哪些是实测、哪些是估计。
• 画出 Lambda 架构三层图，逐层标注输入、处理方式、输出存储、延迟与一致性承诺。
• 在图上标出「同一段业务逻辑被实现了两次」的位置，并写出两份实现产生偏差时如何发现。
• 写一段 Kappa 改造分析：哪些组件会被去掉、消息保留期需要多长、重放一次全量需要多久，并明确标出哪些数值是假设。

自测与答案

今日完成标准

• 提交五组关键数字并标明来源是实测还是估计
• Lambda 架构图三层完整，每层有延迟与一致性承诺
• Kappa 改造分析写明消息保留期与重放耗时的估计依据

常见错误与纠正提示

• 把「数据量大」当作引入分布式方案的充分理由，不核算查询扫描量与时效目标
• 画 Lambda 架构图时只画组件不写延迟与一致性承诺，导致图无法用于决策
• 忽略批速两层口径偏差的对账机制，上线后长期不知道两个数字为什么不一致

分层任务

关联知识点

• 大数据平台

延伸阅读

• Structured Streaming Programming Guide（Apache Spark 官方文档）
• Flink: Stateful Stream Processing（Apache Flink 官方文档）

本日概要

Hadoop 提供了分布式存储与调度的基本范式，理解它是理解后来所有框架的基础。HDFS 把大文件切成固定大小的块分散存储并保留多个副本，NameNode 保存目录树与块位置的元数据，DataNode 保存实际数据；这个设计对「一次写入、多次读取的大文件」友好，对海量小文件则很不友好，因为每个文件都要占用 NameNode 内存。MapReduce 把计算拆成 map、shuffle、reduce 三个阶段，shuffle 是真正的性能瓶颈所在。YARN 把资源管理与作业逻辑分离，让同一个集群可以同时跑多种计算框架。

学习目标

• 能说明 HDFS 的块、副本、NameNode 与 DataNode 各自的职责与失效影响
• 能解释「小文件问题」的成因，并给出至少两种缓解方向
• 能沿 map、shuffle、reduce 三个阶段描述一次 WordCount 的数据流向
• 能说明 YARN 分离资源管理与作业逻辑带来的好处

核心讲解

实践任务

运行一个 WordCount 示例，观察 map、shuffle、reduce 三个阶段的输入输出与耗时分布，并解释小文件为什么会让 NameNode 成为瓶颈。

• 在本人授权的本地环境或教师提供的证据包中运行 WordCount 示例，记录输入文件大小、任务数量与各阶段耗时。
• 查看作业输出，写出 map 阶段产生了多少中间键值对、shuffle 传输了多少数据、reduce 任务有几个。
• 构造一份键分布极不均匀的输入（例如某个词占总量的一半），重新运行并对比 reduce 阶段的耗时分布，说明数据倾斜的表现。
• 估算一百万个小文件在 NameNode 上产生的元数据条目数量，并写出两种在采集侧就避免小文件的做法。

自测与答案

今日完成标准

• 提交 WordCount 运行记录，包含输入规模、任务数量与各阶段耗时
• 用倾斜输入的对比数据说明长尾任务的成因
• 写出小文件元数据估算与两种采集侧缓解做法

常见错误与纠正提示

• 认为集群加机器可以解决一切慢作业，忽略数据倾斜与元数据瓶颈
• 把 HDFS 当成通用文件系统存放大量小文件与频繁随机写
• 只看作业总耗时不看各阶段分布，无法定位 shuffle 还是计算是瓶颈

分层任务

关联知识点

• 大数据平台

延伸阅读

• HDFS Architecture（Apache Hadoop 官方文档）
• MapReduce Tutorial（Apache Hadoop 官方文档）
• Apache Hadoop YARN（Apache Hadoop 官方文档）

本日概要

Spark 相对 MapReduce 的关键差异在于把中间结果保留在内存并用有向无环图统一调度，因而适合需要多轮迭代的计算。它的编程模型有两层：RDD 是不可变的分布式数据集，提供转换与行动两类操作，转换是惰性的，只有行动触发真正的计算；DataFrame 与 Spark SQL 在此之上提供结构化抽象，让优化器可以基于 schema 做谓词下推、列裁剪与执行计划重写，通常比手写 RDD 操作更快。理解「转换惰性、行动触发」和「宽依赖会引发 shuffle」这两点，才能解释一段 PySpark 代码为什么慢。

学习目标

• 能区分转换与行动操作，并解释惰性求值对调试与性能分析的影响
• 能识别窄依赖与宽依赖，并说明哪些操作会引发 shuffle
• 能读懂 DataFrame 的执行计划，指出谓词下推与列裁剪发生在哪一步
• 能用缓存与分区调整解释一次迭代计算的性能变化，并用实测数据支持结论

核心讲解

实践任务

用 PySpark 对一份结构化数据做清洗与聚合，对比 RDD 写法与 DataFrame 写法的执行计划，并找出代码中触发 shuffle 的位置。

• 准备一份带若干列的结构化样例数据，用 DataFrame API 完成过滤、类型转换、去重与按键聚合，记录 Spark 版本与数据规模。
• 打印执行计划，指出谓词下推与列裁剪出现在计划的哪一步，并数出计划中出现了几次 shuffle 交换。
• 用 RDD API 实现同样的逻辑，对比两者的耗时与代码量，说明差异的来源。
• 对被多次引用的中间结果加缓存，记录缓存前后的实测耗时；再对只用一次的结果加缓存，记录耗时变化并解释为什么无效甚至更慢。

自测与答案

今日完成标准

• 提交 DataFrame 与 RDD 两种实现的代码、执行计划与实测耗时
• 在执行计划上标出谓词下推、列裁剪与 shuffle 交换的位置
• 缓存实验包含有效与无效两组对比，并解释差异原因

常见错误与纠正提示

• 在每个中间结果后都加缓存，占用内存却没有复用收益
• 用逐行计时判断性能瓶颈，忽略惰性求值
• 看到作业慢就增加分区数或执行器数量，不先检查 shuffle 次数与数据倾斜

分层任务

关联知识点

• 大数据平台

延伸阅读

• Spark RDD Programming Guide（Apache Spark 官方文档）
• Spark SQL, DataFrames and Datasets Guide（Apache Spark 官方文档）

本日概要

流处理的难点不是「实时」，而是时间与状态。事件时间指事件真实发生的时刻，处理时间指系统处理它的时刻，二者之间的差距由网络、重试和积压造成；只按处理时间开窗，结果会随系统负载而变化，无法复现。Flink 用水位线表示「事件时间已经推进到某一时刻」，据此触发窗口计算，并用允许延迟与侧输出处理迟到数据。有状态计算依赖检查点：作业定期把状态持久化，故障后从最近检查点恢复，这是端到端一致性保证的基础，而不是简单的「重启继续」。

学习目标

• 能区分事件时间与处理时间，并说明按处理时间开窗为什么不可复现
• 能解释水位线的含义，以及它如何在乱序数据中触发窗口计算
• 能为迟到数据设计处理策略，并说明允许延迟与侧输出各自的适用场景
• 能说明检查点在故障恢复与一致性保证中的作用及其开销

核心讲解

实践任务

实现一个基于事件时间的滚动窗口统计，故意注入乱序与迟到事件，观察水位线推进、窗口触发与迟到数据的去向。

• 构造一份带事件时间戳的样例数据流，其中包含一定比例的乱序事件，记录乱序的最大幅度。
• 实现基于事件时间的滚动窗口统计，设置水位线容忍偏移，观察窗口在什么时刻触发并记录结果。
• 把容忍偏移分别设为过小与足够大两个值，对比被判为迟到的事件数量与结果差异。
• 为迟到事件配置侧输出，记录被引出的事件；再模拟一次作业失败与从检查点恢复，记录恢复耗时与结果是否一致。

自测与答案

今日完成标准

• 提交窗口统计的实现与两组容忍偏移下的对比结果
• 记录迟到事件的数量与去向，说明所选处置策略及其对下游的要求
• 记录检查点间隔、状态大小与一次恢复的实测耗时

常见错误与纠正提示

• 默认使用处理时间开窗，上线后发现补数据与实时结果对不上
• 不配置迟到处理，事件被静默丢弃却以为统计完整
• 把检查点当成没有代价的开关，间隔设得极短导致常态吞吐下降

分层任务

关联知识点

• 大数据平台
• 消息队列

延伸阅读

• Flink: Timely Stream Processing（Apache Flink 官方文档）
• Flink: Stateful Stream Processing（Apache Flink 官方文档）
• Structured Streaming Programming Guide（Apache Spark 官方文档）

本日概要

数据仓库解决的是「同一个指标在不同部门算出不同数字」的问题，核心是统一口径而不是存储技术。分层建模是常见做法：贴源层保留原始数据不做加工，明细层完成清洗与规范化，汇总层按主题聚合，应用层面向具体报表；每一层的职责边界清楚，问题才能被定位到具体层次。Hive 让 SQL 可以运行在分布式存储上，而表格式（如 Iceberg）进一步提供了模式演进、快照与时间旅行能力。真正决定数据仓库可信度的，是指标定义、口径文档和可追溯的加工链路。

学习目标

• 能说明数据仓库分层的目的，并为每一层写出职责边界与不该做的事
• 能为一个指标写出可执行的口径定义，包含统计范围、时间口径与排除条件
• 能用 Hive 完成建表与聚合查询，并说明分区对扫描量的影响
• 能说明表格式提供的模式演进与快照能力解决了哪些实际问题

核心讲解

实践任务

为一个业务主题设计分层模型，建表并跑通一次从贴源到汇总的加工，写出至少三个指标的口径定义。

• 选定一个业务主题，画出贴源、明细、汇总、应用四层的表清单，为每层写出职责边界与不该做的事。
• 用 Hive 建立按日期分区的明细表与汇总表，加载样例数据并跑通一次从明细到汇总的聚合。
• 为至少三个指标写出完整口径定义：统计对象、时间口径、排除条件、计算公式、所属表。
• 对比查询全表与查询指定分区的扫描量差异，记录实测数据；再故意用一个高基数字段分区，说明会产生什么问题。

自测与答案

今日完成标准

• 提交四层表清单，每层写明职责边界与不该做的事
• 至少三个指标有完整口径定义，能被他人按定义独立算出相同结果
• 提交分区与全表扫描的实测对比数据，并说明高基数分区的风险

常见错误与纠正提示

• 分层只是命名不同，实际计算路径互相绕过，口径分歧长期无法收敛
• 口径定义只写公式不写排除条件与时间口径，对数时才发现分歧
• 用高基数字段分区，产生海量小分区并重新引入小文件问题

分层任务

关联知识点

• 数据治理
• 数据库

延伸阅读

• Apache Hive Documentation（Apache Hive 官方文档）
• Hive Language Manual（Apache Hive 官方 Wiki）
• Apache Iceberg Documentation（Apache Iceberg 官方文档）

本日概要

数据治理不是给数据加标签，而是让「这个数字从哪来、谁能看、能不能信」这三个问题有可查的答案。元数据管理回答第一个问题：表、字段、作业和它们之间的血缘关系被记录下来，一个指标出问题时可以沿血缘向上定位，一次表结构变更也能提前评估影响范围。权限与分级回答第二个问题：数据按敏感级别分类，访问按最小权限授予并留下审计日志。数据质量回答第三个问题：为关键表定义完整性、唯一性、及时性、一致性等可自动执行的规则，并在规则失败时阻断下游而不是静默放行。

学习目标

• 能说明元数据与数据血缘各自解决的问题，并画出一条从源表到报表的血缘链路
• 能为一张表设计敏感级别分类与最小权限方案，并说明审计日志应记录哪些字段
• 能写出四类可自动执行的数据质量规则，并为每条规则定义阈值与失败处置
• 能解释为什么质量规则失败时应阻断下游，而不是记录告警后继续运行

核心讲解

实践任务

为一张核心表建立元数据与血缘记录，定义至少四条可自动执行的数据质量规则，并说明规则失败时的处置流程。

• 选定一张核心表，记录它的字段清单、含义、产出作业与更新频率，形成元数据条目。
• 画出从源表经明细、汇总到最终报表的完整血缘链路，标出每一步的加工作业。
• 为该表定义至少四条质量规则（完整性、唯一性、及时性、一致性各一条），写出阈值与判定方式。
• 为每条规则写出失败处置流程：是否阻断下游、告警发给谁、保留哪一版本数据、恢复后如何补跑；再设计该表的敏感级别与审计日志字段。

自测与答案

今日完成标准

• 提交完整的元数据条目与一条端到端血缘链路图
• 四条质量规则各有明确阈值、判定方式与失败处置流程
• 敏感级别分类与审计日志字段清单完整，并说明最小权限如何落实

常见错误与纠正提示

• 把数据治理理解为补文档，规则不可自动执行，实际不产生约束
• 质量校验失败只告警不阻断，错误数据流向全部下游
• 权限按部门粗粒度授予，审计日志缺少访问对象与操作类型，事后无法追溯

分层任务

关联知识点

• 数据治理

延伸阅读

• Apache Atlas（Apache Atlas 官方站点）
• Apache Iceberg Documentation（Apache Iceberg 官方文档）

本日概要

本周收尾要回答一个反复出现的问题：什么时候用批处理，什么时候用流处理。判断依据不是「哪个更先进」，而是四组约束——结果需要多快可用、数据是否会迟到与需要重算、口径变更后是否要回溯历史、团队是否有能力运维有状态作业。批处理的优势是简单、易重算、口径变更后重跑即可；流处理的优势是延迟低，代价是状态管理、迟到处理和重放都要显式设计。多数团队的实际路径是先用批处理满足大部分需求，再对确实需要低延迟的少数场景引入流处理，而不是一开始就全面流式化。

学习目标

• 能用延迟目标、迟到与重算需求、口径回溯要求、运维能力四组约束做出批流选择
• 能为每个选择写出代价，而不是只写优点
• 能定义「什么情况下应当改变当前选择」的触发条件
• 能把本周的架构、存储、计算、仓库与治理结论串成一条完整的数据链路说明

核心讲解

实践任务

写一份批处理与流处理的选择说明：为同一业务的三个不同需求分别给出选择、理由与代价，并列出改变选择的触发条件。

• 为同一业务列出三个不同需求（如日报表、近实时看板、实时风控），分别写出延迟目标与业务影响。
• 对每个需求逐一填写四组约束，并据此给出批处理或流处理的选择。
• 为每个选择写出至少两条代价，以及为缓解这些代价需要额外做的工作。
• 为每个选择定义至少两条改变触发条件（含具体数值或比例），并把本周五天的结论整合成一页端到端数据链路说明。

自测与答案

今日完成标准

• 三个需求各有四组约束的填写结果与明确选择
• 每个选择配有至少两条代价与对应的缓解工作
• 改变触发条件包含具体数值或比例，并说明数值来源是实测还是假设

常见错误与纠正提示

• 以「流处理更先进」为由全面流式化，忽略运维能力与重算需求
• 选型说明只写优点不写代价，评审时无法讨论真实取舍
• 不定义改变触发条件，架构决策每次都要从头争论

分层任务

关联知识点

• 大数据平台
• 数据治理

延伸阅读

• Structured Streaming Programming Guide（Apache Spark 官方文档）
• Flink: Timely Stream Processing（Apache Flink 官方文档）
• Apache Iceberg Documentation（Apache Iceberg 官方文档）