Hive1.1.0子查询GROUP BY异常致Error10025问题排查

报错根本成因 #

• 先明确：本次报错和你预判的子查询GROUP BY范围异常完全无关。内层子查询的语法逻辑合法：子查询按item_id分组取max(buy_num_sum_I_7days)，返回的是单行对应一个独立item_id的明细粒度结果集，不存在分组范围的问题。
• 真正的触发原因来自外层查询块的语义校验规则：Hive校验SQL语义时，只要当前SELECT子句中同时出现「无聚合修饰的普通字段」、「不带OVER窗口定义的普通聚合函数（如sum/max/count）」，就会把当前查询判定为全局聚合查询模式。此时所有SELECT中出现的非聚合字段，必须显式声明在对应的GROUP BY子句中，否则直接抛出10025错误。
• 对应你的SQL，外层SELECT里既有普通字段item_id，又有带普通聚合函数的计算字段buy_num_sum_I_7days/sum(buy_num_sum_I_7days)，但外层完全没有写GROUP BY子句，校验器自然会捕获第一个非聚合字段item_id，抛出“Expression not in GROUP BY key 'item_id'”的报错。
• 从语义自洽角度解释规则：如果允许这种写法，不带OVER的sum()会把整个结果集压缩为单行，此时单行中要展示哪个item_id的值是完全不明确的，Hive不会执行这种存在逻辑歧义的查询。

可直接运行的修正方案 #

结合你的业务逻辑（计算单个item_id的7天购买量占全量所有item总购买量的比例），适配Hive 1.1.0版本有两种可用写法：

方案1：使用窗口聚合（更简洁） #

窗口聚合不会改变原有结果集的行粒度，也不会触发全局聚合的语义校验，是这类“行值占全局比例”场景的最优写法：

select 
    item_id,
    buy_num_sum_I_7days / sum(buy_num_sum_I_7days) over () as item_buy_probability
FROM
(
    select 
        item_id,
        max(buy_num_sum_I_7days) as buy_num_sum_I_7days
    FROM
        mytable
    where
        dt>=20210206 and dt<=20210208
    group BY
        item_id
) tt;

方案2：全局总和关联（无窗口函数兼容写法） #

如果需要兼容不支持窗口函数的Hive版本，可将全局购买量总和单独计算后，通过笛卡尔积关联到每一行item的计算值上：

select 
    tt.item_id,
    tt.buy_num_sum_I_7days / total.total_sum as item_buy_probability
FROM
(
    select 
        item_id,
        max(buy_num_sum_I_7days) as buy_num_sum_I_7days
    FROM
        mytable
    where
        dt>=20210206 and dt<=20210208
    group BY
        item_id
) tt
cross join (
    select sum(buy_num_sum_I_7days) as total_sum
    from (
        select 
            item_id,
            max(buy_num_sum_I_7days) as buy_num_sum_I_7days
        FROM
            mytable
        where
            dt>=20210206 and dt<=20210208
        group BY
            item_id
    ) t_inner
) total;

同类问题通用排查思路 #

后续遇到10025类GROUP BY相关报错时，可按固定顺序拆解排查，减少误判：

• 第一步：根据报错信息的行号、列号，先定位问题所在的具体查询块（是最外层还是哪一层嵌套子查询），不要直接从最内层子查询开始排查。比如本次报错定位到Line 2:8的位置，实际对应最外层SELECT的字段，排查范围应优先放在外层查询。
• 第二步：检查当前定位到的查询块的SELECT字段组成，判断是否触发了全局聚合模式：只要出现不带OVER的普通聚合函数，且同时存在未出现在GROUP BY中的普通字段，就必然触发这类报错。
• 第三步：区分业务逻辑的聚合需求：如果是要保留原有行粒度计算占比、排名这类指标，优先用窗口函数替代普通聚合，从根源上避免全局聚合的校验规则；如果是真的需要按维度分组统计，就把所有非聚合的普通字段补充到对应的GROUP BY子句中。
• 第四步：排除外层逻辑问题后，再反向校验内层子查询的字段映射、GROUP BY逻辑是否正确，避免一开始就将排查方向错配到子查询层。

内容的提问来源于stack exchange，提问作者coffee