数据聚集技术在mondrian中的实现

聚集的概念及其作用 

  聚集是指按照维粒度、指标与计算元的不同,依据实际分析需要对底层数据进行记录行压缩、表联接、属性合并等预处理,是对底层的详细数据进行相应的统计的数据加工形式,包括求和、求平均值等。 

  聚集计算的结果是根据用户可能的查询预先计算好的汇总数据。汇总的形式多种多样,可以沿着数据仓库中的多维数据的任何一维或多维进行。如果维分层次,聚集还可以在任何一个层次上进行。维的某种组合对应的聚集数据称为一个方体(Cuboid),给定维集合的所有方体形成的方体格称为该维集合的数据立方(Data Cube)。数据立方的建立就是通过聚集实现的。 

  数据聚集用于提升数据仓库系统进行联机分析处理时的性能,它通过在问题提出之前就准备好答案来缩短查询响应时间,是OLAP技术能够快速响应的基础,主要体现在以下几个方面: 

  (1) 聚集降低了直接访问基础数据对前端应用的影响 

  联机分析处理通常需要的是由细节数据导出的汇总数据,直接在海量基础数据上进行查询统计将极大的影响系统效率。通过聚集预先计算出需要的汇总数据,从而避免对基础数据的直接访问。 

  (2) 聚集减少了对基础数据的重复计算 

  不同的联机分析处理操作可能都需要对同一部分基础数据进行同样的处理。如“2000年第2季度A地区的销售额是对该地区该时间段内所有销售记录的统计汇总,在进行“A地区2000年不同季度销售额对比“A地区不同年份第2季度的销售额对比不同地区2000年第2季度销售额对比等处理时,都需要使用该汇总数据。通过聚集预先计算出该汇总数据,从而避免对相关基础数据的重复计算。 

  (3) 使用聚集可以在一定程度上保证数据一致性 

  一方面,数据仓库中的基础数据是不可实时更新的,由这些相对稳定的基础数据导出的聚集反映的是一段时间内的汇总信息。另一方面,数据仓库中的数据又是时变的,新的数据将被定期的增加。通过聚集可以在一定程度上保证分析过程访问的数据的一致性,避免因直接使用基础数据而导致先后汇总的数据不一致。 

  聚集的存储组织 

  聚集数据通常以多维数据集的形式组织。多维数据集是包含维度和度量值的多维结构,其中维度定义多维数据集的结构,确定度量值的坐标,反映了可以向多维数据集提出的查询;度量值提供了用户感兴趣的数值。 

  2.1 三种聚集存储方式的比较 

  聚集数据按维所指定的坐标存储在多维结构单元中,存储位置依赖于多维数据集的存储方式。包括多维结构(MOLAP)方式和关系型结构(ROLAP)方式,两种方式有各自的优势。 

  (1) MOLAP方式:聚集数据和基础数据的副本一起存储在多维结构中。 

  该方式存储结构简洁、明了,聚集数据预综合较高,可以很大程度的提升查询性能。缺点是适应维数动态变化较差,增加一维,聚集规模迅速增长;适应数据变化较差,数据变化时,聚集重计算量相当大。

  (2) ROLAP方式:聚集数据与基础数据一起保存在关系结构中。

  该方式下聚集数据与基础数据存放在关系表中,适应维数动态变化较好,维数的增加对已有聚集的影响不大;适应数据变化的范围大,聚集数据预综合度灵活,各种粒度的聚集数据可以分开存储。缺点是存储结构和处理过程复杂,处理时间通常也较长。

结合上述两种存储方式的优点,混合型结构(HOLAP)方式将聚集数据存储在多维结构中,将基础数据存储在关系型结构中,但这种方式不适合既需要快速统计分析,有能够快速访问基础数据的应用环境。

  2.2 聚集模式与聚集表

  由于关系型数据库的广泛应用,利用ROLAP实现多维数据组织是最为常用,并且较为成熟的方法。

  在ROLAP中,存储基础数据的关系模式称为基础模式,由存储事实数据的事实表和存储维数据的基本维表构成。存储聚集数据的关系模式称为聚集模式,由聚集表和相关维表(细粒度基本维表和/或粗粒度的上卷维表)构成。聚集模式与基础模式都是典型的星型模式,在结构上基本一致,只是存储数据的粒度不同。

  可以通过修改基本维表,将维的层次信息扩展到其中,从而实现聚集数据和基础数据的集中存放,进而将两种模式合而为一,达到一体化存储、简化数据存储结构的目的。但是这种方法存在一系列问题:

  (1) 增加了查询的复杂度,需要区分基础数据和聚集数据以避免数据重复计算;

  (2) 模糊了列的数据类型,在列中需要存储不同类型的数据;

  (3) 扩大了数据的定义范围,因存储统计数据导致基础数据存储空间的浪费;

  (4) 加大了ETL过程的困难。

  因此,聚集数据通常单独存放在不同的关系表中。

