TDH计算引擎针对数据倾斜现象的保护机制

博客主要介绍了Shuffle阶段的数据倾斜问题。在Shuffle Write阶段,数据倾斜会出现Bucket size is too large的报错,可调整reduce number或分桶策略;Shuffle Read阶段多个参数达到上限会判定数据倾斜,有不同报错及对应解决方案,还提及大表与小表、大表与大表关联的处理方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

shuffle write阶段
Shuffle Write阶段当出现数据倾斜时将出现Bucket size is too large (>2G) after compress的报错提醒,此时应当调整reduce number或者调整分桶策略;

shuffle read阶段
参数一:ngmr.safety.size.single.entry -- hive-site.xml

  • 该参数默认值512000000,单位为byte,可session级别生效;
  • 注释:单task内相同key对应的value的数据量达到512MB的上限,判定为数据倾斜,报错Data skew for single key found;
  • 当出现这个报错提醒时的解决方案:common join转map join或skewjoin

参数二:ngmr.trie.keychunk.mb -- hive-site.xml

  • 默认值-1,可session级别生效;
  • 注释:
a)单task内所有key本身的总数据量达到2G(默认值情况下内部赋值16,16M*128)的上限,不同key太多了,可判定为数据倾斜,报错Key size is exceed;
b)单个key本身的数据大小超过16MB,报错Can't put key into keychunk, because key length exceed;
c)单task内所有key本身的总数据量达到4G(参数不可调),报错Can't put key into keychunk, because key length exceed 4GB;
  • 当出现这个报错提醒时的解决方案:调整reduce number或者分桶数

参数三:ngmr.trie.node.max -- hive-site.xml

  • 默认值20480000,可session级别生效;
  • 注释:与ngmr.trie.keychunk.mb类似,不同key太多了,可判定为数据倾斜,报错Exceed max trie node in key chunk;
  • 当出现这个报错提醒时的解决方案:调整reduce number或者分桶数
  •  大表与小表进行关联 --- Map Join
     大表与大表进行关联 --- Skew Join
### 数据倾斜的定义 数据倾斜是指在分布式计算环境中,由于某些特定原因导致部分节点承担了过多的任务或存储了过量的数据,从而使得这些节点成为整个系统的性能瓶颈。这种现象通常发生在缓存系统中[^1],也可能出现在大数据处理框架中的任务分配阶段。 #### 缓存系统中的数据倾斜 在缓存系统中,数据倾斜表现为大量请求集中在少数几个服务节点上。这种情况可能由负载均衡效果不佳引起[^1],也可能是由于热键(hot key)的存在所致[^2]。例如,在电商场景下,热门商品的信息可能会被频繁访问,而其他冷门商品则很少有人关注。这会导致承载该热门商品信息的服务节点承受巨大的压力。 --- ### 处理数据倾斜的方法 针对不同的应用场景和技术栈,可以采取多种策略来缓解数据倾斜问题: #### 1. **优化负载均衡** 通过改进负载均衡算法,使请求能够更均匀地分布在各个节点之间。常见的做法包括引入一致性哈希算法或其他高级调度机制,减少因不合理的分片逻辑而导致的部分节点负担过重的情况[^1]。 #### 2. **拆分大Key** 如果发现存在特别大的单一Key占用较多资源,则可以通过将其进一步细分为多个子Key的方式降低单个Key的压力。这种方法尤其适用于Redis这样的内存数据库环境当中[^2]。 ```python def split_large_key(key, value): chunk_size = 100 # 假设每条记录最大长度为100字节 chunks = [value[i:i+chunk_size] for i in range(0, len(value), chunk_size)] sub_keys = [] for idx, chunk in enumerate(chunks): new_key = f"{key}_part_{idx}" redis.set(new_key, chunk) # 使用redis客户端设置新的sub-key sub_keys.append(new_key) return sub_keys ``` 上述代码展示了如何将一个较大的Value分割成若干个小片段并分别存储到不同的Sub-Key之中。 #### 3. **预热Cache** 提前加载那些预计会变成Hot Key的数据项进入缓存层,这样当真实流量到来之前就已经做好准备,避免首次访问时因为未命中造成额外延迟以及后续连锁反应引发局部热点形成。 #### 4. **调整Sharding Strategy** 重新设计数据分区方案,确保即使面对突发性的访问模式变化也能维持较好的平衡状态。比如可以根据时间戳、地理位置等因素动态调整shard归属关系[^1]。 #### 5. **利用Hive SQL特性解决Big Data中的Skew Issue** 对于大规模离线数据分析作业而言,经常会出现join操作过程中某张表里少量值对应极多匹配行数的现象。此时可考虑采用如下手段应对: - 对于已知的小维度表可以直接广播出去做map-side join; - 或者尝试启用skewed join hint功能让引擎自动识别偏斜情况并对齐特殊处理路径[^3]; ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值