Google 的三篇论文如何用「一堆廉价小机器」替代「一台昂贵大机器」；开源复刻 Hadoop 的民主化狂欢；数据湖从自由到沼泽的四年；以及一家中国社区团购公司四套组件打架的真实日常。
上一篇的结尾，企业有了数据仓库，但那是大企业的特权——Teradata 一体机百万美元级。与此同时，另一群人的数据问题用老办法根本无解：Google 每天要索引全网几十亿网页，Facebook 要存下几亿用户产生的每一条动态。这批数据的体量以 PB 计，Teradata 的报价单都填不了。于是 Google 发明了新方法，开源社区把它复刻成了 Hadoop，整个 2010 年代，全世界都在喊「大数据」。这一篇讲这十年的狂欢与混乱：数据湖怎么从自由变成沼泽，以及一家中国社区团购公司用四套开源组件打架的真实案例。
本篇要回答的问题
1. Google 的三篇论文到底发明了什么？为什么说没有它们就没有「大数据」这个词？
2. MapReduce 的核心思想，用一个数钱的类比就能讲明白？
3. Hadoop 生态为什么越长越乱——Hive、Kafka、Spark、ClickHouse 都是干什么的？
4. 「数据湖」和「数据沼泽」一字之差，差在哪？
5. 这一十年沉淀下什么教训，让后面 Snowflake 和 Databricks 的崛起成为必然？
2003 年的世界，数据库行业的答案只有两种：要么买 Oracle/Teradata 的高端设备，要么用开源 MySQL——但两者都有一个共同前提：数据装在一台（或一组）足够大的机器里，由这台机器统一管理。
Google 的数据没有这种待遇。它要存下全网几十亿张网页的快照，每天数十亿次搜索的日志，还要在这些数据上跑「给每个网页算重要度」「把搜索请求分发到几千台机器」这类计算。这个体量下，传统数据库的全部假设都失效了：
| 问题 | 传统数据库为什么无解 | Google 的解法 |
|---|---|---|
| 网页快照几十亿份，单机磁盘装不下 | 单机容量有物理上限，垂直扩容（换更大机器）有极限且价格指数上升 | GFS（2003）：把文件切成块，散布在几千台廉价机器上，每块存三个副本防单机损坏——用「概率」替代「贵重硬件」来保证可靠 |
| 全网数据的计算（如索引重建），一台机器要跑几年 | 单机算力有限，垂直加速有极限 | MapReduce（2004）：把计算拆成几千个小任务分给几千台机器同时算，谁坏了就把任务转给别的机器重跑 |
| 网页之间的关联（链接结构）是稀疏的巨图，关系型表格存不了 | 关系模型适合规整的业务数据，不适合稀疏、无模式的巨型表 | BigTable（2006）：放弃严格的表结构，接受「每行可以长得很不一样」 |
这三篇论文共同的哲学只有一句话：放弃「一台可靠的大机器」，改用「一堆不可靠的小机器 + 软件层面的容错」。在 Google 的场景里这是唯一解：与其花一亿美元买一台永远不够用的超级机，不如用一千万美元买一万台普通机，把可靠性做进软件里。
论文是 Google 的，但痛点是全行业的。雅虎、Facebook、eBay 这些公司同样在膨胀：用户日志、点击流、社交关系，体量很快越过传统数据库的天花板。2004 年起，开源社区开始照着论文复刻：工程师 Doug Cutting（他此前做的是全文检索工具 Lucene）在自己的搜索引擎项目 Nutch 里实现了 GFS 和 MapReduce 的开源版。2006 年，这个子项目独立出来，他给儿子的大象玩具命名为 Hadoop——一头黄色大象，从此成为大数据的图腾。
同年 Doug Cutting 加入雅虎，Hadoop 在雅虎长成了真家伙：2008 年雅虎的 Hadoop 集群达到数千台机器、存储数 PB 数据，成为当时全球最大的生产级 Hadoop 部署。关键的市场信号在 2008 年出现：雅虎用 Hadoop 跑赢了「1TB 数据排序」的公开基准——用普通机器组成的集群，排序成本只有传统方案的几十分之一。商业世界立刻读懂了：大数据的时代来了，而且它的门票是免费的。
这是数据基础设施历史上第一次真正的「民主化」：以前，处理海量数据是 Google、银行和电信的特权；现在，任何公司用几十台二手服务器就能入门。2010 年代初，「大数据」成为科技公司招股书里出现频率最高的词，而 Hadoop 是这个词的技术化身。
MapReduce 听起来高深，其实是一个数钱的动作。假设你要数一大箱零钱：
| 阶段 | 数钱的做法 | 技术的名字 |
|---|---|---|
| Map（分散） | 把钱分成五十小堆，五十个人每人数自己那堆：甲数出「1 元硬币 120 枚」，乙数出「1 元硬币 95 枚」……每人只报自己堆里的「币种 × 数量」 | 每台机器对本地数据块做局部统计 |
| Shuffle（归堆） | 把五十个人的结果按币种收拢：所有「1 元硬币」的数字送到一个汇总员手里 | 按 key 重新分发到汇总节点 |
| Reduce（汇总） | 汇总员把 1 元硬币的 120+95+……全部加总，得出总数 | 汇总得到最终结果 |
这个模式妙在两点：其一，人多真的力量大——五十个人数一遍的时间约等于一个人数五十分之一（理想情况）；其二，天然容错——数钱的人里有一个打翻了自己的堆，让他重数那一小堆就行，不影响其他四十九人。Hadoop 把这套流程做成了通用框架：工程师只要写清楚「怎么分」和「怎么合」，集群调度、机器故障重试、进度管理全部由框架兜底。
今天回看，MapReduce 的辉煌与局限是同一枚硬币：它擅长大规模「批处理」（今晚跑通宵、明早出结果），但不擅长交互式查询——你没法等一个「刷新一次报表跑六小时」的系统来回答业务问题。这个局限，是后续所有演化的第一推动力。
Hadoop 解决了「存得下、算得动」，但真实业务要的东西远不止这些。于是 2008–2016 年间，围绕 Hadoop 的生态以「一个痛点一个组件」的方式野蛮生长：
| 痛点 | 组件（诞生年） | 它解决的问题 |
|---|---|---|
| 工程师写 MapReduce 太痛苦（几百行 Java 只为做个分组统计） | Hive（2008，Facebook） | 让分析师能用 SQL 直接查 Hadoop 数据——SQL 翻译成 MapReduce 任务执行 |
| 数据进来太慢（批量每天一次，业务要实时） | Kafka（2011，LinkedIn） | 数据「水龙头」：各系统的事件实时流入，下游各取所需 |
| MapReduce 太慢（中间结果写磁盘，来回折腾） | Spark（2009 AMPLab / 2014 Apache 顶级） | 内存计算——中间结果放内存不落盘，同一任务比 MapReduce 快一到两个数量级 |
| 交互式查询还是太慢（报表要秒级响应） | ClickHouse（2016 开源，Yandex）、Impala、Presto | 专为「人盯着屏幕等结果」优化的查询引擎，秒级甚至毫秒级 |
| 稀疏巨表的存储（BigTable 的开源版） | HBase | 海量稀疏表的实时读写 |
| 机器学习要在同一份数据上做 | MLflow、各种 ML 库 | 模型训练、版本、发布管理 |
每一个组件单独看都 solves 一个真实问题，而且大多出自名门（Facebook 的 Hive、LinkedIn 的 Kafka、伯克利的 Spark——注意，Spark 的作者 Matei Zaharia 后来创办的那家公司，正是 Databricks，这是第五篇的伏笔）。但把它们拼成一家公司的完整数据体系，就像把五套不同品牌的音响接成一套家庭影院：每一套都声称自己是最好的，彼此之间却互不兼容——格式不同、接口不同、运维方式不同、甚至「同一份数据在两边算出来的数」都可能不同。
生态膨胀的同时，一个更根本的策略转变发生了：先存下来，怎么用以后再说。
数据仓库时代的纪律是「先定结构再存数」：数据进仓前必须清洗、对齐口径、定义好每张表——行话叫 schema-on-write（写时定结构）。这保证了仓里的数据干净可靠，但代价是慢（每接一个新数据源都要开发 ETL）和僵化（今天没想到的问题，明天没有数据可查）。
云存储的出现改变了成本函数：2006 年亚马逊 S3 上线，存储价格进入每月几美分一 GB 的量级，且无限弹性。存储贵到必须精打细算的时代结束了。于是「数据湖（Data Lake）」的策略流行开来：把企业所有的原始数据——数据库导出、日志、点击流、传感器、聊天记录——原样扔进湖里，不做清洗不做加工，等到要用的时候再决定怎么处理（schema-on-read，读时定结构）。
这个策略的合理性是真实的：数据一旦扔掉就再也找不回来，而存储是最便宜的那一环；今天用不上的数据，可能就是明年 AI 模型的训练燃料。先存下来，是面向未来的保险。
但湖有另一面。数据仓时代虽然贵和慢，却有一条纪律兜底：进仓的每一条数据都有人负责、有定义、有质检。数据湖把这条纪律撤了——于是三年之后，绝大多数企业的湖变成了这样：
| 阶段 | 状态 | 典型对话 |
|---|---|---|
| 第 1 年 · 蓄水 | 热情高涨，管道疯狂接入，数据以 TB 计增长 | 「以后所有分析都在湖上做！」 |
| 第 2 年 · 迷航 | 没有人说得清湖里到底有什么；同一张表三个团队各存一份、口径各异 | 「这个 user_id 字段到底是什么意思？」「我也不知道，那个建的团队都解散了」 |
| 第 3 年 · 承诺瓦解 | 湖上的查询没人敢担保结果；关键业务报表偷偷退回「从业务库直接导 Excel」 | 「湖里的数能信吗？」「你先跟业务部门的 Excel 对一下再说」 |
| 结局 · 沼泽 | 湖还在、还在花钱（存储+集群），但已经没有人敢把关键决策建在它上面 | 「我们花了三百万建的湖，现在是个昂贵的备份盘」 |
「数据沼泽（Data Swamp）」这个行话的刻薄之处在于它的准确性：湖的价值在于能喝，沼泽的区别是谁也不敢喝。而沼泽化的根源不在技术，在治理——湖给了你「存一切」的自由，却没有给你「用一切」的能力。
把抽象的「组件打架」落到一家具体的企业。兴盛优选，湖南的社区团购企业——它的业务时效就是生死线：每天凌晨汇总前一日的订单，早上六点前要把各区域的数据推送出去，门店才能决定当日备货。
它的数据体系曾经是这样的：Kudu 管实时更新、Impala 管交互查询、Hive 管离线批处理、ClickHouse 管大屏报表——四套系统、四种数据格式、四套运维逻辑、四个团队（或一个团队四套技能）。日常的痛：
| 日常场景 | 四套体系下的麻烦 |
|---|---|
| 早上要看「昨日区域销量」 | Hive 昨晚批处理的结果与 ClickHouse 里实时的数字对不上——因为两边数据同步有先后，口径还各有一版 |
| 营销活动临时要看某几个社群的表现 | 要写一条横跨 Impala 和 ClickHouse 的查询逻辑，工程师现拼管道——排期两天 |
| 某个数据字段口径调整 | 四套系统里的定义都要改，改漏一套，报表互相矛盾 |
| 系统故障排查 | 四套组件的日志格式、监控指标完全不同——故障定位靠老工程师的经验记忆 |
最终的解法是「4 合 1」：全部换成华为云 GaussDB(DWS) 一套平台，营销数据实时接入，复杂分析从 10 分钟级降到秒级，维护工作量降一半。这个案例值得记住的不是华为的产品（第五篇还会回来对比），而是它揭示的行业现实：2010 年代末，「开源组件的自由」让大量企业陷入了「组件动物园」的维护泥潭——他们缺的不是某个更强的组件，而是「一套就能用」的整合。
到 2015 年前后，一家数据量大的企业手里的选项是这样的：
| 旧世界：Teradata / Oracle 数仓 | 新世界：Hadoop 生态 + 数据湖 | |
|---|---|---|
| 成本 | 百万美元级采购 + 每年 20% 维护 | 软件免费，但工程师与集群运维是真金白银 |
| 性能与稳定性 | 稳、快、可预测——但容量天花板明显 | 近乎无限的容量与吞吐——但慢、组件复杂、故障排查靠经验 |
| 取数体验 | SQL 顺畅，分析师自助 | Hive 查询排队，Spark 任务要写代码 |
| 扩容 | 采购制，以月计 | 加机器即可——但要自己重建平衡 |
| 适合谁 | 预算充足的金融/电信巨头 | 有工程师团队、数据体量爆炸的互联网公司 |
绝大多数企业的真实处境，是两头都占：Teradata 处理核心报表，Hadoop 跑机器学习，中间靠 ETL 打通——两套系统、两份成本、两拨团队。业务越发展，这套「杂交体系」越沉重。
把视角拉高：这个局面里藏着两个巨大的未满足需求——
需求一：有没有一个「既像数据仓一样好用、又像数据湖一样便宜且无限」的东西？——这个问题的答案之一叫 Lakehouse，属于 Databricks（第五篇）。
需求二：有没有一个「像 Teradata 一样好用，但便宜一万倍、不用运维、按用量付费」的东西？——这个问题的答案叫 Snowflake（第四篇）。
这两家公司一个从「湖」出发往「仓」走，一个从「仓」出发借「湖」的云——相向而行，在 2015 年前后相遇于同一个市场。它们的崛起不是天才的灵光，而是对上一代体系两个未解痛点的精确回应。下一章，我们分别走进这两家公司。
本篇史实（Google GFS 2003 / MapReduce 2004 / BigTable 2006 论文、Doug Cutting 与 Hadoop 命名由来、雅虎 2008 年千节点集群与 1TB 排序基准、Hive 2008 由 Facebook 开源、Spark 2009 诞生于 UC Berkeley AMPLab 且作者 Matei Zaharia 后创办 Databricks、Kafka 2011 由 LinkedIn 开源、ClickHouse 2016 由 Yandex 开源）均为大数据行业公认公开信息，可在各项目官网、Apache 基金会公告及《Hadoop: The Definitive Guide》等资料交叉验证。兴盛优选案例来自华为云官方公开资料；「数据沼泽」为行业俚语，阶段划分为本文归纳。
系列下一篇 · 《云与两条路线：Snowflake 和 Databricks 的时代》——2006 年云把存储变成「无限便宜」，两家公司分别从仓库和湖泊两端出发，相向而行，共同终结了 Teradata 的特权时代。