MaxCompute复杂数据分布的查询优化实践-阿里云开发者社区

开发者社区> 云攻略小攻> 正文

MaxCompute复杂数据分布的查询优化实践

简介:
+关注继续查看

2017年中国大数据技术大会于12月7-9日在北京新云南皇冠假日酒店隆重举行, 大会就大数据时代社会各行业的智能化进程和行业实践展开深入讨论。

在12月8日的“大数据分析与生态系统”分论坛上,来自阿里巴巴计算平台事业部的高级技术专家少杰,以“MaxCompute 复杂数据分布的查询优化实践”为题,为现场来宾分享了阿里云MaxCompute最新技术与实践的洞察与经验。
4

概述
数据分布的问题在大数据处理领域由来已久。很不幸,如今流行的大数据处理系统仍然没有很好地解决这个问题。在MaxCompute 2.0全新的优化器中,我们引入了复杂数据分布,添加了分区剪枝、分布上拉、下推以及分布对齐等优化措施。本文将从数据分布的历史和原理开始,介绍我们的思路和解决办法。

理解数据分布
提到数据分布,很多人会想到MPP DBMS。的确,我们通常说只有MPP DBMS才需要考虑数据分布优化。先考虑一个流行的分布式数据库分类学:

  1. Shared Everything: 区别于后两类,这一类基本不是分布式的。
  2. Shared Disk: 数据库服务器可以横向扩展,他们本身没有存储器,通过SAN或NAS技术连接到后端同样可以横向扩展的统一存储。受限于这层网络连接,数据库服务器的扩展能力非常有限。Oracle RAC等商业分布式数据库属于这类。
  3. Shared Nothing: 区别于Shared Disk,这种架构让数据库服务器和存储落在相同的物理节点上(co-located),使得物理节点之间不share任何信息,这大幅减少了网络IO。MPP DBMS和Hadoop属于这类。
    5

显然,只有Shared Nothing的数据库才需要考虑数据分布,你需要预知怎样把数据分布到不同的物理节点(而不是像Shared Disk那样放在统一存储),会使后续的操作代价更小。例如,在Greenplum中,必须在建表时指定partition key,系统会按照指定的key(哈希)分布数据。如果Join的两张表都按照join key来partition,这个Join就不需要网络IO。如果其中一张表使用了另一组partition key,那么可能要做一次re-partition。
这就是为什么要理解数据分布的原因:它对应用优化和系统优化都是非常重要的。MPP DBMS在数据分布上都有比较深的积累。但是为什么Hadoop这种大数据处理系统没有这类优化?是因为他们需要更强的扩展能力(以及非结构化数据支持,我们不展开这个话题)。
区别于MPP,Hadoop并不是在物理上强制数据和计算在相同节点,如果这么做,系统的横向扩展能力仍然受限。特别是动态扩展能力,考虑正在运行的一个50个节点的Greenplum集群,我们基本无法做到快速地加入例如2个节点还能高效工作。Hadoop在这方面是很在行的,它的解决办法主要是:
1、存储计算分离
2、去中心化的设计支持高效的peer to peer读写(HDFS)
这就是为什么你在Hive中创建一张表时,无须像Greenplum中那样指定partition key,同时Hive在Join的效率低于Greenplum的原因。

数据分布优化的目的
如上文所述,大数据分布式系统在存储系统上通常倾向随机分布,这提升了扩展性,牺牲了性能。但是重新审视这个权衡,在存储系统上随机分布并不意味着我们不能利用数据分布优化查询。分布优化的目的是希望尽可能的利用已经存在的分布,并尽可能满足未来要求的分布。这种优化包括:

1、分区剪枝:利用数据分布特性,我们可以做分区剪枝来减少数据读取。例如,哈希分布对于点查询,范围分布对于区间查询可以应用分区剪枝。
2、消除重分布:如果当前的分布满足后续算法的要求,我们可以消除额外的重分布操作。众所周知,重分布(在Hadoop中叫做shuffle)是分布式算法最主要的消耗。
3、避免数据倾斜:可以使用更好的数据分布算法避免数据倾斜。例如,某些单值重复率很高(end-biased)的数据集,使用范围分布而不是哈希分布可能会有效避免数据倾斜带来的性能影响。