聚集的物化

  聚集的有效计算是多维分析的核心。如前所述,维集合的任意一个组合对应的聚集数据代表了数据立方中的一个方体,一次聚集计算处理可以是单个方体的计算,也可以是整个数据立方的计算。聚集的计算过程就是数据立方的物化过程。

  3.1 全物化方法

  全物化是指对维集合的所有可能组合都进行聚集。最为简单的全物化方法是2N算法,通过计算N维事实表中的元组,依次得到2N个聚集数据并存储到多维数据集中。当数据立方的维数增多,维的层次更趋复杂时,可能的聚集计算量将剧增,导致存储空间爆炸现象的发生。

  为降低聚集计算量,减少存储空间的使用,可以采用多种改进方法,根据参与聚集计算的数据的范围分为单个方体的聚集计算和基于依赖关系的聚集计算两类。

  典型的单方体聚集计算方法是基于数组方式的聚集计算方法,该方法包括四种形式:G-AggregationM-AggregationInfix-AggregationPrefix-Aggregation。单个方体计算方法会进行多次重复的I/O操作,因此计算效率很低。

  并不是所有的聚集都需要从基础数据开始计算,利用方体之间的依赖关系从子方体汇总计算父方体可以加速聚集计算的过程。基于该思想的聚集计算方法包括基于排序(sort- based)和基于哈希(hash-based)的算法:PipeSortPipeHashOverlap。这类方法先估计数据立方的各种计算方式的代价,确定其计算顺序和导出关系,其目的是使数据立方的计算开销最小。

  上述聚集计算方法特别指针以ROLAP形式存储的数据立方,适合于MOLAP的经典聚集计算方法是多路数组聚集方法。它在寻找最优扫描次序时是将所有的扫描次序需要的内存数量都计算出来,然后将需要内存最少的扫描次序作为最优次序,对数据立方进行聚集计算。多路数组聚集的基本原理如下:

  (1) n维数组划分成小的n维块,其中每个块作为一个独立的单元包含有联机分析处理所需要的信息;

  (2) 对数组分块处理后的子方体进行聚集计算,通过优化计算次序,使部分聚集可以同时计算,并避免不必要的重复计算。

3.2 部分物化策略

  尽管通过全物化可以使所有查询以最短的时间做出响应。但是,当数据量非常庞大时,全物化过程消耗的时间及其占用的空间都可能让用户无法忍受,因而不具现实性。其次,简单排列组合产生的多维数据集往往是一个庞大的稀疏矩阵,存在着大量的空聚集数据单元,造成存储空间的巨大浪费。再次,随着数据仓库的定时刷新,聚集数据的同步更新也将耗费大量的系统资源。因此,应该科学的选择物化方案和聚集策略,以平衡聚集计算和维护与OLAP响应时间之间的矛盾。

  部分物化是指在部分维及其相关层次上进行聚集,即从数据立方的所有方体中选择一个子集进行物化。在一般情况下,通常20%的聚集就能够满足80%的查询需要。如何确定该20%的聚集是提高聚集效率的关键。

  聚集的识别可以综合使用以下方法:

  (1) 在设计数据仓库时,站着用户的角度分析数据仓库可能的查询需求。业务上的功能需要往往可以暴露出潜在的聚集需求;

  (2) 数据仓库模式确定后,通过分析主题域确定频繁的聚集;

  (3) 数据仓库投入使用后,可以从已有系统的查询模式中获取,包括报表、日志以及利用其它商业智能工具。

  完成聚集的识别后,需要对其进行评估,以缩小需要物化的范围。评估需要考察的因素包括几个方面:

  (1) 评估数据仓库可用的资源,用于确定可以物化的聚集数量。在模式上聚集表要小于事实表,然而尽管只是少数几个聚集表,其占用的存储空间可能远远超出事实表。这是限制只能物化部分聚集表的因素之一。

  (2) 将聚集与事实表进行比对,用于确定哪些聚集是有效的,能够实际提高查询效率。聚集究竟能够带来多大的性能提升需要进行量化。量化指标一般直接与该聚集汇总的元组数相关,但数据的稀疏性和倾斜性对该指标带来一定的影响。

  除了和事实表进行比较外,聚集指标还需在不同聚集之间进行衡量,以判断哪种聚集形式更优。如聚集A可以分别从BC得到,相对而言,B更具指标意义,则仅需物化B即可。

  (3) 聚集的粒度。粒度是对数据仓库中的数据综合程度高低的一个度量,粒度小,综合程度低,回答查询的种类多,数据量大;粒度大,综合程度高,回答查询的种类少,数据量小。不明确的聚集粒度将带来一系列问题,包括:导致数据仓库细节数据的遗漏;聚集包含了不合适的维度;应该包含的维度没有被包含;不同事实表的维度包含在同一个聚集表中。

  (4) 聚集能够为多少用户所用,以及对不同用户的重要程度。某些少数查询执行频率不高,但为重要决策所使用,尽管对应的聚集综合指标意义不大,但是仍然需要物化。

  随着时间的发展,应用需求的变化可能使得已有的聚集不再经常被使用,或者以前较少使用的聚集开始需要经常性的使用。因此需要能够对聚集进行添加和删除。

