1. 从聚合到多维分析为什么需要Grouping Sets在日常的数据分析工作中我们经常遇到这样的场景老板不仅要看每个城市、每个车型的销量总和还想同时看到每个城市的总销量不考虑车型以及每个车型的总销量不考虑城市最后还要一个全局总计。如果用最基础的GROUP BY语句我们可能需要写四个独立的查询然后用UNION ALL拼起来。这不仅仅让SQL语句变得冗长、难以维护更重要的是它意味着数据库引擎需要重复扫描同一份数据四次计算四次聚合性能开销巨大。GROUPING SETS就是为了解决这个痛点而生的。它允许你在一个GROUP BY子句中定义多个分组集数据库会在一次数据扫描和计算中同时得出所有分组组合的聚合结果。这就像从一维的“分组透视”升级到了多维的“数据立方体”切割极大地提升了复杂聚合查询的表达能力和执行效率。理解它的底层实现尤其是Spark SQL中关键的Expand算子能帮助我们在编写复杂报表、优化查询性能时真正做到心中有数知其然更知其所以然。2. 核心思路拆解先“展开”再“聚合”的智慧要理解GROUPING SETS首先要抛弃UNION ALL那种“先分别聚合再合并结果”的线性思维。GROUPING SETS采用的是“先扩展后统一聚合”的批处理思想。这个过程可以拆解为两个核心阶段第一阶段数据扩展 (Expand)这是整个流程中最关键的一步。对于原始数据表中的每一条记录系统会根据GROUPING SETS子句中定义的所有分组组合将其“复制”成多条记录。例如对于一条记录(city‘北京’ car_model‘Model 3’ quantity5)如果分组集是((city, car_model), (city), (car_model), ())那么这一条记录会被扩展成四条(‘北京’ ‘Model 3’ 5)– 对应(city, car_model)分组。(‘北京’ null 5)– 对应(city)分组car_model位置用null填充。(null ‘Model 3’ 5)– 对应(car_model)分组city位置用null填充。(null null 5)– 对应()全局分组。你可能会问这样扩展后所有数据都混在一起了后续聚合怎么区分哪些数据属于哪个分组集呢这就引出了一个至关重要的标记列——分组ID在Spark SQL中名为spark_grouping_id。在扩展时每一条生成的记录都会被打上一个数字标签用来标识它源自哪个分组集。比如可以用0、1、2、3来分别标记上述四个分组集。第二阶段统一聚合 (Aggregate)经过Expand阶段后我们得到了一份“膨胀”了的中间数据。接下来的聚合操作就变得非常直观和统一了将“分组ID”连同原始的分组字段一起作为新的分组键。例如要计算(city)这个分组集的聚合实际上就是在聚合时使用GROUP BY city spark_grouping_id HAVING spark_grouping_id 1假设ID1对应(city)分组。由于spark_grouping_id的隔离即使不同分组集的数据混杂在同一张中间表里它们也能在聚合时被清晰地区分开来互不干扰。这种设计的精妙之处在于它把多样性的分组需求转化为了一个统一的、可批量处理的计算模型。数据库只需要扫描一次原始数据进行一次复杂的扩展操作然后执行一次聚合计算就能得到所有结果。相比于UNION ALL的多次扫描、多次计算其性能优势是显而易见的。2.1 与Union All的对比思路决定性能为了更直观地对比两种方式的差异我们可以从执行计划的角度来看。Union All方式其逻辑计划像一棵由多个分支组成的树。每个分支都是一个独立的Aggregate算子节点下面挂着一个扫描数据的Scan节点。执行时每个分支独立工作最后通过Union节点合并结果。数据被重复读取和计算。Grouping Sets方式其逻辑计划是一个更深的、单一路径的管道。最下面是Scan上面是Expand再上面是统一的Aggregate。数据像流水线一样被处理一次。这种架构上的根本差异就是性能差异的来源。Expand Aggregate的单流水线模式减少了数据I/O和中间结果的物化开销更适应现代大规模数据并行处理框架如Spark的计算模型。3. 深入源码ExpandExec算子如何工作理论说得再多不如直接看代码来得透彻。在Spark SQL中Expand算子的具体实现类是ExpandExec。它的核心使命就是高效地完成我们前面所说的“数据扩展”操作。让我们深入到doExecute()方法中看看它是如何运转的。ExpandExec的核心输入是一个projections序列。这个序列的每个元素本身也是一个表达式序列都对应一个分组集。例如对于GROUPING SETS ((city, car_model), (city), ())projections可能包含三个表达式列表第一个列表[city, car_model, 0]// 0是分组ID第二个列表[city, null, 1]// 1是分组IDcar_model位置用字面量null填充第三个列表[null, null, 3]// 3是分组ID所有分组字段用null填充在初始化阶段关键点1和2ExpandExec会为projections中的每一个表达式列表预先创建一个UnsafeProjection对象。你可以把UnsafeProjection理解为一个高性能的“行转换器”。它被绑定到输入数据的Schemachild.output当调用其apply方法并传入一行原始数据时它会根据表达式列表快速计算出一行新的数据。比如对于表达式[city, null, 1]转换器会对输入行取出city列的值在第二列生成一个null在第三列生成常量1。真正的扩展逻辑发生在mapPartitions中关键点3和4。对于上游输入的每一条数据记录input算子会遍历所有预先创建好的UnsafeProjection转换器即groups数组。每应用一个转换器就生成一条新的输出记录。用一个简单的循环伪代码表示就是for (inputRow in inputData) { for (i in 0 until projections.length) { val outputRow groups(i).apply(inputRow) // 关键点4使用不同的投影规则 emit(outputRow) } }这个过程完美诠释了“扩展”的含义一条输入通过N套不同的投影规则变出N条输出。spark_grouping_id就在其中一套投影规则里被作为常量生成从而忠实地记录了每一行扩展数据的“出身”。注意这里使用的UnsafeProjection是Spark内部用于直接操作堆外内存Unsafe Memory的高性能投影接口它避免了Java对象开销和GC压力对于Expand这种需要大量生成新行的操作性能提升至关重要。这也是Spark SQL高效的原因之一。4. 性能实测Grouping Sets优势有多大理论分析和源码解读都指向Grouping SETS更优但实际差距是多少呢我们用一个简单的测试来验证。假设有一张汽车销量表dealer包含citycar_modelquantity字段。我们分别用GROUPING SETS和等价的UNION ALL来编写查询计算城市-车型组合、城市汇总、车型汇总和全局总计。在同一个Spark环境本地模式小数据集下各执行10次取平均耗时。测试结果对比表查询方式平均耗时 (秒)相对耗时比查询语句复杂度GROUPING SETS0.2761x(基准)简洁1个SELECT1个GROUP BYUNION ALL0.616约2.2x冗长4个SELECT 3个UNION ALL从结果可以清晰看到GROUPING SETS版本的性能几乎是UNION ALL版本的两倍以上。这背后的原因主要在于减少数据扫描GROUPING SETS只需扫描一次基表而UNION ALL需要扫描四次。减少中间结果落盘UNION ALL的每个子查询都可能产生中间聚合结果需要缓存或落盘以供最终合并。GROUPING SETS的单一聚合路径优化了此过程。优化器优势现代查询优化器如Spark的Catalyst能对GROUPING SETS整体进行更好的优化比如选择更优的聚合策略而对多个独立的UNION ALL子查询的优化空间相对有限。实操心得这个性能差异在小数据量下可能只是几百毫秒但在生产环境动辄TB、PB级的数据量下这种开销会被急剧放大。一次查询节省数倍时间在并发高的数据平台或ETL任务中对集群资源的节约和任务完成时间的缩短是巨大的。因此只要遇到需要多维度组合聚合的场景应优先考虑使用GROUPING SETS。5. RollUp和CubeGrouping Sets的语法糖理解了GROUPING SETS之后再来看ROLLUP和CUBE就非常轻松了。它们本质上都是GROUPING SETS的便捷写法目的是让SQL语句更简洁底层执行引擎仍然将它们翻译成基于Expand算子的执行计划。5.1 RollUp层级上卷聚合ROLLUP用于生成层级式的聚合通常用于生成小计和总计。它的分组集遵循一种“上卷”的规律。-- 使用 ROLLUP SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY ROLLUP(city car_model) ORDER BY city car_model; -- 等价于使用 GROUPING SETS SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY GROUPING SETS ( (city car_model) -- 最细粒度 (city) -- 上卷一层对city做小计 () -- 上卷到底全局总计 ) ORDER BY city car_model;ROLLUP(a b c)等价于GROUPING SETS((abc) (ab) (a) ())。它假设维度之间有层级关系如年-月-日逐级上卷聚合。5.2 Cube多维立方体全组合聚合CUBE则更加彻底它会生成指定维度所有可能组合的分组集。适用于需要全方位、多角度交叉分析的数据立方体场景。-- 使用 CUBE SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY CUBE(city car_model) ORDER BY city car_model; -- 等价于使用 GROUPING SETS SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY GROUPING SETS ( (city car_model) -- 二维组合 (city) -- 仅city维度 (car_model) -- 仅car_model维度 () -- 零维总计 ) ORDER BY city car_model;CUBE(a b c)等价于GROUPING SETS包含所有abc的子集组合共2^n个n为维度数。它不假设维度间有层级关系是一种“全维度”分析。通过EXPLAIN EXTENDED命令查看Spark SQL的执行计划可以确认ROLLUP和CUBE在优化后的逻辑计划中都被转换成了带有对应projections列表的Expand节点。这证实了它们在执行层面与直接书写GROUPING SETS并无二致性能特性完全一致。注意事项虽然ROLLUP和CUBE是语法糖但选择使用哪一个取决于业务语义。ROLLUP用于有明确层级关系的维度如地理、时间CUBE用于需要平等探索所有维度组合的分析。误用会导致结果集包含不必要或无业务意义的分组浪费计算资源。6. 常见问题与排查技巧实录在实际使用GROUPING SETS、ROLLUP或CUBE时你可能会遇到一些典型问题。这里记录了几个我踩过的坑和解决思路。6.1 如何区分结果中的NULL是原始空值还是聚合填充的NULL这是一个经典问题。当city列本身就有NULL值时聚合结果中city为NULL的行到底代表“城市为空”的记录汇总还是代表“不考虑城市维度”的汇总呢答案是GROUPING函数或Spark SQL中的grouping_id。SELECT city car_model SUM(quantity) AS sum GROUPING(city) AS city_grouping_flag -- 如果city是聚合填充的NULL则返回1否则返回0 GROUPING(car_model) AS model_grouping_flag GROUPING_ID(city car_model) AS grouping_id -- 返回一个二进制位图表示的整数 FROM dealer GROUP BY GROUPING SETS ((city car_model) (city) (car_model) ()) ORDER BY grouping_id city car_model;通过GROUPING函数可以明确判断出NULL值的来源从而在应用程序中正确解读数据。6.2 结果行数异常增多远超预期如果发现结果集行数比预想的多很多首先检查GROUPING SETS中的分组集列表是否有重复。例如GROUPING SETS ((city) (city) ())会导致(city)分组被计算两次。其次检查连接条件。如果在包含GROUPING SETS的查询中使用了JOIN需要特别注意连接键是否可能因为NULL的填充而产生意外的笛卡尔积。通常建议先进行聚合再与其他表连接。6.3 性能反而比Union All更差在极少数情况下GROUPING SETS可能没有表现出性能优势。这可能是因为数据倾斜严重Expand操作会使数据膨胀N倍如果原始数据中某个键的数据量极大膨胀后该键对应的数据量会更大导致后续Aggregate阶段出现严重的数据倾斜。可以通过观察Spark UI中任务的执行时间是否差异巨大来判断。分组集数量极多GROUPING SETS列表非常长例如几十个导致Expand倍数过高中间数据量爆炸。这时需要重新评估业务需求是否合理或者考虑分多次查询。优化器未能选择最佳计划可以尝试收集表的统计信息如ANALYZE TABLE帮助优化器做出更准确的代价估算。在Spark中可以检查spark.sql.adaptive.enabled等自适应执行配置是否打开以应对数据倾斜。6.4 在Spark SQL中如何查看具体的Expand投影内容调试时想确切知道Expand算子生成了哪些投影表达式可以使用explain(mode‘extended’)。在输出的优化后逻辑计划中找到Expand节点它会显示类似Expand [[quantity#2159 city#2157 car_model#2158 0] [quantity#2159 city#2157 null 1] ...]的信息。每一组方括号内的列表就是一个分组集的投影表达式最后的数字就是spark_grouping_id。这有助于验证你的GROUPING SETS、ROLLUP或CUBE是否被正确翻译。掌握GROUPING SETS及其相关语法不仅仅是学会了一种SQL写法更是理解了一种高效的多维聚合计算范式。下次当你面对复杂的多层聚合报表需求时不妨优先考虑它让代码更简洁让查询跑得更快。
深入解析GROUPING SETS：多维聚合原理、性能优化与Spark实现
1. 从聚合到多维分析为什么需要Grouping Sets在日常的数据分析工作中我们经常遇到这样的场景老板不仅要看每个城市、每个车型的销量总和还想同时看到每个城市的总销量不考虑车型以及每个车型的总销量不考虑城市最后还要一个全局总计。如果用最基础的GROUP BY语句我们可能需要写四个独立的查询然后用UNION ALL拼起来。这不仅仅让SQL语句变得冗长、难以维护更重要的是它意味着数据库引擎需要重复扫描同一份数据四次计算四次聚合性能开销巨大。GROUPING SETS就是为了解决这个痛点而生的。它允许你在一个GROUP BY子句中定义多个分组集数据库会在一次数据扫描和计算中同时得出所有分组组合的聚合结果。这就像从一维的“分组透视”升级到了多维的“数据立方体”切割极大地提升了复杂聚合查询的表达能力和执行效率。理解它的底层实现尤其是Spark SQL中关键的Expand算子能帮助我们在编写复杂报表、优化查询性能时真正做到心中有数知其然更知其所以然。2. 核心思路拆解先“展开”再“聚合”的智慧要理解GROUPING SETS首先要抛弃UNION ALL那种“先分别聚合再合并结果”的线性思维。GROUPING SETS采用的是“先扩展后统一聚合”的批处理思想。这个过程可以拆解为两个核心阶段第一阶段数据扩展 (Expand)这是整个流程中最关键的一步。对于原始数据表中的每一条记录系统会根据GROUPING SETS子句中定义的所有分组组合将其“复制”成多条记录。例如对于一条记录(city‘北京’ car_model‘Model 3’ quantity5)如果分组集是((city, car_model), (city), (car_model), ())那么这一条记录会被扩展成四条(‘北京’ ‘Model 3’ 5)– 对应(city, car_model)分组。(‘北京’ null 5)– 对应(city)分组car_model位置用null填充。(null ‘Model 3’ 5)– 对应(car_model)分组city位置用null填充。(null null 5)– 对应()全局分组。你可能会问这样扩展后所有数据都混在一起了后续聚合怎么区分哪些数据属于哪个分组集呢这就引出了一个至关重要的标记列——分组ID在Spark SQL中名为spark_grouping_id。在扩展时每一条生成的记录都会被打上一个数字标签用来标识它源自哪个分组集。比如可以用0、1、2、3来分别标记上述四个分组集。第二阶段统一聚合 (Aggregate)经过Expand阶段后我们得到了一份“膨胀”了的中间数据。接下来的聚合操作就变得非常直观和统一了将“分组ID”连同原始的分组字段一起作为新的分组键。例如要计算(city)这个分组集的聚合实际上就是在聚合时使用GROUP BY city spark_grouping_id HAVING spark_grouping_id 1假设ID1对应(city)分组。由于spark_grouping_id的隔离即使不同分组集的数据混杂在同一张中间表里它们也能在聚合时被清晰地区分开来互不干扰。这种设计的精妙之处在于它把多样性的分组需求转化为了一个统一的、可批量处理的计算模型。数据库只需要扫描一次原始数据进行一次复杂的扩展操作然后执行一次聚合计算就能得到所有结果。相比于UNION ALL的多次扫描、多次计算其性能优势是显而易见的。2.1 与Union All的对比思路决定性能为了更直观地对比两种方式的差异我们可以从执行计划的角度来看。Union All方式其逻辑计划像一棵由多个分支组成的树。每个分支都是一个独立的Aggregate算子节点下面挂着一个扫描数据的Scan节点。执行时每个分支独立工作最后通过Union节点合并结果。数据被重复读取和计算。Grouping Sets方式其逻辑计划是一个更深的、单一路径的管道。最下面是Scan上面是Expand再上面是统一的Aggregate。数据像流水线一样被处理一次。这种架构上的根本差异就是性能差异的来源。Expand Aggregate的单流水线模式减少了数据I/O和中间结果的物化开销更适应现代大规模数据并行处理框架如Spark的计算模型。3. 深入源码ExpandExec算子如何工作理论说得再多不如直接看代码来得透彻。在Spark SQL中Expand算子的具体实现类是ExpandExec。它的核心使命就是高效地完成我们前面所说的“数据扩展”操作。让我们深入到doExecute()方法中看看它是如何运转的。ExpandExec的核心输入是一个projections序列。这个序列的每个元素本身也是一个表达式序列都对应一个分组集。例如对于GROUPING SETS ((city, car_model), (city), ())projections可能包含三个表达式列表第一个列表[city, car_model, 0]// 0是分组ID第二个列表[city, null, 1]// 1是分组IDcar_model位置用字面量null填充第三个列表[null, null, 3]// 3是分组ID所有分组字段用null填充在初始化阶段关键点1和2ExpandExec会为projections中的每一个表达式列表预先创建一个UnsafeProjection对象。你可以把UnsafeProjection理解为一个高性能的“行转换器”。它被绑定到输入数据的Schemachild.output当调用其apply方法并传入一行原始数据时它会根据表达式列表快速计算出一行新的数据。比如对于表达式[city, null, 1]转换器会对输入行取出city列的值在第二列生成一个null在第三列生成常量1。真正的扩展逻辑发生在mapPartitions中关键点3和4。对于上游输入的每一条数据记录input算子会遍历所有预先创建好的UnsafeProjection转换器即groups数组。每应用一个转换器就生成一条新的输出记录。用一个简单的循环伪代码表示就是for (inputRow in inputData) { for (i in 0 until projections.length) { val outputRow groups(i).apply(inputRow) // 关键点4使用不同的投影规则 emit(outputRow) } }这个过程完美诠释了“扩展”的含义一条输入通过N套不同的投影规则变出N条输出。spark_grouping_id就在其中一套投影规则里被作为常量生成从而忠实地记录了每一行扩展数据的“出身”。注意这里使用的UnsafeProjection是Spark内部用于直接操作堆外内存Unsafe Memory的高性能投影接口它避免了Java对象开销和GC压力对于Expand这种需要大量生成新行的操作性能提升至关重要。这也是Spark SQL高效的原因之一。4. 性能实测Grouping Sets优势有多大理论分析和源码解读都指向Grouping SETS更优但实际差距是多少呢我们用一个简单的测试来验证。假设有一张汽车销量表dealer包含citycar_modelquantity字段。我们分别用GROUPING SETS和等价的UNION ALL来编写查询计算城市-车型组合、城市汇总、车型汇总和全局总计。在同一个Spark环境本地模式小数据集下各执行10次取平均耗时。测试结果对比表查询方式平均耗时 (秒)相对耗时比查询语句复杂度GROUPING SETS0.2761x(基准)简洁1个SELECT1个GROUP BYUNION ALL0.616约2.2x冗长4个SELECT 3个UNION ALL从结果可以清晰看到GROUPING SETS版本的性能几乎是UNION ALL版本的两倍以上。这背后的原因主要在于减少数据扫描GROUPING SETS只需扫描一次基表而UNION ALL需要扫描四次。减少中间结果落盘UNION ALL的每个子查询都可能产生中间聚合结果需要缓存或落盘以供最终合并。GROUPING SETS的单一聚合路径优化了此过程。优化器优势现代查询优化器如Spark的Catalyst能对GROUPING SETS整体进行更好的优化比如选择更优的聚合策略而对多个独立的UNION ALL子查询的优化空间相对有限。实操心得这个性能差异在小数据量下可能只是几百毫秒但在生产环境动辄TB、PB级的数据量下这种开销会被急剧放大。一次查询节省数倍时间在并发高的数据平台或ETL任务中对集群资源的节约和任务完成时间的缩短是巨大的。因此只要遇到需要多维度组合聚合的场景应优先考虑使用GROUPING SETS。5. RollUp和CubeGrouping Sets的语法糖理解了GROUPING SETS之后再来看ROLLUP和CUBE就非常轻松了。它们本质上都是GROUPING SETS的便捷写法目的是让SQL语句更简洁底层执行引擎仍然将它们翻译成基于Expand算子的执行计划。5.1 RollUp层级上卷聚合ROLLUP用于生成层级式的聚合通常用于生成小计和总计。它的分组集遵循一种“上卷”的规律。-- 使用 ROLLUP SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY ROLLUP(city car_model) ORDER BY city car_model; -- 等价于使用 GROUPING SETS SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY GROUPING SETS ( (city car_model) -- 最细粒度 (city) -- 上卷一层对city做小计 () -- 上卷到底全局总计 ) ORDER BY city car_model;ROLLUP(a b c)等价于GROUPING SETS((abc) (ab) (a) ())。它假设维度之间有层级关系如年-月-日逐级上卷聚合。5.2 Cube多维立方体全组合聚合CUBE则更加彻底它会生成指定维度所有可能组合的分组集。适用于需要全方位、多角度交叉分析的数据立方体场景。-- 使用 CUBE SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY CUBE(city car_model) ORDER BY city car_model; -- 等价于使用 GROUPING SETS SELECT city car_model SUM(quantity) AS sum FROM dealer GROUP BY GROUPING SETS ( (city car_model) -- 二维组合 (city) -- 仅city维度 (car_model) -- 仅car_model维度 () -- 零维总计 ) ORDER BY city car_model;CUBE(a b c)等价于GROUPING SETS包含所有abc的子集组合共2^n个n为维度数。它不假设维度间有层级关系是一种“全维度”分析。通过EXPLAIN EXTENDED命令查看Spark SQL的执行计划可以确认ROLLUP和CUBE在优化后的逻辑计划中都被转换成了带有对应projections列表的Expand节点。这证实了它们在执行层面与直接书写GROUPING SETS并无二致性能特性完全一致。注意事项虽然ROLLUP和CUBE是语法糖但选择使用哪一个取决于业务语义。ROLLUP用于有明确层级关系的维度如地理、时间CUBE用于需要平等探索所有维度组合的分析。误用会导致结果集包含不必要或无业务意义的分组浪费计算资源。6. 常见问题与排查技巧实录在实际使用GROUPING SETS、ROLLUP或CUBE时你可能会遇到一些典型问题。这里记录了几个我踩过的坑和解决思路。6.1 如何区分结果中的NULL是原始空值还是聚合填充的NULL这是一个经典问题。当city列本身就有NULL值时聚合结果中city为NULL的行到底代表“城市为空”的记录汇总还是代表“不考虑城市维度”的汇总呢答案是GROUPING函数或Spark SQL中的grouping_id。SELECT city car_model SUM(quantity) AS sum GROUPING(city) AS city_grouping_flag -- 如果city是聚合填充的NULL则返回1否则返回0 GROUPING(car_model) AS model_grouping_flag GROUPING_ID(city car_model) AS grouping_id -- 返回一个二进制位图表示的整数 FROM dealer GROUP BY GROUPING SETS ((city car_model) (city) (car_model) ()) ORDER BY grouping_id city car_model;通过GROUPING函数可以明确判断出NULL值的来源从而在应用程序中正确解读数据。6.2 结果行数异常增多远超预期如果发现结果集行数比预想的多很多首先检查GROUPING SETS中的分组集列表是否有重复。例如GROUPING SETS ((city) (city) ())会导致(city)分组被计算两次。其次检查连接条件。如果在包含GROUPING SETS的查询中使用了JOIN需要特别注意连接键是否可能因为NULL的填充而产生意外的笛卡尔积。通常建议先进行聚合再与其他表连接。6.3 性能反而比Union All更差在极少数情况下GROUPING SETS可能没有表现出性能优势。这可能是因为数据倾斜严重Expand操作会使数据膨胀N倍如果原始数据中某个键的数据量极大膨胀后该键对应的数据量会更大导致后续Aggregate阶段出现严重的数据倾斜。可以通过观察Spark UI中任务的执行时间是否差异巨大来判断。分组集数量极多GROUPING SETS列表非常长例如几十个导致Expand倍数过高中间数据量爆炸。这时需要重新评估业务需求是否合理或者考虑分多次查询。优化器未能选择最佳计划可以尝试收集表的统计信息如ANALYZE TABLE帮助优化器做出更准确的代价估算。在Spark中可以检查spark.sql.adaptive.enabled等自适应执行配置是否打开以应对数据倾斜。6.4 在Spark SQL中如何查看具体的Expand投影内容调试时想确切知道Expand算子生成了哪些投影表达式可以使用explain(mode‘extended’)。在输出的优化后逻辑计划中找到Expand节点它会显示类似Expand [[quantity#2159 city#2157 car_model#2158 0] [quantity#2159 city#2157 null 1] ...]的信息。每一组方括号内的列表就是一个分组集的投影表达式最后的数字就是spark_grouping_id。这有助于验证你的GROUPING SETS、ROLLUP或CUBE是否被正确翻译。掌握GROUPING SETS及其相关语法不仅仅是学会了一种SQL写法更是理解了一种高效的多维聚合计算范式。下次当你面对复杂的多层聚合报表需求时不妨优先考虑它让代码更简洁让查询跑得更快。
