最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

数据仓库建设--OLAP和数据立方体概念

[复制链接]
发表于 2019-8-19 17:33:46 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
一、OALP概述
    数据立方体,他是一种用于OLAP以及OLAP操作(如上卷、下钻、切片和切块)的多维数据模型。数据立方体存储多为聚集信息。每个单元存放一个聚集值,对应于多维空间的一个数据点。每个属性都可能存在概念分层,允许在多个抽象层进行数据分析。
    在最低抽象层创建的立方体称为基本方体。基本方体应当对应于感兴趣的个体实体,如sales或customer。换言之,最低层应当是对于分析可用的或有用的。最高抽象的立方体称为顶点方体。对不同层创建的数据立方体称为方体,因此数据立方体可以看做方体的格。每个较高抽象将进一步减小结果数据的规模。当回答OLAP查询或数据挖掘查询时,应当使用给定任务相关的最小可用方体。
    OLTP:联机事务物理系统,主要任务是执行联机事务和查询处理。
    OLAP:联机分析处理,在数据分析和决策方面为用户或“知识工人”提供服务。这种系统可以用不同的格式组织和提供数据,以便满足不同用户的形形色色的需求。
    OLTP和OLAP的主要区别概述如下:
  • 用户和系统的面向性:OLTP是面向顾客的,用于办事员、客户和信息技术专业人员的事务和查询处理。OLAP是面向市场的,用于知识工人(包括经理、主管和分析人员)的数据分析。
  • 数据内容:OLTP系统管理当前数据。通常这种数据太琐碎,很难用于决策。OLAP系统管理大量历史数据,提供汇总和聚集机制,并在不同的粒度层上存储和管理信息。这些特点使得数据更容易用于有根据的决策。
  • 数据库设计:通常OLTP系统采用实体--联系(ER)数据模型和面向应用的数据库设计。而OLAP系统通常面向主题的数据库设计。
  • 视图:OLTP系统主要关注一个企业或部门内部的当前数据,而不涉及历史数据或不同单位的数据。相比之下,由于单位的演变,OLAP系统通常跨越数据库模式的多个版本。OLAP系统还处理来自不同单位的信息,以及由多个数据库集成的信息。由于数据量巨大,OLAP数据也存在多个存储介质上。
  • 访问模式:OLTP系统的访问主要由短的原子事务组成。这种系统需要并发控制和恢复机制。然而,对OLAP系统的访问大部分是只读操作,尽管许多可能是复杂的查询。

二、OLAP系统建设
  • 外部数据源:外部数据源主要包含分散在各个业务部门的业务数据源系统、应用埋点上报数据,以及从网络上爬取的一些数据。业务数据库通常是关系型数据库系统,记录了业务方的业务信息;应用埋点上报数据,是企业方法的一些应用系统,通过这些应用系统采集到的一些用户行为信息;网络上爬取的数据,包含竞对数据、权威方发布数据、以及一些有用辅助信息等。
  • 底层数据仓库服务器:通过一些后端工具和实用程序,由操作数据库和其他外部数据源提取数据,放入底层。这些工具和实用程序进行数据提取、清理和变换,以及装入和刷新,以便更新数据仓库。
  • 中间层是OLAP服务器:其典型的实现使用关系OLAP模型,或者使用多维OLAP模型。
  • 顶层是前端客户层:它包括查询和报告工具、分析工具或数据挖掘工具(例如趋势分析、预测等)。
三、了解数据仓库
1、数据仓库介绍
    从结构的角度看,有三种数据仓库模型:企业仓库、数据集市和虚拟仓库。
    企业仓库:企业仓库搜集了关于主题的所有信息,跨越整个企业。他提供企业范围内的数据集成,通常来自于一个或多个操作数据库系统或外部信息提供者,并且是多功能的。通常,它包含细节数据和汇总数据,其规模由数兆兆字节,到数百兆兆字节,数千兆兆字节,甚至更多。企业数据仓库可以在传统的大型机、超级计算机服务器或并行结构平台上实现。它需要广泛的商务建模,可能需要多年建设和设计。
    数据集市:数据集市包含企业范围数据的一个子集,对于待定的用户群是有用的。其范围现定于选定的主题。例如:销售数据集市可能限定其主题为顾客、商品和销售。包括在数据集市中的数据通常是汇总的。
    虚拟仓库:虚拟仓库是操作数据库上视图的集合。为了有效的处理查询,只有一些可能的汇总视图被物化。虚拟仓库容易建立,但需要操作数据库服务器还有余力。
