数据仓库和BI技术概况

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

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

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

4、都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。 在星型的基础上，发展出雪花模式。通常来说，数据仓库使用星型模型。星型模型位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。 位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。 星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在

5、星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。 使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。总结一下星型模型的特点：非正规化；多维数据集中的每一个维度都与事实表连接（通过主键和外键）；不存在渐变维度；有冗余

6、数据；查询效率可能会比较高；不用过多考虑正规化因素，设计维护较为简单雪花模型在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，

7、为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规范化的结构更容易更新和维护。同样雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。总结一下雪花模型的特点：正规化；数据冗余少；有些数据需要连接才能获取，可能效率较低；规范化操作较复杂，导致设计及后期维护复杂。实际应用中，可以采取上述两种模型的混合体。如：中间层使用雪花结构以降低数据冗余度，数据集市部分采

8、用星型以方便数据提取及分析前端分析应用模型是指为数据挖掘和数据分析以及预测定义的数据模型，有数据库模型以及电子表模型。主流的产品有：DB2 OLAP serverMS OLAP Analysis server HYPERLINK /a2010/0921/1107/000001107002.shtml Hyperion Essbase OLAP server HYPERLINK /a2010/0921/1107/000001107031.shtml Oracle Express Server HYPERLINK /a2010/0921/1107/000001107034.shtml%20 SAS

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

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

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

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

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

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

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

16、展性以适应企业的发展保证数据的安全的方式是根据需要有目的可以读取应用数据必须具备恢复机制，当数据传输过程中发生连接中断等异常时可以确保数据的恢复一个完整的 EAI 解决方案应当包含以下五个层面：用户交互：实现应用用户界面统一的接入与安全机制，利用门户技术进行构建。应用连接：通过 HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换。 业务流程整合：实现业务流程管理，包括工作流管理和自动化流程两个方面。构建整合：这个层面包含两个部分，一部分是构建与现有应用兼容的新应用，另一部分是对现有资源进行重用以适应新环境的需要。信息集成：实现数据集成，在异构的数据源之间实现数据层的

17、直接整合相关技术：EAI解决方案通常涉及到JCA、JMS、Web服务以及XML等多种企业级技术。这些技术都已经成为业界的标准，从而可以最大化地保护客户投资。这些技术既可以被包含在相关产品中供用户透明地使用，也可以由用户自己在应用程序中加以调用。此外，SOA（面向服务的架构）随着各大厂商的追捧而变得炙手可热。虽然SOA本身不是一个全新的概念，但由于Web服务以及网格计算等技术的成熟，SOA具备了更好的发展条件。对于EAI 来说，基于SOA的企业应用系统可以随着企业业务的变化而逐渐变化，能够实现“柔性化”的软件系统，从而降低实施EAI的成本和风险，因此我们可以说SOA的兴起给了EAI厂商一个新的机

18、会。ETL概念ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程。它是构建数据仓库的重要环节。数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合，用以支持经营管理中的决策制定过程。数据仓库系统中有可能存在着大量的噪声数据,引起的主要原因有：滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等。即便是一个设计和规划良好的数据库系统，如果其中存在着大量的噪声数据，那么这个系统也是没有任何意义的，因为“垃圾进，垃圾出”（garbagein, garbage out），系统根本就不可能为决策分析系统提供任何支持。为了清除噪声数据，必须在数据库系

19、统中进行数据清洗。目前有不少数据清洗研究和ETL研究，但是如何在ETL过程中进行有效的数据清洗并使这个过程可视化，此方面研究不多。本文主要从两个方面阐述ETL和数据清洗的实现过程：ETL的处理方式和数据清洗的实现方法。ETL的处理方式一般来说ETL的处理方式有两种，一种是在数据仓库中做数据的转换，如：TERADATA datawarehouse;一种是在数据抽取之后在数据库外转换，典型的如：IBM的Datastage、Informati HYPERLINK /corpCenter/249.html t _blank ca公司的Powercenter。还有一种方式，如果数据量小，没有什么转换逻辑

