📚 课程目录第1章云数据仓库的演进与核心特征

1. 云数据仓库的演进与核心特征

传统数据仓库的核心矛盾，可以用一句话概括：数据在长大，而机器不能跟着长。早期数仓以 Teradata、Oracle Exadata、IBM Netezza 等一体机为代表，计算与存储绑定在同一批物理节点上，扩容只能整机采购、停机搬迁、重新分布数据。当业务从 T+1 报表走向实时看板、从结构化订单走向日志与埋点，这种"烟囱式"架构很快撞上三堵墙：扩容周期以月计、峰值资源长期闲置、单集群容量存在物理上限。

云数据仓库并不是把传统数仓搬到虚拟机上，而是把"存储"和"计算"这两件本来被焊死的事拆开。理解这一点，是理解后面所有特性的钥匙。

存算分离：把数据放在对象存储，把算力做成临时集群

存算分离的物理基础是对象存储（S3、OSS、GCS、Azure Blob）。数据以列式文件（Parquet、ORC）形式持久化在对象存储中，计算节点不再持有数据，只负责读取、计算、写回。这带来三个直接后果：

计算可随时销毁：查询结束，计算集群可以立即释放，不必为"下次查询"保留机器。
多集群共享同一份数据：ETL 集群、BI 查询集群、数据科学集群读同一份表，互不复制数据。
存储成本与计算成本解耦：冷数据沉在廉价对象存储，热计算按需付费。

代价也很真实：对象存储的延迟远高于本地 SSD，因此云数仓必须在缓存层、元数据层和文件布局上做大量优化，否则"分离"会变成"变慢"。

弹性伸缩与按需付费：从"买容量"到"买算力秒"

弹性伸缩的本质是计算资源的供给曲线可以跟随负载曲线。以 Snowflake 为例，虚拟仓库（Virtual Warehouse）可在秒级启动，从 XS 到 6XL 逐级放大；多集群仓库还能在并发升高时自动增加集群数量。BigQuery 则更进一步，采用无服务器（Serverless）模式，用户不感知任何集群，只提交 SQL，由 Google 调度槽位（Slot）执行。

按需付费把成本模型从"固定资产折旧"变成"可变成本"。这既是优势也是陷阱：一条没有分区裁剪的全表扫描，可能在一分钟内烧掉几十美元。因此云数仓的优化重点，从"如何让 SQL 跑得更快"扩展为"如何让 SQL 跑得又快又便宜"。

四款典型产品的定位差异

Snowflake、BigQuery、Redshift、MaxCompute 常被放在一起比较，但它们的出身和设计哲学差别很大。下面这张图从"架构形态—弹性方式—计费粒度—典型场景"四个维度做了对照，便于建立选型直觉。

从图中可以看出，四者的差异并不在"谁更快"，而在弹性发生在哪一层。Snowflake 把弹性放在虚拟仓库层，用户显式管理算力；BigQuery 把弹性藏在调度器里，用户只面对 SQL；Redshift 的弹性仍带有 MPP 集群的痕迹，扩容往往伴随数据重分布；MaxCompute 则用 Quota 把算力切成可分配的资源组，适合多项目、多团队共享的大规模离线场景。

一个可观察的对比示例

假设有一张 2TB 的订单明细表 dwd_order_detail，按 dt 分区，每天新增约 8GB。现在要跑一条"近 30 天各省 GMV"的查询。在传统数仓里，这条 SQL 的执行时间基本固定；在云数仓里，它会同时受三个变量影响：

-- 示例查询（参数为教学假设值）
SELECT province, SUM(pay_amt) AS gmv
FROM   dwd_order_detail
WHERE  dt BETWEEN '2024-05-01' AND '2024-05-30'
GROUP  BY province;

-- 假设：30 个分区，每分区 8GB，总扫描量约 240GB
-- BigQuery 按扫描量计费：240GB × $6.25/TB ≈ $1.5
-- Snowflake 用 XS 仓库（1 credit/小时）：若耗时 90 秒 ≈ 0.025 credit
-- 若忘记加 dt 过滤，扫描量变为 2TB，BigQuery 成本约 $12.5，相差 8 倍

这个例子说明：云数仓的成本与"扫描了多少数据"强相关，而不是与"返回了多少行"相关。分区裁剪、列裁剪、聚簇/排序键，在云上从"性能优化"升级为"成本控制"。

判断一个云数仓是否真正"云原生"，可以看三个信号：计算资源能否在不搬迁数据的前提下独立扩缩；存储是否由对象存储承载并支持多引擎共享；计费是否细到秒级或扫描量级。三者缺一，往往只是"托管在云上的传统数仓"。

选型时真正该问的问题

不要先问"哪个产品最强"，而要先问四个问题：数据主要落在哪个云上？查询是高频小并发还是低频大扫描？团队是否愿意管理算力规格？预算是按固定容量还是按实际用量？Snowflake 适合愿意精细管理仓库、需要跨云与多租户隔离的团队；BigQuery 适合不想运维、查询模式偏即席与日志分析的团队；Redshift 适合已深度绑定 AWS、以 BI 报表为主的团队；MaxCompute 适合数据量极大、需要多项目算力隔离的离线数仓场景。

理解存算分离、弹性伸缩、按需付费这三件事，以及它们在不同产品中的落地方式，是后续学习建模、分区、聚簇、物化视图与成本治理的前提。云数仓没有改变"数仓要建模、要治理"的本质，它改变的是资源的使用方式与成本的可见方式。