大数据系统的核心问题是：数据太大，单机放不下或算不动，所以需要分布式存储和分布式计算。
Hadoop
Hadoop 是大数据生态的基础框架，主要组件包括：
- HDFS：分布式文件系统
- MapReduce：分布式计算模型
- YARN：资源调度
HDFS 把大文件拆成块，分散存储到多台机器上，并通过副本保证容错。
MapReduce 把计算拆成 Map 和 Reduce 两阶段：
- Map：每个节点处理自己负责的数据块
- Reduce：聚合中间结果
优点是可靠、可扩展；缺点是批处理延迟较高。
Spark
Spark 是大规模数据计算框架，通常比 Hadoop MapReduce 更快，因为它大量使用内存计算。
常见组件：
- Spark Core
- Spark SQL
- Spark Streaming
- MLlib
- GraphX
Spark 适合迭代计算、机器学习、交互式分析和流处理。
Spark 与 Hadoop MapReduce
MapReduce 更偏传统批处理，每一步会频繁落盘。
Spark 把中间数据尽量放在内存中，适合需要多轮计算的任务。
Hive
Hive 是数据仓库工具，可以用类 SQL 的方式查询 HDFS 上的数据。
它适合：
- 离线分析
- 报表
- 数据仓库
- 让熟悉 SQL 的人查询大数据
Hive 不是传统 OLTP 数据库，不适合高频低延迟事务查询。
总结
- Hadoop：分布式存储和批处理基础
- Spark：更快的大规模计算引擎
- Hive：面向分析的数据仓库 SQL 层
延伸理解
复习这篇时，不要只记住名词，要把重点放在 HDFS、MapReduce、Spark 内存计算、Hive SQL 和批处理数据平台分层。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- 大数据系统的核心是吞吐、容错、延迟和成本之间的取舍，不是单个工具的语法。
- 区分批处理、流处理、交互式查询和离线建模，有助于判断 Hadoop、Spark、Hive 等工具的位置。
- 数据平台还要考虑 schema 演进、数据质量、分区策略、血缘追踪和重跑成本。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个日志分析平台里理解：业务服务产生日志，数据先落到对象存储或 HDFS，再由 Spark 做清洗和聚合，Hive 提供 SQL 查询层，最终输出报表或特征数据。这里的重点是数据量、延迟、重跑成本和数据质量。批处理系统通常接受分钟到小时级延迟，但要求能够稳定重跑；流处理更关注实时性，但对状态管理和容错要求更高。
常见误区：
- 没有区分批处理和流处理需求。
- 只关心计算框架，不关心数据分区和重跑策略。
- 缺少数据质量校验，导致下游结果不可解释。