20、的时候，自己开发ETL似乎非常节省成本的一种好方式。但是如果不能得到厂家长期的支持，必然随着数据量的增加，ETL复杂度的增加，自己开发ETL成本就不低了。ETL与EAI 之间的关系随着集成的增多，企业信息系统之间需处理的数据量也将越来越大，数据的传输将变得越来越复杂。ETL越来越适合用于这种数据处理的工作，并逐渐挑战传统EAI(enterprise application integration)在系统集成中的地位了。ETL(extraction, transformation and loading)最初ETL的设计是为了方便建立数据市场和数据仓库，并将它们升级为批处理方式。而下一代的ETL

21、工具则在许多功能上做了扩展，使其能够适用于企业的应用集成，并且其中的一些工具将能够起到EAI某些工具的作用。但是ETL还不能取代EAI，下一代ETL在应用集成领域中还只是EAI的补充。但是随着ETL技术的发展，企业在建立基于批处理数据仓库的系统集成工具时，将越来越关注对ETL的选择，同时EAI和ETL之间的界限也将变得越来越模糊。ETL与EAI 之间的区别ETL工具适合数据集成，EAI工具则适用于流程操作。 ETL工具更加适用于解决两个系统间数据的批量或者实时同步工作，特别是当大量巨大的数据在两个系统间提取、转换和存储时，ETL的优势更加明显。EAI则适用于工作流和商业流程管理的需求，特别是擅

22、长处理大量小事务。对于交互式流程，如果它没有扩展工作流的需求，没有复杂数据的转换的需求，或者需要批量实时数据的合并处理，则工具将是比较好的选择。ETL工具比较适合于数据集成的工作，如应用系统之间的数据同步和点对点的单步交互工作；需要实时数据处理的工作中包含了大量的数据处理、复杂的数据传输和数据运算，它同样适合采用ETL 工具。上面这些工作，即便是有些具体的处理需要通过EAI工具编程实现，我们还是可以用ETL中的工具来处理。因为 ETL工具主要是通过关系型数据库来实现大量数据操作的，所以使用这类工具来传输大块的数据将取得更好的效果。EAI工具无疑是最适合流程集成的工具，如果流程中包含了大量的传输

23、，那么它就必然包含了对业务流程的管理和实时交互的流程。ETL各阶段任务做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。从名字上就可以看到，将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。ETL难点难点一ETL的过程就是数据流动的过程，从不同异构数据

24、源流向统一的目标数据。其间，数据的抽取、清洗、转换和装载形成串行或并行的过程。ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。和OLTP系统中不同，那里充满这单条记录的insert、update和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般都是DBMS系统自身附带的工具，例如Oracle SQLLoader和DB2的autoloader等。ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来说。静态的ETL单元和动态的ET

25、L单元实例；一次转换指明了某种格式的数据如何格式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以在运行时，当这个ETL单元创建一个实例时才指定。对于静态和动态的ETL单元，Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multiple instances，而且还不是默认选项。Powermart中将这两个概念加以区分，静态的叫做Mapping，动态运行时叫做Session。ETL元数据；元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数据。主要包括每次转换前

26、后的数据结构和转换的规则。ETL元数据还包括形式参数的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数，实参不在元数据管理范围之内。数据流程的控制；要有可视化的流程编辑工具，提供流程定义和流程监控功能。流程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和转换只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操作。当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有找到很好的细分策略。比如，我们可以规定将装载一个表的功能作为一个ETL单元

27、，但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个Hash表，要将这个Hash表装入内存两次。转换规则的定义方法；提供函数集提供常用规则方法，提供规则定义语言描述规则。对数据的快速索引；一般都是利用Hash技术，将参照关系表提前装入内存，在转换时查找这个hash表。Datastage中有Hash文件技术，Powermart也有类似的Lookup功能。难点二分类我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。它们包括：交互式运行环境，你可以指定数据源、目标数据，指定规

28、则，立马ETL。这种交互式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。还有数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要牺牲一定的性能为代价。所以如果要处理海量数据的话，每次读取一条记录，每次对规则进行解释执行，每次在写入一条记录，这对性能影响是非常大的。专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放在一些周边的功能上，例如读文件功能、写数据库的功能，而将精力主要放在规则的实现上面。这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关（这也是不

29、可忽视的因素之一）。对于处理大数据量，处理复杂转换逻辑，这种方式的ETL实现是非常直观的。代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要运行这个ETL过程，必须要编译才行。Datastage就是类似这样的产品，设计好的job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是什么。以前我设计的ETL工具大挪移其实也是归属于这一类，它提供了界面让用户编写规则，最后生成C+语言，编译后即可运行。这类工具的特点就是要在界面上下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完

