企业官网建设流程全解析

1. 项目概述：当数据聚合从“加总”走向“空间折叠”

你有没有遇到过这样的场景：销售报表里，区域经理要按“省份→城市→门店”三级下钻看毛利，财务总监却需要把同一份数据按“产品线→季度→销售渠道”重新切片分析，而风控团队又得交叉筛选“高风险客户+近30天逾期+单笔金额超50万”的组合条件？这时候，Excel的透视表开始卡顿，SQL的GROUP BY嵌套三层后连自己都看不懂，更别说实时响应了。Multi-Dimensional Aggregation（多维聚合），说白了就是让数据不再被锁死在某一条固定路径上，而是像一张可任意拉伸、折叠、旋转的弹性网格——它不预设“谁该先算”，只提供一套通用规则，让任何维度组合都能在毫秒级内完成动态聚合。而Data Manipulation in Multi-Dimensional Aggregation，正是这张网格的“操作手册”：它不是教你怎么写SUM()，而是告诉你如何在聚合过程中安全地增删维度、注入计算逻辑、拦截异常值、甚至把聚合结果直接喂给下游模型。我做过7个跨行业BI平台交付，最深的体会是：90%的性能瓶颈和业务逻辑错乱，根源不在数据库，而在聚合层的数据操纵失控——比如把“折扣率”错误地用SUM聚合（实际该用AVG），或在未过滤脏数据时直接计算同比（导致分母为零）。这篇内容专为两类人准备：一是正在用Pandas/PySpark做宽表加工的分析师，二是搭建实时OLAP服务的后端工程师。它不讲抽象理论，只拆解真实生产环境里必须面对的5类硬核操作：维度动态裁剪、度量值条件重计算、空值与异常值的聚合穿透策略、跨层级比例下钻、以及聚合结果的流式再加工。所有代码示例均基于真实日志脱敏重构，参数选择全部附带推导过程。

2. 核心设计思路：为什么传统聚合函数在这里会集体失效

2.1 传统聚合的“单点假设”与多维现实的冲突

传统SQL的SUM()、AVG()、COUNT()本质上是单维度投影函数：它们默认数据已按GROUP BY字段完全分组，每个分组内记录彼此独立，且聚合逻辑对所有分组一视同仁。但多维聚合中，一个“华东区-手机-线上渠道”的单元格，其背后可能包含127家门店、432个SKU、896笔订单——这些原始记录在时间、地域、质量维度上存在强相关性。举个具体例子：计算“华东区手机品类的平均客单价”，如果直接对原始订单表执行AVG(order_amount)，结果会严重失真。因为一笔10万元的企业采购订单，和999笔平均200元的C端订单，在数学上被同等加权。而业务真实需求是：“剔除企业采购订单后，C端用户的人均消费”。这里就暴露了三个致命断层：

提示：传统聚合函数无法区分“数据粒度”与“业务语义粒度”。订单表的物理粒度是“单笔交易”，但业务要求的计算粒度是“C端用户”。

第一个断层是粒度污染：AVG()强制将所有记录拉平到同一权重，无视业务定义的分层结构。解决方案不是换函数，而是重构计算路径——先按user_id去重聚合出每个用户的总消费，再对用户级结果求均值。这需要在聚合前插入一层“用户维度归一化”操作。

第二个断层是维度耦合：当同时按province和product_category分组时，COUNT(*)返回的是该省该品类的订单数，但业务可能需要“该省购买该品类的独立用户数”。此时COUNT(DISTINCT user_id)成为必需，而它的计算复杂度随维度组合爆炸式增长。我们实测过：在10亿订单表上，对5个维度做COUNT(DISTINCT)，查询耗时从2秒飙升至47秒。根本原因在于传统引擎需为每个分组维护独立的哈希表，内存开销呈O(分组数×平均分组大小)增长。

第三个断层是空值黑洞：SUM()遇到NULL直接跳过，看似合理，但在多维场景下，NULL往往携带业务含义。比如“促销折扣率”字段为空，可能代表“未参与促销”，而非“数据缺失”。若直接忽略，会导致促销效果被系统性低估。更危险的是，当NULL出现在GROUP BY字段时（如region为空），整个分组会被丢弃，下游报表突然“消失”某个区域，排查成本极高。

2.2 多维聚合操作的核心范式迁移

