数据倾斜处理
数据倾斜处理
概述
PALO 是一个 MPP 数据库，依赖数据 shuffle 进行并行的计算加速。但是实际生产场景经常会遇到因为数据倾斜导致查询并行的单线程的执行瓶颈。下节介绍如何发现这类问题，并提供一些通用的解决方法。
案例 1：Bucket 数据倾斜导致 shuffle 方式不优
当 Table 在 Join Key 上出现数据倾斜时，数据会在不同的 BE instance 间会分布不均，导致单点的执行瓶颈，进而拖慢整个查询的执行时间。
1HASH_JOIN_OPERATOR (id=27):
2 - PlanInfo
3 - join op: INNER JOIN(PARTITIONED)[]
4 - equal join conjunct: (customer_number = customer_number)
5 - runtime filters: RF001[bloom] <- customer_number(200/256/2048)
6 - cardinality=200
7 - vec output tuple id: 28
8 - output tuple id: 28
9 - vIntermediate tuple ids: 27
10 - hash output slot ids: 192 193 194 195 196 197 198 199 200 201 174 175 240 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
11 - project output tuple id: 28
12 - BlocksProduced: sum 4.883K (4883), avg 33, max 39, min 29
13 - CloseTime: avg 37.28us, max 132.653us, min 13.945us
14 - ExecTime: avg 166.206ms, max 10s947.344ms, min 8.845ms
15 - InitTime: avg 0ns, max 0ns, min 0ns
16 - MemoryUsage: sum , avg , max , min
17 - PeakMemoryUsage: sum 11.81 MB, avg 84.00 KB, max 84.00 KB, min 84.00 KB
18 - ProbeKeyArena: sum 11.81 MB, avg 84.00 KB, max 84.00 KB, min 84.00 KB
19 - OpenTime: avg 194.970us, max 497.685us, min 93.738us
20 - ProbeRows: sum 23.884018M (23884018), avg 165.861K (165861), max 219.346276M (219346276), min 1984 (1984)
21 - ProjectionTime: avg 7.336ms, max 33.540ms, min 3.760ms
22 - RowsProduced: sum 28.8K (28800), avg 200, max 200, min 200 从上面的 Join 的 Profile 上 max 指标上来看，执行时间和 ProbeRows 的有明显的倾斜情况。
1ExecTime: avg 166.206ms, max 10s947.344ms, min 8.845ms
2ProbeRows: sum 23.884018M (23884018), avg 165.861K (165861), max 219.346276M (219346276), min 1984 (1984) 然而，由于数据基于 join key shuffle 之后分布不均，会导致其中一个线程处理了 2 亿行数据，而另一个线程只处理了 几千行数据。
上述 case 在理想情况下，每个线程各处理的数据是接近的。但因为 Join 列数据倾斜的问题，可能会导致大量的计算工作由一个线程完成的。为了解决这个性能瓶颈，可以参考“使用 Hint 控制 Join Shuffle 方式”章节中提到的调优技巧，指定 broadcast join hint 如下，让左表不进行数据的 shuffle，这样就可以有效避免因为 Join 列数据倾斜导致的性能瓶颈。
1SELECT COUNT(*) FROM orders o JOIN [broadcast] customer c ON o.customer_number = c.customer_number;案例 2：列数据倾斜导致 join 左右边颠倒
当前 PALO 优化器基于数据均匀假设估算选择率，过滤估行偏差大会影响算子的计划选择。以如下 SQL 为例：
1select count(*)
2from orders, customer
3where o_custkey = c_custkey
4and o_orderdate < '1920-01-02';在均匀分布的假设下，优化器可能会认为经过o_orderdate < '1920-01-02'过滤后输出的行数会少于 customer 表的行数，因此可能选择customerjoin orders 的连接顺序。
但是如果实际数据存在倾斜，导致满足条件的 orders 表的条数多于 customer ，那么更合理的连接顺序应该是ordersjoincustomer 。为了解决这个性能问题，可以参考“使用 Leading Hint 控制 Join 顺序”章节中提到的调优技巧，指定 leading hint 如下，强制生成customerjoin orders 的连接顺序。
改写 SQL 如下：
1select /*+leading(orders customer)*/ count(*)
2from orders, customer
3where o_custkey = c_custkey
4and o_orderdate < '1920-01-02'总结
数据倾斜是常见的生产场景性能问题。通过 EXPLAIN 和 PROFILE 工具输出观察计划和执行瓶颈，定位倾斜原因，然后就可以使用 Hint 工具进行相应的计划调整，规避数据倾斜对性能的影响了。