2、数据仓库建设
    数据仓库开发是自顶向下,还是自顶向上?
    自顶向下开发企业仓库是一种系统的解决方案,并能最大限度的减少集成问题。然而,它费用高,开发周期长,并且缺乏灵活性,因为整个组织就共同数据模型达成一致是比较困难的。
    自底向上通过设计、开发、配置独立的数据集市的方法,提供了灵活性、低花费,并能快速回报投资。然而,将分散的数据集市集成,形成一个一致的企业数据仓库时,可能导致问题。
     对于开发数据仓库系统,一种推荐的方法是以递增、进化的方式实现数据仓库。首先,在一个合理短期的时间内,定义一个更高层次的企业数据模型,在不同的主题和可能的应用之间,提供企业范围的、一致的、集成的数据视图。这个高层模型将大大减少今后的集成问题,尽管在企业数据仓库和部门数据集市的开发中,它还需要进一步提炼。其次,基于上述相同的企业数据模型,可以并行的实现独立的数据集市和企业数据仓库。再次,可以通过中心服务器集成不同的数据集市,构造分布数据集市。最后,构造一个多层数据仓库。这里,企业仓库是所有仓库数据的唯一管理者,仓库数据分布在一些依赖的数据集市中。

3、数据提取、变换和装入
    数据仓库系统使用后端工具和实用程序来加载和刷新他的数据。这些工具和实用程序包含以下功能:
  • 数据提取:通常,由多个异构的外部数据源收集数据;
  • 数据清理:检测数据中的错误,可能时订正它们;
  • 数据变换:将数据由遗产或宿主格式转换成数据仓库格式。
  • 装入:排序、汇总、合并、计算视图、检查完整性,并建立检索和划分。
  • 刷新:传播由数据源到数据仓库的更新。
    数据仓库通常还提供一组数据仓库管理工具。数据清理和数据变换是提高数据质量,从而提高其后的数据挖掘结果质量的重要步骤。
4、元数据库
    元数据是关于数据的数据。在数据仓库中,元数据是定义仓库对象的数据。元数据在数据仓库体系结构的底层。对于给定的数据仓库的数据名和定义,创建元数据。其他元数据包括对提取数据添加的时间标签、提取数据的源、被数据清理或集成处理添加的缺失字段等。
    元数据库应当包括以下内容:
  • 数据仓库结构的描述,包括仓库模式、视图、维、分层结构、导出数据的定义,以及数据集市的位置和内容;
  • 操作元数据,包括数据血统、数据流通和管理信息。
  • 用于汇总的算法,包括度量和维定义算法,数据所处的粒度、划分、主题领域、聚集、汇总、预定义的查询和报告;
  • 由操作环境到数据仓库的映射,包括源数据库和他们的内容,新关描述,数据划分,数据提取、清理、转换规则和默认值,数据刷新和净化规则,以及安全性;
  • 关于系统性能的数据,除刷新、更新和复制周期的定时和调度的规则外,还包括改善数据存取和检索性能的索引和概要。
  • 商务元数据,包括商务术语和定义,数据拥有者信息和收费策略;
    数据仓库包含不同的汇总层,元数据是其中一种类型。其他类型包括当前的细节数据、老的细节数据、稍加汇总的数据和高度汇总的数据。
四、数据仓库模型:数据立方体与OLAP
    数据仓库和OLAP工具基于多维数据模型。这种模型将数据看做数据立方体形式。主要包括:数据立方体对n维数据建模,各种多维模型--星型模型、雪花模型和事实星座。还有分层和度量,以及上卷和下钻。