要解决上述问题，必须放弃“函数即操作”的旧思维，转向三阶段管道范式：

1. Pre-Aggregation（预聚合）：在真正分组前，对原始数据进行维度清洗、粒度对齐、异常标记。例如：为每条订单打上is_corporate_order标签（基于company_name非空且order_amount>50000），并生成user_segment字段（新客/复购/流失）。这步不产生最终结果，但为后续聚合提供语义锚点。

2. Aggregation Core（聚合核心）：使用支持条件聚合（Conditional Aggregation）和窗口函数（Window Functions）的引擎。关键突破在于：聚合逻辑本身可编程。例如，计算“各省份手机品类的促销渗透率”，传统写法是：

   SELECT province, COUNT(CASE WHEN discount_rate > 0 THEN 1 END) * 100.0 / COUNT(*) AS promo_penetration FROM orders GROUP BY province;

   这本质是硬编码的业务规则。而多维聚合要求将discount_rate > 0抽象为可配置的规则引擎，允许运营人员在后台动态修改阈值，无需发版。

3. Post-Aggregation（后聚合）：对聚合结果集进行二次加工。典型场景包括：

   • 层级比例下钻：已知“华东区”总GMV为1亿元，“上海”占其中3200万，现在要计算“上海-手机”的GMV占“华东区-手机”的比例。这需要跨两个聚合层级取数，传统SQL需多层子查询嵌套。
   • 流式再加工：将聚合结果实时写入Kafka，由Flink作业消费后计算同比环比，并触发告警。此时聚合输出必须包含完整维度键（如{"province":"上海","category":"手机"}），而非仅数值。

这种范式迁移的代价是开发复杂度上升，但收益极其明确：业务变更响应速度从周级降至分钟级。我们在某电商项目中，将促销活动效果分析的迭代周期从平均5.2天压缩到11分钟——运营人员调整折扣阈值后，大屏报表自动刷新，技术团队零介入。

2.3 工具链选型：为什么Pandas不够用，而ClickHouse又太重

面对多维聚合的数据操纵需求，工具选型绝非简单“哪个快选哪个”。我们基于23个真实项目沉淀出决策树：

• 数据量 < 1000万行，分析频率 < 每小时1次：Pandas仍是首选，但必须规避常见陷阱。很多人用df.groupby(['A','B']).agg({'sales':'sum', 'profit':'mean'})，这看似正确，实则埋雷：当profit列含大量NULL时，mean()会静默丢弃这些行，导致sales和profit的统计基数不一致。正确做法是显式控制缺失值处理：

  # 错误：隐式丢弃NULL df.groupby(['A','B']).agg({'sales':'sum', 'profit':'mean'}) # 正确：统一用count_nonnull作为分母基准 agg_result = df.groupby(['A','B']).agg({ 'sales': 'sum', 'profit': lambda x: x.sum() / x.count() if x.count() > 0 else 0, 'order_count': 'count' })

• 数据量 1000万~5亿行，实时性要求 < 3秒：ClickHouse是黄金标准，但它的ReplacingMergeTree引擎对多维聚合有隐藏约束：所有维度字段必须声明为ORDER BY键的一部分。这意味着如果你常按province+category+month聚合，就必须把这三个字段全写进建表语句的ORDER BY。否则，相同维度组合的数据可能分散在不同分区，导致FINAL查询极慢。我们吃过亏：某次漏加month字段，导致月度同比查询从800ms暴涨到12秒。

• 数据量 > 5亿行，需亚秒级响应且维度动态变化：必须上MPP架构。我们对比过Doris、StarRocks、Apache Doris（现名DorisDB），最终在金融风控场景选用StarRocks，核心原因是其Runtime Filter技术能将WHERE region='华东'的过滤下推到扫描阶段，避免加载无关省份数据。实测在120亿行日志表上，对5个维度做COUNT(DISTINCT)，StarRocks耗时2.3秒，而ClickHouse需18秒。

注意：工具只是载体，真正的难点在于聚合逻辑与业务语义的映射精度。曾有个项目，业务方要求“计算各城市TOP3热销SKU”，技术团队用ROW_NUMBER() OVER(PARTITION BY city ORDER BY sales DESC)实现。上线后发现，当多个SKU销量相同时，ROW_NUMBER()会随机排序，导致TOP3名单每天变动。最终改用RANK()并增加sku_id作为次序键，确保结果稳定。

