企业官网建设流程全解析

1. 项目概述：多维聚合中的数据操作，远不止GROUP BY那么简单

“Part 20: Data Manipulation in Multi-Dimensional Aggregation”——这个标题乍看像是一门数据库课程的第20讲，但如果你真把它当成“GROUP BY加个COUNT”就完事，那在实际业务中踩坑是迟早的事。我在电商中台干了七年，从最早写SQL跑日报，到后来设计千万级用户行为宽表，再到牵头重构BI底层聚合引擎，最深的体会就是：多维聚合不是数据的终点，而是数据操作的起点。它背后牵扯的从来不是语法对错，而是维度建模的合理性、计算资源的分配逻辑、业务口径的一致性，以及下游消费时的稳定性预期。比如，一个“按省份+月份+商品类目统计GMV”的需求，表面是三个维度聚合，实则暗藏陷阱：当某省某月某类目销量为0时，该记录是否必须补全？当用户临时要求加入“新老客标签”这一维度，而原始明细表里没有该字段，是回刷历史还是做实时打标？当聚合结果要同步给12个下游系统，其中3个只认宽表、4个依赖API、5个需要流式更新，你聚合出来的结构到底该是宽表、窄表还是键值对？这些都不是SELECT province, month, category, SUM(gmv) FROM sales GROUP BY 1,2,3能回答的。本篇不讲基础语法，也不堆砌函数列表，而是聚焦真实生产环境里，我们如何把“多维聚合”从一个静态计算动作，变成一套可配置、可追溯、可扩展、可降级的数据操作体系。适合三类人：刚脱离单表查询、开始接触宽表开发的中级数据工程师；常被业务方一句“再加个维度”搞得要重跑全量的BI分析师；以及正在设计数仓分层、纠结DWS层到底该存什么形态的架构师。接下来的内容，全部来自我亲手落地的6个大型聚合项目，包括某头部直播平台的实时成交归因引擎、某跨境SaaS企业的多币种多时区营收聚合服务，以及我们自研的聚合任务治理平台AggFlow——所有方案都经过日均百亿级事件、千级并发查询的验证。

2. 多维聚合的本质解构：它不是计算，而是数据契约的建立

2.1 为什么传统GROUP BY在复杂场景下必然失效

很多人以为多维聚合的核心难点在于“性能”，其实不然。真正卡住项目进度的，永远是语义模糊性和契约缺失。举个我去年处理的真实案例：某金融客户要求“按产品线+客户等级+开户渠道统计季度新增资产”。开发同学很快写出SQL，跑出结果交付。两周后业务方提出质疑：“为什么‘财富管理’产品线下，‘黑金客户’在‘APP渠道’的数值，比我们自己用Excel交叉汇总的结果少了17%？”排查发现，问题出在“客户等级”的定义上——上游CRM系统里，“黑金客户”是按AUM（资产管理规模）动态计算的，而聚合任务用的是开户当日快照等级。更致命的是，“开户渠道”字段在埋点日志里存在歧义：用户通过APP下载H5页注册，但最终在APP内完成开户，该记为“H5渠道”还是“APP渠道”？两个系统各自有理，但聚合层没做任何澄清。这说明，多维聚合的第一步不是写SQL，而是签订一份数据契约（Data Contract）：明确每个维度的来源系统、更新频率、取值逻辑、空值含义、枚举范围，以及维度间的关系约束（如“客户等级”不能独立于“客户ID”存在）。我们后来强制推行的契约模板包含7个必填项：维度名称、物理字段名、业务定义原文、数据源表/接口、刷新策略（T+1/实时/准实时）、默认值规则、与其他维度的依赖关系。例如，“开户渠道”的契约中明确写道：“取值仅限['APP','H5','小程序','线下柜台']，来源为开户事件日志的channel_id字段，若为空则根据user_agent和referrer联合推断，推断失败时置为'未知'，且'未知'不参与任何下钻分析”。这份契约不是文档，而是直接嵌入聚合任务元数据，在调度平台上线前强制校验。没有契约的聚合，就像没有图纸盖楼，外表光鲜，地基全是沙子。

2.2 多维聚合的三层结构：从物理计算到逻辑服务

我把生产环境中的多维聚合拆解为三个不可割裂的层次，每一层解决不同维度的问题：