1、什么是数据立方体
    数据立方体允许以多维对数据建模和观察。它由维和事实定义。一般而言,维是一个单位想要记录的透视或实体。通常,多维数据模型围绕诸如销售这样的中心主题组织。主题用事实表表示。事实是数值度量的。事实表包括事实的名称或度量,以及每个相关维表的码。存放最低层次汇总的方体称作基本方体。
2、多维数据模型
    最流行的数据仓库的数据模型是多维数据模型。这种模型可以是星形模型、雪花模式或事实星座模型。
  • 星型模型:最常见的模型是星型模式,其中数据仓库包括①一个大的中心表(事实表),它包括大批量数据并且不含冗余;②一组小的附属表(维表),每维一个。这种模式图很像星光四射,维表表示在围绕中心表的射线上。
  • 雪花模式:是星型模式的变种,其中某些维表被规范化,因而把数据进一步分解到附加的表中。结果模式图形成类似于雪花的形状。雪花模式和星形模式主要区别在于,雪花模式的维表可能是规范化形式,以便减少冗余。这种表易于维护,并节省存储空间。此外由于执行查询需要更多的连接操作,雪花结构可能降低浏览的效率。因此,系统的性能可能会受到影响。所以雪花模式不如星形模式流行。
  • 事实星座:复杂的应用可能需要多个事实表共享维表。这种模式可以看做星形模式的汇集,因此称作星系模式或事实星座。
3、维:概念分层的作用
    概念分层定义一个映射序列,将底层概念集映射到较高层、更一般的概念。例如time:hour-->week-->month-->year。 通过概念分层允许用户根据他们的特殊需要裁减预定义的分层。也可以通过给定维或属性离散化或分组来定义概念分层,产生集合分组分层。可以在值的组合之间定义全序或偏序。
    概念分层可以由系统用户、领域专家、知识工程师人工的提供,或根据数据分布的统计分析自动的产生。
4、度量的分类和计算
    数据立方体空间的多维点可以用维--值对的集合来定义。数据立方体度量是一个数值函数,该函数可以对数据立方体空间的每个点求值。通过给定点的各维--值对聚集数据,计算该点的度量值。
    度量根据其所用的聚集函数可以分成三类:分布的、代数的和整体的。
  • 分布的:一个聚集函数如果能用如下分布式进行计算,则它是分布的。假设数据被划分为n个集合,将函数用于每一部分,得到n个聚集值。如果将函数用于n个聚集值得到的结果与将函数用于整个函数集得到的结果一样,则该函数可以用分布式计算。
  • 代数的:一个聚集函数如果能够用一个具有M个参数的代数函数计算,而每个参数都可以用一个分布聚集函数求得,则它是代数的。例如:avg()==sum()/count()计算。其中sum()和count()都是分布聚集函数。
  • 整体的:一个聚集函数如果描述它的子聚集所需的存储没有一个常数界,则它是整体的。也就是说,不存在一个具有M个参数的代数函数进行这一计算。整体函数常见的例子包括median、mode和rank。一个度量如果是由整体聚集函数得到的,则他是整体的。
    大部分数据立方体应用需要有效的计算分布的和代数的度量,对此存在许多有效的技术。相比之下,有效地计算整体度量是比较困难的。然而,对于某些整体函数的近似计算,有效的技术是存在的。
5、典型的OLAP操作
     在多维数据模型中,数据组织在多维空间,每维包含由概念分层定义的多个抽象层。这种组织为用户从不同角度观察数据提供了灵活性。有一些OLAP数据立方体操作用来物化这些不同视图,允许交互查询和分析手头数据。因此OLAP为交互数据分析提供了友好的环境。
  • 上卷:通过沿一个维的概念分层向上攀升或者通过维规约在数据立方体上进行聚集。例如:按照地域上卷--street-->city-->province-->contry。当用维规约进行上卷时,一个或多个维从给定的立方体中删除。
  • 下钻:他是由不太详细的数据到更详细的数据。下钻可以通过沿维的概念分层向下或引入附加的维来实现。例如:在日期维度上--day<month<quarter<year,定义的time维的概念分层向下,在中心立方体执行下钻操作的结果。由于下钻操作对给定数据添加更多细节,他也可以通过添加新的维到立方体来实现。
  • 切片和切块:切片操作在给定的立方体的一个维上进行选择,导致一个子立方体。切块操作通过在两个或多个维上进行选择,定义子立方体。
  • 转轴:是一种目视操作,它转动数据的视图,提供数据的替代表示。
  • 其他OLAP操作:有些OLAP系统还提供其他钻取操作。例如,钻过执行涉及到多个事实表的查询。钻透操作到数据立方体的底层,到后端关系表。
  • 其他OLAP操作可能包括列出表中最高或最低的N项,以及计算移动平均值、增长率、利润、内部返回率、贬值、流通转换和统计功能。