聚集导航与优化

  聚集导航的本质是基本SQL语句的转换,即将基本SQL语句通过查询重写重定位到已有的聚集上,利用聚集数据提高查询效率。没有聚集导航,终端用户将不得不直接面对聚集选择问题。严格限制事实表上的聚集数量,可以降低人工选择带来的混乱,但同时也限制了可能的性能提升。通过聚集导航,可以增加事实表上聚集的数量,实现查询的透明性。

  4.1聚集的导航策略

  聚集的标识是实现其导航的前提,复杂的标识将对聚集的管理带来不利的影响。以ROLAP为例,聚集的标识包括聚集的命名和聚集表属性的命名。在命名时需要参考以下原则:

  (1) 事实和维的属性的名称在聚集模式和基础模式中应该保持一致;

  (2) 聚集维表的命名机制应与基础维表的一致,通过表名都能够指示表中记录的含义;

  (3) 聚集事实表的命名比较复杂,简单的根据聚集的粒度或聚集的对象进行命名将导致较长的表名。由于聚集的使用对用户是透明的,聚集的名字可以对用户不可见。提供聚集导航后,只需要由聚集导航过程处理复杂的聚集命名和解释过程。此时可以使用编号等方式对同一事实表上的聚集进行区分。

除了对聚集进行标识外,在设计聚集维表时,还应注意以下问题:

  (1) 除了关键字外,聚集维表必须是基础维表的子集;

  (2) 聚集维表属性的取值必须与基础维表的一致,明确聚集维表的数据是对基础维表数据的汇总;

  (3) 对于基础维表中的每一个属性值的组合,聚集维表中有且仅有一条记录与之对应,从而解决维表数据的加载问题。

  根据用户的查询在数据仓库中的大量聚集中找到对应聚集的过程就是聚集导航。聚集导航的任务有:

  (1) 用最快的速度找到能够回答用户需求的聚集;

  (2) 找到的聚集应该是回答查询问题的最优聚集。

  4.2 聚集的优化

  聚集优化包括两个方面:一是指聚集处理过程和处理技术的优化,如索引的建立与更新、多线程技术、并行处理技术等,其作用是提高系统聚集效率,降低聚集的时间与空间复杂性;二是指聚集策略和聚集导航的优化。前者是相关技术在聚集上的应用,与聚集技术本身关联不大,需要重点考察的是后者。

  聚集策略的优化就是指在聚集的时间复杂性、空间复杂性与查询速度及性能之间取得动态的平衡。当用户的分析查询相对稳定时,通过优化可以找出最优或接近最优的聚集策略;聚集策略并不是一成不变的,还要根据用户需求的变化不断的进行调整以满足用户新的需求。

  构成聚集优化质量目标的质量要素及其质量属性如表4.1和4.2所示。

   在数据仓库的设计开发阶段,如果想获得较好的聚集物化方案,需要分析所有用户和应用的需求,研究实际使用中需要哪些维度、粒度层次的汇总信息,从而确定 所有可能涉及的聚集和估算使用的频度。但在数据仓库创建的初期,进行这种需求分析显然是比较困难或不太现实,且很多情况下可能并不准确,所以采用系统缺省 的聚集物化方案,有时不失为一种

表4.1 维与指标的取舍原则

 

元素

策略

原则条件

 

放弃

长期不使用;不属于主题主键

 

维粒度

放弃

长期不使用;不影响上层的快速聚集生成;不影响其它层的钻取操作

 

增加

高频度钻取到的层次

 

指标

放弃

长期不使用,不属于任何一个复合指标的因子

 

复合指标

放弃

长期不使用

 

增加

高频度计算的新的复合指标

 

 

表4.2 数据聚集优化的质量要素

质量要素

内容(质量属性)

数据对象

维对象(聚集方案、维成员、限制条件、时间)

指标对象(指标名、指标运算、限制条件)

访问日志

操作日期、操作时间、操作类型、维数据对象、特殊维数据对象、指标数据对象、响应时间、用户名称

 

响应敏捷率

