做网站需要学js吗,土特产网站模板,jsp企业网站开发前期报告,专业服务网站开发对于分布式数据库来说#xff0c;QUERY的运行效率取决于最慢的那个节点。当数据出现倾斜时#xff0c;某些节点的运算量可能比其他节点大。除了带来运行慢的问题#xff0c;还有其他的问题#xff0c;例如导致OOM#xff0c;或者DISK FULL等问题。如何监控倾斜1、监控数据…对于分布式数据库来说QUERY的运行效率取决于最慢的那个节点。当数据出现倾斜时某些节点的运算量可能比其他节点大。除了带来运行慢的问题还有其他的问题例如导致OOM或者DISK FULL等问题。如何监控倾斜1、监控数据库级别倾斜2、监控表级倾斜出现数据倾斜的原因和解决办法1.分布键选择不正确导致数据存储分布不均。例如选择的字段某些值特别多由于数据是按分布键VALUE的HASH进行分布的导致这些值所在的SEGMENT的数据可能比而其他SEGMENT多很多。分布键的选择详见2.查询导致的数据重分布数据重分布后数据不均。例如group by的字段不是分布键那么运算时就需要重分布数据。解决办法1由于查询带来的数据倾斜的可能性非常大所以Greenplum在内核层面做了优化做法是先在segment本地聚合产生少量记录将聚合结果再次重分布重分布后再次在segment聚合最后将结果发到master节点,有必要的话在master节点调用聚合函数的final func(已经是很少的记录数和运算量)。例子tblaocol表是c1的分布键但是我们group by使用了c398字段因此看看它是怎么做的呢请看执行计划的解释。对于非分布键的分组聚合请求Greenplum采用了多阶段聚合如下第一阶段在SEGMENT本地聚合。(需要扫描所有数据这里不同存储前面的列和后面的列的差别就体现出来了行存储的deform开销,在对后面的列进行统计时性能影响很明显。)第二阶段根据分组字段将结果数据重分布。(重分布需要用到的字段此时结果很小。)第三阶段再次在SEGMENT本地聚合。(需要对重分布后的数据进行聚合。)第四阶段返回结果给master有必要的话master节点调用聚合函数的final func(已经是很少的记录数和运算量)。3.内核只能解决一部分查询引入的数据重分布倾斜问题还有一部分问题内核没法解决。例如窗口查询。使用窗口函数时Greenplum需要先按窗口中的分组对数据进行重分布这一次重分布就可能导致严重的倾斜。实际上内核层优化才是最好的解决办法例如以上窗口函数由于我们只需要取c2分组中c3最小的一条记录。因此也可以在每个节点先取得一条再重分布再算。不通过修改内核还有什么方法呢3.1 Mapreduce任务就很好解决Greenplum的mapreduce接口调用方法如下3.2 通过写PL函数也能解决。例如小结数据倾斜的原因可能是数据存储的倾斜QUERY执行过程中数据重分布的倾斜。数据倾斜可能引入以下后果计算短板oomdisk full数据倾斜的解决办法如果是存储的倾斜通过调整更加均匀的分布键来解决。(也可以选择使用随机分布或者使用多列作为分布键)。如果是QUERY造成的倾斜Greenplum内核对group by已经做了优化即使分组字段不是分布键通过多阶段聚合可以消除影响。如果是窗口函数QUERY造成的倾斜目前内核没有对这部分优化首先会对窗口函数的分组字段所有数据进行重分布如果这个分组字段数据有严重倾斜那么会造成重分布后的某些节点数据量过大。解决办法有mapreduce或pl函数。参考《Greenplum 内存与负载管理最佳实践》《Greenplum 最佳实践 - 数据分布黄金法则 - 分布列与分区的选择》
