数据仓库是数据的仓库,数据是从操做型数据库系统中获取,通过集成处理、按照合适的粒度进行聚合而成的数据的集合。 构建数据仓库,要从数据模型、数据集成、粒度设计和分区设计这四个方面着手,迭代式开发。数据库
在设计数据仓库以前,首先要了解操做型数据库的数据模型,数据模型分为三个层次:缓存
1,实体关系图(ERD)性能优化
实体关系图是数据之间关系的高度抽象,直接定义了数据模型中的实体(主题)和实体之间的关系,用于理解数据模型中涵盖的主题架构
2,数据集成(DIS)并发
对实体-关系模型中标识出的每个主题或实体,都要创建一个DIS模型,数据库设计
数据集成模型基本上由三部分构成:性能
当在ERD层标识一个实体-关系以后,在DIS层就用链接器和数据分组来表现:大数据
数据分组包含关键字和其余属性,用于对数据分组进行详细的描述。 优化
3,物理模型(关系表)编码
物理模型是从DIS模型建立而来的, 通常来讲,数据集成模型中定义的数据分组,都对应一个关系表,数据分组中的关键字和属性,用于定义关系表的主键和属性列。可是,这些表不能直接用于设计数据库中的关系表,可是,物理模型是设计关系的依据,还要考虑对关系表进行性能优化。
设计关系表的关键是集成数据,设计数据的粒度和分区,另外,为了优化性能,还须要设计缓存,设计冗余字段,去外键,增长层次结构。
1,数据集成
把原始数据集成到数据仓库中,为了性能优化,一般会对数据列作以下处理:
另外,通常数据仓库中,不会保留长文本数据,若是必须保留长文本数据,建议把该文本列分离出去。对于无效的数据,须要清理出去;对于空值得数据,须要设置默认值等。
2,粒度
在数据仓库中,数据存在着不一样的细节级:原始数据(最细节的数据)、当前细节数据、轻度聚合数据和高度聚合数据,数据的粒度升级,是在数据由操做层传输到导出层进行的,一旦数据过时,就由原始数据导出当前细节数据,进而导出聚合数据。咱们把聚合以后的数据称做缓存数据,这是为了定向提升某个主题或分析的查询性能。
不一样的细节级,实际是由数据粒度的不一样致使的,而粒度的升级一般是由时间、类别等属性聚合以后获得的。粒度会深入地影响存储到数据仓库中的数据量的大小和数据仓库支持的查询类型。数据仓库中数据量的大小和粒度成反比,粒度越低,支持的查询范围越普遍,数据量越大。换句话说,低粒度能够回答任何问题,而高粒度会限制数据所能回答的问题。
因为高粒度会下降数据量,使得查询速度更快;而低粒度可以回答更多的问题,所以,在数据仓库中,通常根据数据被查询的频次,设计多重粒度,这样啊,既能使用高粒度快速响应高频问题,也能使用低粒度回答低频的问题。
3,分区
数据分区是把数据分散到可独立进行IO处理的分离的硬盘中,从根本上来讲,分区的好处有两点:
对数据分区,须要依据特定的数据列,一般以时间列做为分区列,把不一样的时间区间的数据存放到不一样的分区中去。
注意:把分区分布于不一样的物理硬盘,才能充分利用硬件的IO能力,一般状况下,一块物理硬盘会划分为多个逻辑硬盘,若是把不一样的分区放到不一样的逻辑硬盘上,而这些逻辑硬盘属于同一个物理硬盘,那么IO实际上不会并发执行。
4,反向规范化
数据模型的输出是一系列的关系表,每一个表都包含关键字和属性,典型的OLTP数据库设计的规范是避免冗余,全部的属性都必须依赖于主键,不容许传递依赖(即不容许间接依赖主键),这样设计的结果使更新操做的cost最小化,可是,对于一个查询请求,可能会join多张表,而SQL Server对于多表的Join操做的性能优化能力有限,这会致使查询性能急剧下降。
因为数据仓库不多对数据进行更新,一般是保存历史数据不变;在设计数据仓库时,能够违反第三范式(不容许间接依赖主键),把实体的相关字段合并到一个表中,使相关的数据在物理上是顺序存储的。这样的表结构设计,既能减小了查询语句中使用Join的次数,充分利用SQL Server引擎的优化能力,也能利用物理硬盘的IO特性(顺序读取一块数据),提升数据查询的性能。
另一个提升查询性能的表设计是根据访问频率来分裂表,当一个列是长文本字段,且访问频次至关低时,能够把该列分离出去,存放到另外一个附表中,这样设计表的结果是高频访问的列和窄列放到主表中,低频的长文本列放到副表中,主表和附表经过代理主键关联在一块儿。
5,缓存设计
因为数据仓库中的数据更新的次数少,对于经常使用的数据聚合,能够预先把数据计算好,存储到缓存表,也就是说,在数据仓库中,建立不一样粒度的关系表。而缓存表中的数据,能够把计算的时间安排在夜晚等非工做时间段,这样,用户在工做时不须要重复计算,只须要查询就能够快速得到结果,提升了工做效率。
6,外键关系
对于参照完整性,在数据仓库中,通常不会建立外键关系,参照完整性是经过“人工”识别的。这样,即便删除了参考表中的数据,也不会影响引用表,只不过join不出结果而已。
把外键关系转换为数据冗余,这也就是数据的反规范化设计,这样作会增大数据仓库使用的存储容量,下降数据更新的性能,可是会加快数据查询的速度,当数据是稳定的,补偿更新时,采用数据冗余是性能优化的设计方案。
7,增长层次结构
层次结构是聚合数据的角度,例如,数据是以天为单位,那么能够设计时间维度,该维度表的层次结构分别是天、周、月、季和年,分析人员能够按照周、月、季和年来聚合数据,以不一样的视角来分析数据。经常使用的层次结构是日期、行政区划,类别等。数据仓库中,确定是存储在时间维度的,也一定存在日期维度。
8,数据压缩
对于数据仓库而言,IO资源比CPU资源更加稀缺,咱们可使用计算资源换IO资源。虽然压缩和解压缩会浪费CPU资源,可是数据压缩使得数据能够存储到较小的硬盘空间中,也就是说,一样的硬盘空间存储更多的数据,这使得一次IO可以读取更多的数据。
9,索引设计
尽可能使用窄列建立索引时,索引不是越多越好,但也不能一个索引都不建立。
对于只插入数据,而极少查询的数据表,能够建立一个自增列做为主键,并建立汇集索引从物理上顺序存储数据;
对于复合主键的状况下,能够建立非汇集索引,而使用自增列做为主键,并建立汇集索引从物理上顺序存储数据;
对于变长数据类型,若是数据常常更新或改变,可能会带来很是严重的性能问题,在建立索引时,尽可能不要把变化频繁的变长列做为索引列,考虑做为包含列来处理。
数据仓库中常常提到的设计方法是多维结构,基于星型链接、事实表和维度表来设计关系表架构,多维方法只适用于数据集市,而不适合数据仓库。数据集市中的表结构是根据部门的特殊需求而创建的,其结构通常是星型链接,包含事实表和维度表,一般由OLAP技术支持。
一般来讲,多维结构的特征是:
使用多维结构的结果是:事实表中基本不存储文本数据,维度表中记录的是实体的类别,时间等属性,大多数是文本数据和层次结构数据。多维结构灵活性不足,通用性不足。
数据仓库的数据库设计有两种基本模型:关系模型和多维模型,关系模型更加灵活,因此更适合数据仓库的设计,而多维模型更适合数据集市。
1,关系模型
关系模型是OLTP数据库系统的设计模型,表设计符合数据库设计的第一范式、第二范式和第三范式,关系模型提升了数据更新的性能,而牺牲了数据查询的性能。因为OLTP是高更新的数据库系统,所以,关系模型很是适合操做型数据库系统。然而,数据仓库中存储的数据不常更新,更多的是对数据的查询。
关系模型的最大优势是灵活,支持适度变化的需求,适合数据仓库的设计。
2,多维模型
一般认为,多维模型是创建数据仓库的设计方法,多维模型牺牲数据更新的性能,以提升数据查询的性能。多维模型的两种结构是星形链接和雪花形链接,雪花形链接是星形链接的扩展。多维模型存在数据冗余,这会使得,经过一次访问就能够获得一个实体的全部数据,Join操做较少,数据查询较快,能够直接用于OLAP技术。缺点是不够灵活,一旦设计完成,要想改动就很难了。
(1)星形链接
从设计模型上来看,星形链接是以一颗事实表为中心,周围围绕着维度表。
星形链接的中心是一个事实表,事实表是包含大量数据值的一个表;事实表的周围是维度表,用于描述事实表的类别,时间等属性。事实表和维度表经过公共属性(外键)相关联。
(2)雪花形链接
一般,星形链接只包含一张事实表,当须要多张事实表相结合时,这就是雪花形结构:
在雪花形结构中,不一样的事实表经过共享一个或多个公共维度表链接起来。
参考文档: