Rubik支持的OLAP Cube降维方法（二）

Original 2017-08-25 Coda6 大数据开放实验室

在上周文章Rubik支持的OLAP Cube降维方法（一）中，我们介绍了Rubik支持的几种Cube降维策略，一方面降低数据膨胀率，缓解存储压力，避免空间爆炸，另一方面缩减build Cube消耗的时间，从而既保证Cube预计算的实现，又能够减少计算和存储成本。本节将进一步介绍如何通过在Rubik上的操作，实现这些优化。

优化策略回顾

上一篇文章主要介绍了如下Cube降维策略。

聚合组：根据查询习惯和业务模式将维度按照使用场景进行分组。
必备维度：在OLAP业务中，将参与所有业务查询的字段设为必备维度。
联合维度：总是在一起查询的字段，或者基数很低的多个字段，可以合并为一个维度。
衍生维度：当维度表中的某一列，可以推导出其它列值时，就可以构造衍生维度。
层次维度：一组有层级关系的维度。
Partial Cube：指当因为个体基数很大，没有聚合度可言，可以抛弃这种字段组合的策略。

使用的表

本文将通过一则实例来对Rubik中的以上Cube优化策略进行演示。将用到以下六张表，包括一张事实表，五张维度表：

trade_fact：事实表，记录各种销售数据。
buyers_dim：维度表，记录买家信息，包括姓名，身份证号，性别，年龄，所在位置。
time_dim：维度表，记录时间信息，包括年，月，日三个字段。
area_dim：维度表，记录地理信息，包括国家，省份，城市。
currency_dim：维度表，记录货币类型，以及交易发生时的货币汇率。
suppliers_dim：维度表，记录供应商信息，包括供应商名称以及所有者姓名。

这几张表的关联关系如下图所示：

需求分析

分析师目前需要对销售和供应商的情况进行分析，具体有如下需求。

销售情况分析

分析不同地区的销售情况。
从性别、年龄、地域的角度出发分析不同类型消费的消费情况。

供应商情况分析

分析总体供应量最大的供应商。
分析每个供应商在不同时间的供应情况。

Cube模型设计

上述需求将业务需求分为两部分：一是以购买方为分析的主体，另一个是以供应方为分析主体。因此我们可以根据聚合组策略将该业务需求拆分为两个Cube模型，可以暂且将他们分别命名为buyers_cube以及suppliers_cube。

接下来对每块Cube内部的维度关系进一步分析。

首先来看buyers_cube。
根据对消费者的业务分析需求，buyers_cube内部需要涉及到事实表trade_fact，维度表buyers_dim、area_dim、currency_dim。其中buyers_dim、area_dim共同构建雪花模型的维度，currency_dim构建星型模型维度。
消费者信息包含三部分，id_no、name、gender、age，它们之间存在这样的衍生关系：给定id_no可推出name、gender、age，因此可采用衍生维度策略。
地域信息由area_dim中的country、province、city三个字段提供，三者存在层次关系，即必定是以从上至下的顺序聚合的：
GROUP BY country,province,city;
GROUP BY country,province;
GROUP BY country;
符合层次维度的定义。
此外，由于此次分析围绕交易额进行，而且必须指定交易货币类型（否则分析结果没有意义），因此currency_dim中的currency（货币类型）字段设计为必备维度。
接下来看suppliers_cube。
根据对供应商的业务分析需求，suppliers_cube内部涉及事实表trade_fact，维度表suppliers_dim、time_dim，皆以星型模型构建维度。
时间表由三个字段提供信息：year、month、day，存在year->month->day的层次关系，因此可以构建层次维度。
suppliers_dim记录供应商信息，其中的name和owner字段在每次查询时都会共同出现，所以采用联合维度可以实现优化。

用Rubik实现Cube设计模型

根据业务需求完成Cube设计后，可以在Rubik中着手Cube模型实现。

构造buyers_cube

首先创建维度cube_buyers_dim，并根据设计在其中构造衍生维度和层次维度。

衍生维度的创建
创建维度cube_buyers_dim，并在该维度中将id_no、name、gender、age设置于同一级别buyers-level下，分别作为该级别的不同属性，并将id_no设置为基列，即可实现衍生为维度。
由于该维度不涉及层次维度的优化，因此cube_buyers_dim维度的buyers-hierarchy层次中只包含一个级别buyers-level。
层次维度的创建
层次维度的优化策略通过对area_dim中的字段创建层次实现。首先创建三个级别，这三个级别分别包含country、province、city属性。
随后在创建层次area-hierarchy时，将country-level、province-level、city-level按照从上至下的顺序添加在层次的级别列表中。注意，必须要保证顺序正确，否则不具有优化作用。
必备维度的创建
必备维度在创建实例时设置。所以，首先请完成星型模型维度cube_currency_dim，该维度包含一个单级别的层次，层次中包含属性currency。然后创建buyers_cube，将事实表同维度相互关联。完成设计并保存，接着进行实例化。在设置实例化过程的层次选择步骤中选中“自定义组合策略”，在必备级别一栏中添加currency-level。
该设置模块中还提供了对“共生级别”和“互斥级别”的设置，共生级别用于在级别的粒度上进行联合，可以帮助实现跨维度的字段组合，互斥级别可以起到Partial Cube的左右，将基数大聚合度低的字段设置为互斥可以节省预计算Cube的计算和空间资源。

构造suppliers_cube

层次维度的创建
suppliers_cube涉及层次维度和联合维度的创建。层次维度的创建方法可以参考cube_buyers_dim中area-hierarchy的创建方式，实现从year->month->day的层次，具体过程不再赘述。
联合维度的创建
联合维度的创建方法是将需要联合的字段作为属性创建在同一级别中，不同于衍生维度的创建，设置联合维度时不需要设置基列，这是建立联合维度(name,owner)时的级别设置：

优化效果

Rubik中实现上述Cube的构造与实例化后，一些SQL的执行，可以直接从示例化后的预计算结果读取所需内容，或者进行一定的上卷处理，大多数查询速度会得到数量级的提升。

分析1：获取每个用户的消费总量情况

SELECT id_no, name,currency SUM(value) FROM buyers_dim a JOIN trade_fact b ON a.buyer_id = b.buyer_id GROUP BY id_no, name,currency;

该语句将从字段组合(id_no, currency)中获取聚合结果，并从衍生维度中的Basic Column（id_no）映射得到name。

分析2：分析不同区域的用户消费情况

SELECT country, province, city, currency, SUM(value) FROM buyers_dim a JOIN area_dim c ON a.area_id = b.area_id JOIN trade_fact b ON a.buyer_id = b.buyer_id GROUP BY country, province, city,currency;

SELECT country, province, currency, SUM(value) FROM buyers_dim a JOIN area_dim c ON a.area_id = b.area_id JOIN trade_fact b ON a.buyer_id = b.buyer_id GROUP BY country, province, currency;

这两条语句将分别从字段组合(country, province,city,currency)和(country, province,currency)中获取聚合结果。

分析3：分析供应商对于销售额的贡献随着时间（以月为单位）的变化情况

SELECT name,owner,year,month, currency, SUM(value) FROM suppliers_dim a JOIN trade_fact b ON a.supplier_id = b.supplier_id GROUP BY name,owner,year,month, currency;

该语句将从字段组合(name,owner,year,month,currency)中获取聚合结果。

优化操作总结

本文介绍了如何利用Rubik界面上提供的操作实现Cube的降维优化，下面对各种优化策略与Rubik操作之间的对应关系做以总结。