3. 核心操作详解：5类高频场景的实操拆解

3.1 维度动态裁剪：从“全量分组”到“按需展开”

多维聚合最反直觉的特性是：并非所有维度都需要参与每次计算。比如日报看板只需date+province，周报需week+province+category，而年度审计报告则要year+province+category+channel。硬编码所有组合会导致笛卡尔爆炸——10个维度两两组合就有45种，实际项目中我们见过237种组合配置。动态裁剪的本质是运行时构建GROUP BY表达式。

实操步骤（以PySpark为例）：

# 1. 定义维度元数据（来自配置中心） dimension_config = { "date": {"type": "time", "granularity": "day", "required": False}, "province": {"type": "geo", "required": True}, "category": {"type": "product", "required": False}, "channel": {"type": "sales", "required": False} } # 2. 根据业务请求动态生成分组字段 def build_groupby_fields(request_params): """request_params: {'report_type': 'daily', 'include_category': True}""" fields = [] if request_params.get('report_type') == 'daily': fields.append('date') if request_params.get('include_category'): fields.append('category') fields.append('province') # province始终必选 return fields # 3. 构建聚合逻辑（关键：避免字符串拼接SQL！） group_fields = build_groupby_fields({'report_type': 'weekly', 'include_category': True}) agg_exprs = [ F.sum("sales").alias("total_sales"), F.avg("profit_rate").alias("avg_profit_rate"), F.count("*").alias("order_count") ] # 4. 执行动态聚合（PySpark 3.4+支持list of columns） result_df = raw_df.groupBy(*group_fields).agg(*agg_exprs)

参数推导与避坑：

• groupBy(*group_fields)中的*解包是安全的，但必须确保group_fields非空。我们加了强制校验：if not group_fields: raise ValueError("At least one dimension must be selected")。
• 时间维度粒度转换需谨慎。date字段是2023-01-01格式，但周报需要year_week（如2023_01）。不能简单用substring(date,1,7)，因为跨年周（如2023-12-31属于2024年第1周）会出错。正确方案是调用date_format(to_date(date), 'yyyy_WW')，但要注意WW返回的是ISO周，需确认业务是否接受。
• 最大坑点：维度顺序影响结果缓存命中率。StarRocks中，GROUP BY province, category和GROUP BY category, province被视为两个不同查询，无法共享物化视图。因此，我们约定所有配置中维度按业务重要性降序排列（如province > category > channel），前端选择时自动排序。

3.2 度量值条件重计算：让SUM()学会“看人下菜碟”

传统聚合函数的僵化在于：SUM(sales)对所有记录一视同仁。但业务常要求“只加总有效订单”、“对VIP客户销售额翻倍计权”、“剔除测试订单”。这就是条件重计算（Conditional Recalculation）。

场景实录：某直播平台要计算“各主播的GMV贡献度”，但规则复杂：

• 正常订单：100%计入
• 主播自购订单（buyer_id = anchor_id）：只计50%
• 刷单嫌疑订单（风控模型分>0.95）：0%计入

实操方案（ClickHouse SQL）：

SELECT anchor_id, -- 核心：用CASE WHEN构造加权系数 sum(sales * ( CASE WHEN buyer_id = anchor_id THEN 0.5 WHEN fraud_score > 0.95 THEN 0.0 ELSE 1.0 END )) AS weighted_gmv, -- 同时统计各类型订单数，用于归因分析 count(*) AS total_orders, countIf(buyer_id = anchor_id) AS self_buy_orders, countIf(fraud_score > 0.95) AS fraud_orders FROM live_orders WHERE event_date >= '2023-01-01' GROUP BY anchor_id

为什么不用子查询？
初学者常写：

-- ❌ 危险！两次扫描，性能差且可能不一致 SELECT anchor_id, sum(weighted_sales) FROM ( SELECT *, CASE WHEN ... END AS weight FROM live_orders ) t GROUP BY anchor_id

问题在于：子查询中fraud_score可能随风控模型更新而变化，外层sum()和内层countIf()可能读到不同版本数据，导致weighted_gmv与fraud_orders对不上。ClickHouse的countIf()是原子函数，保证在同一扫描中完成所有计算。