6、查询多维数据库的星网查询模型
    多维数据库查询可以基于星网模型。星网模型由从中心点发出的射线组成,其中每一条射线代表一个维的概念分层。概念分层上的每个“抽象级”称为一个足迹,代表诸如上卷、下钻等OLAP操作可用的粒度。
    例如:一个星网由四条射线组成,分别代表维location、customer、item和time的概念分层。每条线由一些足迹组成,代表该维的抽象级。例如,time线有4个足迹:day、month、quarter、year。一个概念分层可以涉及单个属性,或若干属性。为了考察商品销售,用户可以沿着time维上卷,由month到quarter,或沿着location维下钻,由country到city。
    通过用较高层抽象值替换低层抽象值,概念分层可以用于泛化数据。通过用低层抽象值替换高层抽象值,概念分层也可以特殊化数据。
7、多维数据挖掘
    多维数据挖掘把数据挖掘与OLAP集成在一起,在多维数据库中发现知识。在数据挖掘的许多不同范例和结构中,由于以下原因,多维数据挖掘特别重要:
  • 数据仓库中数据的高质量:大部分数据挖掘工具需要在集成的、一致的和清理过的数据上运行,这需要昂贵的数据清理、数据变换和数据集成作为预处理步骤。经由这些预处理而构造的数据仓库不仅充当OLAP,而且也充当数据挖掘的高质量的、有价值的数据源。
  • 环绕数据仓库的信息处理基础挖掘:全面的数据处理和数据分析基础设备已经或将要围绕数据仓库而系统的建立,这包括多个异构数据库的访问、集成、合并和变换,web访问和服务机制,报表和OLAP分析工具。明智的做法是尽量利用可用的基础设施,而不是一切从头做起。
  • 基于OLAP的多维数据探索:有效的数据挖掘需要探索式数据分析。用户常常想遍历数据库,选择相关数据,在不同的粒度上分析他们,并以不同的形式提供知识、结果。多维数据挖掘提供在不同的数据子集和不同的抽象层上进行数据挖掘的机制,在数据立方体和数据挖掘的中间结果上进行钻取、旋转、过滤切块和切片。这些与数据/知识可视化工具一起,将大大增强探索数据挖掘的能力和灵活性。
  • 数据挖掘功能的联机选择:用户常常可能不知道他想挖掘什么类型的知识。通过将OLAP与多种挖掘功能集成在一起,多维数据挖掘为用户选择所期望的数据挖掘功能,动态的切换数据挖掘提供灵活性。
8、数据立方体的有效计算
    多维数据分析的核心是有效的计算许多维集合上的聚集。用SQL的术语,这些聚集称为分组(group-by)。每个分组可以用一个方体表示,而分组的集合形成定义数据立方体的方体的格。
