技术 | Rubik支持的OLAP Cube降维方法(一)

OLAP Cube可视化设计工具—Transwarp Rubik所介绍,利用Transwarp Rubik设计并实例化OLAP Cube,采用的是空间换区时间的策略来优化OLAP业务执行的。系统将根据业务逻辑,对查询访问的数据进行预计算并缓存计算结果。但是在基于预计算的OLAP应用中,维度爆炸是一个广为诟病的问题。也就是说,为了优化业务执行,OLAP模型占用了系统过多的存储空间。其中很多的维度组合被用于优化的次数寥寥可数,甚至根本不会被访问,所以实际上空间是被浪费的。为了避免制造不必要的维度组合,同时能起到优化业务的作用,提高Cube的产出和代价比,在建立的Cube的时候应该遵循一些减少维度组合的优化策略。


原始Cube引发的空间问题

对于原始的未经任何优化Cube来说,维度表中的任意一个字段或字段表达式即是一个维度。Cube就是所有可能的维度组合的集合,例如维度表中有两个字段A,B,维度组合有四种:{A,B}、{A}、{B}、{},实例化Cube时,系统会根据每种维度组合物化分别出一张表,下图给出了每一种维度组合所对应的SQL示例。

因此一个n维的Cube中,共有2^n个可能的维度组合,将对应产生2^n张物化表。当Cube维度变成n+m时,物化表的个数急剧增加到2^(n+m),呈指数级增长。当维度数量较多时,空间资源将趋于爆炸。

所以在保证解决OLAP业务优化绝大部分需求的前提下,减少维度组合数量,是至关重要的。


Rubik支持的OLAP Cube降维方法

减少维度组合数量要需要遵循一定策略,Rubik支持以下降维优化方式,用户可以结合业务需求和实际业务进行选择,设计合适的OLAP Cube模型。


聚合组(Aggregation Group)

当维度数目比较多时(>10),建议根据查询习惯和业务模式将维度按照使用场景进行分组。

示例:

假设,原Cube的维度数量高达50,其中的维度分为对公业务和对私业务两部分,两部分业务互不相干,那么就可以根据业务信息将该Cube的50个维度分割成20维度+30维度两个子Cube。

优化效果:

物化Cube表的数量从2^(m+n)变为2^m + 2^n,占用的空间以指数级减少。

除了划分聚合组之外,下面还有一些常用的组内维度优化的手段。所以,在完成聚合组拆分后,还可以在组内进行进一步优化。


必备维度(Mandatory Dimension)

必备维度是在OLAP业务中,参与所有业务查询的维度,从预计算SQL角度来说总是会出现在WHERE或GROUP BY里。将某个或者某些维度设置为必备维度后,没有包括必备维度的组合就会被舍弃。

示例:

例如,在数据立方体中,银行客户想统计交易金额相关的业务(如交易金额总量、月平均等),查询时必须指定币种字段,因为相同币种的统计分析结果才有意义。所以,可以把币种字段设为Mandatory,从而将Cube的体积减少一半。

优化效果:

将某个维度指定为Mandatory,将只留下包含必备维度的组合。每指定一个必备维度,Cube表数就减少一半;若设置n个必备维度,物化Cube表的数量将从2^m 减少到2^(m-n)。


联合维度(Joint Dimension)

对于某些维度,可以将它们的组合视为一个维度。

通常适用于如下两种场景:

  • 总是在一起查询的维度:假设表中的name和id字段总在一起作为聚合字段出现,那么这两个维度就可以合并为一个维度{name,id}。该维度组没有各自进行组合的必要(即不可能单独GROUP BY name,或者GROUP BY id),因此可以无损合并。

  • 基数很低的维度:对于基数低且没有明显关系的维度组,可以进行合并,例如将sex,class合并为{sex,class}。这样对 sex单独聚合时,会在“GROUP BY sex,class”的基础上再实时的聚合一次。这种情况会损失一些性能,适合没有高基维且维度数非常多的场景。