数据对象OLAP操作响应时间/(标准响应时间+数据对象OLAP操作响应时间/)

数据查询率

数据对象被查询次数/OLAP操作总次数

数据下钻率

数据对象的下钻次数/OLAP操作总次数

数据归并率

数据对象的归并次数/OLAP操作总次数

指标复合率

指标复合运算次数/OLAP操作总次数

简单易行的方法,而将聚集优化放到系统运行的过程中,基于对系统运行情况的分析之上周期性的实施。具体实施步骤如下:

  •建立初始聚集物化方案。

  •确定并录入与聚集优化的相关参数指标(包括:聚集关键度、应用需求度上限阀值、应用需求度下限阀值、聚集阀值、查询阀值等)。

  •启动/周期性触发聚集监测进程,采集系统运行记录。

  •系统日志分析和用户需求分析。在对系统日志分析的基础上,按照维和粒度层次的取舍原则和应用需求度的判断流程,确定哪些聚集需要物化,哪些可以删除,哪些聚集需要经过进一步判断。

  •建立有向聚集关系表,获取各聚集权重。

  •交替执行物化选择算法和聚集路径的优化算法,在满足用户期望值和系统性能要求的基础上,确定哪些聚集需要物化,确定哪些聚集无需物化,而转为查询关系,实现聚集方案的总代价最小。

  •根据优化算法处理后得到的物化聚集方案集合和最优路径,重新调整数据仓库的聚集。

5 Mondrian中的聚集实现



  5.1 一个星型模式

  开源项目Mondrian是一个用JAVA写成的OLAP引擎。它用MDX语言实现查询,从关系数据库中读取数据,然后经过Java API用多维的方式对结果进行展示;它通过模式Schema实现关系数据模式到多维数据模式的映射。Mondrian不仅能进行数据聚集,建立多维度的分析和查询,同时还提供切片、切块、下钻、上卷和旋转等数据分析功能。

  5.1 聚集表的定义与创建

  在Mondrian中,聚集表依赖于事实表,并且依赖关系定义在多维模式中。给定如图5.1所示的星型模式,其中事实表Sales上典型的一个聚集表agg_1的定义如图5.2所示。



  Mondrian能够根据实际的查询决定是从事实表还是从聚集表中获取数据。

  一个事实表可以有0到多个聚集表,一个聚集表只能对应于一个事实表。聚集表从事实表的1到多个维度对其度量进行汇总。

  每一维上都可以采取两种方式实现聚集:

  (1) 维的“舍弃”,即舍弃星型模式的某一维,聚集表在该维上实现数据的完全汇总;

  (2) 维的“折叠”,即将展开的星型模式的某一维折叠到聚集表中,通过将其部分属性包含进聚集表从而实现在该维上数据的部分汇总。如在上述聚集表agg_1中,维Customer被舍弃掉了,而维Product则被折叠到其中。

 每一个聚集表都以独立关系表的形式被创建,如图5.3所示。没有必要创建所有的聚集表。选择创建哪些聚集表类似与选择哪些列建立索引,取决于应用需求和经验。

sales_fact_1997

product_id

time_id

customer_id

promotion_id

store_id

store_sales

store_cost

unit_sales

CREATE TABLE agg_l_05_sales_fact_1997 (

  product_id INTEGER NOT NULL,

  customer_id INTEGER NOT NULL,

  promotion_id INTEGER NOT NULL,

  store_id INTEGER NOT NULL,

  store_sales DECIMAL(10,4) NOT NULL,

  store_cost DECIMAL(10,4) NOT NULL,

  unit_sales DECIMAL(10,4) NOT NULL,

  fact_count INTEGER NOT NULL);

 

CREATE INDEX i_sls_97_cust_id ON agg_l_05_sales_fact_1997 (customer_id);

CREATE INDEX i_sls_97_prod_id ON agg_l_05_sales_fact_1997 (product_id);

CREATE INDEX i_sls_97_promo_id ON agg_l_05_sales_fact_1997 (promotion_id);

CREATE INDEX i_sls_97_store_id ON agg_l_05_sales_fact_1997 (store_id);

INSERT INTO agg_l_05_sales_fact_1997 (

  product_id,

  customer_id,

  promotion_id,

  store_id,

  store_sales,

  store_cost,

  unit_sales,

  fact_count)

SELECT

  product_id,

  customer_id,

  promotion_id,

  store_id,

  SUM(store_sales) AS store_sales,

  SUM(store_cost) AS store_cost,

  SUM(unit_sales) AS unit_sales,

  COUNT(*) AS fact_count

FROM

  sales_fact_1997

GROUP BY

  product_id,

  customer_id,

promotion_id,

store_id;

 


原文地址:https://www.cnblogs.com/iammatthew/p/1803884.html