一、Data WareHousing和OLAP的区别

DW是一套数据处理流程和数据结构,其目的是将一个公司的各种数据整理存储。OLTP(online transaction processing)数据模型用于记录公司的业务流水,除了查询数据,还涉及到数据的新增和更新,并且要保证数据的事务性,即Transaction。而DW更多是应对大数据的查询和报表计算,不会涉及事务和更新等场景。

OLAP是基于DW中的海量数据做分析,挖掘出数据中隐藏的信息从而指导商业决策

二、什么是Star schema

2.1 定义

将原始OLTP中的业务表,按照一定的业务逻辑组织成事实表(Fact Table)和维度表(Dimension Table)两种类型的表。且一张事实表,往往关联多张维度表,从而形成一个星形,故而将这种数据结构设计叫做Star schema.

事实表一条记录往往定义了一次业务事件。其中存储这次业务事件对应各维度id和业务指标。
维度表存放了维度的详细信息

以下图来举例

1537276979566

事实表存放了某一时间点,某个商店(store)销售了什么商品,以及销售了多少个的信息。而围绕它周围的是三张维度表,时间维度表详细记录了某个具体时间其对应一周的第几天、对应哪个季度、哪年等信息。商店维度记录了每个具体商店的编号,所属国家省份等信息。产品维度表记录了产品的名称、品牌、分类等信息。

有些维度表,可能过于复杂,还需要进一步拆分成更细的维度表。这样构建起来的schema更为复杂,叫做雪花型(
Snowflake schema)。形状如下:
1537277682586

2.2 作用

星形模型的schema设计,虽然不符合OLTP数据结构设计范式。但其方便了海量数据的查询和统计。

三、什么是OLAP Cube

想要对传统OLTP数据库做数据分析,在数据量变大时,往往耗时严重,一张报表的计算长达数天都是不什么新鲜事。且基于OLTP做报表计算,还会拖慢OLTP本身的业务处理。所以预计算的OLAP Cube就应运而生,只要建模合适,这样的立方可以快速高效的进行报表计算。

OLAP Cube是为方便海量数据分析而设计的数据结构。它由多个维度和指标组成。比如:

1537093038262
上图的立方体的三个坐标方向中,有两个业务维度和一个指标维度

  • 分类维度(Category Dimension) 类别有confections、condiments等
  • 时间维度(Time Dimension) 记录了2013年各月份
  • 指标维度(Measures) 则是各指标

以上三个维度每个单位交叉的表格,即为具体的指标值。比如最左下角的数值22表示了,四月份,confections的库存数(In Stock)。

有了这个数据立方,我们可以进行一系列的操作,就像使用真正的立方一样,来求取各种报表数据。

3.1 切片(slice)

想象用一把刀,将立方底部四分之一出,水平切割。切出一片只含四月份(april)的各产品类型的各种指标。切出来的效果
1537280327319

3.2 切块(dice)

假设我们从左到右五分之二处,沿垂直方向切割。切出了所有分类在2013年所有月份的库存(in stock) 和订单(on order)数量。
1537362791563
可以看到切片和切块的区别在于,块中不止一片

3.3 向下钻取(Drill Down)

有可能我关注的不是每个月的指标,而是想看每天的指标,这个时候对某一月向下查看明细,便叫做钻取。

3.4 向上钻取(Drill Up)

而对某个维度的向上统计其父级别的指标,则叫做向上钻取,比如按年维度来统计指标

3.5 透视表(pivot table)

数据cube,可能多个维度,而从数据cube中只切分两个维度的形成的数据表,叫做透视表,透视表可以方便的进行一系列的汇总操作。
例如普通的表:
1537093531738

pivot table则为:
1537093555550

四、OLAP Cube数据库

OLAP Cube的可以直接基于Star schema 创建,也可以基于原始OLTP数据来创建。由于OLAP Cube的多维度特性。普通的关系型数据库无法处理,所以需要专门的数据库产品进行存储使用。这里有各种商业产品,也有许多开源产品。比如Apach kylin, Druid 等。

普通的关系数据表,其查询语句是SQL,OLAP Cube也有其专有的查询语法,叫做MDX,当然很多OLAP产品提供了更友好的支持,不需要用户去直接写MDX