优化效果:

假设原有m个维度,其中n个维度组合为联合维度后,组合数由2^m 变为 2^(m-n+1) 。


衍生维度(Derived Dimension)

当维度表中的某一列(例如主键)可以推导出其它列值时,就可以构造衍生维度。称该列为Basic Column,被推导出的列称为Derived Column,

示例:

例如用户维度表中,给定id可以推出其余字段name、sex,所以GROUP BY id,name和GROUP BY id,sex的结果完全等价于GROUP BY id,因此只需一种维度组合{id,name,sex}。

优化效果:

若Basic Column数为1,Derived Column数为m,则设置衍生维度后,相关的组合维度数从2^m减少到1。


层次维度(Hierarchy Dimension)

Hierarchy是一组有层级关系的维度,可用于减少没有业务需求的字段间的聚合。

示例:

例如某维度表中有“省”,“市”,“县”三个字段,在做聚合查询时,通常都是从高层维度往下伸展的,如GROUP BY “省”,“市”,“县”等,而不会单独出现GROUP BY “市”,“县”之类的情况,因此可以抛弃不满足层次关系的组合。

优化效果:

对于有m个维度的Cube,假设其所有维度构成了一个Hierarchy,那么Cube表的数量就会从2^m减少到m。若能保证潜在的查询严格符合预设的层级关系模型,按照模型设置层次维度将不仅可以大幅减少Cube表数量,而且完全不会影响查询效率。


Partial Cube

Partial Cube优化的思路是,当一个维度组合包含两个中基维(基数为1000到10000)或者一个高基维(基数大于100000)时,我们可以认为该组合没有聚合度可言,其预计算结果用于OLAP优化的效果将很差,而且计算该维度组合物化表所消耗的时间和空间都非常大,所以抛弃该组合。


OLAP Cube构建步骤总结

如何选择和使用以上降维手段都是由实际的数据和业务特征决定的,因此在创建OLAP Cube时必须学会分析真实场景,运用以上降维优化技巧,达到OLAP优化的目的。下面结合优化策略,对OLAP Cube的创建步骤进行简单总结。

首先,根据业务范围,将所有维度进行分组(Aggregation Group),将维度列分成n种大类的业务场景,按照实际情况建立多个Cube实例或者Cube模型。

然后,对于每类业务场景进行单独的分析:

是否存在必备维度,是否可以创建层级维度,当层级维度数较多时,即组合数量从2^m减少到m后,m的值依然很大的情况下,可以考虑创建衍生维度,对于数据量较大的表,衍生维度将造成较为严重的性能损失,不过大幅度降低存储压力,需要进行权衡,接着考虑是否可以构成组合维度,最后根据实际的数据特征和聚合情况决定是否采用Partial Cube来进行优化。

按照上述步骤,做到既提高Cube存储空间利用价值,又实现可观的优化效果。

后续文章中我们将介绍具体如何在Rubik中实现这些优化方法。

往期技术文章推荐

TDH中的高效SQL IDE--Waterdrop

Transwarp Pilot: 让BI分析全面自助化

技术 | 近实时的ETL工具--Transwarp Transporter

MBO: SQL优化之基于物化视图的优化

用Slipstream构建复杂事件处理应用

用StreamSQL实现事件驱动的实时计算

技术 | 混合负载下的资源调度神器--Inceptor Scheduler

你应该知道的工作流调度平台——Transwarp Workflow

OLAP Cube可视化设计工具—Transwarp Rubik



回复关键字,获取更多资讯


简介 | 产品 | 技术 | 案例集 | 培训 | 白话大数据

评测 |  投资 | 新手上路 | Holodesk | TED视频

技术支持| 金融 | 电力 | 视频监控 | 运营商 |交通

税务 | 电商 | 智能金融 | 医疗 | 快递|TDH5.0|流式计算 | 九城巡展


相关文章

相关标签/搜索