30、成读、写和转换函数。大挪移在这方面就太弱了，规则必须手写，而且要写成标准c+语法，这未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。另外一点，这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还有提供特定语言来实现高级功能。例如Datastage提供一种类Basic的语言，不过他的Job的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub一样地工作。将这种类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的

31、方法，此类主要从数据处理角度。目前有一些产品属于EAI（Enterprise Application Integration），它的数据集成主要是一种准实时性。所以这类产品就像Hub一样，不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中去。虽然，这些类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。难点三转换ETL难点一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？宏观输入输出从对数

32、据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大

33、数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字

34、段上。聚集。数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特定字段（维度），对度量字段再使用某种聚集函数。但是对于大数据量情况下，聚集算法的优化仍是探究的一个课题。例如是直接使用SQL的Group by，还是先排序，在处理。微观规则从数据的转换的微观细节分，可以分成下面的几个基本类型，当然还有一些复杂的组合情况，例如先运算，在参照转换的规则，这种基于基本类型组合的情况就不在此列了。ETL的规则是依赖目标数据的，目标数据有多少字段，就有多少条规则。直接映射，原来是什么就是什么，原封不动照搬过来，对这

35、样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般对数值型字段而言。参照转换，在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是比较合适也是最常见的，在整个ETL开始之前，它就装入内存，对性能提高的帮助非常大。字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型

36、字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。空值判断，对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作为特定一种维成员？这恐怕还要看应用的情况，也是需要进一步探求的。但是无论怎样，对于可能有NULL值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的值。日期转换，在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。日期运算，基于日

37、期，我们通常会计算日差、月差、时长等。一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。聚集运算，对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum,count,avg,min,max。既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值。难点四数据质量“不要绝对的数据准确，但要知道为什么不准确。”这是我们在构建BI系统是对数据准确性的要求。确实，对绝对的数据准确谁也没有把握，不仅是系统集成商，包括客户也

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

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

40、一清二楚。我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生重大影响。规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在难点三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元

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

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

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

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

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

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

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

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

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

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

51、觉得元数据也没啥，不就是建一堆表描述界面的元素，再利用这些数据自动生成界面吗。到了数据仓库系统中，这个概念更强了，是数据仓库中一个重要的部分。但是至今，我还是认为这个概念过于玄乎，看不到实际的东西，市面上有一些元数据管理的东西，但是从应用情况就得知，用的不多。之所以玄乎，就是因为抽象层次没有分清楚，关键就是对于元数据的分类（这种分类就是一种抽象过程）和元数据的使用。你可以将元数据抽象成0和1，但是那样对你的业务有用吗？必须还得抽象到适合的程度，最后问题还是“度”。OLAP 概念联机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd于1993年提出的。当时，Codd认为联机事务处理

52、(OLTP)已不能满足终端用户对数据库查询分析的需要，SQL对大数据库进行的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此Codd提出了多维数据库和多维分析的概念。OLAP是大多数数据仓库解决方案中使用的报告方式的一种，通常被作为数据仓库的解决方案，这是错误的表达。数据仓库最重要的特性是数据集成，最重要的用途是数据展现。OLAP服务不是针对数据集成设计的，而是针对数据展现设计的，是一种强大的数据展现方法，是数据仓库解决方案的一部分。OLAP基本操作OLAP的基本多维分析操作有钻取（Drill-up和Dril

53、l-down）、切片（Slice）和切块（Dice）、以及旋转（Pivot）等，让用户从多种维度、多个侧面、多种数据综合观察数据，从而深入的了解和分析数据。OLAP的基本多维分析操作迎合了人的思维，减少和降低的混淆。数据切片（slice）切片操作就是在某个或某些维上选定一个属性成员，而在其他维上取一定区间的属性成员，或全部属性成员来观察数据的一种分析方式。数据切块（dice）切块就是在各个维上去一定区间的成员属性，或全部成员属性来观察数据的一种分析方式，可以认为切片是切块的特例，切块是切片的扩展。数据上探、下钻（drill-up/drill-down）钻取包含向下钻(Drill-down)和向

