数据仓库和BI技术概况

《数据仓库和BI技术概况》由会员分享，可在线阅读，更多相关《数据仓库和BI技术概况（25页珍藏版）》请在装配图网上搜索。

1、1. 数据仓库1.1. 概念数据仓库项目是以关系数据库为依托，以数据仓库理论为指导、以OLAP为多层次多视 角分析，以ETL工具进行数据集成、整合、清洗、加载转换，以前端工具进行前端报表展现 浏览，以反复叠代验证为生命周期的综合处理过程。最终目标是为了达到整合企业信息信息， 把数据转换成信息、知识，提供决策支持。1.2. 数据源数据库、磁带、文件、网页等等。同一主题的数据可能存储在不同的数据库、磁带、甚 至文件、网页里都有。1.3. 数据粒度粒度问题第一反应了数据细化程度；第二在决策分析层面粒度越大，细化程度越低。 一般情况，数据仓库需求存储不同粒度的数据来满足不同层面的要求。例子如顾客的移动

2、话费信息。1.4. 数据分割分割结构相同的数据，保证灵活的访问数据。1.5. 设计数据仓库 与OLTP系统的接口设计：ETL设计 数据仓库本身存储模型的设计：数据存储模型设计1.6. ETL设计难点数据仓库有多个应用数据源，导致同一对象描述方式不同： 表达方式不同：字段类型不同 度量方式不同：单位不同 对象命名方式不同：字段名称不同 数据源的数据是逐步加载到数据仓库，怎么确定数据已经加载过 如何避免对已经加载的数据的读取，提高性能 数据实时发生变化后怎么加载2. 数据存储模型过程模型：适用于操作性环境。数据模型：适用于数据仓库和操作性环境。数据模型从设计的角度分：高层次模型（实体关系型），中间

3、层建模（数据项集），物理模型。2.1. 数据仓库的存储方式数据仓库的数据由两种存储方式：一种是存储在关系数据库中，另一种是按多维的方式 存储，也就是多维数组。2.2. 数据仓库的数据分类数据仓库的数据分元数据和用户数据。用户数据按照数据粒度分别存放，一般分四个粒度:早期细节级数据，当前细节级数据， 轻度综合级，高度综合级。元数据是定义了数据的数据。传统数据库中的数据字典或者系统目录都是元数据，在数 据仓库中元数据表现为两种形式：一种是为了从操作型环境向数据仓库环境转换而建立的 元数据，它包含了数据源的各种属性以及转换时的各种属性；另一种元数据是用来与多维模 型和前端工具建立映射用的。2.3.

4、数据存储模型分类多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型 由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于 其四周，并与事实表连接。在星型的基础上，发展出雪花模式。通常来说，数据仓库使用星型模型。2.3.1. 星型模型位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据 仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得 从指标

5、实体查询返回较少的行，从而缩小访问X围。每个维表有自己的属性，维表和事实表 通过关键字相关联。星形模式虽然是一个关系模型，但是它不是一个规x化的模型。在星形模式中，维度 表被故意地非规乂化了，这是星形模式与OLTP系统中的关系模式的基本区别。使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的 优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表 就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般 都很小，甚至可以放在高速缓存中，与事实表作连接时其速度较快;便于用户理解。对于非计 算机专业的用户而言，星形模式比较

6、直观，通过分析星形模式，很容易组合出各种查询。总结一下星型模型的特点： 非正规化； 多维数据集中的每一个维度都与事实表连接（通过主键和外键）； 不存在渐变维度； 有冗余数据； 查询效率可能会比较高； 不用过多考虑正规化因素，设计维护较为简单2.3.2. 雪花模型在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括 星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不 同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储 量，因而提高了查询功能。雪花模式的维度表是基于x式理论的

7、，因此是界于第三X式和星形模式之间的一种设计 模式，通常是部分数据组织采用第三X式的规X结构，部分数据组织采用星形模式的事实表 和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层 次和处理多对多关系而对数据表进行规X化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规X化的结构更容易更新和维护。同 样雪花模式也存在不少缺点：雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外 的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查 询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。总结一下雪花模型的

8、特点： 正规化； 数据冗余少； 有些数据需要连接才能获取，可能效率较低； 规X化操作较复杂，导致设计及后期维护复杂。实际应用中，可以采取上述两种模型的混合体。如：中间层使用雪花结构以降低数据冗 余度，数据集市部分采用星型以方便数据提取及分析3. 前端分析应用模型是指为数据挖掘和数据分析以及预测定义的数据模型，有数据库模型以及电子表模型。 主流的产品有：DB2 OLAP serverMS OLAP Analysis serverHyperion Essbase OLAP serverOracle Express ServerSAS OLAP Server3.1. 电子表模型在电子表中可以向单元格

