多维聚合后数据再加工：从GROUP BY到业务指标落地的三层流水线

1. 这不是简单的“GROUP BY”——多维聚合中的数据变形术到底在解决什么问题如果你正在处理销售报表、用户行为分析、IoT设备时序汇总或者哪怕只是整理一份带地区、季度、产品线、渠道四个维度的Excel透视表那你一定遇到过这种场景原始数据是百万行明细每行记录一次订单含省份、城市、产品类别、下单时间、金额、是否促销而你需要的不是“全国总销售额”而是“华东地区Q3高单价品类在直播渠道的环比增长率”。这时候SQL里一个GROUP BY region, quarter, category, channel远远不够——你得先定义“高单价”比如TOP 20%价格分位数再按时间窗口计算环比还要排除退货单干扰最后把结果按区域热力图时间折线双视图呈现。这已经超出了传统聚合的范畴进入了多维数据操纵Multi-Dimensional Data Manipulation的深水区。本篇讲的就是Part 20这个标题背后真正要落地的能力它不是教你怎么写SUM()或AVG()而是聚焦在聚合之后、展示之前那个被90%教程跳过的“中间层”——如何对已分组的数据块进行再加工、再结构化、再关联、再校准。比如把每个省份的月度销售额序列转成Z-score标准化向量用于聚类把同一客户在不同渠道的行为频次矩阵做SVD降维后提取主成分或者更实际的——把“各城市日均订单量”这个二维表城市×日期动态折叠成“城市-最近7天移动均值-同比变化率-预警状态”三列宽表直接喂给BI看板。这些操作Pandas叫transform/apply/agg的嵌套组合SQL叫窗口函数链式调用Spark叫mapGroupspandas_udf协同但底层逻辑一脉相承聚合不是终点而是数据形态跃迁的起点。适合三类人细读一是业务分析师常卡在“导出数据后还得在Excel里手动算环比”的二是数据工程师发现调度任务总因聚合后二次加工逻辑混乱而失败的三是算法同学抱怨特征工程脚本又慢又难复现的。下面我们就从设计哲学开始一层层拆解这个“Part 20”究竟该怎么实打实地落地。2. 多维聚合数据操纵的核心设计逻辑为什么不能只靠一层GROUP BY2.1 传统聚合的“三重失真”陷阱多数人写聚合的第一反应是“先GROUP BY所有维度再SELECT聚合函数”。但实际跑起来会发现三个隐蔽却致命的问题第一重失真维度坍缩导致上下文丢失假设你有销售数据表sales字段包括city,product_type,date,amount。你想看“每个城市的热销品类TOP3”直觉写法是SELECT city, product_type, SUM(amount) as total FROM sales GROUP BY city, product_type ORDER BY total DESC LIMIT 10;结果只返回10条记录根本看不出哪个城市占了几个名额。你真正需要的是“每个城市内部排序取前三”这要求聚合结果必须保留city作为分组锚点同时在每个city组内对product_type做局部排序——这已经不是GROUP BY能解决的必须引入窗口函数或分组内apply逻辑。第二重失真聚合粒度与业务指标不匹配比如计算“客户复购率”业务定义是“过去90天内下单≥2次的客户数 / 所有下单客户数”。如果直接GROUP BY customer_id统计次数再全局计数看似合理。但问题在于90天窗口是动态的今天看是6月1日-8月29日明天就变成6月2日-8月30日而GROUP BY是静态分组。更糟的是若某客户在窗口内下了5次单他只该被计为1个复购客户而不是5次——这意味着聚合前必须先去重、再按窗口切片、再分组计数整个流程是预处理→动态分窗→分组→再聚合的四步链路任何一步错位都会让指标失真。第三重失真跨维度关联信息无法原生获取还是销售数据现在要加一列“该城市平均客单价 vs 全国平均客单价的比值”。如果只做GROUP BY city你能拿到每个城市的平均值但全国平均值在同一个GROUP BY里是不可见的除非子查询嵌套。而子查询在大数据量下性能极差。正确解法是先算全国均值单行结果再广播到每个城市分组中做除法——这要求聚合引擎支持分组间广播变量或两阶段聚合先全局聚合再与分组结果join。提示这三个失真不是Bug而是关系型聚合模型的固有局限。它假设数据是“扁平表格”而现实业务数据天然具有层次性国家→省→市、时序性T-30天→T-7天→T日、关联性客户主表订单明细商品属性。Part 20要突破的正是这个模型边界。2.2 真正有效的设计范式三层流水线架构基于十年处理电商、金融、制造领域聚合任务的经验我总结出稳定可靠的多维数据操纵必须遵循三层流水线Three-Tier Pipeline第一层维度锚定层Dimension Anchoring目标明确“以什么为单位进行后续操作”。不是简单列维度名而是定义维度的业务语义层级和唯一性约束。例如city不能只是字符串要关联到region_hierarchy表确认其上级是province且city_code是唯一键date不能只是日期字段要标记为calendar_date类型并预置is_workday,quarter_start,promo_period_flag等衍生属性对product_type需提前建立category_tree映射确保“手机”属于“3C”“耳机”属于“配件”避免聚合时因命名不一致导致漏统。这一层的工作往往在ETL建模阶段完成但很多团队跳过它直接写SQL结果就是后续所有聚合都带着“脏维度”隐患。第二层动态分窗层Dynamic Windowing目标解决时间/序列敏感指标的计算。关键不是用BETWEEN硬编码日期而是构建可配置的时间表达式引擎。例如定义window: last_7_days→ 实际解析为date current_date - interval 7 days AND date current_date定义window: rolling_30_days→ 解析为date BETWEEN (current_date - interval 29 days) AND current_date更进一步支持window: fiscal_quarter_to_date自动识别当前财季起始日如4月1日、7月1日等我在某零售客户项目中把这类窗口定义存成JSON Schema调度系统每次执行前动态注入真实日期既保证复用性又杜绝了人工改SQL日期的错误。第三层分组内操纵层In-Group Transformation这才是Part 20的主战场。它包含四类原子操作标量增强Scalar Enrichment给每个分组添加计算字段如group_total / global_total as share_pct序列变形Sequence Reshaping把分组内多行转为单行多列如[day1_sales, day2_sales, ..., day7_sales]→ARRAY[...]拓扑关联Topology Join将分组结果与外部维度表关联如城市分组结果join人口普查表加population_density字段规则校准Rule-Based Calibration应用业务规则修正数据如“促销订单金额*0.8计入GMV”、“退货单金额取绝对值后加负号”这三层不是线性顺序而是网状依赖第二层的窗口定义可能依赖第一层的维度属性如fiscal_quarter_to_date需知道公司财年设置第三层的校准规则又可能引用第二层的窗口结果。所以真正的设计文档应该是一张维度-窗口-操作的依赖矩阵表而非流程图。2.3 工具选型不是技术问题而是协作成本问题很多人纠结“用Pandas还是SparkSQL还是Python”——其实选型核心标准只有一个谁来维护以及维护频率。如果是BI团队每天跑的日报SQL窗口函数PostgreSQL/Redshift BI工具内置计算字段最稳妥。因为SQL易审计、权限好控、DBA熟悉且窗口函数性能经过十年优化ROW_NUMBER() OVER(PARTITION BY city ORDER BY amount DESC)比Pandas的groupby().apply(lambda x: x.sort_values().head(3))快5倍以上实测千万级数据。如果是算法团队做特征工程Pandas pd.groupby().agg()的字典式聚合如{sales: sum, orders: count, avg_price: lambda x: x.sum()/x.count()}更灵活。但必须配合lru_cache装饰器缓存中间结果否则每次apply都重新计算基础聚合效率归零。如果是实时大屏Flink SQL的OVER WINDOWMATCH_RECOGNIZE是唯一选择。比如检测“某城市连续3天销量突增50%”用Flink的模式匹配比用KafkaPython消费后判断可靠十倍——因为前者在流引擎内完成状态管理后者要自己维护滑动窗口状态故障恢复极难。注意所谓“统一技术栈”是伪命题。我在三个不同客户现场见过同一套指标体系离线用Spark SQL近实时用Flink即席分析用Trino。关键不是工具统一而是指标定义统一——所有工具最终输出的字段名、口径注释、空值处理逻辑必须完全一致。这才是Part 20真正要解决的“一致性”问题。3. 核心操作详解从代码到业务含义的逐层穿透3.1 标量增强让每个分组“看见全局”这是最常用也最容易写错的操作。典型需求“显示每个省份的GDP占比以及该省GDP与全国均值的倍数”。错误写法子查询嵌套性能灾难SELECT province, SUM(gdp) as province_gdp, SUM(gdp) / (SELECT SUM(gdp) FROM provinces) as share_pct, SUM(gdp) / (SELECT AVG(gdp) FROM provinces) as vs_avg_multiple FROM provinces GROUP BY province;问题子查询执行两次且无法利用索引10万行数据耗时2.3秒。正确写法窗口函数单次扫描SELECT province, province_gdp, province_gdp / SUM(province_gdp) OVER() as share_pct, province_gdp / AVG(province_gdp) OVER() as vs_avg_multiple FROM ( SELECT province, SUM(gdp) as province_gdp FROM provinces GROUP BY province ) t;原理OVER()不带PARTITION BY时表示对整个结果集计算聚合相当于“广播全局值”。这里SUM(province_gdp) OVER()就是所有省份GDP之和AVG(province_gdp) OVER()是各省GDP的平均值。整个查询只需一次分组扫描耗时0.17秒提升13倍。进阶技巧多级广播当需要“省级均值 vs 全国均值 vs 大区均值”三级对比时不能写三个OVER()而要用两层嵌套-- 第一层先算出大区均值 WITH regional_avg AS ( SELECT region, AVG(province_gdp) as regional_mean FROM ( SELECT p.province, r.region, SUM(p.gdp) as province_gdp FROM provinces p JOIN regions r ON p.province r.province GROUP BY p.province, r.region ) t GROUP BY region ) -- 第二层关联并计算 SELECT t.province, t.province_gdp, t.province_gdp / AVG(t.province_gdp) OVER() as vs_national_avg, t.province_gdp / ra.regional_mean as vs_regional_avg FROM ( SELECT p.province, r.region, SUM(p.gdp) as province_gdp FROM provinces p JOIN regions r ON p.province r.province GROUP BY p.province, r.region ) t JOIN regional_avg ra ON t.region ra.region;这个写法的关键在于把“需要广播的值”提前物化为临时表再通过JOIN注入避免窗口函数在复杂关联下的语义歧义。3.2 序列变形把“行”变成“特征向量”这是算法同学最头疼的部分。比如用户行为分析中要把每个用户的点击流多行转成固定长度的向量用于模型训练。原始数据结构user_idevent_timeevent_typepage_idU0012023-06-01 10:00:00clickP101U0012023-06-01 10:02:15viewP102U0012023-06-01 10:05:30clickP101目标结构每个用户一行包含最近5次事件的类型和页面IDuser_idlast_5_events_typeslast_5_events_pagesU001[click,view,click][P101,P102,P101]Pandas实现注意内存陷阱import pandas as pd from typing import List, Tuple def build_user_sequence(df: pd.DataFrame, time_col: str event_time, type_col: str event_type, id_col: str user_id, max_len: int 5) - pd.DataFrame: # 关键先按用户和时间排序再分组避免apply时顺序错乱 df_sorted df.sort_values([id_col, time_col]) def get_last_n(x: pd.DataFrame) - pd.Series: # 取最后max_len行但用iloc[-max_len:]比tail()更稳定tail可能返回少于max_len行 recent x.iloc[-max_len:] return pd.Series({ last_5_events_types: recent[type_col].tolist(), last_5_events_pages: recent[page_id].tolist() }) # 使用groupby().apply()但必须指定result_typeexpand才能展开为多列 result df_sorted.groupby(id_col, group_keysFalse).apply( get_last_n, result_typeexpand ).reset_index() return result # 调用 seq_df build_user_sequence(raw_df)Spark实现避免Driver OOMfrom pyspark.sql import Window from pyspark.sql.functions import * # 定义窗口按用户分组按时间降序排列 window_spec Window.partitionBy(user_id).orderBy(col(event_time).desc()) # 添加行号只取前5行 df_with_rank raw_df.withColumn( rn, row_number().over(window_spec) ).filter(col(rn) 5) # 聚合为数组 seq_df df_with_rank.groupBy(user_id).agg( collect_list(event_type).alias(last_5_events_types), collect_list(page_id).alias(last_5_events_pages) )实操心得Pandas方案在百万用户时会爆内存因为apply把每个分组加载到Driver内存Spark方案虽快但collect_list默认无序必须配合row_number确保时序正确。我在某社交APP项目中把collect_list(struct(event_type,page_id))改为collect_list(struct(rn,event_type,page_id))再sort_array才彻底解决顺序错乱问题。3.3 拓扑关联让分组结果“长出业务血肉”单纯聚合结果是干瘪的。比如“各城市月度销售额”表如果不关联人口、GDP、竞品门店数就只是数字游戏。典型错误在聚合后LEFT JOIN维度表SELECT s.city, s.month, s.sales, d.population, d.gdp_per_capita FROM ( SELECT city, month, SUM(amount) as sales FROM sales GROUP BY city, month ) s LEFT JOIN dim_city d ON s.city d.city;问题如果dim_city有1000个城市但当月只有200个有销售LEFT JOIN会把另外800个城市的sales设为NULL而你真正想要的是“所有城市无论有无销售都显示”即FULL OUTER JOIN。但多数数仓不支持FULL JOIN且性能差。正确解法预关联再聚合Pre-Join Aggregation-- 步骤1先关联再聚合即使没销售城市维度也存在 SELECT d.city, COALESCE(s.month, 2023-06) as month, -- 填充默认月份 COALESCE(SUM(s.amount), 0) as sales, d.population, d.gdp_per_capita FROM dim_city d LEFT JOIN sales s ON d.city s.city AND s.month 2023-06 GROUP BY d.city, d.population, d.gdp_per_capita;原理把维度表dim_city作为主表用LEFT JOIN拉取事实表数据确保维度完整性。COALESCE处理NULLGROUP BY包含所有维度字段避免隐式去重。高阶技巧动态维度注入当维度表本身也在更新如新开了5家竞品门店需要“聚合时自动感知最新维度”。这时要用版本化维度表-- dim_city_v2 表结构city, population, gdp_per_capita, version, valid_from, valid_to -- 聚合时关联有效版本 SELECT d.city, s.month, SUM(s.amount) as sales, d.population, d.gdp_per_capita FROM sales s JOIN dim_city_v2 d ON s.city d.city AND s.month BETWEEN d.valid_from AND d.valid_to GROUP BY d.city, d.population, d.gdp_per_capita, s.month;这个设计让业务方修改维度数据后聚合结果自动生效无需重跑历史任务。3.4 规则校准用业务语言写数据逻辑这是最体现业务理解深度的部分。比如电商的“GMV”定义正常订单amount促销订单amount * 0.8平台补贴20%退货订单-abs(amount)负向计入虚拟订单测试单0过滤掉SQL实现CASE WHEN链但要注意顺序SELECT city, SUM( CASE WHEN order_type promotion THEN amount * 0.8 WHEN order_type return THEN -ABS(amount) WHEN order_type test THEN 0 ELSE amount END ) as adjusted_gmv FROM orders WHERE status ! cancelled -- 先过滤无效状态 GROUP BY city;关键细节CASE WHEN的顺序很重要。如果把WHEN order_type test放在最后而测试单的status也是cancelled就会被前面的status ! cancelled过滤掉根本进不了CASE逻辑。所以规则校准必须和前置过滤协同设计。Pandas实现向量化比循环快100倍import numpy as np # 预先定义规则映射 rule_map { promotion: lambda x: x * 0.8, return: lambda x: -np.abs(x), test: lambda x: 0.0, normal: lambda x: x } # 向量化应用先用map映射函数再用apply调用 orders_df[adjusted_amount] ( orders_df[order_type].map(rule_map) .apply(lambda f: f(orders_df[amount])) # 错误这样会把整个amount Series传给每个f ) # 正确写法用np.where链式判断推荐 orders_df[adjusted_amount] np.where( orders_df[order_type] promotion, orders_df[amount] * 0.8, np.where( orders_df[order_type] return, -np.abs(orders_df[amount]), np.where( orders_df[order_type] test, 0.0, orders_df[amount] ) ) )注意Pandas的mapapply在这里是反模式因为apply会逐行调用失去向量化优势。np.where是纯向量化千万行数据处理时间从42秒降到0.3秒。4. 实战全流程从需求到上线的7个关键环节4.1 需求翻译把业务语言转成数据契约客户说“我要看各城市爆款商品的转化率”。这句话有4个隐藏坑“各城市”是指地级市还是包含直辖市港澳台是否单列“爆款商品”是按销量TOP10还是按销售额TOP10还是平台定义的“爆款标签”“转化率”是“加购人数/曝光人数”还是“下单人数/加购人数”分母要不要去重“看”是日报表还是实时大屏延迟容忍多少我的做法是强制填写《指标定义卡》Metric Definition Card必须包含字段示例值说明业务定义“用户看到商品详情页后30分钟内下单的比例”用完整句子描述禁用缩写分子COUNT(DISTINCT CASE WHEN event_typeorder THEN user_id END)明确去重逻辑、过滤条件分母COUNT(DISTINCT CASE WHEN event_typeview THEN user_id END)同上且注明是否与分子同时间窗口时间窗口event_time BETWEEN 2023-06-01 AND 2023-06-30写死还是动态动态则定义表达式维度粒度city地级市不含直辖市港澳台单列附维度表版本号数据源ods_user_behavior_v3分区字段dt注明表生命周期、SLA异常处理分母为0时转化率返回NULL不填0避免误导这张卡是开发、测试、BI、业务方四方签字确认的依据。没有它后面所有工作都是空中楼阁。4.2 数据探查在写代码前先“摸清家底”很多人跳过这步直接写聚合SQL结果跑出来发现city字段有“北京市”、“北京”、“BJ”三种写法event_type里混着“click”、“CLICK”、“Click”amount有负数但没标注是退货还是优惠券抵扣。标准化探查清单每次必做-- 1. 维度值分布看是否有脏数据 SELECT city, COUNT(*) as cnt FROM sales GROUP BY city ORDER BY cnt DESC LIMIT 20; -- 2. 字段空值率影响聚合精度 SELECT ROUND(COUNT(*) FILTER (WHERE city IS NULL)::DECIMAL / COUNT(*), 4) as city_null_rate, ROUND(COUNT(*) FILTER (WHERE amount IS NULL)::DECIMAL / COUNT(*), 4) as amount_null_rate FROM sales; -- 3. 数值异常用IQR法找离群值 WITH stats AS ( SELECT PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount) as q1, PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount) as q3 FROM sales WHERE amount 0 ) SELECT MIN(amount), MAX(amount), COUNT(*) FILTER (WHERE amount (SELECT q3 1.5*(q3-q1) FROM stats)) as outlier_cnt FROM sales;探查不是为了“清理数据”而是为了在聚合逻辑中显式处理异常。比如发现city有3种写法就在SQL里加TRIM(UPPER(city))标准化发现amount有大量负数就单独建is_return字段而不是简单WHERE amount 0过滤掉。4.3 聚合脚本开发从单机验证到集群部署本地验证Pandas# 用真实抽样数据1万行验证逻辑 sample_df pd.read_parquet(sales_sample_10k.parquet) # 复制业务方给的Excel公式用Pandas逐行实现 expected_result pd.read_excel(business_formula.xlsx) # 自动比对生成相同维度的聚合结果 actual_result sample_df.groupby([city,month]).agg({ amount: sum, order_id: count }).round(2).reset_index() # 用assert_series_equal比对失败时打印差异行 pd.testing.assert_frame_equal( actual_result.sort_values([city,month]).reset_index(dropTrue), expected_result.sort_values([city,month]).reset_index(dropTrue), check_dtypeFalse )这个步骤能捕获90%的逻辑错误。比如业务方Excel里用了SUMIFS跨表关联而你SQL里忘了JOIN本地验证会立刻报错。集群部署Airflow DAG# airflow_dag.py from airflow import DAG from airflow.providers.amazon.aws.operators.emr import EmrAddStepsOperator from datetime import datetime, timedelta default_args { owner: data-engineer, depends_on_past: False, start_date: datetime(2023, 6, 1), retries: 2, retry_delay: timedelta(minutes5), } dag DAG( multi_dim_aggregation_v20, default_argsdefault_args, schedule_interval0 2 * * *, # 每天2点跑 catchupFalse ) # 步骤1运行Spark聚合核心逻辑 spark_step EmrAddStepsOperator( task_idrun_spark_aggregation, job_flow_id{{ var.value.emr_cluster_id }}, steps[{ Name: MultiDimAgg-Part20, ActionOnFailure: CONTINUE, HadoopJarStep: { Jar: command-runner.jar, Args: [ spark-submit, --deploy-mode, cluster, --conf, spark.sql.adaptive.enabledtrue, s3://my-bucket/jobs/part20_agg.py, --date, {{ ds }}, # Airflow宏注入日期 --output, s3://my-bucket/output/part20/{{ ds }} ] } }], dagdag )关键点--date {{ ds }}把Airflow调度日期注入脚本避免硬编码spark.sql.adaptive.enabledtrue开启自适应查询优化对多维聚合性能提升显著实测TPC-DS Q18提速2.1倍。4.4 结果验证不只是“数字对得上”验证分三层第一层技术验证Technical Validation行数检查聚合后行数是否符合预期如按city,month分组应有300*123600行实际3598行说明有2个组合缺失空值检查关键字段如adjusted_gmv空值率是否为0非0则查LEFT JOIN是否漏关联边界检查最大值/最小值是否在合理范围如某城市GMV是全国均值的1000倍大概率是数据错位第二层业务验证Business Validation抽样比对随机选3个城市导出明细数据用Excel手工计算验证趋势验证看环比变化是否符合业务常识如618大促后7月GMV应下降若上升则逻辑有误归因验证挑一个异常值如上海7月GMV突降50%下钻到product_type维度确认是“手机品类缺货”还是“数据采集故障”第三层自动化验证Automated Validation在DAG末尾加一个PythonOperator执行断言def validate_results(**context): # 从S3读取当日结果 result_df read_from_s3(fs3://bucket/output/part20/{context[ds]}) # 断言1无空值 assert result_df[adjusted_gmv].isnull().sum() 0, GMV has null values # 断言2总量守恒所有城市GMV之和 全国GMV national_gmv get_national_gmv(context[ds]) # 从另一张表查 city_sum result_df[adjusted_gmv].sum() assert abs(city_sum - national_gmv) 100, fCity sum {city_sum} ! national {national_gmv} # 断言3TOP3城市占比60%防数据倾斜 top3_share result_df.nlargest(3, adjusted_gmv)[adjusted_gmv].sum() / city_sum assert top3_share 0.6, fTop3 cities share {top3_share:.2%} 60% validate_task PythonOperator( task_idvalidate_results, python_callablevalidate_results, dagdag )这个验证会在每次调度失败时给出明确错误信息而不是让业务方反馈“数据不对”。4.5 上线发布灰度发布与回滚机制绝不允许“全量上线”。我的标准流程灰度1%流量在Flink作业中用WHERE rand() 0.01只处理1%的订单验证逻辑正确性双跑验证新逻辑和旧逻辑并行运行3天比对结果差异率要求0.001%功能开关在配置中心如Apollo加开关part20_enabledtrue上线后先设为false验证无误再打开回滚预案准备回滚SQLDROP TABLE IF EXISTS part20_new; RENAME TABLE part20_old TO part20_new;5分钟内可恢复。某次上线因timezone配置错误导致海外订单计入错误日期就是靠这个回滚机制在2分钟内止损。4.6 监控告警不只是“任务成功”而是“结果可信”监控指标必须包含监控项告警阈值告警方式原因定位任务延迟30分钟企业微信查YARN队列资源争抢行数突变±30%邮件电话查上游数据源是否中断空值率突增0.1%企业微信查维度表JOIN是否失效TOP1城市占比70%邮件查数据采集是否只上报了该城市特别重要的是业务指标漂移监控用KS检验Kolmogorov-Smirnov比对本周和上周的adjusted_gmv分布若p-value 0.01说明分布发生显著变化触发人工核查。4.7 文档沉淀让知识不随人员流失文档不是Word而是可执行的Notebookpart20_design.ipynb包含需求翻译、维度定义、SQL原型、验证用例part20_deployment.mdDAG截图、资源配置EMR core节点数、SLA承诺99.9%成功率part20_troubleshooting.md常见问题如“为什么上海数据为空”答dim_city表未同步上海新行政区划需联系GIS团队更新。文档每周由新同学更新一次确保永远是最新的“活文档”。5. 常见问题与独家避坑指南5.1 “GROUP BY后COUNT(*)结果比预期少”——90%是NULL惹的祸现象按city, product_type分组预期有5000行实际只有4800行。根因city或product_type字段有NULL值而GROUP BY会把所有NULL归为一组导致其他非NULL组合被压缩。排查命令-- 查NULL分布 SELECT COUNT(*) FILTER (WHERE city IS NULL) as city_null_cnt, COUNT(*) FILTER (WHERE product_type IS NULL) as pt_null_cnt, COUNT(*) FILTER (WHERE city IS NULL AND product_type IS NULL) as both_null_cnt FROM sales;解决方案短期在WHERE中过滤WHERE city IS NOT NULL AND product_type IS NOT NULL长期在ETL