粒度的设计

 

2007-10-26 15:09 朱德利 电子工业出版社

《SQL Server 2005数据挖掘与商业智能完全解决方案》第3章讲的是BI分析的基石：结构良好的数据仓库设计，本小节说的是粒度的设计。

 

3.5.3  粒度的设计

在数据仓库中的数据分为4个级别：早期细节级、当前细节级、轻度综合级和高度综合级。如图3-36所示，源数据经过综合 后，首先进入当前细节级，并根据具体需要进行进一步综合，从而进入轻度综合级乃至高度综合级，老化的数据将进入早期细节级。从中可以看出，数据仓库中存在 着不同的综合级别，这就是 “粒度”的直观表现。

      错误！

 

图3-36  数据仓库中的数据细节级别

粒度模型是数据仓库设计中需要解决的十分重要的问题之一。所谓粒度是指数据仓库中数据单元的详细程度和级别。数据越详细，粒度就越小，级别也就越低；数据综合度越高，粒度就越大，级别也就越高。

1．粒度对数据分析的影响

1）影响逻辑结构的设计

先举一个粒度设计的例子，Adventure Works Cycles公司的管理者想按照国家、区域、分区域和分区域内的销售员这样的层次关系来查看公司的销售情况，按照此需求可以得到如图3-37所示的设计结果。它是通过将地理层次国家、区域和分区域嵌入到销售员维度得到的。

 

图3-37  细化到销售员层次的设计结果

如果公司的决策者认为不需要了解具体到某个销售人员的情况，而只需要了解各个地理区域的销售情况，则没有必要把销售员维作为一个维度，把地域相关的表综合成为地理维度就可以了，设计结构如图3-38所示。

由以上实例可知，对事实粒度需求的不同，会直接导致数据仓库逻辑设计的差异。
 
错误！

 

图3-38  细化到分区域层次的设计结果

2）影响数据的存储

粒度对数据仓库最直接的影响就是存储容量。如图3-39所示的例子，按照每“月”统计的客户购买数据和按照每次消费记载的客户购买数据，两者的数据量相差极大。不妨假定每个字段为8个字节，每个客户一天有5次消费，则1个客户1个月的消费细节数据的数据量为8×6×30×5＝7200字节，而1个客户1个月的消费汇总数据的数据量为8×4＝32字节。

 错误！

 

图3-39  不同粒度的储存容量示例

3）影响分析效果

不同的粒度设计对应不同的分析需求，若分析需求和粒度设计不匹配，则会直接影响分析效果。

因为数据的综合使得细节信息丢失，所以若分析需求的粒度小于设计的粒度，则需求不可能得到满足；反之，若分析需求的粒度大于设计的粒度，则查询会在更小的粒度上进行统计运算后才能回答，这将增加用户的等待时间。

例如在图3-40中，要回答“张某在2007年1月29号是否在北京买了一辆山地车”这样非常细致的问题，细节数据非常合适，而综合数据不可能回答。如果要回答“王某在2006年1月到2006年12月自行车配件的总消费是多少”这样综合程度较高的问题时，使用综合数据则可以迅速地回答这个问题。如图3-40综合数据和细节数据的用途和查询代价所示，很好地说明了这一点。

 

图3-40  综合数据和细节数据的用途和查询代价

由于数据仓库的主要作用是决策分析，因而大多数查询都基于一定程度的综合数据之上，而只有少数查询涉及到细节。因此在数据仓库中，设计多重粒度是必不可少的。下面具体讲解粒度的设计问题。

2．粒度的设计技巧

由以上的分析可知，数据仓库的性能和存储空间是一对矛盾。如果粒度设计得很小，则事实表将不得不记录所有的细节，储存数据所需要的空间将会急剧的膨胀；若设计的粒度很大，虽然由于事实表体积大而带来的诸多问题能够得到一定程度的缓解，但决策者不能观察细节数据。粒度的设计成了事实表设计中的重要一环。

1）设计步骤

（1）粗略估算

确定合适的粒度级的起点，可以粗略估算数据仓库中将来的数据行数和所需的直接存取存储空间，粗略估算可以按照以下步骤完成。

① 确定数据仓库中将要创建的所有表，然后估计每张表中行的大小（确切大小可能难以知道，估计一个下界和一个上界就可以了）。

② 估计一年内表中的最少行数和最多行数。这是设计者所要解决的最大问题。比方说一个顾客表，就应该估计在一定的商业环境和该公司的商业计划影响下的当前的顾客数；如果当前没有业务，就估计为总的市场业务量乘以市场份额；如果市场份额不可知的话，就用竞争对手的业务量来估计。总之，要从一方或多方收集顾客的合理估算信息开始。如果数据仓库是用来存放业务活动的话，就要估计顾客数量，以及估计每个时间单位内业务活动量。同样，可用相同的方法分析当前的业务量、竞争对手的业务量和经济学家的预测报告，等等。

一旦估计完一年内数据仓库中数据单位的数量（用上下限推测的方法），就用同样的方法对5年内的数据进行估计。粗略数据估计完后，就要计算一下索引数据所占的空间。对每张表（对表中的每个键码）确定键码的长度和原始表中每条数据是否存在键码。