9、中插入数值或公式。电子表对于复杂的公式很有帮助，因为它 便于用户操控。电子表的缺点之一是它在大小方面很受限制，并且电子表本质上只是一个二 维结构。使用电子表存储模型构建的OLAP多维数据集可以把这个模型扩展为支持多个维度， 并且比常规的电子表大很多。在基于电子表模型的OLAP中，整个多维数据集中的任何单元 格都有可能被物理地存储。这既是好事也是坏事。优点是可以在多维数据集空间内的任何点 上输入常量值，并且在多维数据集空间内的任何点上保存计算的结果。缺点是一个称为数据 爆炸的小问题，它限制了 OLAP多维数据集的大小。基于电子表的OLAP工具往往与财务应用程序相关联。多数财务应用程序都涉及相对较

10、 小但具有复杂的非累加性(noadditive)计算的数据库。3.2. 数据库模型使用数据库模型来存储多维数据集的OLAP工具的行为截然不同。它们利用了多数报表 都需要加操作，还有相加是个关联操作这个事实。例如把数字3、5和7相加时，无论是先 把3和5相加得到8然后再加上7,还是先把5和7相加得到12然后再加上3都没有关系。 两种情况下结果都是15。在纯粹的关系数据库中，通过创建具体表以得到快速的查询结果。 在聚合表中存储的是报表需要的预先加好的数值。例如在一个包含了几千种产品、5年明细 数据，也许还有其他几个维度的事实表中，可能存储了几百万行数据，即使在只有50个子 类别和20个季度的情况下

11、，也需要好几分钟来生成一个按产品子类别或季度分组的报表。 但如果先把这些数据汇总起来，并保存到只包含子类别和季度的聚合表中，那么该表中最多 只有一千行数据，而且只根据子类别或季度分组的查询将执行得很快。事实上，根据加操作 的关联性，根据产品类别或年进行汇总的报表也可以使用相同的聚合表，同样也能很快地产 生结果。使用数据库模型进行存储的OLAP最大的优点是可以避免数据爆炸。因为使用相对较少 的聚合表提供快速的结果，可以创建比电子表模型拥有更多维度和属性的更大的多维数据集。 使用数据库模型进行存储的OLAP最大的缺点是，没有固有的方法来存储使用非关联性操作 计算的结果。一个极端复杂的财务计算就是留

12、存收益(Retained Earning Since Inception)。 为了计算这个值，必须首先计算纯收益一一而它本身就是各种加、减和乘法的大杂烩。并且 还必须计算每个时间段从开始时间点的纯收益值，以便把它们加到一起。这不是个关联操作， 所以为业务的每个单元分别计算并不能使整个公司的计算更加容易。即使是使用数据库模型存储的OLAP多维数据集也能快速地计算某些非关联操作。例如， 平均销售价格并不是一个可累加值(additive value)不能简单地把价格相加起来。但在整个产品线层次计算平均销售价格时，只要简单地计算出销售额和销售量的总数，然后在产 品线层次用销售额总数除以销售量总数。因为

13、是在计算两个可累加值的比率，所及本质上该 计算将与获取简单的可累加值一样快。数据库形式的OLAP工具通常与销售或类似的数据库关联。销售多维数据集通常都非常 巨大一一不仅有上亿条的事实表数据，并且还有具有很多属性的维度。销售多维数据集通常 都涉及累加性的度量值(美元和数量通常都是可累加的)，或者是可以基于可累加值快速计算 的公式。OLAP的一个主要优点就是能够提前计算数值，这样就能快速地呈现报表。不同的OLAP 技术有不同的优势和劣势，但一个好的OLAP实现了在涉及高度汇总值时比等同的关系查询 快很多。4. 数据集市4.1. 概念数据集市是一个小型的基于企业的一个组织或者部门的数据仓库。有两种类

14、型的数据集 市：独立型和从属型。独立型数据集市从操作性数据库中获取数据；从属型数据集市从企业 级数据仓库中获取数据。大家可以考虑一下：哪一种数据集市更为稳定？5. ETL随着企业信息化的发展，有两种方式可以完成系统间的协作和数据分析挖掘。一种是 EAI，一种是ETL。这两种方式哪一种更好，下面我们会给予解释分析。5.1. EAI5.1.1. 概念为了解决企业内部“信息孤岛“的问题，企业应用集成(Enterprise Application Integration，EAI)技术应运而生，它可以通过中间件作为粘合剂来连接企业内外各种业务 相关的异构系统、应用以及数据源，从而满足E-merce、ER

15、P、CRM、SCM、OA、数据库、数 据仓库等重要系统之间无缝共享和交换数据的需要。EAI涉及技术广泛，实施复杂。EAI的核心是使用中间件连接企业应用。有多种不同类 型的中间件可以提供EAI的功能。在选择EAI中间件时，要注意基本特征如下： 通过中间件将不同的应用连接起来，保证应用的独立性，在不需要修改应用自身的 业务逻辑的同时，又解决了数据共享问题。 对核心共享业务数据模型的处理与支持 实现业务流程自动化。确保各个部门在采用不同的系统的同时可以协同完成同一个 工作。 对流程管理提供预定义的通用模型与行业模型 支持应用架构的不断变更。可以方便地重新配制以增加或去除系统而不会影响其它 系统。 既

