现代数据仓库的崛起：八个时代的二十年历程
企业如何从手工构建的销售报告发展到拥有数千消费者的PB级多租户平台以及未来十年将如何发展 。
二十年前，“数据仓库”几乎等同于将 数据提取、转换和加载 (ETL) 到 Oracle 或关系型数据库管理系统 (RDBMS) 。存储空间以 GB 为单位 衡量。报表 按月或按周 交付。大多数企业只有不到十几个仪表盘，分析师往往是 SQL 的把关人 。
快进到今天：
Google BigQuery可以对EB 级 数据进行查询
Netflix 使用 Apache Iceberg 来管理 每天数十亿次的流媒体事件 。
Uber 使用 Apache Hudi 管理 150+ PB 的数据 。
这不仅仅是技术问题——这是数据如何成为现代商业 核心产品的故事。
第一个时代：2005–2010 年 · 直接表格 → “只需生成报告”
💡 “数据是成本中心，而不是资产。”
应用程序直接写入报告表（sales_report、customer_report、inventory_report）。 报表通常是 硬编码的 SQL 脚本， 通过cron 作业进行定时运行。 电子表格是手动导出的，并作为“单一事实来源”通过电子邮件发送。应用程序直接写入报告表。仪表板直接询 这些表 。
这种方法原本没问题，直到有人问： 👉 “考虑到库存可用性，我们按客户群体划分的收入是多少？”
解决这个问题通常需要 在 Excel 中手动连接数据 ——有时需要花费数周的时间。
Gartner 2008 年的商业智能魔力象限报告将数据仓库/商业智能的采用描述为“仅限于少数高管”。 大多数公司中只有不到 10% 的员工 能够访问任何数据仓库数据。
突破性进展 ：谷歌的 Dremel（2010 年） 证明了 SQL 可以在几秒钟内处理 数万亿行数据 。这催生了 BigQuery ，彻底改变了人们对数据处理方式的预期，从批量报表转向交互式分析。
第二个时代：2011-2015 年 · 云仓库走向主流
💡 “弹性是新的可扩展性。”
三大创新：
BigQuery（2011 年正式发布） → 首个无服务器、按查询付费的数据仓库。
Amazon Redshift（2013 年正式发布） → 首款价格亲民的PB 级数据仓库。发布之初，定价约为 1000 美元/TB/年 ， 比 Teradata便宜近 20 倍 。
Snowflake（2016 年发布） →多集群共享数据架构，分离存储和计算。
Redshift 的推出引发了数据史上规模最大的迁移之一——3 年内，数千名Oracle/Teradata 客户迁移到了 AWS。
影响 ：销售、客户和库存首次可以集中在一个 云原生仓库 中。扩展规模不再意味着购买新设备；而意味着 只需几分钟即可启动集群 。
第三个时代：2015–2018 · 意大利面条式管道 → 规范原始区域
💡 “要么只有一个真理来源，要么就没有真理。”
随着普及率的提高，管道数量呈爆炸式增长：
财务部门需要一个finance_sales方案。
招聘市场营销人员 需要一个 campaign_customers方案。
招聘操作员 需要一个 inventory_ops方案。
很快，应用程序写入了 多个冗余的数据源 。治理机制崩溃了。
解决方案 ：规范的原始内容 + 精选内容区域。
原始 的：sales_raw，customers_raw，inventory_raw。
精选：fact_sales，dim_customers，fact_inventory。
Presto（Facebook，2013） 等工具支持跨数据源的联合查询。到2018年，Facebook 每天 运行超过3万次Presto查询，为产品分析和广告报告提供支持。
案例研究 ：在此期间，Airbnb 从 MySQL 转储迁移到基于 Hive 的数据仓库，后来又迁移到 Minerva 以强制执行指标一致性。
技术里程碑 ： Presto （由 Facebook 开发）成为首个 快速联合 SQL 引擎 。它允许查询 Hive、MySQL 和 Cassandra 中的数据，而无需迁移数据。
第四个时代：2016–2020 · 湖仓一体
💡 “把酸带到沼泽地。”
数据湖（HDFS、S3、GCS）呈爆炸式增长——但如果没有治理，就会变成 数据沼泽 。
解决方案： 表格式 + ACID 层。
Apache Hudi（2016，Uber） →增量插入、CDC、时间变化。为 Uber Eats 提供预计到达时间预测 支持。
Delta Lake（2020 年，Databricks） → ACID 事务，模式演化。
Apache Iceberg（Netflix） → 可扩展的元数据，隐藏分区。Netflix 每天使用它来处理数十亿条事件 。
到 2019 年，Uber 的 Hudi 管道 每天摄取数千亿行数据 ，管理着超过 150 PB 的存储空间 。
重要性 ：这三人创建了 Lakehouse 。商业智能团队可以运行仪表盘，而机器学习工程师可以使用同一套一致的数据训练模型。
第五个时代：2018–2022 年 · 实时仓储
💡 “如果不是实时更新的，就已经过时了。”
批量 ETL 对 Uber、Netflix 和 LinkedIn 来说还不够：
Uber AthenaX → 基于 Flink 的流式 SQL。用于 动态定价和欺诈检测 。
Apache Pinot（LinkedIn → Uber） → 亚秒级 OLAP。LinkedIn 用它来显示 “谁查看了你的个人资料” ，Uber 用它来提供实时运营仪表盘。
影响 ：
实时检测到库存缺货情况。
促销活动动态调整。
客户流失情况已实时标记。
Netflix 的实时基础设施（Mantis + Iceberg） 每天处理数百亿个事件， 以调整推荐内容。
第六个时代：2018–2024 · 元数据、语义与治理
💡 “没有背景信息的数据就是噪音。”
PB级数据仓库带来了新的问题： 数据发现、信任和治理。
Uber Databook → 拥有超过 10,000 个数据集的元数据平台。
LinkedIn DataHub → 开源元数据 + 血缘关系，现已被 Expedia、Saxo Bank 等公司采用。
Airbnb Minerva → 统一的指标层，每季度节省数千小时的分析师工作时间。
Gartner 估计，到 2023 年， 60-70% 的企业 将有多个相互矛盾的指标定义（“两种收入版本”），因决策质量下降而浪费数十亿美元。
第七个时代：2022–2025 年 · 跨云架构
💡 “你的数据无处不在，所以你的数据仓库也必须如此。”
企业现在运行 多云+混合云环境 。
Google BigLake (2022) → BigQuery + open tables的统一治理/安全层
Microsoft OneLake（2023 年，Fabric） → 用于所有 Fabric 服务的“一个逻辑数据湖”。
第八个时代：2025–2035 年 · 下一步是什么
💡 “你的仓库会先你一步思考。”
基于当前事实的预测：
1.AI原生仓库
已投入使用：BigQuery AI、Snowflake Cortex、Microsoft Fabric Copilot。
到 2030 年， 超过 50% 的查询将由 AI 副驾驶自动生成 （Gartner）。
2. 自主治理
OpenLineage等标准+ AI 监控血缘关系、成本和模式漂移方面的异常情况。
3. 数据网格 2.0
域（销售、客户、库存）变为具有服务级别协议 (SLA) 的 数据产品 API 。
4. 自然语言界面
“显示亚太地区下季度的库存风险”→ LLM 转换为 SQL → Copilot 通过血缘关系和指标进行验证。
5. 默认采用跨云架构
Google BigLake、Microsoft OneLake、Snowflake 的跨云复制 → 真正的“架构”基础设施。
九 要点总结
2000 年代 → 直接表，脆弱但简单。
2010 年代 → 云仓库 + 原始区域使分析大众化。
2010 年代后期 → Lakehouse + 流式统一批处理 + 实时。
2020年代 → 元数据、语义、治理和跨云架构。
下一个十年 → 人工智能原生、自主、受控、基于织物的仓库。
十 架构师、分析师和领导者应该从中汲取什么经验
每五年进行一次变革性的设计 → 架构演进速度超过技术债务偿还速度
规范原始区域是不可协商的 → 对于审计、重放和合规性至关重要。
语义一致性比计算速度更重要 → 指标漂移的成本比存储成本更高。
流式处理优先的思维模式 → 仅批量处理 = 过时的做法。
元数据 + 血缘 = 最重要的任务 → 发现和信任比摄取速度更重要。
跨云架构将占据主导地位 → 数据是全球性的，治理也必须随之全球化。
AI 副驾驶将成为仓库用户 → 设计您的仓库以同时服务于人类和机器。
投资于可观测性 → 将数据管道视为软件产品（SLO、SLA、警报）。
数据即产品 → 各领域必须拥有销售、客户、库存数据集并签订合同。
本文来自微信公众号 “数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