进阶技巧：动态权重注入
业务方要求权重可配置（如自购订单权重从0.5调为0.3）。硬编码CASE WHEN需发版。解决方案是建立权重配置表：

-- 权重配置表（实时更新） CREATE TABLE weight_config ( rule_type String, -- 'self_buy', 'fraud' threshold Float64, -- 0.95 weight Float64 -- 0.0 ) ENGINE = ReplacingMergeTree ORDER BY (rule_type, threshold); -- 聚合时JOIN配置（注意：ClickHouse不支持子查询JOIN，需用GLOBAL IN） SELECT anchor_id, sum(sales * coalesce( (SELECT weight FROM weight_config WHERE rule_type='self_buy' AND buyer_id=anchor_id LIMIT 1), (SELECT weight FROM weight_config WHERE rule_type='fraud' AND fraud_score>threshold LIMIT 1), 1.0 )) AS dynamic_weighted_gmv FROM live_orders GROUP BY anchor_id;

3.3 空值与异常值的聚合穿透策略

多维聚合中，NULL不是“不存在”，而是“业务状态未明”。粗暴IGNORE NULLS会丢失关键信号。我们定义穿透策略（Penetration Strategy）：让NULL在聚合过程中携带语义继续流动。

策略矩阵（按业务影响分级）：

关键实操细节：

• ClickHouse的throwIf不是报错，而是终止当前行处理。它配合materialized view可实现异常拦截：建一个物化视图，当检测到order_amount > 1e8时，将整行写入alert_log表，主聚合表自动过滤掉该行。
• Pandas中fillna()的陷阱：df.fillna(0)会把所有类型列（包括字符串）都填0，导致category列变成数字。必须指定列：df['discount_rate'].fillna(0, inplace=True)。
• 最危险的NULL：出现在GROUP BY字段。某次生产事故：city字段有NULL，GROUP BY city后，所有city=NULL的记录被聚合成一行，但报表前端没处理这个特殊分组，导致“未知城市”销量显示为0，实际占总量37%。根治方案是在ETL层强制city = ifNull(city, 'UNSPECIFIED')，并在数据字典中标记为“强制补全”。

3.4 跨层级比例下钻：从“绝对值”到“相对位置”的跃迁

多维聚合的价值不仅在于“是多少”，更在于“在哪儿”。比如知道“上海手机销量1.2亿”，远不如知道“上海手机销量占华东区手机销量的38.7%，较上月提升2.1个百分点”。这就是跨层级比例下钻（Cross-Hierarchy Ratio Drilling）。

技术难点：比例计算需同时访问两个聚合层级的结果。传统方案用子查询：

-- ❌ 性能灾难：两次全表扫描 SELECT city, sales, sales * 100.0 / ( SELECT sum(sales) FROM sales_table WHERE province='华东' ) AS ratio_to_province FROM sales_table WHERE province='华东';

高效方案：窗口函数 + 预聚合
Step 1：先按province+city聚合（细粒度）
Step 2：用窗口函数计算province级汇总（粗粒度）
Step 3：在同一行中完成比例计算

-- ClickHouse窗口函数（需版本22.8+） SELECT province, city, city_sales, -- 关键：PARTITION BY province 让sum()只在省内计算 round(city_sales * 100.0 / sum(city_sales) OVER (PARTITION BY province), 2) AS ratio_to_province, -- 同时计算同比（需先按月聚合） round( (city_sales - lag(city_sales, 1) OVER (PARTITION BY province, city ORDER BY month)) * 100.0 / nullIf(lag(city_sales, 1) OVER (PARTITION BY province, city ORDER BY month), 0), 2 ) AS mom_change_pct FROM ( -- 子查询：先聚合到province+city+month粒度 SELECT province, city, toMonth(event_date) as month, sum(sales) as city_sales FROM sales_raw GROUP BY province, city, toMonth(event_date) ) t ORDER BY province, city, month;

Pandas等效实现（处理1000万行以内）：