16、能够提供实时接口和批处理接口，又能够提供同步和异步接口 良好的性能和数据吞吐量，并且具有灵活的可扩展性以适应企业的发展 保证数据的安全的方式是根据需要有目的可以读取应用数据 必须具备恢复机制，当数据传输过程中发生连接中断等异常时可以确保数据的恢复一个完整的EAI解决方案应当包含以下五个层面： 用户交互：实现应用用户界面统一的接入与安全机制，利用门户技术进行构建。 应用连接：通过HUB或总线架构，实现应用与应用之间的连接，完成相关的数据 路由与数据格式转换。 业务流程整合：实现业务流程管理，包括工作流管理和自动化流程两个方面。 构建整合：这个层面包含两个部分，一部分是构建与现有应用兼容的新应用，

17、另一 部分是对现有资源进行重用以适应新环境的需要。 信息集成：实现数据集成，在异构的数据源之间实现数据层的直接整合相关技术：EAI解决方案通常涉及到JCA、JMS、Web服务以及XML等多种企业级技术。这些技术都 已经成为业界的标准，从而可以最大化地保护客户投资。这些技术既可以被包含在相关产品 中供用户透明地使用，也可以由用户自己在应用程序中加以调用。此外，SOA （面向服务的 架构）随着各大厂商的追捧而变得炙手可热。虽然SOA本身不是一个全新的概念，但由于 Web服务以及网格计算等技术的成熟，SOA具备了更好的发展条件。对于EAI来说，基于SOA 的企业应用系统可以随着企业业务的变化而逐渐变

18、化，能够实现“柔性化的软件系统，从 而降低实施EAI的成本和风险，因此我们可以说SOA的兴起给了 EAI厂商一个新的机会。5.2. ETL5.2.1. 概念ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程。它是构建数据 仓库的重要环节。数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合， 用以支持经营管理中的决策制定过程。数据仓库系统中有可能存在着大量的噪声数据，引起 的主要原因有：滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等。即 便是一个设计和规划良好的数据库系统，如果其中存在着大量的噪声数据，那么这个系统也 是没有任何意义

19、的，因为“垃圾进，垃圾出”（garbagein, garbage out），系统根本就不可 能为决策分析系统提供任何支持。为了清除噪声数据，必须在数据库系统中进行数据清洗。 目前有不少数据清洗研究和ETL研究，但是如何在ETL过程中进行有效的数据清洗并使这个 过程可视化，此方面研究不多。本文主要从两个方面阐述ETL和数据清洗的实现过程：ETL 的处理方式和数据清洗的实现方法。5.2.2. ETL的处理方式一般来说ETL的处理方式有两种，一种是在数据仓库中做数据的转换，如：TERADATA datawarehouse； 一种是在数据抽取之后在数据库外转换，典型的如：IBM的Datastage、

20、Informatica 公司的 Powercenter。还有一种方式，如果数据量小，没有什么转换逻辑的时候，自己开发ETL似乎非常节省 成本的一种好方式。但是如果不能得到厂家长期的支持，必然随着数据量的增加，ETL复杂 度的增加，自己开发ETL成本就不低了。5.3. ETL与EAI之间的关系随着集成的增多，企业信息系统之间需处理的数据量也将越来越大，数据的传输将变得 越来越复杂。ETL越来越适合用于这种数据处理的工作，并逐渐挑战传统EAI(enterprise application integration)在系统集成中的地位了。ETL(extraction, transformation a

21、nd loading)最初 ETL 的设计是为 了 方便建立数据 市场和数据仓库，并将它们升级为批处理方式。而下一代的ETL工具则在许多功能上做了扩 展，使其能够适用于企业的应用集成，并且其中的一些工具将能够起到EAI某些工具的作用。 但是ETL还不能取代EAI，下一代ETL在应用集成领域中还只是EAI的补充。但是随着ETL 技术的发展，企业在建立基于批处理数据仓库的系统集成工具时，将越来越关注对ETL的选 择，同时EAI和ETL之间的界限也将变得越来越模糊。5.4. ETL与EAI之间的区别ETL工具适合数据集成，EAI工具则适用于流程操作。ETL工具更加适用于解决两个系统间数据的批量或者实

