String类型的key和Int类型有什么不同？编码和数据类型对倾斜的影响

这是一道非常细节的面试题，能考出候选人对数据系统底层实现的理解深度。数据倾斜的本质是key的哈希分布不均，而哈希分布受到key的数据类型和编码的直接影响。String类型的哈希函数和Int类型不同，某些特定的String值（比如都是数字的字符串）可能产生哈希冲突，导致数据集中。我在某短剧出海公司处理广告ID倾斜时，就发现了一个因为数据类型不一致导致的「假倾斜」——两张表的ad_id，一张是String，一张是BigInt，JOIN时发生了隐式类型转换，产生了意想不到的分布不均匀。

String key的哈希分布问题

String类型的哈希值是基于字符序列计算的，不同的String值产生不同的哈希值，理论上分布均匀。但某些特殊情况会破坏均匀性：

-- 测试String key的哈希分布（Spark SQL）
SELECT
  pmod(hash(key_value), 10) AS partition_id,  -- 模拟分10个分区
  COUNT(*) AS row_count
FROM your_table
GROUP BY pmod(hash(key_value), 10)
ORDER BY partition_id;
-- 如果各partition_id的row_count差异很大，说明String哈希分布不均
 
-- 常见的String哈希不均匀场景：
-- 场景1：key都是纯数字字符串（如'001','002',...,'999'）
-- 数字字符串的Unicode码点集中（48-57），哈希后可能碰撞
 
-- 场景2：key有规律的前缀（如'AD_001','AD_002',...）
-- 前缀相同，哈希值相近，可能集中到相邻分区
 
-- 场景3：key里有大量空值字符串（''，空格）
-- 空字符串的哈希值固定（类似NULL的问题），导致集中

-- 实际验证：检查你的key的哈希分布
-- 如果某个partition_id的count比其他高出5倍，考虑更换哈希函数
 
-- Spark SQL里可以指定哈希函数：
-- hash()：MurMur3哈希，默认
-- xxhash64()：xxHash算法，速度更快，分布更均匀
-- sha1()/sha2()：密码学哈希，绝对均匀但速度慢
 
-- 如果发现MurMur3哈希不均匀，改用xxhash64：
SELECT
  pmod(xxhash64(key_value), 10) AS partition_id,
  COUNT(*) AS row_count
FROM your_table
GROUP BY pmod(xxhash64(key_value), 10);
-- 对比两种哈希函数的分布，选择更均匀的

隐式类型转换导致的「假倾斜」

这是最容易踩的坑：两张表JOIN时，key的类型不匹配，引擎做了隐式转换，转换后的分布和原始分布不同。

-- 典型场景：orders表的ad_id是String，ad_info表的ad_id是BigInt
-- 发生隐式类型转换：String转换为Double再比较
 
SELECT o.order_id, a.ad_name
FROM orders o
JOIN ad_info a ON o.ad_id = a.ad_id;
-- o.ad_id类型：String（'123456789'）
-- a.ad_id类型：BigInt（123456789）
-- Spark会把String隐式转换为Double再比较
 
-- 问题1：Double转换时精度丢失！
-- String '99999999999999999' 转换为Double后
-- 变成了 100000000000000000（精度丢失，多了个0）
-- 导致本来能匹配的记录JOIN不上！
 
-- 问题2：转换后的哈希分布和原始分布不同
-- 原始String的哈希值按字符序列计算
-- 转换为Double后按数值计算，分布可能集中
 
-- 解决：显式类型转换，保证两侧类型一致
SELECT o.order_id, a.ad_name
FROM orders o
JOIN ad_info a ON CAST(o.ad_id AS BIGINT) = a.ad_id;
-- 或者在建表时就统一类型，消除隐式转换的风险

这个问题我在某短剧出海公司实际踩过。广告数据从Facebook API拿到的ad_id是String类型，存到ODS层也是String；但DWD层的广告信息表是从MySQL同步的，ad_id是BigInt。两张表JOIN时，有5%的记录因为精度丢失JOIN不上，另外Join的数据分布也出现了异常集中，折腾了两天才找到根因。

编码问题：空格、大小写、多字节字符

数据清洗不彻底导致的编码问题，经常是倾斜的隐性原因：

-- 常见的编码导致的分布问题：
 
-- 问题1：前后空格导致key不一致
-- 'user001' 和 ' user001' 是两个不同的key（前面有空格）
-- 但业务上应该是同一个用户
-- 带空格的key可能集中在某个分区
SELECT user_id, COUNT(*) FROM user_events
GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 10;
-- 如果发现 ' user001'（带空格）比'user001'多很多，就是这个问题
 
-- 解决：在ETL清洗时TRIM
SELECT TRIM(user_id) AS user_id, event_type
FROM raw_events;
 
-- 问题2：大小写不统一
-- 'User001' 和 'user001' 是不同的key
-- 如果有大量大小写混用的数据，会分裂成多个小key
-- 间接「消除」了倾斜，但数据是错的（同一个用户被拆成多个）
SELECT LOWER(user_id) AS user_id, COUNT(*)  -- 统一转小写
FROM user_events GROUP BY LOWER(user_id);
 
-- 问题3：emoji或特殊字符在key里
-- 某些平台允许用户名包含emoji，emoji是多字节UTF-8字符
-- 哈希时按字节序列计算，emoji的哈希值分布和ASCII不同
-- 建议：对包含emoji的key做normalize处理（移除非ASCII字符）
SELECT REGEXP_REPLACE(user_name, '[^\\x00-\\x7F]', '') AS clean_name
FROM users;