高级 SQL 优化

1. 核心优化方向指南

在复杂的大数据 ETL 与报表生成环境中，SQL 开发人员应将精力聚焦于以下核心调缺点：

• 严格审查 关联（JOIN） 的使用频次，寻找能否用其他窗口逻辑或条件聚合替换 JOIN 的空间。
• 在“简单关联查询”与“海量子查询”之间寻找 I/O 成本的平衡点。
• 熟练运用分析型引擎中的高级内置 UDF（用户自定义函数）及复杂类型处理（如 Map/Struct/Array 的聚合）。
• 根据数据倾斜的特性灵活应用 窗口函数 (Window Functions) 处理时序业务。

---

2. 组件调度边界原则

2.1. Q: 什么场景使用 BigQuery？什么场景必须用 Spark？

最高原则：能用 BQ 优先使用 BQ。

• BQ 作为纯托管的 Serverless 数仓，完全免去了运维负担，且其底层的 MPP 和向量化引擎在处理常规的重型聚合及多表 Join 时，性能与稳定性通常优于需要自己调参防 OOM 的 Spark 集群。
• 仅当涉及极其复杂的图计算、迭代式机器学习特征工程、或必须处理极不规则的非结构化数据流时，才向 Spark 倾斜。

---

3. 场景优化战术 (Data Modeling Tactics)

3.1. 应对“多维度的海量 Group By 统计”

特征痛点：输出的大多是高度嵌套的复杂结构（如 Struct 数组），虽然维度有上限但组合庞大，容易引发 Shuffle 内存爆炸。 处理路径：

1. 先条件聚合：尽量在单一 SQL 中利用 SUM(IF(condition, 1, 0)) 甚至 ARRAY_AGG(IF(..., struct, null)) 在早期打平数据。
2. 最终才执行代价昂贵的底层物理 JOIN。

3.2. 极致压缩 JOIN 频次

场景：标量性度量统计（区别于保留所有明细的嵌套统计）。 处理路径：

1. 优先将多个维度的状态位打入一张极致的 窄表。
2. 随后通过聚合转置，将窄表行转化为 宽表 的列（Pivot）。避免在每个小维度计算完成后都在底层直接通过 JOIN 进行拼接。

3.3. 数据变更追踪策略

场景：对比源表与目标表的增量 Change（拉链表或同步）。 原则：充分利用 BQ 内置的 MERGE 语法，或结合 Hash 散列键对整行进行指纹比对，避免大量冗长的字段级别比对逻辑。