22、时同步工作，特别是当大量巨大 的数据在两个系统间提取、转换和存储时，ETL的优势更加明显EAI则适用于工作流和商 业流程管理的需求，特别是擅长处理大量小事务。对于交互式流程，如果它没有扩展工作流 的需求，没有复杂数据的转换的需求，或者需要批量实时数据的合并处理，则工具将是比较 好的选择。ETL工具比较适合于数据集成的工作，如应用系统之间的数据同步和点对点的单步交互 工作；需要实时数据处理的工作中包含了大量的数据处理、复杂的数据传输和数据运算，它 同样适合采用ETL工具。上面这些工作，即便是有些具体的处理需要通过EAI工具编程实 现，我们还是可以用ETL中的工具来处理。因为ETL工具主要是通过关

23、系型数据库来实现 大量数据操作的，所以使用这类工具来传输大块的数据将取得更好的效果。EAI工具无疑是最适合流程集成的工具，如果流程中包含了大量的传输，那么它就必然 包含了对业务流程的管理和实时交互的流程。5.5. 各阶段任务做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就 是倒数据的工具。从名字上就可以看到，将倒数据的过程分成3个步骤，E、T、L分别代表 抽取、转换和装载。其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓 库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动， 按照固定周期运行的，甚至现

24、在还有人提出了实时ETL的概念。二是数据量，一般都是巨大 的，值得你将数据流动的过程拆分成E、T和L。5.6. ETL 难点5.6.1. 难点一ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据。其间，数据 的抽取、清洗、转换和装载形成串行或并行的过程ETL的核心还是在于T这个过程，也就 是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件， 其复杂度没有转换部件高。和OLTP系统中不同，那里充满这单条记录的insert、update 和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般 都是DBMS系统自身附带的工具

25、，例如Oracle SQLLoader和DB2的autoloader等。ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来 说。 静态的ETL单元和动态的ETL单元实例；一次转换指明了某种格式的数据如何格 式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以 在运行时，当这个ETL单元创建一个实例时才指定。对于静态和动态的ETL单元， Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job 同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multiple instances，而且还

26、不是默认选项。Powermart中将这两个概念加以区分，静态的 叫做Mapping，动态运行时叫做Session。 ETL元数据；元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数 据。主要包括每次转换前后的数据结构和转换的规则ETL元数据还包括形式参数 的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数， 实参不在元数据管理X围之内。 数据流程的控制；要有可视化的流程编辑工具，提供流程定义和流程监控功能。流 程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由 开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和

27、转换 只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操 作。当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有 找到很好的细分策略。比如，我们可以规定将装载一个表的功能作为一个ETL单元， 但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个 Hash表，要将这个Hash表装入内存两次。 转换规则的定义方法;提供函数集提供常用规则方法，提供规则定义语言描述规则。 对数据的快速索引；一般都是利用Hash技术，将参照关系表提前装入内存，在转 换时查找这个hash表。Datastage中有Hash文件技术，Powermart也有类似的

28、 Lookup 功能。5.6.2. 难点二一分类我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。 它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。它们包 括： 交互式运行环境，你可以指定数据源、目标数据，指定规则，立马ETL。这种交互 式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为 一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。还有 数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要 牺牲一定的性能为代价。所以如果要处理海量数据的话，每次读取一条记录，每次 对规则进行解

29、释执行，每次在写入一条记录，这对性能影响是非常大的。 专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放 在一些周边的功能上，例如读文件功能、写数据库的功能，而将精力主要放在规则 的实现上面。这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关(这 也是不可忽视的因素之一)。对于处理大数据量，处理复杂转换逻辑，这种方式的 ETL实现是非常直观的。 代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让 你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要 运行这个ETL过程，必须要编译才行。Datastage就是类似这样的产品

30、，设计好的 job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是 什么。以前我设计的ETL工具大挪移其实也是归属于这一类，它提供了界面让用户 编写规则，最后生成C+语言，编译后即可运行。这类工具的特点就是要在界面上 下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完成读、写和转 换函数。大挪移在这方面就太弱了，规则必须手写，而且要写成标准c+语法，这 未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。另外一点， 这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所 有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还

31、有提供特 定语言来实现高级功能。例如Datastage提供一种类Basic的语言，不过他的Job 的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。 最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub 一样地工作。将这种 类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的方法， 此类主要从数据处理角度。目前有一些产品属于EAI (Enterprise Application Integration)，它的数据集成主要是一种准实时性。所以这类产品就像Hub 一样， 不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中 去。虽然，这些

32、类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的 选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员 技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。5.6.3. 难点三一转换ETL难点一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类 型呢？宏观输入输出从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类： 大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据 仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。 如果用SQL实现，必然需要

33、将一个大表和一堆小表都Join起来，当然如果使用ETL 工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大 表一样。 大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻 辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳 定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数 据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复 也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表， 形成大小交的类型。这类情况的输出数据粒度和主表一样。 站着进来，躺着出去。事务系

34、统中为了提高系统灵活性和扩展性，很多信息放在代 码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽 化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode 肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄 表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定 要比窄表粗一些，就粗在那个代码字段上。 聚集。数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数 据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特 定字段（维度），对度量字段再使用某种聚集函数。但是对