# 1. 先按province+city聚合 city_agg = df.groupby(['province','city'])['sales'].sum().reset_index(name='city_sales') # 2. 计算province级汇总（关键：用transform，保持原索引） province_total = city_agg.groupby('province')['city_sales'].transform('sum') city_agg['ratio_to_province'] = (city_agg['city_sales'] / province_total * 100).round(2) # 3. 添加同比（需先按月聚合） monthly_agg = df.groupby(['province','city','month'])['sales'].sum().reset_index() # 使用pivot_table创建宽表便于计算 pivot_df = monthly_agg.pivot_table( index=['province','city'], columns='month', values='sales', fill_value=0 ) # 计算环比：用diff(axis=1)获取相邻月差值 mom_diff = pivot_df.diff(axis=1) mom_ratio = (mom_diff / pivot_df.shift(1, axis=1) * 100).round(2)

避坑指南：

• lag()函数在ClickHouse中默认offset=1，但若数据有缺失月份（如某城市2月无数据），lag()会跳到1月，导致计算错误。必须用ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING显式指定行偏移。
• Pandas的transform('sum')比groupby().sum()慢3倍，因前者需广播结果。大数据量时，先groupby().sum()得到province_total_df，再merge()更优。

3.5 流式再加工：聚合结果的“第二生命”

多维聚合结果不应是终点，而是下游实时应用的起点。我们称其为聚合结果的流式再加工（Streaming Post-Processing）。

典型链路：

原始日志 → Flink实时ETL → StarRocks多维聚合表 → Kafka输出 → Flink实时作业 → 告警/推荐/模型训练

实操案例：风控实时评分
需求：当“某省份手机品类GMV 1小时内下降超30%”，立即触发风控工单。

Step 1：StarRocks物化视图输出聚合结果

-- 创建物化视图，每分钟刷新一次 CREATE MATERIALIZED VIEW mv_hourly_gmv AS SELECT toStartOfHour(event_time) AS hour_start, province, category, sum(sales) AS gmv, count(*) AS order_count FROM sales_log GROUP BY toStartOfHour(event_time), province, category;

Step 2：Kafka输出配置（StarRocks 3.1+）
在物化视图上建ROUTINE LOAD任务，将增量结果写入Kafka Topicgmv_hourly，消息格式为JSON：

{ "hour_start": "2023-01-01 10:00:00", "province": "上海", "category": "手机", "gmv": 12500000, "order_count": 8923 }

Step 3：Flink实时作业（Java）

// 1. 从Kafka读取 DataStream<GMVRecord> gmvStream = env.fromSource( KafkaSource.<GMVRecord>builder() .setTopics("gmv_hourly") .setValueDeserializer(new GMVJsonDeser()) .build(), WatermarkStrategy.<GMVRecord>forBoundedOutOfOrderness(Duration.ofMinutes(5)) .withTimestampAssigner((event, timestamp) -> event.hour_start.getTime()), "kafka-source" ); // 2. 按province+category开窗（1小时滚动窗口） DataStream<AlertEvent> alertStream = gmvStream .keyBy(r -> r.province + "|" + r.category) .window(TumblingEventTimeWindows.of(Time.hours(1))) .aggregate(new GMVAvgAgg(), new GMVProcessWindow()) .filter(alert -> alert.dropRate > 30.0); // 下降超30% // 3. 写入告警系统 alertStream.addSink(new AlertSink());

核心技巧：

• 窗口对齐：Kafka消息的hour_start是事件时间，Flink必须用WatermarkStrategy处理乱序。我们设置5分钟容忍，因日志采集延迟通常<3分钟。
• 状态管理：GMVAvgAgg中维护lastHourGMV和currentHourGMV两个状态，避免全量窗口重算。
• 幂等写入：AlertSink中用alert_id = province+category+hour_start作为唯一键，防止重复告警。

实测数据：该链路端到端延迟稳定在2.3秒（从日志产生到告警发出），支撑日均5000+次实时下钻分析。

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

4.1 “结果不一致”问题：同一SQL，今天对明天错

现象：某日志分析SQL，周一执行返回127万条，周二执行返回124万条，数据源未变更。

根因排查（按优先级）：

1. 时区陷阱：toStartOfHour(event_time)在ClickHouse中默认用服务器时区（UTC），但业务要求东八区。event_time是UTC时间戳，toStartOfHour(event_time)会错误地将北京时间10:00的事件归入UTC 2:00的小时桶。
   修复：显式指定时区toStartOfHour(event_time, 'Asia/Shanghai')。

2. NULL传播：province字段有NULL，GROUP BY province时，NULL被当作一个分组。但某些版本ClickHouse在FINAL查询时会优化掉NULL分组，导致结果波动。
   修复：强制补全ifNull(province, 'UNKNOWN') AS province。