54、上钻(Drill-up)/上卷(Roll-up)操作。下钻指从概括性的数据出发获得相应的更详细的数据，上钻则相反。钻取的深度与维度所划分的层次相对应。数据旋转（prvot）旋转即改变一个报告或页面显示的维方向。旋转可能包含交换行和列，或是把某一个行维移到列为中去，或包页面显示中的一个维和页面外的维进行交换。其他OLAP操作除了上面的几种方式外，有些OLAP系统还提供其他的方式：如钻透，以及获取最大最小值的N项等等。OLAP的数据模型从上一节可以看出OLAP工具事实上是定义了数据存储模型。在 HYPERLINK l _数据存储模型 2.数据存储模型我们可以知道，OLAP的数据模型基本上有两种。接

55、下来我们讲一下基本概念数据立方体数据立方体是一种面向“主题”和“属性”而建立起来的一种多维数据集，一般来说一个数据立方体是针对一个“主题”的，而“属性”就是维度。从这点上上讲，数据立方体与维度很像对象与属性之间的关系。例如，对于销售数据构建数据立方体，维度就包含了：订单编号、制单时间、销售人员、货品、数量、售价、折扣换句话来解释，数据立方体是包含维度和事实的。事实是主题，维度是属性。维度是人们观察数据的特定角度。例如：时间，地点，商品，供应商等等。每一个维度都有一个维度表。人们观察数据的某个特定角度还可以存在细节程度不同的多个描述层次，我们称这些层次为维的层次，如时间可分为年、月、日。维的一个

56、取值称为该维的一个维成员。如果维已经分成了多个层次，则维成员就是不同维层次取值的组合。主题，就是数据立方体中的事实表。事实数据表可能包含业务销售数据，如商品买卖所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性维度表的主键。包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一

57、组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。一般来说，一个事实数据表都要和一个或多个维度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。OLAP分析是建立在多维数据模型基础上的。有两种实施方案可供选取，一种是直接采用多维数据库进行联机分析处理，叫做多维联机分析处理，简称MOLAP。而如果采用关系数据库来存放多维数据进行联机分析处理，则称之为关系联机分析处理，简称ROLAP。多维联机分析处理（MOLAP）概念在RD

58、BMS中，数据以关系的形式来组织存在。而在多维数据库中，数据以多维的方式来组织存储，形成大量的稀疏矩阵。多维数据库的维是通过对问题的分析得到的，如分析各产品在各地的销售情况，可以选取地理维，产品维，以销量为事实的度量，形成多维数据，表达现实中的一对多和多对多的关系。在关系型数据库中，只有一对多的关系。同时关系型数据库需要更多的表和存储空间。由上图可以看出，如果取东北的冰箱数据，在多维数据库中和关系型数据库的读取数据量是不一样的。同时，在多维数据库中通常会对用户数据做预处理，当用户来请求数据时，预先已经算好数据了，这就是以空间换时间的理论。维的分类多维数据库的另外一个重要概念是维内元素的类的概念

59、。类是对维成员的一个按照某标准的划分。比如产品可分为畅销或者非畅销。类和层次的概念是不一样的，维的层次是为了上下钻取数据，让用户从不同层次看数据；而类是为了在不同类别上进行比较。类和层次的区别：意义不同：层次表达的是变量的不同层次，也就是维的父子关系。类表达的是同一维度的某一类成员的共同特征。分析方式不同：层次上进行的是上下钻取类总要是分析和归纳在实际环境中，通常是层次和类上的综合分析。存储方式MDDB是经过高度压缩的索引和指针结构。每一个对象由聚集成组的单元块组成，每一个单元块由类似于多维数组的结构存储。由于有些维度间的组合不一定能产生有效的值，因此多维数据库必须是一个稀疏矩阵，可以忽略空值

60、、缺省和重复数据。时间是一个比较特殊的维度，建议采用一个时间序列的值来存储数据，简化对数据的处理。关系联机分析处理（ROLAP）概念同专用的多维数据库相比，ROLAP虽然表达起来不大自然，但是也是一种表达方式。ROLAP将多维数据库中的多维结构分为维表和事实表。维表用来记录维度信息；事实表用来记录维度交叉点的度量信息以及各维度的码值。这样的话，就如上图所示，存在多个维度表，以及事实表。上图的设置可以看出事实表存在多个维度的码值，以节约存储空间，由此就带来了性能上的消耗。ROLAP和MOLAP的比较数据的存取速度：在ROLAP中，多维立方体并没有真正存在，需要根据相应的请求，临时拼出多维立法体，