35、于大数据量情况下，聚 集算法的优化仍是探究的一个课题。例如是直接使用SQL的Group by，还是先排 序，在处理。微观规则从数据的转换的微观细节分，可以分成下面的几个基本类型，当然还有一些复杂的组合 情况，例如先运算，在参照转换的规则，这种基于基本类型组合的情况就不在此列了 ETL 的规则是依赖目标数据的，目标数据有多少字段，就有多少条规则。 直接映射，原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源 字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要 做一些简单运算。 字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般 对数值型字段

36、而言。 参照转换，在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组 中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是 比较合适也是最常见的，在整个ETL开始之前，它就装入内存，对性能提高的帮助 非常大。 字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如XX号。而 且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符 串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这 种规则的时候，一定要加上异常处理。 空值判断，对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作 为特定一种维成员？这恐

37、怕还要看应用的情况，也是需要进一步探求的。但是无论 怎样，对于可能有NULL值的字段，不要采用“直接映射的规则类型，必须对空 值进行判断，目前我们的建议是将它转换成特定的值。 日期转换，在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法， 例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类 型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、 6位月份值等。 日期运算，基于日期，我们通常会计算日差、月差、时长等。一般数据库提供的日 期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必 须有一套自己的日期运算函数集。

38、 聚集运算，对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用 聚集函数得来的，这些聚集函数为SQL标准中，包括sum,count,avg,min,max。 既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对 目标字段取一个固定的或是依赖系统的值。5.6.4. 难点四一数据质量“不要绝对的数据准确，但要知道为什么不准确。”这是我们在构建BI系统是对数据准确性的要求。确实，对绝对的数据准确谁也没有把 握，不仅是系统集成商，包括客户也是无法确定。准确的东西需要一个标准，但首先要保证 这个标准是准确的，至少现在还没有这样一个标准。客户会提出一个相对标准，例如将你的

39、OLAP数据结果和报表结果对比。虽然这是一种不太公平的比较，你也只好认了吧。首先在数据源那里，已经很难保证数据质量了，这一点也是事实。在这一层有哪些可能 原因导致数据质量问题？可以分为下面几类： 数据格式错误，例如缺失数据、数据值超出X围或是数据格式非法等。要知道对于 同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例 如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。 这类情况诸如XX、手机号、非日期类型的日期字段等。 数据一致性，同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束， 这通常会导致数据不一致。例如在帐务表中会出现一个用户表中

40、没有的用户ID， 在例如有些代码在代码表中找不到等。 业务逻辑的合理性，这一点很难说对与错。通常，数据源系统的设计并不是非常严 谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在 多个用户ID也是有可能发生的。对这种情况，有什么办法吗？构建一个BI系统，要做到完全理解数据源系统根本就是不可能的。特别是数据源系统 在交付后，有更多维护人员的即兴发挥，那更是要花大量的时间去寻找原因。以前曾经争辩 过设计人员对规则描述的问题，有人提出要在ETL开始之前务必将所有的规则弄得一清二楚。 我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要 正面这些脏数

41、据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错 误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生 重大影响。 规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错 误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求 的一个课题。规则是依附于目标字段的，在难点三中，提到规则的分类。但是规则 总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员 能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去 很多手工操作了。 ETL开发错误。即时规则很明确，ETL开发的

42、过程中也会发生一些错误，例如逻辑 错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常 开发人员没注意，一个大于等于号写成大于号就导致数据错误。 人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL 过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的 理解去运行，发生的错误可能是误删了数据、重复装载数据等。5.6.5. 难点五一质量保证上回提到ETL数据质量问题，这是无法根治的，只能采取特定的手段去尽量避免，而且 必须要定义出度量方法来衡量数据的质量是好还是坏。对于数据源的质量，客户对此应该更 加关心，如果在这个源头不能保证比较

43、干净的数据，那么后面的分析功能的可信度也都成问 题。数据源系统也在不断进化过程中，客户的操作也在逐渐规X中，BI系统也同样如此。 本文探讨一下对数据源质量和ETL处理质量的应对方法。如何应对数据源的质量问题？记得在onteldatastage列表中也讨论过一个话题一-1 的处理”，在数据仓库模型维表中，通常有一条-1记录，表示“未知”，这个未知含义可广 了，任何可能出错的数据，NULL数据甚至是规则没有涵盖到的数据，都转成-1。这是一种 处理脏数据的方法，但这也是一种掩盖事实的方法。就好像写一个函数FileOpen(filename)， 返回一个错误码，当然，你可以只返回一种错误码，如-1，但