• 物理层（Physical Layer）：这是最接近传统认知的“计算层”，负责将原始明细数据（如订单表、日志表）通过SQL或Spark作业，按指定维度组合进行分组、聚合、计算指标。关键点在于：它必须是幂等的、可重跑的、带版本控制的。我们要求所有物理层脚本必须声明输入表版本（如sales_v202310）、输出表版本（如dws_sales_agg_v202310），并自动记录每次执行的输入数据时间范围（dt_start='2023-09-01',dt_end='2023-09-30'）。这样当业务发现9月数据异常，可以精准重跑9月全量，而不影响其他月份。物理层不处理任何业务逻辑判断，只做纯粹的数学运算。

• 逻辑层（Logical Layer）：这是最容易被忽视，却最关键的一层。它负责将物理层产出的“原始聚合结果”，转化为业务可理解的“逻辑视图”。例如，物理层产出的是province_code, month, gmv_sum, order_cnt，而逻辑层要提供province_name, month_name, gmv_formatted, is_top10_province。这里的关键操作是：维度表关联（将编码转名称）、指标衍生（如gmv_per_order = gmv_sum / order_cnt）、业务规则注入（如is_top10_province需调用实时排名服务API）。逻辑层必须与物理层解耦，允许业务方在不触碰底层计算的情况下，快速调整展示逻辑。我们采用View-as-Code模式，所有逻辑层定义以YAML文件形式管理，例如dws_sales_logic.yaml中定义：

  view_name: sales_summary base_table: dws_sales_agg_v202310 joins: - table: dim_province on: "t1.province_code = t2.province_code" columns: - name: province_name expr: "t2.province_name" - name: gmv_formatted expr: "format_number(t1.gmv_sum, 2)" metrics: - name: gmv_per_order expr: "t1.gmv_sum / NULLIF(t1.order_cnt, 0)"

• 服务层（Service Layer）：这是面向下游消费的统一出口。它不存储数据，而是提供标准化访问方式：REST API、GraphQL端点、或预生成的宽表导出。服务层的核心职责是：权限控制（某部门只能查本省数据）、缓存策略（高频查询走Redis，低频走直连）、降级机制（当底层聚合延迟超5分钟，自动返回T-1缓存数据）、以及最重要的——查询重写（Query Rewriting）。例如，当用户在BI工具中拖拽“省份”、“月份”、“GMV”三个字段时，服务层会识别出这是对sales_summary视图的查询，并自动将前端请求转换为对物理表dws_sales_agg_v202310的高效查询，同时注入租户隔离条件AND tenant_id = 'finance_dept'。没有服务层，每个下游系统都要自己写JOIN、自己处理权限、自己实现缓存，聚合的价值就被稀释了。

这三层不是线性流程，而是环形协作：物理层为逻辑层提供原料，逻辑层为服务层提供语义，服务层的消费反馈（如某维度查询慢、某指标使用率低）又驱动物理层优化计算逻辑。忽略任一层，都会导致聚合体系脆弱不堪。

2.3 维度爆炸的真相：不是维度太多，而是维度关系没理清

“维度爆炸”常被当作多维聚合的天敌，但我的经验是：80%的所谓爆炸，源于维度建模的随意性。比如，一个电商项目初期定义了“用户性别”、“用户年龄分段”、“用户城市等级”三个维度，单独看都很合理。但当业务方要求“按性别+年龄分段+城市等级”交叉分析时，组合数达到2×5×3=30种，而其中“男性+18-24岁+超一线城市”的样本量可能只有个位数，导致统计结果毫无意义，还拖慢查询。问题不在维度数量，而在维度间的业务相关性和数据分布合理性。我们后来建立了维度健康度评估模型，对每个新维度上线前强制打分：

只有总分≥75分的维度才允许进入聚合体系。这套模型让我们砍掉了17个“看起来有用”的维度，聚合任务的平均响应时间反而下降了40%。维度不是越多越好，而是越能精准刻画业务本质越好。

3. 核心数据操作技术详解：从补全、填充到动态切片

3.1 维度补全（Dimensional Completeness）：让“零值”变得有意义

在多维聚合中，“某维度组合下无数据”是最常见的业务困惑。比如，财务部要求“按月份+产品线统计营收”，但某新产品线9月才上线，8月数据自然为空。如果聚合结果直接不返回8月该产品线的记录，下游BI图表就会出现“断层”，业务方第一反应是“数据丢了”。真正的解决方案不是让SQL返回空行，而是主动补全（Full Outer Join）所有合法的维度组合。但这说起来简单，做起来有三大陷阱：

