一只特立独行的cherry大数据这三个字，从概念热潮到成为生产系统里的标配，中间经历了好几轮技术风向的转向。我最近在整理过去十年的知识积累时，把大量内容做了减法，最后决定用《大数据与计算模型》这个题目，做成“十年十篇”的系列沉淀。原因是框架一直在变，但围绕“数据如何被组织、切片、传输和计算”的思考方式——也就是计算模型——才是真正经得起时间考验的东西。这篇博客就是这个系列的一份总纲式复盘，也是写给那些正在自学、准备面试、做毕业设计，或者正在为团队做技术选型的读者看的：如果你也想从一堆热点名词中跳出来，抓住大数据里那些“换了壳也还在原处”的核心问题，这篇文章应该能帮你把路线理顺。
1. “十年十篇”的取舍：为什么不做一本按框架罗列的大全书
1.1 从技术热度变化看沉淀重点
回到十年前看，大多数人认知里的大数据约等于 Hadoop，约等于 “写一个 MapReduce 作业然后等着跑完”。2013 年前后大家的兴奋点还集中在 HDFS 能把文件拆成块、YARN 能把任务调度到多台机器上，MapReduce 的编程模型让一批没做过分布式的人第一次接触到了“分而治之”的滋味。
但这些年过去，技术生态的变化速度远超预期。
- Hadoop MapReduce 2.x 刚稳定没几年，Spark 以内存计算和 DAG 调度的方式冲了出来。
- 流式计算从 Storm 的“逐个处理”逐步过渡到 Flink 所代表的“有状态流处理”，并且提出了流批一体的说法。
- 数据湖概念兴起后，Iceberg、Hudi、Delta Lake 又把存储层上“表格式元数据管理”推到了新的高度。
- 云厂商开始强调存算分离，告诉我们不再需要为计算临时扩容而被迫复制三副本的数据。
如果按工具去写一套资料，2019 年写完可能 2022 年就有相当一部分内容得作废。换一个角度，如果按“计算模型”去梳理，几乎所有工具都能被归类为某个抽象思想的实现。你是用 Spark 还是用 Flink，用 Hive 还是用 ClickHouse，本质上都绕不开那几类模型问题：数据是静态批量到达还是有界流？任务是无限并行还是 DAG 级依赖？状态到底放在本地还是外部系统？一篇文章的 API 会过时，但这些问题不会。那沉淀哪一部分，答案就很清楚了。
1.2 这套内容主要想被谁拿去用
《大数据与计算模型》不是什么面面俱到的百科全书，它更接近一份按问题域组织的“知识地图”。
- 如果你是刚入行或者准备转行做数据开发的读者，你需要先建立一份认知骨架，知道从 HDFS、MapReduce 看到 Spark 和 Flink 时，变化的到底是什么。你不需要把每一行源码都看明白，但你需要搞清楚你写下的 groupByKey 底层是怎么 shuffle 的，为什么会慢。
- 如果你是正在做毕业设计或者准备面试的在校生，这套十篇内容里很多专题其实可以直接对应到经典面试题和系统设计题背后的原理，比如“Spark 为什么比 MapReduce 快”“Flink 的 exactly-once 到底怎么保证”“数据倾斜该怎么处理”。
- 如果你是团队里负责平台选型或做架构决策的人，阅读这套内容会更关注计算模型带来的边界：什么时候适合一套交互式查询引擎，什么时候需要引入实时流处理，湖仓融合究竟在存储和计算之间做了什么取舍。
换句话说，这不是一份“安装配置教程汇总”，而是一份关于“为什么要这样设计”的复盘。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。