添加Spark查询Hint是否会导致结果不一致？附复现案例

问题结论 #

是的，给Spark查询添加Hint确实可能导致返回结果不同，你遇到的就是典型案例：添加SHUFFLE_HASH(i) Hint后，左半连接的结果从1条变为0条，该问题在Spark 3.4.1、3.5.3、3.5.5版本均可复现。

核心原因 #

1. 连接策略的强制变更
   默认情况下，Spark会根据表的大小自动选择最优连接策略：你的右表geohashes_to_include只有10条数据，Spark会自动采用Broadcast Hash Join——将小表广播到所有节点，左表每条数据都能和完整的右表做匹配，因此能正确找到9ykchgz95z与9ykchgz95的前缀匹配关系。

   当你添加SHUFFLE_HASH(i) Hint时，强制Spark使用Shuffle Hash Join，并指定右表作为构建表（build side）。这种策略需要将两张表都按连接键哈希分区后再做匹配，但你的连接条件是SUBSTRING(g.geohash,1,7)=SUBSTRING(i.geohash_prefix,1,7) AND STARTSWITH(g.geohash,i.geohash_prefix)——属于非等值的前缀匹配连接，哈希分区仅基于前7位的子串，导致同一分区内的右表数据可能不包含能匹配左表的9位前缀，最终无法找到匹配记录。

2. 非等值连接对Shuffle Hash Join的兼容性问题
   Shuffle Hash Join更适合处理等值连接，对于依赖前缀匹配这类非等值条件的场景，哈希分区无法保证所有潜在匹配的记录被分到同一分区，从而出现漏匹配的情况。

解决方案 #

方案1：移除不必要的Hint #

优先让Spark自动选择连接策略，对于小表参与的连接，Broadcast Hash Join是最优选择，无需手动指定Hint。

方案2：调整连接条件为等值匹配 #

根据业务逻辑，你的STARTSWITH(g.geohash,i.geohash_prefix)等价于SUBSTRING(g.geohash,1,9)=i.geohash_prefix（因为右表的前缀都是9位），将连接条件改为等值连接后，Shuffle Hash Join也能正确处理：

SELECT /*+ SHUFFLE_HASH(i) */ * 
FROM geohashes g 
LEFT SEMI JOIN geohashes_to_include i 
ON SUBSTRING(g.geohash, 1, 9) = i.geohash_prefix

方案3：指定更小的表作为构建表 #

如果必须使用Shuffle Hash Join，应该将数据量更小的左表作为构建表（左表仅2条数据），修改Hint为：

SELECT /*+ SHUFFLE_HASH(g) */ * 
FROM geohashes g 
LEFT SEMI JOIN geohashes_to_include i 
ON SUBSTRING(g.geohash, 1, 7) = SUBSTRING(i.geohash_prefix, 1, 7) AND STARTSWITH(g.geohash, i.geohash_prefix)

这样构建表的数据量极小，哈希分区后能保证所有匹配记录被正确关联。

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