• 陷阱一：补全范围失控。如果对“月份”补全过去10年，“产品线”补全全部历史曾用过的50个，组合数高达120×50=6000行，其中99%是业务完全不关心的“幽灵数据”。我们的做法是：补全必须基于业务有效周期。在契约中明确定义每个维度的“活跃期”。例如，“产品线”维度的活跃期是start_date <= current_date AND (end_date IS NULL OR end_date >= current_date)，而“月份”维度的活跃期是month >= '2023-01'（公司统一规定只保留3年数据）。补全脚本会先扫描所有维度表，获取当前有效的维度值集合，再做笛卡尔积。代码逻辑如下（Spark SQL）：

  -- 步骤1：获取有效月份（只取近36个月） WITH valid_months AS ( SELECT to_date(date_add(last_day('2023-01-01'), seq*30)) as month_dt FROM (SELECT posexplode(split(repeat(',', 35), ',')) as (seq, x)) t ), -- 步骤2：获取有效产品线（状态为'active'） valid_products AS ( SELECT product_id, product_name FROM dim_product WHERE status = 'active' ), -- 步骤3：生成所有有效组合 full_combinations AS ( SELECT m.month_dt, p.product_id, p.product_name FROM valid_months m CROSS JOIN valid_products p ) -- 步骤4：左连接原始聚合结果，空值补0 SELECT fc.month_dt, fc.product_id, fc.product_name, COALESCE(a.revenue_sum, 0) as revenue_sum, COALESCE(a.order_cnt, 0) as order_cnt FROM full_combinations fc LEFT JOIN dws_revenue_agg a ON fc.month_dt = a.month_dt AND fc.product_id = a.product_id;

  这样生成的补全结果，既满足业务“图表不断层”的需求，又不会产生垃圾数据。

• 陷阱二：补全逻辑与业务口径冲突。比如，“用户等级”维度中，“VIP1”到“VIP5”是连续等级，但“VIP3”在某个月份因策略调整被暂停发放，导致该月无VIP3用户。如果机械补全，会显示“VIP3营收=0”，误导业务认为“VIP3用户流失”。此时应补全为NULL而非0，并在契约中注明：“等级维度补全仅针对已存在的等级，不预测未来等级”。我们在服务层增加了一条规则：当补全值对应维度的is_active = false时，指标列置为NULL并附加注释"dimension_inactive"。

• 陷阱三：补全后的指标不可加总。补全产生的“0”值，在做上卷（Roll-up）时会导致错误。例如，按“产品线”上卷时，VIP3的0会拉低整体平均值。因此，补全必须标记元数据。我们在输出表中增加is_completeness_row BOOLEAN字段，并在服务层API中提供include_completeness参数，默认false，仅当业务明确需要查看补全行时才返回。这避免了下游无意中把补全数据纳入统计。

提示：补全不是技术炫技，而是业务沟通的结果。每次补全方案上线前，必须与业务方共同签署《补全影响说明书》，明确列出补全的维度、范围、对现有报表的影响、以及替代方案（如不补全，改用“最近非空值”填充）。

3.2 动态切片（Dynamic Slicing）：让同一份聚合数据，服务千人千面

传统聚合是“一次计算，全局适用”，但现实是：销售总监要看全国大区对比，区域经理只关心自己辖区，一线销售只想看自己跟进的客户。如果为每个人物角色都建一张聚合表，存储和维护成本指数级增长。动态切片的核心思想是：在服务层，根据请求上下文，实时过滤和重定向查询，而不是在物理层预计算。我们基于Apache Calcite构建了轻量级切片引擎，其工作流程如下：

1. 请求解析：API网关收到请求GET /api/v1/sales?region=华东&product=手机&time_range=last_30d，提取出region、product、time_range三个切片条件。
2. 策略匹配：引擎查询切片策略库，找到匹配规则。例如，策略sales_region_product定义：

   { "name": "sales_region_product", "base_table": "dws_sales_agg_v202310", "filters": [ {"field": "region_code", "source": "region_map", "mapping": {"华东": "EAST", "华北": "NORTH"}}, {"field": "product_category", "value": "手机"}, {"field": "dt", "range": "last_30d", "calculation": "date_sub(current_date, 30)"} ], "cache_ttl": 300 }

