papi酱|关于OLTP 和OLAP 干货知识分享( 三 )


这个CUBE本身的描述是通过一个或者一组XML文件来组成的 , 把里面所有可能用到的SQL在XML文件里面组织起来 。 真正处理这个CUBE的时候 , 实际上跑的是这些SQL语句 , 在关系型数据库中比如数据仓库中把数据取出来进行存储 。 所以CUBE的空间有时比数据仓库还要大 , 各种数据的组合都考虑到了 。

当然 , 实际开发中并不会是所有的维度、所有的属性、所有的指标都有组合分析的必要 , 因此还可以提前做一些配置 , 把哪些认为可能组合分析的维度、指标关联上就可以了 。
在CUBE里面就可以很灵活的做各种透视分析 , 数据都是秒出的 。 但是有一些非直接通过维度和指标组合就可以出来的数据结果就需要通过查询的方式把数据给查询出来 , 这个时候就要用到MDX语句 。 在关系型数据库上的数据操作我们通过SQL语句去搞定 , 在多维分析数据库CUBE上的数据操作就要使用MDX的语句去搞定 。 从代码量上比 , MDX比SQL要少很多 。 比如分析去年在TOP 10消费的客户今年不在的客户有哪些 , MDX可能两句话就搞定了 , 但是SQL就需要写一堆 。
但是从便利性上来说 , MDX语法更加复杂 , 三个月不写基本上就可以忘记差不多了 , 因为CUBE它是一个多维空间 , 不像关系型数据库是一个二维的、行列交叉一眼就能看明白 。 学习CUBE还是需要有一定的想象力空间 , 跟关系型数据库取数的逻辑思考方式完全不一样 。
CUBE在一些海量数据 , 特别是大维度表 , 比如百万级别的维度、千万级的维度这种场景下分析优势还是比较明显的 。
但是现在也有很多MPP数据库、列式数据库 , 再结合对数据仓库建模的优化 , 也可以解决一部分场景下的分析性能问题 。 现在OLAP的引擎也已经很多了 , 比如ClickHouse、Impala、Doris、Kylin等等 。

OLAP CUBE的数据来源一般是来自规范的数据仓库 , 最好是基于Kimball维度建模的数据仓库 , 本身就是标准的维度和事实 , CUBE处理起来就更加的简单方便 。 但是在ETL调度的时候 , 周期就会拉的比较长 , 因为要先处理数据仓库的数据 , 再才能处理OLAP CUBE里面的数据 。
【papi酱|关于OLTP 和OLAP 干货知识分享】OLAP里面还有一些分类比如MOLAP、HOLAP、ROLAP , 这些查查资料基本上就看明白 , 大概理解了就可以了 。