③ 将各表中行数可能的最大值和最小值分别乘以数据的最大长度和最小长度。另外，还要将索引项的数目与键码的长度的乘积累加到总的数据量中去。

（2）确定双重或单一的粒度

一旦估计完成后，下一步就要将数据仓库环境中总的行数和表3-8中所示的表格进行比较。根据数据仓库环境中将具有的总的行数的大小，设计和开发必须采取不同的方法。以1年期为例，如果总的行数小于10 000行，那么任何的设计和实现实际上都是可以的。如果1年期总行数是100 000行或更少，那么设计时就需小心谨慎。如果在头一年内总行数超过1 000 000行，那么就要请求采取双重粒度级。如果在数据仓库环境中总行数超过10 000 000行的话，必须强制采取双重粒度级，并且在设计和实现中应该小心谨慎。对于5年期数据，行的总数大致依据数量级改变，参见表3-8。

表3-8  存储空间与粒度设计层次的考虑

数据量（行数）		粒度划分策略	数据量（行数）	粒度划分策略
10 000 000	双重粒度并仔细设计	20 000 000	双重粒度并仔细设计
1 000 000	双重粒度	10 000 000	双重粒度
100 000	仔细设计	1 000 000	仔细设计
10 000	不考虑	100 000	不考虑

（3）确定粒度的级别

在数据仓库中确定粒度的级别时，需要考虑这样一些因素：要接受的分析类型、可接受的数据最低粒度和能存储的数据量。

计划在数据仓库中进行的分析类型将直接影响到数据仓库的粒度划分。将粒度的层次定义得越高，就越不能在该仓库中进行更细致的分析。例如，将粒度的层次定义为月份时，就不可能利用数据仓库进行按日汇总的信息分析。

数据仓库通常在同一模式中使用多重粒度。数据仓库中，可以有今年创建的数据粒度和以前创建的数据粒度。这是以数据仓库中所需的最低粒度级别为基础设置的。例如，可以用低粒度数据保存近期的财务数据和汇总数据，对时间较远的财务数据只保留粒度较大的汇总数据。这样既可以对财务近况进行细节分析，又可以利用汇总数据对财务趋势进行分析，这里的数据粒度划分策略就需要采用多重数据粒度。

定义数据仓库粒度的另外一个要素是数据仓库可以使用多种存储介质的空间量。如果存储资源有一定的限制，就只能采用较高粒度的数据粒度划分策略。这种粒度划分策略必须依据用户对数据需求的了解和信息占用数据仓库空间的大小来确定。

选择一个合适的粒度是数据仓库设计过程中所要解决的一个复杂的问题，因为粒度的确定实质上是业务决策分析、硬件、软件和数据仓库使用方法的一个折中。在确定数据仓库的粒度时，可以采用多种方法来达到既能满足用户决策分析的需要，又能减少数据仓库的数据量。如果主题分析的时间范围较小，可以保持较少时间的细节数据。例如，在分析销售趋势的主题中，分析人员只利用一年的数据进行比较，那么保存销售主题的数据只需要15个月的就足够解决问题了，不必保存大量的数据和时间过长的数据。

还有一种可以大幅降低数据仓库容量的方法．就是只采用概括数据。这样处理后，确实可以降低数据仓库的存储空间，但是有可能达不到用户管理决策分析中对数据粒度的要求。因此，数据粒度的划分策略一定要保证数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的—个准则。

2）设计实例

下面以类似Adventure Works Cycles公司的生产部门数据仓库设计为例，如图3-41所示。由于对不同的生产业务查询需求的差异，这里采用多重粒度来设计。左边是操作型数据，记录的是完成若干给定部件的生产线运转情况，每一天都会积累许多记录，是生产业务的详细数据，最近30天的活动数据都存储在操作型的联机环境中。

操作型数据的右边是轻度汇总级的数据，轻度汇总级包括两个表，一个汇总某一部件在3个月中的生产情况，另一个汇总部件的组装情况，汇总周期为1年。真实档案级的数据包括每个生产活动的详细记录。
错误！

 

图3-41  生产环境的多重粒度

3）设计原则

粒度在数据仓库生命周期中是重要的考虑因素。它由业务问题所驱动，受技术的制约。如果粒度太大，就会丢失个别细节，就要花更多的处理时间来解开聚 合；而若粒度太小，就会由于一叶障目而不见森林，许多宝贵的处理时间都浪费在建立聚合上。因此粒度设计主要是权衡粒度级别，对于业务量大，分析要求比较高 的情况下，最佳解决办法则是采用多重粒度的形式。

而针对具体的某个事实的粒度而言，应当采用“最小粒度原则”，即将量度的粒度设置到最小。

假设目前的数据最小记录到秒，即数据库中记录了每秒的交易额。那么，如果可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，就可以在 ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”；反过来，如果不能确认将来的分析需求在时间上是否需要精确到秒，那么，就需要 遵循“最小粒度原则”，精确到“秒”以满足查询的可能需求