44、这是一种不好的设计，对于调 用者来说，他需要依据这个错误码进行某些判断，例如是文件不存在，还是读取权限不够， 都有相应的处理逻辑。数据仓库中也是一样，所以，建议将不同的数据质量类型处理结果分 别转换成不同的值，譬如，在转换后，-1表示参照不上，-2表示NULL数据等。不过这仅仅 对付了上回提到的第一类错误，数据格式错误。对于数据一致性和业务逻辑合理性问题，这 仍有待探求。但这里有一个原则就是“必须在数据仓库中反应数据源的质量”。对于ETL过程中产生的质量问题，必须有保障手段。从以往的经验看，没有保障手段给 实施人员带来麻烦重重。实施人员对于反复装载数据一定不会陌生，甚至是最后数据留到最 后的C

45、ube，才发现了第一步ETL其实已经错了。这个保障手段就是数据验证机制，当然， 它的目的是能够在ETL过程中监控数据质量，产生报警。这个模块要将实施人员当作是最终 用户，可以说他们是数据验证机制的直接收益者。首先，必须有一个对质量的度量方法，什么是高质什么是低质，不能靠感官感觉，但这 却是在没有度量方法条件下通常的做法。那经营分析系统来说，联通总部曾提出测试规X， 这其实就是一种度量方法，例如指标的误差X围不能高于5%等，对系统本身来说其实必须 要有这样的度量方法，先不要说这个度量方法是否科学。对于ETL数据处理质量，他的度量 方法应该比联通总部测试规X定义的方法更要严格，因为他更多将BI系统

46、看作一个黑盒子， 从数据源到展现的数据误差允许一定的误差。而ETL数据处理质量度量是一种白盒的度量， 要注重每一步过程。因此理论上，要求输入输出的指标应该完全一致。但是我们必须正面完 全一致只是理想，对于有误差的数据，必须找到原因。在质量度量方法的前提下，就可以建立一个数据验证框架。此框架依据总量、分量数据 稽核方法，该方法在高的数据仓库中的数据稽核技术一文中已经指出。作为补充，下面 提出几点功能上的建议： 提供前端。将开发实施人员当作用户，同样也要为之提供友好的用户界面。稽核 技术一文中指出测试报告的形式，这种形式还是要依赖人为判断，在一堆数据中 去找规律。到不如用OLAP的方式提供界面，不

47、光是加上测试统计出来的指标结果， 并且配合度量方法的计算。例如误差率，对于误差率为大于0的指标，就要好好查 一下原因了。 提供框架。数据验证不是一次性工作，而是每次ETL过程中都必须做的。因此，必 须有一个框架，自动化验证过程，并提供扩展手段，让实施人员能够增加验证X 围。有了这样一个框架，其实它起到规X化操作的作用，开发实施人员可以将主要 精力放在验证脚本的编写上，而不必过多关注验证如何融合到流程中，如何展现等 工作。为此，要设计一套表，类似于DM表，每次验证结果数据都记录其中，并且 自动触发多维分析的数据装载、发布等。这样，实施人员可以在每次装载，甚至在 流程过程中就可以观察数据的误差率。

48、特别是，如果数据仓库的模型能够统一起来， 甚至数据验证脚本都可以确定下来，剩下的就是规X流程了。 规X流程。上回提到有一种ETL数据质量问题是由于人工处理导致的，其中最主要 原因还是流程不规X。开发实施人员运行单独一个ETL单元是很方便的，虽然以前 曾建议一个ETL单元必须是“可重入”的，这能够解决误删数据，重复装载数据问 题。但要记住数据验证也是在流程当中，要让数据验证能够日常运作，就不要让实 施者感觉到他的存在。总的来说，规X流程是提高实施效率的关键工作，这也是以 后要继续探求的。5.6.6. 难点六一元数据对于元数据(Metadata)的定义到目前为止没有什么特别精彩的，这个概念非常广，

49、一 般都是这样定义，“元数据是描述数据的数据(Data about Data)”，这造成一种递归定义， 就像问小强住在哪里，答，在旺财隔壁。按照这样的定义，元数据所描述的数据是什么呢？ 还是元数据。这样就可能有元元元.元数据。我还听说过一种对元数据，如果说数据是一 抽屉档案，那么元数据就是分类标签。那它和索引有什么区别？元数据体现是一种抽象，哲学家从古至今都在抽象这个世界，力图找到世界的本质。抽 象不是一层关系，它是一种逐步由具体到一般的过程。例如我-男人-人-哺乳动物-生物 这就是一个抽象过程，你要是在软件业混会发现这个例子很常见，面向对象方法就是这样一 种抽象过程。它对世界中的事物、过程进

50、行抽象，使用面向对象方法，构建一套对象模型。 同样在面向对象方法中，类是对象的抽象，接口又是对类的抽象。因此，我认为可以将“元” 和“抽象”换一下，叫抽象数据是不是好理解一些。常听到这样的话，“xx领导的讲话高屋建瓴，给我们后面的工作指引的清晰的方向”， 这个成语“高屋建瓴”，站在10楼往下到水，居高临下，能砸死人，这是指站在一定的高度 看待事物，这个一定的高度就是指他有够“元”。在设计模式中，强调要对接口编程，就是 说你不要处理这类对象和那类对象的交互，而要处理这个接口和那个接口的交互，先别管 他们内部是怎么干的。元数据存在的意义也在于此，虽然上面说了一通都撤到哲学上去，但这个词必须还是要