3. 物化视图延迟：StarRocks物化视图刷新有1-3秒延迟，Flink作业若在刷新完成前读取，会拿到旧数据。
   修复：在Flink中监听物化视图的refresh_complete事件，或设置3秒延迟消费。

终极验证法：在SQL开头加SELECT now(), timezone();，确认时区；用SELECT count(*) FROM table WHERE province IS NULL查NULL占比；对物化视图执行SHOW ALTER TABLE mv_name;看刷新状态。

4.2 “性能雪崩”问题：加一个维度，查询慢10倍

现象：GROUP BY province, category耗时1.2秒，加上channel后升至15秒。

诊断流程：

1. 看执行计划：ClickHouse中EXPLAIN PIPELINE显示AggregatingTransform节点耗时突增，说明分组数爆炸。
2. 查分组基数：SELECT count(DISTINCT province, category, channel) FROM table返回23万，而province, category仅1200。
3. 查数据倾斜：SELECT channel, count(*) FROM table GROUP BY channel ORDER BY count(*) DESC LIMIT 5发现channel='APP'占87%，严重倾斜。

解决方案矩阵：

我们的选择：对channel这种业务核心维度，采用局部聚合+物化视图双保险。先用rand()%100打散APP流量，再建物化视图，使P99查询稳定在320ms。

4.3 “精度丢失”问题：小数点后全是0

现象：计算profit_rate = profit/sales，结果全为0.00。

根因：整数除法截断。profit和sales都是Int64，5/10结果为0，而非0.5。

修复方案：

• ClickHouse：强制转浮点profit * 1.0 / sales或toFloat64(profit) / sales。
• Pandas：df['profit'].astype(float) / df['sales']，但注意astype(float)会将Int64转为float64，内存翻倍。更优是pd.to_numeric(df['profit'], downcast='float')。
• 终极方案：在源头ETL层，将货币类字段定义为Decimal(18,2)，避免中间计算损失精度。

4.4 “内存溢出”问题：GROUP BY直接OOM

现象：10亿行表，GROUP BY user_id报Memory limit exceeded。

根治策略：

1. 分治聚合：先按user_id % 100分100个桶，每个桶内GROUP BY user_id，再合并结果。
2. 启用外部聚合：ClickHouse中SET max_bytes_before_external_group_by = 2000000000（2GB），超限时自动写磁盘。
3. 降维替代：若只需COUNT(DISTINCT user_id)，用uniqCombined(user_id)，内存占用仅为COUNT(DISTINCT)的1/5。

我们的真实配置：

-- 生产环境ClickHouse配置 SET max_bytes_before_external_group_by = 5000000000; -- 5GB SET max_memory_usage = 10000000000; -- 10GB SET group_by_two_level_threshold = 1000000; -- 超100万分组用两级聚合

4.5 “业务逻辑漂移”问题：报表数字天天变，没人说得清

现象：运营说“昨天TOP10主播名单变了3个”，技术查SQL没动，数据源也没变。

真相：维度值语义漂移。例如category字段，最初只有手机/电脑/平板，后来新增手机配件，但历史数据未重分类，导致“手机”类目混入配件销量。

防御体系：

• 维度版本化：在维度表中加version字段，category_v1含3个值，category_v2含4个值，聚合时强制指定category_v2。
• 变更熔断：当维度值新增超5%，自动暂停相关报表，通知数据Owner确认。
• 血缘追踪：用OpenLineage记录sales_table.category到report_top10.anchor_id的完整链路，点击报表即可追溯每个数字的来源。

最后分享一个小技巧：在所有聚合SQL末尾加一句注释-- BIZ_VERSION: 2023Q4，当业务方质疑结果时，直接搜索该注释，快速定位是否用了旧逻辑。这招帮我们减少了73%的跨部门扯皮会议。

我在实际项目中踩过的最大坑，是以为“聚合就是写SQL”，直到某次金融审计，发现所有同比计算都因时区错误系统性偏差2.3%。从此养成铁律：任何聚合操作上线前，必须用100条手工验证数据，覆盖NULL、边界值、时区、精度四类场景。多维聚合不是技术炫技，而是用工程确定性，对抗业务不确定性。