定义
数据分布类型
数据分布类型和对应的意义和范例如下所示:
6
7

实现
在不破坏Volcano优化器语义的前提下,我们把分布特性实现为一种physical property,称作distribution。和其他property一样,它有required property和delivered property成对的属性。例如,对于sorted merge join,它对所有输入会施加一个Partial Ordered的required property,同时自身会deliver一个Partial Ordered property,这使得它的后继操作有机会利用这个property,避免一次重新分布。考虑以下查询:
11

此时Join如果被实现为Sorted Merge Join,它可能会deliver一个Hash[uid]的property,这正好被Aggregate要求,那么这里我们就可以省去一次不必要的重分布操作。
要做到类似的优化效果,我们需要关注下列问题:
1、收集分布特性
2、(局部关系代数编译)选择合适的分布特性
3、(全部代价计算上)规避不合适的分布特性
收集分布特性
产生数据分布有3种途径:
1、用户指定:就像MPP那样,可以在DDL中引入partition key,允许用户指定数据分布。当然区别于MPP,这种分布仅要求在分布式文件系统上的目录结构,并不能关联具体的物理节点。
2、SQL逻辑:SQL逻辑可能产生一次运行时的数据分布。例如distribute by字句声明了一次运行时的数据分布。
3、算法的副作用:每个分布式算法可能产生一次运行时数据分布。例如,sorted merge join可以保证它的输出数据满足按join key的有序和哈希分布的特征。

有若干算法要求一种特殊的数据分布:
1、Aggregate:Sorted Aggregate要求grouping key的Hash分布。
2、Join:Sorted Merge Join和Hash Join都要求输入按照join key的相同Hash分布。
3、Sort:Order by要求sort key上的Range分布,或Singleton分布。
选择合适的分布特性
即使给定了一系列required和delivered distribution property, 确定某个操作的分布仍然不是容易的事情。区别于ordering property(仅有排序列和升降序的属性),distribution property的变化很多,这些变化的原因包括:
1、满足要求的分布有多种选择。例如group by a, b, c这个aggregate,对输入有按a, b, c的Partial Ordered的要求,它对ordering的要求是a, b, c有序,但是满足它的分布可以是Hash(a), Hash(b), Hash(a,b), Hash(a,b,c), RNG(a)等不同的组合。
2、能利用的实现分布有多种选择。例如join a and b on a.id = b.id这个join,如果a服从Hashid, b服从Hashid,对于Sorted Merge Join,它可以选择要求Hashid,或Hashid,甚至任意Hash(id)。
这些复杂度加大了最优计划的搜索空间。事实上,最优计划是相对于关系代数数量的一个NPC问题。为了缩小搜索空间,我们引入了启发式的分支选择算法。在编译一个关系代数时,不仅需要满足后继操作的要求,还要考虑前序操作提供满足的分布的可能性,后者被实现为称作Pulled Up Property的模块。

12

Pulled Up Property猜测并筛选可能的前序delivered property,用于在编译时减少搜索宽度。考虑上图的查询,在Join编译时,因为Sink的需求下推,它被要求提供一个Hashc1。Pulled Up Property则从前序操作猜测可能会提供Hashc1和Hashc1,综合考虑,Join可能会直接要求Hashc1,从而减少了Hashc1和Hashc1这两个分支。

规避不合适的分布特性
数据倾斜(Skew)是指在分布中少量节点被分配了大部分数据,导致整个算法退化为单机操作。低并发(Under Partition)是指分布指定了过少的节点,是的分布式资源不能被有效利用。我们希望能避免这两种情况。
很显然,更好的统计信息会帮助我们规避这两种情况。Skew和Under Partition的情况下,需要对代价估计做相应的惩罚,降低他们被选为最优计划的可能性。我们定义”好”的分布是每个节点处理的数据量在一个预设的范围,低于或高于这个范围都会被施加惩罚。估计这个数据量的依据包括:
1、输入数据记录数(row count)
2、重复度最高的数据(top values)
3、直方图(histogram)