51、结合软件设计中看，我不知道在别的领域是不是存在Metadata这样的叫法，虽然我相信别 的领域必然有类似的东东。元数据的存在就是要做到在更高抽象一层设计软件。这肯定有 好处，什么灵活性啊，扩展性啊，可维护性啊，都能得到提高，而且架构清晰，只是弯弯太 多，要是从下往上看，太复杂了。很早以前，我曾看过backorifice的代码，我靠，一个简 单的功能，从这个类转到父类，又转到父类，很不理解，为什么一个简单的功能不在一个类 的方法中实现就拉到了呢？现在想想，还真不能这样，这虽然使代码容易看懂了，但是结构 确实混乱的，那他只能干现在的事，如果有什么功能扩展，这些代码就废了。98年元数据的概念当时叫做

52、元数据驱动的系统架构，后来在QiDSS中也用到这个概念构建QiNavigator,但是现在觉得元数据也没啥，不就是建一堆表描述界面的元素，再利用这些 数据自动生成界面吗。到了数据仓库系统中，这个概念更强了，是数据仓库中一个重要的部 分。但是至今，我还是认为这个概念过于玄乎，看不到实际的东西，市面上有一些元数据管 理的东西，但是从应用情况就得知，用的不多。之所以玄乎，就是因为抽象层次没有分清楚， 关键就是对于元数据的分类(这种分类就是一种抽象过程)和元数据的使用。你可以将元数 据抽象成0和1，但是那样对你的业务有用吗？必须还得抽象到适合的程度，最后问题还是 “度”。6. OLAP6.1. 概念联

53、机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd于1993年提出的。当时， Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的需要，SQL对大数据 库进行的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量 计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此Codd提出了多维数 据库和多维分析的概念。OLAP是大多数数据仓库解决方案中使用的报告方式的一种，通常被作为数据仓库的解 决方案，这是错误的表达。数据仓库最重要的特性是数据集成，最重要的用途是数据展现。OLAP服务不是针对数 据集成设计的，而是针对数据展现设计的，是

54、一种强大的数据展现方法，是数据仓库解决方 案的一部分。6.2. OLAP基本操作OLAP的基本多维分析操作有钻取(Drill-up和Drill-down)、切片(Slice)和切块(Dice)、 以及旋转(Pivot)等，让用户从多种维度、多个侧面、多种数据综合观察数据，从而深入 的了解和分析数据。OLAP的基本多维分析操作迎合了人的思维，减少和降低的混淆。6.2.1. 数据切片(slice)切片操作就是在某个或某些维上选定一个属性成员，而在其他维上取一定区间的属性成 员，或全部属性成员来观察数据的一种分析方式。g 国43所示是一个按产品维、城市睡利时间维(年)组织起来的产品 销售掣据，用寥维

55、数幻表示为(时队 城市S,销售额)，如果在城 市维上选定一个维成员(设为上海”或“广州* )，就佃到了在城一市推 一的个切升：:7 J 如果庄产品维.：选定个维成员翌为立电视机”或七L 到压产品睡上的 个切氐显然,这些切片律J数了在决.IH图4.3数据均井示意图糖藏6.2.2. 数据切块(dice)切块就是在各个维上去一定区间的成员属性，或全部成员属性来观察数据的一种分析方 式，可以认为切片是切块的特例，切块是切片的扩展。6.2.3. 数据上探、下钻(drill-up/drill-down)钻取包含向下钻(Drill-down)和向上钻(Drill-up)/上卷(Roll-up)操作。下钻指从

56、概括 性的数据出发获得相应的更详细的数据，上钻则相反。钻取的深度与维度所划分的层次相对 应。IhlNmrl 探旧曲JililJ 1yo部gr鬲部门3fiflWCH年郡门1季度a季匣3季受4取W 1 1如IS邮in!55ir为fl： 11 ;弓20.118S7【果刈时if遴鹰3定 2是我们能确J到协最 细节的数据.不能再进-西下钻。如果对时间绯度定义了 “年 “季废”、“JJ份*、周”-，日计箸更参的屋次，则还可以进 步钻皎.类似地，也可以在部门桀度上品行岛取.6.2.4. 数据旋转（prvot）H.b -3，1.淘ill i广,l丽5仙心L李原.1 .-.知5 JJ If Ji和r.也旋转即改

