维度建模读书笔记
看Kimball的书,记录几点笔记：
>SCD FWD from Jeromy's blog
在数据仓库系统中，维度属性的变化是不可避免的，通常我们会用缓慢变化维的三类处理策略来解决这个问题。也就是
类型一，覆盖原属性。
类型二，添加新的维度行。
类型三，添加新的维度列。
当维度的属性发生变化时，客户除了要求能用当前值对历史事实信息进行分析外，经常会要求能以历史上的属性分类信息对事实进行分析。随着大家对商业智能的了解和期望程度，这种分析需求变得越来越多。二十年前（Kimball的二十年前），大家对用当前属性分析历史事实数据就能很满意了，但是现在我们需要用类型二的缓慢变化维策略对维度表的历史信息进行保存，以便提供对历史情况的分析。
在KDT#15中，我们讨论了组合使用缓慢变化维策略的方法。组合使用缓慢变化维的策略虽然实现起来麻烦一些，但是能提供较灵活的分析方式。
从物理上来说，组合使用缓慢变化维的策略是在一张维度表中增加一个字段，与原有字段一起分别保留历史信息和当前信息。我们还有一种类似的方案可以选择，就是将所有最新的属性建立一张支架维度表（outrigger）。该支架维度表中只保留维度的最新信息，用自然键做主键，不使用代理键。当维度的属性发生变化时，直接更新这个维度表中的数据。原来的维度表保留维度的历史信息，为了方便使用，可以在两个表上建立视图。当然，当性能很差时，这种方案是不可选的。
Kimball居然很关心市场篮子分析，如果没有挖掘工具，他提供了用SQL做关联规则的简化办法：先关联抽象级别高的门类（数据量小，比如服饰+食品+电器3个门类），全组合得到6个组合，选择其中销售金额，数量，交易量较高的那些，然后把组合前半部分细化到子类，看和哪些后半部分的大门类关联多，然后把所选的后半部分大门类们细化到子类，再用门槛过滤。
然后把结果存入一个事实表！
Kimball 认为从下往上，按BUS规范即可。4步建dimension模:1.根据业务流程，而非部门边界来确定：保证跨部门的一致性
2.确定fact的粒度。3对事实表每列选择合适的dimension.
4.根据“我们想测量什么？”来确定事实，多数是数值变量。
通常来说，事实表应该包含最细的粒度；促销应该是一个维度。
dimension表一定用代理键作为主键，并用于Join事实表。这是解决缓慢变化维的办法（博主按：按实际应用来说，代理键可能要避免，但是可以用自增id来实现。
设计维度表促销几点考量
：是否导致促销前，后的销量下降（购买转移）（time shifting)；是否导致同类商品下降（cannibalization);是否带动了促销后的增长（促销后市场份额）
果说数据量大，效率差的话应该属于数据仓库调优问题。
一般调优的话，可以从几个方面进行处理。
第一个是从硬件、操作系统、网络等相关设备。
第二个是从数据库角度，如建立索引，建立聚集等。
第三个是从建模的角度。
第四个是从应用程序的角度。
下面我简单的谈谈我的理解，希望能对您有点帮助。
如果是单条查询效率差的话，多在索引上找找问题吧。
如果是在多维分析时效率差的话，可以考虑下面几条。
1.使用星型模型，不使用雪花模型
只建立一个IP维度表或者地区维度表，IP、国家、地区等的中文描述都建立在这个表中，不要把国家、地区等的描述再规范化到其他的表中。
2.使用代理键
维度表使用代理键时连接性能可以好很多。
3.建立聚集表或者使用多维数据库
如果做OLAP分析的话，聚集表或者多维数据库对性能的提升能起到非常大的作用。
转：探求ETL本质之三（转换）
ETL探求之一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？
一、宏观输入输出
从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：
1、大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。
2、大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。
3、站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。
>SCD FWD from Jeromy's blog
在数据仓库系统中，维度属性的变化是不可避免的，通常我们会用缓慢变化维的三类处理策略来解决这个问题。也就是
类型一，覆盖原属性。
类型二，添加新的维度行。
类型三，添加新的维度列。
当维度的属性发生变化时，客户除了要求能用当前值对历史事实信息进行分析外，经常会要求能以历史上的属性分类信息对事实进行分析。随着大家对商业智能的了解和期望程度，这种分析需求变得越来越多。二十年前（Kimball的二十年前），大家对用当前属性分析历史事实数据就能很满意了，但是现在我们需要用类型二的缓慢变化维策略对维度表的历史信息进行保存，以便提供对历史情况的分析。
在KDT#15中，我们讨论了组合使用缓慢变化维策略的方法。组合使用缓慢变化维的策略虽然实现起来麻烦一些，但是能提供较灵活的分析方式。
从物理上来说，组合使用缓慢变化维的策略是在一张维度表中增加一个字段，与原有字段一起分别保留历史信息和当前信息。我们还有一种类似的方案可以选择，就是将所有最新的属性建立一张支架维度表（outrigger）。该支架维度表中只保留维度的最新信息，用自然键做主键，不使用代理键。当维度的属性发生变化时，直接更新这个维度表中的数据。原来的维度表保留维度的历史信息，为了方便使用，可以在两个表上建立视图。当然，当性能很差时，这种方案是不可选的。
Kimball居然很关心市场篮子分析，如果没有挖掘工具，他提供了用SQL做关联规则的简化办法：先关联抽象级别高的门类（数据量小，比如服饰+食品+电器3个门类），全组合得到6个组合，选择其中销售金额，数量，交易量较高的那些，然后把组合前半部分细化到子类，看和哪些后半部分的大门类关联多，然后把所选的后半部分大门类们细化到子类，再用门槛过滤。
然后把结果存入一个事实表！
Kimball 认为从下往上，按BUS规范即可。4步建dimension模:1.根据业务流程，而非部门边界来确定：保证跨部门的一致性
2.确定fact的粒度。3对事实表每列选择合适的dimension.
4.根据“我们想测量什么？”来确定事实，多数是数值变量。
通常来说，事实表应该包含最细的粒度；促销应该是一个维度。
dimension表一定用代理键作为主键，并用于Join事实表。这是解决缓慢变化维的办法（博主按：按实际应用来说，代理键可能要避免，但是可以用自增id来实现。
设计维度表促销几点考量
：是否导致促销前，后的销量下降（购买转移）（time shifting)；是否导致同类商品下降（cannibalization);是否带动了促销后的增长（促销后市场份额）
果说数据量大，效率差的话应该属于数据仓库调优问题。
一般调优的话，可以从几个方面进行处理。
第一个是从硬件、操作系统、网络等相关设备。
第二个是从数据库角度，如建立索引，建立聚集等。
第三个是从建模的角度。
第四个是从应用程序的角度。
下面我简单的谈谈我的理解，希望能对您有点帮助。
如果是单条查询效率差的话，多在索引上找找问题吧。
如果是在多维分析时效率差的话，可以考虑下面几条。
1.使用星型模型，不使用雪花模型
只建立一个IP维度表或者地区维度表，IP、国家、地区等的中文描述都建立在这个表中，不要把国家、地区等的描述再规范化到其他的表中。
2.使用代理键
维度表使用代理键时连接性能可以好很多。
3.建立聚集表或者使用多维数据库
如果做OLAP分析的话，聚集表或者多维数据库对性能的提升能起到非常大的作用。
转：探求ETL本质之三（转换）
ETL探求之一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？
一、宏观输入输出
从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：
1、大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。
2、大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。
3、站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。
posted by hunter at 9:46 AM
0 Comments:
Post a Comment
<< Home