①compute cube操作与维灾难
    立方体计算的一种方法是扩充SQL,使之包含compute cube操作。compute cube操作在操作指定的维的所有子集上计算聚集。这可能需要很大的存储空间,特别是对于很大量的维。例如:有一个数据立方体,包含city、item、year,那数据立方体计算的方体或分组总数为2的3次方=8个。基本方体是最低泛化的方体。顶点方体是最高泛化的方体。从顶点方体开始,沿方体的格向下探查,这等价于在数据立方体中下钻。从基本方体向上探查,则类似于上卷。
    不包含分组的sql查询是0维操作。包含一个分组的sql查询是一维操作。在n维上的一个立方体操作等价于一组分组语句,每个对应于n个维的一个子集。对于不同的查询,OLAP可能需要访问不同的方体。因此,提前计算所有的或者至少一部分方体。预计算带来快速响应时间,并避免一些冗余计算。然而,预计算的挑战是:如果数据立方体中所有方体都预先计算,所需存储空间可能爆炸,特别是当立方体包含许多维时。当许多维都有相关联的概念分层、具有多层时,存储需要更多。这就是维灾难。
②部分物化:方体的选择计算
  • 不物化:不预先计算任何“非基本”方体。这导致回答查询时实时计算昂贵的多维聚集,这可能很慢;
  • 完全物化:预先计算所有方体。计算的方体的格是完整方体。通常,这种选择需要海量存储空间来存放所有预计算的方体。
  • 部分物化:有选择的计算整个可能的方体集中一个适当的子集。我们也可以计算数据立方体的一个子集,它只包含满足用户指定的某种条件的那些单元。其中各种方体只有某些单元被预计算,部分物化是存储空间和响应时间二者之间的很好折中。
    方体或者子立方体的部分物化应考虑三个因素:确定要物化的方体子集或子立方体;在查询处理时利用物化的方体或子立方体;在装入和刷新时,有效的更新物化的方体或子立方体。 物化方体或子立方体的选择需要考虑工作负荷下的查询,以及他们的频率和他们的访问开销。此外,也要考虑工作负荷的特点、增量更新的开销和整个存储需求量,选择还必须考虑物理数据库设计的情况。
    还有一种常用的策略是物化一个外壳方体。这涉及预计算数据立方体的只有少量维的方体。在维的其他组合上的查询可以临时计算。
③OLAP常用索引:位图索引和连接索引
    位图索引:在OLAP产品中很流行,因为它允许在数据立方体中快速搜索。位图索引是record_ID(RID)列表的一种替代表示。在给定属性的位图索引中,属性域中的每个值v,有一个不同的位向量Bv。如果给定的属性域包含n个值,则位图索引中每项需要n个位。如果数据表给定行上该属性值为v,则在位图索引的对应行,表示该值的位为1,该行的其他位均为0.
     连接索引:方法的流行源于他在关系数据库查询处理方面的应用。传统的索引将给定列上的值映射到具有该值的行的列表上。与之相反,连接索引登记来自关系数据库的两个关系的可连接行。例如:如果两个关系R(RID,A)和S(B,SID)在属性A和B上连接,则连接索引记录包含(RID,SID)对,其中RID和SID分别为来自关系R和S的记录标示符。因此,连接索引记录能够识别可连接的元组,而不必执行开销很大的连接操作。对于维护来自可连接的关系的外码和与之匹配的主码的联系,连接索引特别有用。
④OLAP查询的有效处理
    物化立方体和构造OLAP索引结构的目的是加快数据立方体查询处理的速度。给定物化的视图,查询处理应该安如下步骤进行:
  • 确定哪些操作应当在可利用的方体上执行:这涉及将查询中的选择、投影、上卷和下钻操作转化成对应的SQL或OLAP操作。例如:数据立方体上的切片和切块可能对应于物化立方体上的选择和投影操作。
  • 确定相关操作应当使用那些物化的方体:这涉及到找出可能用于回答查询的所有物化方体,使用方体之间的“支配”联系知识,进行修剪,评估使用剩余物化方体的开销,并选择开销最小的方体。
    例如:定义了一个数据立方体,形式为sales_cube[time,item,location]:sum(sales_in_dollars)"。所用的维层次对于time是day<month<quarter<year,对于item是item_name<brand<type,对于location是street<city<province_or_state<country。假设待处理的查询在{brand,province_or_city}上,选择常量为“year=2010”还假定有四个物化的立方体可用,他们是:{year,item_name,city}{year,brand,country}{year,brand,province_or_state}{item_name,province_or_state}。以上四个方体应该选择哪一个处理?

