PolarDB 并行查询的前世今生
平均阅读时长为 2分钟
一 背景
1 PolarDB
2 挑战
3 方案
二 并行查询介绍
1 特性
完全基于MySQL codebase,原生的MySQL 100%兼容,这里包括
语法兼容 类型兼容 行为兼容 0 附加成本,随产品发布就携带的功能
无需额外存储资源 无需额外计算节点 0 维护成本,使用和普通查询没有任何差别,只是响应变快了
随集群部署,开箱即用 对业务无侵入 单一配置参数(并行度) 实时性分析,PolarDB原生的一部分,受惠于REDO物理复制的低延迟
统一底层事务型数据 提交即可见 极致性能,随着PQ的不断完善,对于分析型算子、复杂查询结构的支持能力不断提升
全算子并行 高效流水线 复杂SQL结构支持 稳定可靠,作为企业级特性,这个毋庸置疑
扩展MySQL测试体系 线上多年积累 完备诊断体系
2 演进
PQ1.0
执行模式是简单的scatter-gather,也就是只有一个plan slice,多个worker完成相同的功能,汇总到leader
尽可能的下推算子到worker上
leader负责完成无法下推的计算
计划形态是单一的,导致算子的并行方式单一,比如group by + aggregation,只能通过二阶段的聚集来完成:worker先做partial aggregation,leader上做final aggregation
一旦leader上完成聚集操作,后续如果有distinct / window function / order by等,都只能在leader上完成,形成单点瓶颈
如果存在数据倾斜,会使部分worker没有工作可做,导致并行扩展性差
此外实现上还有一些待完善的地方,例如少量算子不支持并行、一些复杂的查询嵌套结构不支持并行
PQ2.0
全新的Cost-based并行优化器,基于统计信息和代价决定最优计划形态
全算子的并行支持,包括上面提到的复杂的多层嵌套结构,也可以做到完全的并行
引入exchange算子,也就是支持shuffle/broadcast这样的数据分发操作
引入一定自适应能力,即使并行优化完成了,也可以根据资源负载情况做动态调整,如回退串行或降低并行度
SELECT t1.a, sum(t2.b)
FROM
t1 JOIN t2 ON t1.a = t2.a
JOIN t3 ON t2.c = t3.c
GROUPBY t1.a
ORDERBY t1.a
LIMIT10;
在join的表集合中,寻找一个可以做逻辑分片的表做拆分,如果3个表都不足以拆分足够多的分片,那就选最多的那个,比如这里选择了t2,它可能拆出12个分片,但仍然无法满足并行度16的要求,导致有4个worker读不到数据而idle。
聚集操作先在worker上做局部聚集,leader上做汇总聚集,如果各个worker上分组的聚拢不佳,导致leader仍然会收到来自下面的大量分组,leader上就会仍然有很重的聚集计算,leader算的慢了,会来不及收worker数据,从而反压worker的执行速度,导致查询整体变慢。
虽然仍然只能在t2上做数据分片,但12个worker只需要完成t1 join t2这个操作,在join完成后一般数据量会膨胀,通过Shuffle(Repartition)将更多的中间结果分发到后续的slice中,从而以更高的并行度完成与t3的join 各worker完成局部聚集后,如果分组仍很多,可以基于group by key做一次Shuffle来将数据打散到下一层slice,下一组worker会并行完成较重的聚集操作,以及随后的order by局部排序,最终leader只需要做一次merge sort的汇总
随着业务增长数据不断膨胀,通过相应提高并行度来使用匹配的计算资源,来持续得到稳定可预期的查询性能
始终快速的分析时间可以驱动快速的业务决策,使企业在快速变化的市场环境中保持竞争力
3 架构
Cost-based Parallel Optimizer,嵌入在MySQL的优化器框架中,完成并行优化部分
Parallel Plan Generator,根据抽象的并行计划描述,生成可供worker执行的物理执行计划
Parallel Executor,并行执行器组件,包括一些算子内并行功能和数据分发功能等
4 性能
5 使用方式
三 并行查询实现
1 并行优化器
代价模型的增强
统计信息自动更新 串行优化流程中做针对并行执行的补强,例如修正table扫描方式等,这也是上面性能数据中Q6/Q12会有超线性加速比的原因 全算子统计信息推导+代价计算,补充了一系列的cost formula和cardinality estimation推导机制
自适应执行策略
串行优化与并行优化解耦,并行优化会重新构建抽象算子树,并以此为输入开始enumeration 并行优化与并行计划生成解耦,优化的结果是计划子片段的抽象描述,作为输出进行plan generation
基于代价的穷尽式枚举
2 并行计划生成
SELECT t1.a, sum(t2.b) sumb
FROM t1 join t2
ON t1.c = t2.c
GROUPBY t1.a
ORDERBY sumb;
clone
refix
3 并行执行器
parallel scan
尽量做细粒度的切分,使分片数 >> worker数,然后worker之间通过round robin的方式去“抢”分片来执行,这样自然做到了能者多劳,避免由于数据分布skew导致的负载不均衡问题,这是shared storage系统的一个天然优势。 切分时可以不用dive到叶子节点,也就是以page作为最小分区单位,来加速初始分区速度。
parallel hash join
build阶段,多个worker向同一个共享的lock-free hash table中插入数据。 probe阶段,多个worker并行到hash table做搜索。
partition hash join
build/probe两侧都根据join key做shuffle,将数据分发到目标partition; 在每个partition内,build侧各自构建小hash table; 在每个partition内,probe侧各自查找对应的hash table;
子查询并行 - pushdown exec
SELECT c1 FROM t1
WHEREEXISTS (
SELECT c1 FROM t2 WHERE t2.a = t1.a <= EXISTS subquery
)
ORDERBY c1
LIMIT10;
子查询并行 - pushdown shared
SELECT c1 FROM t1
WHERE t1.c2 IN (
SELECT c2 FROM t2 WHERE t2.c1 < 15 <= IN subquery
)
ORDERBY c1
LIMIT10;
Exchanges
四 未来规划
打通节点间计算资源,实现更高的计算并行度
突破单节点在IO / CPU上的瓶颈,充分利用分布式存储的高吞吐能力
结合全局节点管理与资源视图,平衡调度全局计算资源,实现负载均衡的同时保证查询性能
结合全局一致性视图,保证对事务性数据的正确读取
互联网技术实战营·数据智能专题
关键词
问题
组件
节点
结构
数据库
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。