ETL架构师之分析类

本部分的题目来自Kimball的ETL Toolkit著作，原著未直接给出答案。这里的中文是参考网友整理(Jerome's BI BLOG )加上自己整理而得，不是原创。

第一：分析类
1.什么是逻辑数据映射？它对ETL项目组的作用是什么？
答：
逻辑数据映射（Logical Data Map）用来描述源系统的数据定义、目标数据仓库的模型以及将源系统的数据转换到数据仓库中需要做操作和处理方式的说明文档，通常以表格或Excel的格式保存如下的信息：
目标表名：
目标列名：
目标表类型：注明是事实表、维度表或支架维度表。
SCD类型：对于维度表而言。
源数据库名：源数据库的实例名，或者连接字符串。
源表名：
源列名：
转换方法：需要对源数据做的操作，如Sum(amount)等。

逻辑数据映射应该贯穿数据迁移项目的始终，在其中说明了数据迁移中的ETL策略。在进行物理数据映射前进行逻辑数据映射对ETL项目组是重要的，它起着元数据的作用。项目中最好选择能生成逻辑数据映射的数据迁移工具。

评论1：
逻辑数据映射分为两种:
1 : 模型映射:
从源模型到DW目标模型之间的映射类型有：
一对一：一个源模型的数据实体只对应一个目标模型的数据实体。如果源类型与目标类型一致，则直接映射。如果两者间类型不一样，则必须经过转换映射。
一对多：一个源模型的数据实体只对应多个目标模型的数据实体。在同一个数据存储空间，常常出现会一个源实体拆分为多个目标实体的情况下。在不同的存储空间中，结果会对应到不同的存储空间的实体。
一对零：一个源模型的数据实体没有与目标模型的数据实体有对应，它不在我们处理的计划范围之内。
零对一：一个目标模型的数据实体没有与任何一个源数据实体对应起来。例如只是根据设计考虑，时间维表等。
多对一：多个源模型的数据实体只对应一个目标模型的数据实体。
多对多：多个源模型的数据实体对应多个目标模型的数据实体。

[@more@]

2: 属性映射
一对一：源实体的一个数据属性列只对应目标实体的一个数据属性列。如果源类型与目标类型一致，则直接映射。如果两者间类型不一样，则必须经过转换映射。
一对多：源实体的一个数据属性列只对应目标实体的多个数据属性列。在同一个实体中，常常出现会一个源属性列拆分为目标的多个属性列情况。在不同实体中，结果会对应到不同的实体的属列。
一对零：一个源实体的数据属性列没有与目标实体的数据属性列有对应，它不在我们处理的计划范围之内。
零对一：一个目标实体的数据属性列没有与任何一个源数据属性列对应起来。例如只是根据设计考虑，维表和事实表中的时间戳属性，代理健等。
多对一：源实体的多个数据属性列只对应目标实体的一个数据属性列。
多对多：源实体的多个数据属性列对应目标实体的多个数据属性列。

作用:
1 为开发者传送更为清晰的数据流信息。映射关系包括有关数据在存储到DW前所经历的各种变化的信息，对于开发过程中数据的追踪审查过程非常重要。
2 把ETL过程的信息归纳为元数据，将数据源结构，目标结构，数据转换规则，映射关系，数据的上下文等元数据保存在存储知识库中，为元数据消费者提供很好的参考信息，追踪数据来源与转换信息，有助于设计人员理解系统环境变化所造成的影响；

开发设计者可以轻松的回答以下的问题：
1、这些数据从那里来？
2、这样的结果通过什么样的计算和转化得来？
3、这些数据是如何组织的？
4、数据项之间有什么联系？
5、如果源发生变化，有那几个系统，目标受影响？

2.在数据仓库项目中，数据探索阶段的主要目的是什么？
答：
在逻辑数据映射进行之前，需要首先对所有的源系统进行分析。对源系统的分析通常包括两个阶段，一个是数据探索阶段（Data Discovery Phase），另一个是异常数据检测阶段。
数据探索阶段包括以下内容：
1．收集所有的源系统的文档、数据字典等内容。
2．收集源系统的使用情况，如谁在用、每天多少人用、占多少存储空间等内容。
3．判断出数据的起始来源（System-of-Record）。
4．通过数据概况（Data Profiling）来对源系统的数据关系进行分析。
数据探索阶段的主要目的是理解源系统的情况，为后续的数据建模和逻辑数据映射打下坚实的基础。

评论1：
确定了数据源，我们必须仔细研究每个数据源的内容，可获得性程度等。因为在某个系统中同样一个目标值的数据来源可能会有多个，这样这个过程并不能是一个自动化的过程，更多的是依靠经验，会根据数据量，数据质量，数据内容，数据完整性等方面来确定哪个是我们要使用的数据源，并选择需要的数据内容。在这个阶段选择数据源时必须对业务有深刻的了解，如果想取一个数据，在源表中多个表都存在， 如对于一些大表，在业务系统中为了性能的需要，经常会只保留三个月的交易数据，这样如果我们要分析一个一年以上的数据，这个源表就不能符合我们的需求。 这些都需要IT的信息专家参与，他们对组织中的数据非常熟悉，了解大部分数据源的历史。 通过对所有的数据源进行详细的分析，了解其真实的数据内容。在选定数据源时，在某种情况下，并非可以随处捕捉到数据。这些数据必须要考虑它的其他方式的来源。
评论2：
在数据仓库设计的最早阶段上，设计者关注两样工作：用户需求的收集和数据源分析。设计者必须将用户需求与现实各种数据源放在一起通盘考虑， 尽可能深入的了解与需求密切相关的数据源，把其作为下一步研究的基础。 通常用户都会说明他们需要有关销售，库存，财务等方面的数据，可是他们并不能详细的说明这些数据的来源与存放在企业的哪个数据库中。 在这一步骤为每个事实表与维表确定来源，收集有关它的信息，是静态的还是动态的，数据是缓慢变化的还是频繁变化的，数据源在何处，数据源所处的平台等，确定ETL的范围；并且确认那些是来自正式的数据源或者是非正式的数据源。 正式的数据源是由业务系统进行支持； 而非正式的数据源，如分析竞争对手时的市场占有调查报告等，这些是不能有现有的业务系统支持， 而是来自于用户的收集与使用的，这些信息往往需要一个获取信息的处理过程，将其收集到数据仓库中。

3.如何确定起始来源数据？
答：
这个问题的关键是理解什么是System-of-Record。System-of-Record和数据仓库领域内的其他很多概念一样，不同的人对它有不同的定义。在Kimball的体系中，System-of-Record是指最初产生数据的地方，即数据的起始来源。在较大的企业内，数据会被冗余的保存在不同的地方，在数据的迁移过程中，会出现修改、清洗等操作，导致与数据的起始来源产生不同。

起始来源数据对数据仓库的建立有着非常重要的作用，尤其是对产生一致性维度来说。我们从起始来源数据的越下游开始建立数据仓库，我们遇到垃圾数据的风险就会越大。

评论1：
理解源系统的本质对于创建DW结构，ETL过程结构等非常关键。各种工具、连接和服务都部分依赖于数据的来源以及输出的数据内容。 在数据仓库设计的最早阶段上，设计者关注两样工作：用户需求的收集和数据源分析。设计者必须将用户需求与现实各种数据源放在一起通盘考虑， 尽可能深入的了解与需求密切相关的数据源，把其作为下一步研究的基础。 通常用户都会说明他们需要有关销售，库存，财务等方面的数据，可是他们并不能详细的说明这些数据的来源与存放在企业的哪个数据库中。 在这一步骤为每个事实表与维表确定来源，收集有关它的信息，是静态的还是动态的，数据是缓慢变化的还是频繁变化的，数据源在何处，数据源所处的平台等，确定ETL的范围；并且确认那些是来自正式的数据源或者是非正式的数据源。 正式的数据源是由业务系统进行支持； 而非正式的数据源，如分析竞争对手时的市场占有调查报告等，这些是不能有现有的业务系统支持， 而是来自于用户的收集与使用的，这些信息往往需要一个获取信息的处理过程，将其收集到数据仓库中.
确定了数据源，我们必须仔细研究每个数据源的内容，可获得性程度等。因为在某个系统中同样一个目标值的数据来源可能会有多个，这样这个过程并不能是一个自动化的过程，更多的是依靠经验，会根据数据量，数据质量，数据内容，数据完整性等方面来确定哪个是我们要使用的数据源，并选择需要的数据内容。在这个阶段选择数据源时必须对业务有深刻的了解，如果想取一个数据，在源表中多个表都存在， 如对于一些大表，在业务系统中为了性能的需要，经常会只保留三个月的交易数据，这样如果我们要分析一个一年以上的数据，这个源表就不能符合我们的需求。 这些都需要IT的信息专家参与，他们对组织中的数据非常熟悉，了解大部分数据源的历史。 通过对所有的数据源进行详细的分析，了解其真实的数据内容。在选定数据源时，在某种情况下，并非可以随处捕捉到数据。这些数据必须要考虑它的其他方式的来源。

4.简述实时ETL的一些难点及其解决办法。
答：实时ETL的引入给数据仓库的建设带来了很多新的问题和挑战，下面列举了一些问题，其中有些问题有具体的解决办法，有些只能在实际情况下去斟酌。
1．连续的ETL处理对系统可靠性提出更高的要求。
2．离散快照数据的间隔时间变短。
3．缓慢变化维变成快速变化维。
4．如何确定数据仓库中数据的刷新频率。
5．目的是只出报表还是要实现数据整合。
6．做数据整合还是应用整合。
7．采用点对点的方式还是集中的方式。
8．前端展现工具的数据刷新方式如何确定。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16723161/viewspace-1027427/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16723161/viewspace-1027427/