9、数据特征的面向属性的归纳
    数据立方体方法基本上是基于数据的物化视图,通常在数据仓库中预先计算。一般而言,在OLAP或数据挖掘查询提交处理之前,他脱机的计算聚集。另一方面,面向属性的归纳基本上是面向查询的、基于泛化的、联机的数据分析处理技术。注意,并不存在按照联机聚集和脱机预计算区分两种方法的固有界限。数据立方体中有哪些聚集也可以联机计算,而多维空间的脱机预计算要也可以加快面向属性的归纳速度。
    面向属性归纳的基本思想是:首先使用数据库查询收集相关的数据,然后,通过考察任务相关数据中每个属性的不同值的个数进行泛化。泛化或者通过属性删除、或者通过属性泛化进行。聚集通过合并相同的广义元组,并收集他们对应的计算值进行。这降低了泛化后的数据集合的规模。结果广义关系可以映射到不同形式提供给用户。
  • 删除属性:如果初始工作关系的某个属性有大量不同的值,但是在该属性上没有泛化操作符,或者他的较高概念用其他属性表示,则应当将该属性从工作关系中删除。
  • 泛化属性:如果初始工作关系的某个属性有大量不同的值,并且该属性上存在泛化操作符的集合,则应当选择一个泛化操作符,并将它用于该属性。 该规则基于如下理由:使用泛化操作符泛化工作关系中元组或者规则的属性值,将使得规则涵盖更多的元数据的元组,从而泛化了它所表示的概念。这对应于泛化规则,在实例学习中称之为沿泛化树攀升或概念攀升。
    例如:
  • name:由于name存在大量不同值,并且其上没有定义泛化操作,因此该属性被删除。
  • gender:由于gender只有两个不同值,因此该属性保留, 并且不对其进行泛化。
  • birth_place:该属性有大量不同值,因此应当对他泛化。假设存在birth_place的概念分层,定义为city->province_or_state->country。如果初始工作关系中country的不同值个数大于属性泛化阀值,则birth_place应当删除,因为尽管存在泛化操作,泛化阀值也不会满足。如果country的不同值个数小于泛化阀值,则birth_place应当泛化到birth_country。
    类比较的面向属性归纳:在许多应用中,用户可能对单个类的描述或特征不感兴趣,而是希望挖掘一种描述,它将一个类或概念与其他可以比较的类相区分。类区分或比较挖掘区分目标类和它的对比类的描述。注意,目标类和对比类必须是可比较的,意指他们具有相似的维或属性。例如:person、address、item这三个类不是可比较的。然而,过去三年的销售是可比较的,计算机科学的学生和物理学的学生也是可比较的。如何进行类比较,一般如下:
  • 数据采集:通过查询处理收集数据库中相关数据,并把它划分成一个目标类和一个或多个对比类。
  • 维相关分析:如果有多个维,则应当在这些类上进行维相关分析,仅选择与进一步分析高度相关的维。这一步可以使用相关性度量或基于熵的度量。
  • 同步泛化:泛化在目标类上进行,泛化到用户或领域专家制定的维阀值控制的层,产生主目标类关系。对比类的概念泛化到与主目标类关系相同的层次,形成主对比类关系。
  • 导出比较的表示:结果类比较描述可以用表、图或规则的形式可视化。
    概括的说,与数据立方体方法对比,数据特征和泛化的面向属性归纳方法提供了另一种数据泛化方法。它并不局限于关系数据,因为这种归纳可以在空间、多媒体、序列以及其他类型的数据集上进行。此外,不需要预先计算数据立方体,因为泛化可以基于收集到用户查询在线进行。
    此外,可以把自动分析加入这种归纳过程,自动过滤不相关或不重要的属性。然而,由于面向数据的归纳自动把数据泛化到较高层,因此它不能有效地支持下钻到比被泛化的关系提供的抽象层还深的层。集成数据立方体技术与面向属性的归纳可能平衡预计算和联机计算。当需要下钻到比被泛化的关系提供的抽象层还深的层时,也能支持快速的联机计算。


楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 20:27

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表