3. SQL重写：引擎将原始请求重写为：

   SELECT province, month, SUM(gmv) as gmv_sum FROM dws_sales_agg_v202310 WHERE region_code IN ('EAST') AND product_category = '手机' AND dt BETWEEN '2023-08-25' AND '2023-09-23' GROUP BY province, month

4. 执行与缓存：查询提交至Presto集群，结果缓存5分钟。

这种模式的优势在于极致灵活：新增一个“按客户行业分类”的切片，只需在策略库中添加一条JSON，无需改动任何物理表或ETL任务。我们甚至支持嵌套切片，例如销售总监先按大区切片，再下钻到“华东”内部，系统自动继承上级的region_code='EAST'条件，避免重复过滤。动态切片让聚合数据从“静态快照”变成了“活水”，这才是多维聚合的终极形态。

3.3 指标衍生与上下文注入：让数字开口说话

聚合结果中的原始指标（如SUM(gmv)）只是数字，要让它产生业务价值，必须注入上下文。我们把指标衍生分为三类，每类对应不同的技术实现：

• 静态衍生（Static Derivation）：基于固定规则的计算，如“GMV环比”、“订单转化率”。这类直接在逻辑层YAML中定义，编译为SQL表达式。例如：

  metrics: - name: gmv_mom expr: "(t1.gmv_sum - LAG(t1.gmv_sum) OVER (PARTITION BY t1.province ORDER BY t1.month)) / NULLIF(LAG(t1.gmv_sum) OVER (PARTITION BY t1.province ORDER BY t1.month), 0)"

  关键是窗口函数必须与聚合维度严格对齐。如果物理层按province+month聚合，那么LAG的PARTITION BY必须是province，ORDER BY必须是month，否则结果错乱。