57、变一个报告或页面显示的维方向。旋转可能包含交换行和列，或是把某一个行 维移到列为中去，或包页面显示中的一个维和页面外的维进行交换。6.2.5. 其他OLAP操作除了上面的几种方式外，有些OLAP系统还提供其他的方式：如钻透，以及获取最大最 小值的N项等等。6.3. OLAP的数据模型从上一节可以看出OLAP工具事实上是定义了数据存储模型。在2.数据存储模型我们可 以知道，OLAP的数据模型基本上有两种。接下来我们讲一下基本概念6.3.1. 数据立方体数据立方体是一种面向“主题”和“属性”而建立起来的一种多维数据集，一般来说一 个数据立方体是针对一个“主题”的，而“属性”就是维度。从这点上上讲，

58、数据立方体与 维度很像对象与属性之间的关系。例如，对于销售数据构建数据立方体，维度就包含了：订 单编号、制单时间、销售人员、货品、数量、售价、折扣换句话来解释，数据立方体是包含维度和事实的。事实是主题，维度是属性。维度是人们观察数据的特定角度。例如：时间，地点，商品，供应商等等。每一个维度 都有一个维度表。人们观察数据的某个特定角度还可以存在细节程度不同的多个描述层次， 我们称这些层次为维的层次，如时间可分为年、月、日。维的一个取值称为该维的一个维成 员。如果维已经分成了多个层次，则维成员就是不同维层次取值的组合。主题，就是数据立方体中的事实表。事实数据表可能包含业务销售数据，如商品买卖所 产

59、生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实）， 并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由 多个部分组成的索引，该索引包含作为外键的相关性维度表的主键。包含在事实数据表中的“度量值有两中：一种是可以累计的度量值，另一种是非累计 的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可 以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售 情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一 座大厦的不同位置测量温度时，如果将大厦中所有不同位置

60、的温度累加是没有意义的，但是 求平均值是有意义的。一般来说，一个事实数据表都要和一个或多个维度表相关联，用户在 利用事实数据表创建多维数据集时，可以使用一个或多个维度表。OLAP分析是建立在多维数据模型基础上的。有两种实施方案可供选取，一种是直接采 用多维数据库进行联机分析处理，叫做多维联机分析处理，简称MOLAP。而如果采用关系数 据库来存放多维数据进行联机分析处理，则称之为关系联机分析处理，简称ROLAP。6.3.2. 多维联机分析处理（MOLAP）6.3.2.1. 概念在RDBMS中，数据以关系的形式来组织存在。而在多维数据库中，数据以多维的方式来 组织存储，形成大量的稀疏矩阵。多维数据

61、库的维是通过对问题的分析得到的，如分析各产 品在各地的销售情况，可以选取地理维，产品维，以销量为事实的度量，形成多维数据，表 达现实中的一对多和多对多的关系。在关系型数据库中，只有一对多的关系。同时关系型数 据库需要更多的表和存储空间。1啊*电WU1加HU-if I翳堆表）询1蛾:值拒：!/抱,番咨L北50西北尚TA1UU费ill东北网芦ll7&玖/山,1此Kbfi i .匚苇表：的幼舜川沮3-ILiJil.IL7-IL?060Idii210；：11170曲网。加IV1401必%侦币.| L1LKI波箝却ii210品匕40旭*lLso服fifli胁ifiWj-；LpgMJ29-调HO询即瑚3

62、Hi虱11M直2SH聊|fL,k理：ii时7?iiX果山I 3萍功梢亍.-放由上图可以看出，如果取东北的冰箱数据，在多维数据库中和关系型数据库的读取数据量是不一样的。同时，在多维数据库中通常会对用户数据做预处理，当用户来请求数据时，预先已经算 好数据7，这就是以空间换时间的理论。6.3.2.2. 维的分类多维数据库的另外一个重要概念是维内元素的类的概念。类是对维成员的一个按照某标 准的划分。比如产品可分为畅销或者非畅销。类和层次的概念是不一样的，维的层次是为了上下钻取数据，让用户从不同层次看数据;而类是为了在不同类别上进行比较。类和层次的区别： 意义不同： 层次表达的是变量的不同层次，也就是维

63、的父子关系。 类表达的是同一维度的某一类成员的共同特征。 分析方式不同： 层次上进行的是上下钻取 类总要是分析和归纳在实际环境中，通常是层次和类上的综合分析。6.3.2.3. 存储方式MDDB是经过高度压缩的索引和指针结构。每一个对象由聚集成组的单元块组成，每一 个单元块由类似于多维数组的结构存储。由于有些维度间的组合不一定能产生有效的值，因此多维数据库必须是一个稀疏矩阵， 可以忽略空值、缺省和重复数据。时间是一个比较特殊的维度，建议采用一个时间序列的值来存储数据，简化对数据的处 理。6.3.3. 关系联机分析处理（ROLAP）6.3.3.1.概念同专用的多维数据库相比，ROLAP虽然表达起来不大自然，但是也是一种表达方式。H3IKM.1Z1KA1-4不知Lim_iduIex*