数据仓库和BI技术概况Word格式文档下载.docx
《数据仓库和BI技术概况Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《数据仓库和BI技术概况Word格式文档下载.docx（32页珍藏版）》请在冰点文库上搜索。
●如何避免对已经加载的数据的读取，提高性能
●数据实时发生变化后怎么加载
2.数据存储模型
过程模型：
适用于操作性环境。
数据模型：
适用于数据仓库和操作性环境。
数据模型从设计的角度分：
高层次模型（实体关系型），中间层建模（数据项集），物理模型。
2.1.数据仓库的存储方式
数据仓库的数据由两种存储方式：
一种是存储在关系数据库中，另一种是按多维的方式存储，也就是多维数组。
2.2.数据仓库的数据分类
数据仓库的数据分元数据和用户数据。
用户数据按照数据粒度分别存放，一般分四个粒度：
早期细节级数据，当前细节级数据，轻度综合级，高度综合级。
元数据是定义了数据的数据。
传统数据库中的数据字典或者系统目录都是元数据，在数据仓库中元数据表现为两种形式：
一种是为了从操作型环境向数据仓库环境转换而建立的元数据，它包含了数据源的各种属性以及转换时的各种属性；
另一种元数据是用来与多维模型和前端工具建立映射用的。
2.3.数据存储模型分类
多维数据建模以直观的方式组织数据，并支持高性能的数据访问。
每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。
多维模型最常见的是星形模式。
在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。
在星型的基础上，发展出雪花模式。
通常来说，数据仓库使用星型模型。
2.3.1.星型模型
位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。
每个指标实体代表一系列相关事实，完成一项指定的功能。
位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。
每个维表有自己的属性，维表和事实表通过关键字相关联。
星形模式虽然是一个关系模型，但是它不是一个规范化的模型。
在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。
使用星形模式主要有两方面的原因:
提高查询的效率。
采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。
同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;
便于用户理解。
对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。
总结一下星型模型的特点：
●非正规化；
●多维数据集中的每一个维度都与事实表连接（通过主键和外键）；
●不存在渐变维度；
●有冗余数据；
●查询效率可能会比较高；
●不用过多考虑正规化因素，设计维护较为简单
2.3.2.雪花模型
在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。
雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。
雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。
在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。
雪花模式的优点是:
在一定程度上减少了存储空间;
规范化的结构更容易更新和维护。
同样雪花模式也存在不少缺点:
雪花模式比较复杂，用户不容易理解;
浏览内容相对困难;
额外的连接将使查询性能下降。
在数据仓库中，通常不推荐“雪花化”。
因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。
总结一下雪花模型的特点：
●正规化；
●数据冗余少；
●有些数据需要连接才能获取，可能效率较低；
●规范化操作较复杂，导致设计及后期维护复杂。
实际应用中，可以采取上述两种模型的混合体。
如：
中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及分析
3.前端分析应用模型
是指为数据挖掘和数据分析以及预测定义的数据模型，有数据库模型以及电子表模型。
主流的产品有：
DB2OLAPserver
MSOLAPAnalysisserver
HyperionEssbaseOLAPserver
OracleExpressServer
SASOLAPServer
3.1.电子表模型
在电子表中可以向单元格中插入数值或公式。
电子表对于复杂的公式很有帮助，因为它便于用户操控。
电子表的缺点之一是它在大小方面很受限制，并且电子表本质上只是一个二维结构。
使用电子表存储模型构建的OLAP多维数据集可以把这个模型扩展为支持多个维度，并且比常规的电子表大很多。
在基于电子表模型的OLAP中，整个多维数据集中的任何单元格都有可能被物理地存储。
这既是好事也是坏事。
优点是可以在多维数据集空间内的任何点上输入常量值，并且在多维数据集空间内的任何点上保存计算的结果。
缺点是一个称为数据爆炸的小问题，它限制了OLAP多维数据集的大小。
基于电子表的OLAP工具往往与财务应用程序相关联。
多数财务应用程序都涉及相对较小但具有复杂的非累加性（noadditive）计算的数据库。
3.2.数据库模型
使用数据库模型来存储多维数据集的OLAP工具的行为截然不同。
它们利用了多数报表都需要加操作，还有相加是个关联操作这个事实。
例如把数字3、5和7相加时，无论是先把3和5相加得到8然后再加上7，还是先把5和7相加得到12然后再加上3都没有关系。
两种情况下结果都是15。
在纯粹的关系数据库中，通过创建具体表以得到快速的查询结果。
在聚合表中存储的是报表需要的预先加好的数值。
例如在一个包含了几千种产品、5年明细数据，也许还有其他几个维度的事实表中，可能存储了几百万行数据，即使在只有50个子类别和20个季度的情况下，也需要好几分钟来生成一个按产品子类别或季度分组的报表。
但如果先把这些数据汇总起来，并保存到只包含子类别和季度的聚合表中，那么该表中最多只有一千行数据，而且只根据子类别或季度分组的查询将执行得很快。
事实上，根据加操作的关联性，根据产品类别或年进行汇总的报表也可以使用相同的聚合表，同样也能很快地产生结果。
使用数据库模型进行存储的OLAP最大的优点是可以避免数据爆炸。
因为使用相对较少的聚合表提供快速的结果，可以创建比电子表模型拥有更多维度和属性的更大的多维数据集。
使用数据库模型进行存储的OLAP最大的缺点是，没有固有的方法来存储使用非关联性操作计算的结果。
一个极端复杂的财务计算就是留存收益（RetainedEarningSinceInception）。
为了计算这个值，必须首先计算纯收益——而它本身就是各种加、减和乘法的大杂烩。
并且还必须计算每个时间段从开始时间点的纯收益值，以便把它们加到一起。
这不是个关联操作，所以为业务的每个单元分别计算并不能使整个公司的计算更加容易。
即使是使用数据库模型存储的OLAP多维数据集也能快速地计算某些非关联操作。
例如，平均销售价格并不是一个可累加值（additivevalue）——不能简单地把价格相加起来。
但在整个产品线层次计算平均销售价格时，只要简单地计算出销售额和销售量的总数，然后在产品线层次用销售额总数除以销售量总数。
因为是在计算两个可累加值的比率，所及本质上该计算将与获取简单的可累加值一样快。
数据库形式的OLAP工具通常与销售或类似的数据库关联。
销售多维数据集通常都非常巨大——不仅有上亿条的事实表数据，并且还有具有很多属性的维度。
销售多维数据集通常都涉及累加性的度量值（美元和数量通常都是可累加的），或者是可以基于可累加值快速计算的公式。
OLAP的一个主要优点就是能够提前计算数值，这样就能快速地呈现报表。
不同的OLAP技术有不同的优势和劣势，但一个好的OLAP实现了在涉及高度汇总值时比等同的关系查询快很多。
4.数据集市
4.1.概念
数据集市是一个小型的基于企业的一个组织或者部门的数据仓库。
有两种类型的数据集市：
独立型和从属型。
独立型数据集市从操作性数据库中获取数据；
从属型数据集市从企业级数据仓库中获取数据。
大家可以考虑一下：
哪一种数据集市更为稳定？
5.ETL
随着企业信息化的发展，有两种方式可以完成系统间的协作和数据分析挖掘。
一种是EAI，一种是ETL。
这两种方式哪一种更好，下面我们会给予解释分析。
5.1.EAI
5.1.1.概念
为了解决企业内部“信息孤岛“的问题，企业应用集成（EnterpriseApplicationIntegration，EAI）技术应运而生，它可以通过中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源，从而满足E-Commerce、ERP、CRM、SCM、OA、数据库、数据仓库等重要系统之间无缝共享和交换数据的需要。
EAI涉及技术广泛，实施复杂。
EAI的核心是使用中间件连接企业应用。
有多种不同类型的中间件可以提供EAI的功能。
在选择EAI中间件时，要注意基本特征如下：
⏹通过中间件将不同的应用连接起来，保证应用的独立性，在不需要修改应用自身的业务逻辑的同时，又解决了数据共享问题。
⏹对核心共享业务数据模型的处理与支持
⏹实现业务流程自动化。
确保各个部门在采用不同的系统的同时可以协同完成同一个工作。
⏹对流程管理提供预定义的通用模型与行业模型
⏹支持应用架构的不断变更。
可以方便地重新配制以增加或去除系统而不会影响其它系统。
⏹既能够提供实时接口和批处理接口，又能够提供同步和异步接口
⏹良好的性能和数据吞吐量，并且具有灵活的可扩展性以适应企业的发展
⏹保证数据的安全的方式是根据需要有目的可以读取应用数据
⏹必须具备恢复机制，当数据传输过程中发生连接中断等异常时可以确保数据的恢复
一个完整的EAI解决方案应当包含以下五个层面：
⏹用户交互：
实现应用用户界面统一的接入与安全机制，利用门户技术进行构建。
⏹应用连接：
通过HUB或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换。
⏹业务流程整合：
实现业务流程管理，包括工作流管理和自动化流程两个方面。
⏹构建整合：
这个层面包含两个部分，一部分是构建与现有应用兼容的新应用，另一部分是对现有资源进行重用以适应新环境的需要。
⏹信息集成：
实现数据集成，在异构的数据源之间实现数据层的直接整合
相关技术：
EAI解决方案通常涉及到JCA、JMS、Web服务以及XML等多种企业级技术。
这些技术都已经成为业界的标准，从而可以最大化地保护客户投资。
这些技术既可以被包含在相关产品中供用户透明地使用，也可以由用户自己在应用程序中加以调用。
此外，SOA（面向服务的架构）随着各大厂商的追捧而变得炙手可热。
虽然SOA本身不是一个全新的概念，但由于Web服务以及网格计算等技术的成熟，SOA具备了更好的发展条件。
对于EAI来说，基于SOA的企业应用系统可以随着企业业务的变化而逐渐变化，能够实现“柔性化”的软件系统，从而降低实施EAI的成本和风险，因此我们可以说SOA的兴起给了EAI厂商一个新的机会。
5.2.ETL
5.2.1.概念
ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程。
它是构建数据仓库的重要环节。
数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合，用以支持经营管理中的决策制定过程。
数据仓库系统中有可能存在着大量的噪声数据,引起的主要原因有：
滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等。
即便是一个设计和规划良好的数据库系统，如果其中存在着大量的噪声数据，那么这个系统也是没有任何意义的，因为“垃圾进，垃圾出”（garbagein,garbageout），系统根本就不可能为决策分析系统提供任何支持。
为了清除噪声数据，必须在数据库系统中进行数据清洗。
目前有不少数据清洗研究和ETL研究，但是如何在ETL过程中进行有效的数据清洗并使这个过程可视化，此方面研究不多。
本文主要从两个方面阐述ETL和数据清洗的实现过程：
ETL的处理方式和数据清洗的实现方法。
5.2.2.ETL的处理方式
一般来说ETL的处理方式有两种，一种是在数据仓库中做数据的转换，如：
TERADATAdatawarehouse;
一种是在数据抽取之后在数据库外转换，典型的如：
IBM的Datastage、Informatica公司的Powercenter。
还有一种方式，如果数据量小，没有什么转换逻辑的时候，自己开发ETL似乎非常节省成本的一种好方式。
但是如果不能得到厂家长期的支持，必然随着数据量的增加，ETL复杂度的增加，自己开发ETL成本就不低了。
5.3.ETL与EAI之间的关系
随着集成的增多，企业信息系统之间需处理的数据量也将越来越大，数据的传输将变得越来越复杂。
ETL越来越适合用于这种数据处理的工作，并逐渐挑战传统EAI（enterpriseapplicationintegration）在系统集成中的地位了。
ETL（extraction,transformationandloading）最初ETL的设计是为了方便建立数据市场和数据仓库，并将它们升级为批处理方式。
而下一代的ETL工具则在许多功能上做了扩展，使其能够适用于企业的应用集成，并且其中的一些工具将能够起到EAI某些工具的作用。
但是ETL还不能取代EAI，下一代ETL在应用集成领域中还只是EAI的补充。
但是随着ETL技术的发展，企业在建立基于批处理数据仓库的系统集成工具时，将越来越关注对ETL的选择，同时EAI和ETL之间的界限也将变得越来越模糊。
5.4.ETL与EAI之间的区别
ETL工具适合数据集成，EAI工具则适用于流程操作。
ETL工具更加适用于解决两个系统间数据的批量或者实时同步工作，特别是当大量巨大的数据在两个系统间提取、转换和存储时，ETL的优势更加明显。
EAI则适用于工作流和商业流程管理的需求，特别是擅长处理大量小事务。
对于交互式流程，如果它没有扩展工作流的需求，没有复杂数据的转换的需求，或者需要批量实时数据的合并处理，则工具将是比较好的选择。
ETL工具比较适合于数据集成的工作，如应用系统之间的数据同步和点对点的单步交互工作；
需要实时数据处理的工作中包含了大量的数据处理、复杂的数据传输和数据运算，它同样适合采用ETL工具。
上面这些工作，即便是有些具体的处理需要通过EAI工具编程实现，我们还是可以用ETL中的工具来处理。
因为ETL工具主要是通过关系型数据库来实现大量数据操作的，所以使用这类工具来传输大块的数据将取得更好的效果。
EAI工具无疑是最适合流程集成的工具，如果流程中包含了大量的传输，那么它就必然包含了对业务流程的管理和实时交互的流程。
5.5.ETL各阶段任务
做数据仓库系统，ETL是关键的一环。
说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。
从名字上就可以看到，将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。
其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。
但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。
二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。
5.6.ETL难点
5.6.1.难点一
ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据。
其间，数据的抽取、清洗、转换和装载形成串行或并行的过程。
ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。
和OLTP系统中不同，那里充满这单条记录的insert、update和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般都是DBMS系统自身附带的工具，例如OracleSQLLoader和DB2的autoloader等。
ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来说。
⏹静态的ETL单元和动态的ETL单元实例；
一次转换指明了某种格式的数据如何格式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以在运行时，当这个ETL单元创建一个实例时才指定。
对于静态和动态的ETL单元，Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multipleinstances，而且还不是默认选项。
Powermart中将这两个概念加以区分，静态的叫做Mapping，动态运行时叫做Session。
⏹ETL元数据；
元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数据。
主要包括每次转换前后的数据结构和转换的规则。
ETL元数据还包括形式参数的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数，实参不在元数据管理范围之内。
⏹数据流程的控制；
要有可视化的流程编辑工具，提供流程定义和流程监控功能。
流程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和转换只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操作。
当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有找到很好的细分策略。
比如，我们可以规定将装载一个表的功能作为一个ETL单元，但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个Hash表，要将这个Hash表装入内存两次。
⏹转换规则的定义方法；
提供函数集提供常用规则方法，提供规则定义语言描述规则。
⏹对数据的快速索引；
一般都是利用Hash技术，将参照关系表提前装入内存，在转换时查找这个hash表。
Datastage中有Hash文件技术，Powermart也有类似的Lookup功能。
5.6.2.难点二—分类
我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。
它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。
它们包括：
⏹交互式运行环境，你可以指定数据源、目标数据，指定规则，立马ETL。
这种交互式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。
还有数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要牺牲一定的性能为代价。
所以如果要处理海量数据的话，每次读取一条记录，每次对规则进行解释执行，每次在写入一条记录，这对性能影响是非常大的。
⏹专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放在一些周边的功能上，例如读文件功能、写数据库的功能，而将精力主要放在规则的实现上面。
这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关（这也是不可忽视的因素之一）。
对于处理大数据量，处理复杂转换逻辑，这种方式的ETL实现是非常直观的。
⏹代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要运行这个ETL过程，必须要编译才行。
Datastage就是类似这样的产品，设计好的job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是什么。
以前我设计的ETL工具大挪移其实也是归属于这一类，它提供了界面让用户编写规则，最后生成C++语言，编译后即可运行。
这类工具的特点就是要在界面上下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完成读、写和转换函数。
大挪移在这方面就太弱了，规则必须手写，而且要写成标准c++语法，这未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。
另外一点，这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还有提供特定语言来实现高级功能。
例如Datastage提供一种类Basic的语言，不过他的Job的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。
⏹最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub一样地工作。
将这种类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的方法，此类主要从数据处理角度。
目前有一些产品属于EAI（EnterpriseApplicationIntegration），它的数据集成主要是一种准实时性。
所以这类产品就像Hub一样，不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中去。
虽然，这些类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。
5.6.3.难点三—转换
ETL难点一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？
宏观输入输出
从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：
⏹大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。
如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。
这种情况，输出数据的粒度和大表一样。
⏹大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表LeftJoin辅表。
大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到
升级会员 