总结
在这篇文章中,我们介绍了数据分布优化的问题和意义,并解释了MaxCompute在数据分布优化上的实践。这一优化效果已经体现在MaxCompute最新的发布中。
从我们的测试来看,这个优化有相当显著的效果。我们对TPC-H进行了适当分区后,整体性能提升在20%的量级。即使没有对表数据分区,对用户完全透明的运行时分区优化也有很好的效果。在我们线上运行的环境中,14%的查询因为这个优化减少了至少一次数据重分布。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云容器服务新建集群优化方案
前言 选择阿里云的容器服务,主要原因是公司主要业务基本都运行在阿里云上。相较自建 kubernetes 集群,容器服务的优势在于部署相对简单,与阿里云 VPC 完美兼容,网络的配置相对简单,而如果使用 kubeadmin 安装部署 kubernetes 集群,除了众所周知的科学上网问题,还有一系列的问题,包括 etcd 、 scheduler 和 controller-manager 的高可用问题等。
1272 0
一次HASH JION过慢优化(2)
原创 转载请注明出处 可以看到进行了笛卡尔集,再HASH JION的时候使用了过多的临时表空间用于存储HASH值,达到了2.6M。而笛卡尔集是test1和test2做的。
664 0
转载:30多条mysql数据库优化方法,千万级数据库记录查询轻松解决
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, Sql 代码 : select id from t where num is null; 可以在 num 上设置默认值 0,确保表中 num 列没有 null 值,然后这样查询: Sql 代码 : select id from t where num=0; 3.应尽量避免在 where 子句中使用!=或操作符,否则将引擎放弃使用索引而进行全表扫描。
822 0
一次HASH JION过慢优化(1)
原创 转载请注明出处 最近我发现生产有一个语句执行比较慢。需要4-5分钟。所以对其进行了优化,优化结果执行只需要不到3秒。语句如下:我发现出问题的部分是select *                  from (select a.
623 0
【云周刊】 第210期:阿里巴巴复杂搜索系统的可靠性优化之路
本期头条 欢迎关注云周刊 阿里巴巴复杂搜索系统的可靠性优化之路 搜索引擎是电商平台成交链路的核心环节,搜索引擎的高可用直接影响成交效率。闲鱼搜索引擎作为闲鱼关键系统,复杂度和系统体量都非常高,再加上闲鱼所有导购场景都依靠搜索赋能,搜索服务的稳定可靠成为了闲鱼大部分业务场景可用能力的衡量标准;如何保障搜索服务的稳定和高可用成为了极大的挑战。
3723 0
MaxCompute客户端(odpscmd)在windows命令行下查询中文乱码问题处理实践
MaxCompute客户端工具是阿里云大数据计算服务MaxCompue产品官方客户端工具,通过客户端工具可以连接MaxCompute项目,完成包括数据管理、数据上下传、作业执行、用户及授权管理等各项操作。
5303 0
云上成本管理最优化实践
随着业务发展,客户在云上管理了大规模的机器,如何做好云资源成本管理,合理利用云资源支持好业务发展,成为企业重点关注的领域,需要数字化管理云上资源成本。
142 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
7758 0
同样是查询语言,它和 SQL 竟然有这么多不同
这篇文章将介绍图数据库 Nebula Graph 的查询语言 nGQL 和 SQL 的区别。
140 0
Sql Server中百万级数据的查询优化
原文:Sql Server中百万级数据的查询优化 万级别的数据真的算不上什么大数据,但是这个档的数据确实考核了普通的查询语句的性能,不同的书写方法有着千差万别的性能,都在这个级别中显现出来了,它不仅考核着你sql语句的性能,也考核着程序员的思想。
1471 0
+关注
云攻略小攻
计算,存储,网络,数据库,企业应用服务,开发者服务统统在这里。
442
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载