• 动态衍生（Dynamic Derivation）：依赖外部实时数据的计算，如“当前库存周转天数”（需查库存服务API）、“竞品价格优势”（需调用比价爬虫）。这类不能在SQL中硬编码，我们采用UDF（用户自定义函数）+服务网关模式。在Presto中注册Java UDF：

  public class InventoryUdf { @ScalarFunction("inventory_turnover_days") @SqlType(StandardTypes.DOUBLE) public static double getTurnoverDays(@SqlType(StandardTypes.VARCHAR) Slice productId) { // 调用库存服务HTTP API String url = "https://inventory-api.example.com/turnover?product_id=" + productId.toStringUtf8(); return HttpUtil.get(url).getDouble("turnover_days"); } }

  逻辑层调用：inventory_turnover_days(product_id)。为防服务雪崩，UDF内置熔断器（Hystrix），超时1s即返回NULL，并记录告警。

• 语义衍生（Semantic Derivation）：赋予数字业务含义，如“高价值客户”（GMV > 10万且复购率 > 30%）、“风险订单”（支付成功但物流超7天未揽收）。这类衍生不产生新数字，而是生成标签。我们采用规则引擎（Drools）+异步计算。物理层产出原始指标后，触发Drools规则评估：

  rule "High Value Customer" when $c: Customer(gmvSum > 100000, repurchaseRate > 0.3) then insert(new CustomerTag($c.id, "HIGH_VALUE")); end

  标签结果写入customer_tag表，服务层查询时通过LEFT JOIN注入。语义衍生的最大价值是：规则可配置、可审计、可回溯。业务方在管理后台修改“高价值”阈值，无需发版，当天生效。

注意：所有衍生指标必须在契约中明确定义计算逻辑、数据源、更新频率。我们曾因“复购率”在逻辑层用T+1数据，而服务层API又实时调用Drools，导致同一客户在不同入口看到不同标签，引发严重客诉。教训是：衍生指标的“新鲜度”必须统一，要么全T+1，要么全实时，绝不混用。

4. 实操全流程：从需求接收到上线监控的12个关键节点

4.1 需求接收与契约初稿（节点1-3）

这不是简单的“抄需求”，而是结构化访谈。我坚持用一套问题清单，确保不遗漏关键信息：

• Q1：这个聚合结果谁用？用在哪儿？（明确消费者画像）
  例：不是“销售团队”，而是“华东大区销售总监，用于周会PPT，需导出为Excel”
  → 决定服务层输出格式（API/Excel导出）、权限粒度（按大区）、缓存策略（PPT用数据，缓存24h足够）

• Q2：维度组合中，哪些是强制下钻路径？哪些是可选筛选？（区分主次维度）
  例：“省份+城市”是强制下钻（必须能从省看到市），“用户性别”是可选筛选（不能作为下钻起点）
  → 决定物理层是否预计算“省份+城市”组合，还是只存“省份”，城市由服务层实时JOIN

• Q3：指标的业务定义是什么？有没有例外情况？（捕获边界Case）
  例：“GMV”是否含退款？是否含优惠券抵扣？某促销活动期间是否按特殊口径计算？
  → 决定物理层WHERE条件（WHERE order_status != 'refunded'）和逻辑层是否需要CASE WHEN分支

完成访谈后，2小时内产出《数据契约初稿》，包含维度清单、指标定义、示例数据（手写3行模拟数据）、以及3个最可能出问题的假设场景（如“某城市无数据时如何展示”）。初稿发给业务方，要求48小时内书面确认，否则视为需求冻结。

4.2 物理层开发与测试（节点4-7）

开发不是写完SQL就结束，而是四步验证法：

1. 数据源验证：用SELECT COUNT(*), COUNT(DISTINCT key) FROM source_table WHERE dt = '2023-09-01'确认源表数据量和主键去重率。我们要求去重率必须≥99.5%，否则说明存在脏数据（如重复埋点），必须先清洗源表。

2. 逻辑验证：抽取100条明细数据，人工计算期望的聚合结果，再与SQL结果比对。重点检查NULL值处理（COALESCE是否覆盖所有可能）、COUNT与COUNT DISTINCT误用、SUM是否该用AVG。

3. 性能压测：用EXPLAIN分析执行计划，确保走了索引。然后在测试环境用spark-submit提交全量任务，记录耗时。我们设定红线：单次聚合耗时≤15分钟（T+1场景）或≤30秒（准实时场景）。超时必须优化：要么加索引，要么改用物化视图，要么拆分维度（如先按省份聚合，再按城市聚合）。

4. 幂等性验证：对同一输入日期，连续运行任务3次，检查输出表_version字段是否递增，且三次输出数据完全一致。这是防止线上事故的最后防线。

实操心得：我习惯在物理层SQL开头加注释块，记录本次开发的决策依据。例如：

/* * 聚合逻辑说明： * 1. GMV定义：订单支付成功且未退款的金额，含运费，不含优惠券（因优惠券由营销中心单独核算） * 2. 时间口径：按订单支付时间（pay_time）分区，非下单时间（create_time） * 3. 空值处理：province_code为空时，根据IP地址库映射，映射失败置为'UNKNOWN' * 4. 性能优化：在dim_province表的province_code字段上创建BloomFilter索引 */

4.3 逻辑层与服务层联调（节点8-10）

这是最容易被跳过的环节，却是上线前最关键的“翻译校验”。我们强制要求：

• 逻辑层YAML必须通过Schema校验：使用JSON Schema定义dws_logic_schema.json，校验字段名合法性、表达式语法（用ANTLR解析）、指标循环引用（如a = b + c,b = a + d）。

• 服务层API必须通过契约测试：用Postman Runner批量发送100个典型请求（含正常、空值、越界、SQL注入尝试），验证：

  • 响应状态码（200/400/403/500）
  • 响应体结构（字段名、类型、是否可空）
  • 响应时间（P95 ≤ 1.5s）
  • 错误信息友好性（不暴露SQL细节，如“参数region无效”而非“Unknown column 'region'”）

• 权限沙盒测试：创建3个测试账号（管理员、区域经理、普通销售），分别登录BI工具，验证他们能看到的数据范围是否严格符合契约中定义的权限矩阵。我们曾发现一个BUG：区域经理账号能查到其他区域数据，原因是服务层的tenant_id过滤条件写在了JOIN之后，导致WHERE失效。这个BUG只能在联调时暴露。

4.4 上线发布与灰度监控（节点11-12）

上线不是“一键发布”，而是渐进式交付：

• Step 1：影子发布（Shadow Release）
  新聚合任务与旧任务并行运行，新任务结果写入dws_new_v202310_shadow表，不对外提供服务。持续7天，对比新旧表数据差异率（ABS(new-old)/NULLIF(old,0)），要求差异率≤0.1%。差异主要来自修复的逻辑Bug（如之前漏了某个退款状态）。

• Step 2：读流量灰度（Read Traffic Shift）
  将5%的API请求路由到新服务，监控错误率、耗时、缓存命中率。同时，让2个核心业务方（如销售总监、财务BP）手动比对新旧数据，签署《灰度验证报告》。

• Step 3：全量切换与熔断
  切换后，立即开启熔断开关：当新服务错误率>5%或P95耗时>3s，自动回切到旧服务，并触发告警。熔断开关本身也需测试——我们每月做一次“熔断演练”，随机关闭新服务，验证回切是否在10秒内完成。

监控不是只看“任务成功”，而是盯紧四个黄金指标：

1. 数据新鲜度（Freshness）：从源数据产生到聚合结果可用的时间差，SLO为T+1≤2小时，准实时≤5分钟；
2. 数据准确性（Accuracy）：与抽样核验的基准数据比对，误差率≤0.5%；
3. 服务可用性（Availability）：API 200成功率≥99.95%；
4. 查询性能（Performance）：P95响应时间≤1.2s。
   这四个指标全部接入Prometheus+Grafana，设置分级告警（Warning/Critical），Critical告警必须15分钟内响应。

5. 常见问题与实战排障指南：那些文档里不会写的坑

5.1 问题速查表：高频故障与根因定位

5.2 我踩过的三个血泪坑

坑一：用COUNT(*)代替COUNT(column)引发的灾难
项目上线第三天，业务方惊呼“用户数暴增10倍”！排查发现，物理层SQL中写了COUNT(*)统计用户数，但事实表中存在大量user_id IS NULL的测试订单。COUNT(*)统计所有行，而COUNT(user_id)只统计非NULL。修正很简单，但代价是：重跑过去30天数据，消耗了额外2000核小时计算资源。教训：永远用COUNT(主键)或COUNT(业务关键字段)，并在契约中明确定义“用户数”的统计口径是“去重有效用户ID”。

坑二：维度表更新延迟导致的“昨日数据丢失”
某次大促后，发现“省份”维度表因上游系统故障，延迟了6小时才更新。而我们的聚合任务在凌晨2点启动，此时维度表中“新上线的XX省”还未录入，导致所有该省订单在聚合中被归为UNKNOWN。解决方案：在物理层SQL中加入维度表“兜底逻辑”：

-- 先尝试精确匹配 LEFT JOIN dim_province p1 ON f.province_code = p1.province_code -- 再尝试模糊匹配（如用IP库） LEFT JOIN dim_province_ip p2 ON f.ip_address BETWEEN p2.start_ip AND p2.end_ip -- 最终取值：优先p1，p1为空则取p2，都为空则'UNKNOWN' COALESCE(p1.province_name, p2.province_name, 'UNKNOWN') as province_name

并设置告警：当p1.province_name IS NULL AND p2.province_name IS NULL的比例>1%，立即通知维度表负责人。

坑三：服务层缓存击穿引发的雪崩
某次发布会，CEO在大屏上实时查看“各渠道GMV”，瞬间百万QPS涌入。由于所有请求的time_range=now，缓存Key高度一致（如sales_now），导致缓存穿透，所有请求直击底层Presto，集群CPU飙到100%。根治方案是“缓存Key打散”：在服务层，对now类时间参数，生成随机后缀：

# 伪代码 if time_range == "now": cache_key = f"sales_{int(time.time() / 60)}_{random.randint(1, 100)}" else: cache_key = f"sales_{time_range}"

这样，每分钟最多100个Key，分散了压力。同时，为now类查询设置更短的TTL（30秒），确保数据新鲜度。

5.3 性能优化的五个反直觉技巧

1. 不要迷信“物化视图”：很多团队一上来就建物化视图加速聚合，但物化视图的维护成本（存储、刷新延迟、一致性保障）往往超过收益。我们的经验是：只有当某个维度组合的查询频率≥100次/天，且计算耗时≥5秒时，才考虑物化。否则，用Presto的WITH子句+查询结果缓存更轻量。

2. “小表广播”有时比“大表分桶”更有效：当维度表<10MB时，强制Spark广播（spark.sql.autoBroadcastJoinThreshold=20971520），比对事实表分桶JOIN快3倍。我们曾将dim_product（8MB）广播后，聚合任务从12分钟降至4分钟。

3. 用ARRAY_AGG替代多次JOIN：当需要在一个聚合结果中