ETL 杂1
|
Explain the three basic delivery steps for conformed dimensions.
简述对一致性维度的三种基本的交付步骤。
答：数据整合的关键就是生成一致性维度，再通过一致性维度将来自不同数据源的事实数据合并到一起，供分析使用。通常来说，生成一致性维度有如下三个步骤：
1.标准化（Standardizing）
标准化的目的是使不同数据源的数据编码方式，数据格式等相同，为下一步数据匹配打下基础。
2.匹配（Matching and Deduplication）
数据匹配的工作有两种，一种是将不同数据源的标识同一事物的不同属性匹配到一起，是数据更完善；另一种是将不同数据源的相同数据标识成重复，为下一步的筛选打下基础。
3.筛选（Surviving）
数据筛选的主要目的是选定一致性维度作为主数据（Master Data），也就是最终交付的一致性维度数据。
浅析基本事实表的ETL处理
|
Name the three fundamental fact grains and describe an ETL approach for each. 简述三种基本事实表，并说明ETL的过程中如何处理它们。 答：事实表从粒度的角色来划分可以分为三类，分别是交易粒度事实表（Transaction Grain）、周期快照粒度事实表（Periodic Snapshot）和累计快照粒度事实表（Accumulating Snapshot）。在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。 交易粒度事实表的来源伴随交易事件成生的数据，例如销售单。在ETL过程中，以原子粒度直接进行迁移。 周期快照事实表是用来记录有规律的，固定时间间隔的业务累计数据，例如库存日快照。在ETL过程中，以固定的时间间隔生成累计数据。 累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息。在ETL过程中，随着业务处理过程的步骤逐步完善该表中的记录。 |
|||||
|
浅析桥接表的作用 How are bridge tables delivered to classify groups of dimension records associated to a single fact? 简述桥接表是如何将维度表和事实表进行关联的？ 答：桥接表（Bridge Table）是维度建模中的一类比较特殊的表。 在数据仓库的建模时，会遇到具有层次结构的维度表，对于这样的表有一种建模方式是建立父子表，即每条记录上包括一个指向其父记录的字段。这种父子表的建立在层级深度可变时尤其有用，是一个紧凑而有效的建模方式。但是这种建模方式也有缺点，就是用标准SQL很难对递归结构进行操作。 与这种递归结构的父子表不同，桥接表采用不同的建模方式也可以表示这种层级结构。桥接表是建立在维度表和事实表中间的一个具有较多冗余信息的表，其中的记录包含层级结构中节点到其下面每个节点的路径。表结构如下所示： 父关键字 子关键字 父层数 层名 底端标识 顶端标识 在桥接表中，节点与其下面的任意一个节点都建立一个关联记录保存在表中，即父子关系不再局限在相邻层，如第一层与第三层同样有父子关系，通过父层数可以区分相隔了几层。这样，可以通过父层数和父子关系来进行层级结构的查询。 当然，桥接表也不是一个完备的解决方案，它只能是在某些情况下是查询变得容易。
State the primary types of tables found in a data warehouse and the order which they must be loaded to enforce referential integrity. 简述数据仓库中的表的基本类型，以及为了保证引用完整性该以什么样的顺序对它们进行加载。 答：数据仓库中的表的基本类型有维度表、事实表、子维度表、桥接表等几类。其中子维度表即雪花模型由支架维度技术处理，桥接表用来处理多值维度或层级结构。 数据仓库中需要加载的各类表之间有相互依赖的关系，所以加载时需要以一定的顺序进行加载。下面是一些加载的基本原则： 子维度表加载成功后，再加载维度表。 维度表加载成功后，再加载桥接表。 子维度表、维度表和桥接表都加载成功后，再加载事实表。 这个加载顺序可以通过主外键的关系来确定。 （注意，此回答为总线架构的数据仓库的表的加载顺序。）
Describe the different types of ETL metadata and provide examples of each. 举例说明各种ETL过程中的元数据。 答：元数据是ETL项目组面对的一个非常重要的主题，对于整个数据仓库项目也是非常重要的一部分。对于元数据的分类和使用没有很确定的定义。 通常来说，我们可以把元数据分为三类，分别为业务元数据（Business Metadata），技术元数据（Technical Metadata）和过程处理元数据（Process Execution Metadata）。 业务元数据，是从业务的角度对数据的描述。通常是用来给报表工具和前端用户对数据进行分析和使用提供帮助。 技术元数据，是从技术的角度对数据的描述。通常包括数据的一些属性，如数据类型、长度、或者数据概况分析后一些结果。 过程处理元数据，是ETL处理过程中的一些统计数据，通常包括有多少条记录被加载，多少条记录被拒绝接受等数据。
浅析数据加载顺序
State the primary types of tables found in a data warehouse and the order which they must be loaded to enforce referential integrity. 简述数据仓库中的表的基本类型，以及为了保证引用完整性该以什么样的顺序对它们进行加载。 答：数据仓库中的表的基本类型有维度表、事实表、子维度表、桥接表等几类。其中子维度表即雪花模型由支架维度技术处理，桥接表用来处理多值维度或层级结构。 数据仓库中需要加载的各类表之间有相互依赖的关系，所以加载时需要以一定的顺序进行加载。下面是一些加载的基本原则： 子维度表加载成功后，再加载维度表。 维度表加载成功后，再加载桥接表。 子维度表、维度表和桥接表都加载成功后，再加载事实表。 这个加载顺序可以通过主外键的关系来确定。 （注意，此回答为总线架构的数据仓库的表的加载顺序。） |
浅析ETL的技术支持
What are the characteristics of the four levels of the ETL support model?
简述ETL技术支持工作的四个级别的特点。
答：数据仓库上线后，ETL组需要为保证ETL工作的正常运行提供技术支持。通常这种技术支持工作分为四个级别。
1．第一级别的技术支持通常是电话支持人员，属于技术支持服务窗口（Help Desk）类型。如果数据迁移出现错误或者用户发现数据有问题，问题通过电话反映到第一级别的技术支持处。第一级别支持人员通过ETL项目组提供的一些问题的解决办法尽可能的解决发现的问题，阻止问题升级。
2．第二级别的技术支持通常是系统管理员和DBA。如果第一级别不能解决问题，问题反映到第二级别。第二级别的人员通常技术上比较强，硬件基础结构和软件架构上的问题都可以解决。
3．第三级别的技术支持通常是ETL项目负责人。如果第二级别不能解决问题，问题反映到第三级别。ETL项目负责人应该具备足够的知识，能够解决生产环境中的绝大部分问题。ETL项目负责人在必要时可以和开发人员或者外部产品提供商对某些问题进行交流，以便找出解决问题的办法。
4．第四级别的技术支持通常是ETL的实际开发人员。如果第三级别不能解决问题，问题反映到第四级别。ETL的实际开发人员可以对代码进行跟踪分析并找到问题的解决办法。如果问题出现在产品供应商的应用中，还需要供应商提供技术支持。
在小一些的数据仓库环境中，也是通常的情况下，第三级别和第四级别可以合并在一起。合并后对第二级别的要求会高一些。不建议每次出现问题都找ETL的开发人员。第一级别的技术支持人员不应该仅仅提供电话支持服务，在将问题反映给下一个级别前，要尽自己的能力去解决问题。
|
浅析迟到数据的处理 How does late arriving data affect dimensions and facts? Share techniques for handling each. 迟到的数据对事实表和维度表有什么影响？怎样来处理这个问题？ 答：迟到的数据分为两种，一种是迟到的事实表数据，另一种是迟到的维度表数据。 对于迟到的事实记录，我们可以插入到相应的事实表中。在插入的同时，还需要做一些处理。首先，对于具有SCD TYPE 2型维度的事实记录需要在插入前判断该事实记录的发生日期到目前为止，维度记录是否发生过变化，如果有变化，该事实记录需要对应到事实发生时的维度记录上。其次，在事实记录插入完成后，与该事实表相关的聚集事实表和合并事实表需要做相应的处理。 对于迟到的维度记录，我们需要做的处理要复杂一些。首先，如果迟到的维度记录是第一次进入数据仓库中，那么需要在维度表中生成一条维度记录，并将与该维度记录对应的事实记录的外键进行更新。其次，如果迟到的维度记录是对原维度进行的修改，那么我们在维度表中生成一条新记录的同时，还需要找到维度本次变化到下次变化间的事实行，并将其维度外键更新为新加维度的代理关键字。 |
|
Offer techniques for sharing business and technical metadata.
简述共享业务元数据和技术元数据的方法。
答：为了能共享各种元数据，在数据仓库的构建过程中必须要有一些元数据标准，并在实际开发中遵守这些标准。这些标准包括元数据命名规则、存储规则及共享规则等内容。有关元数据标准的内容可以参看公共仓库元模型（Common Warehouse Metamodel，CWM）的相关资料 。
在最基本的层面上，企业应该在下面三个方面制定好标准。
1．命名规则
命名规则应该在ETL组开始编码前制定好，范围包括表、列、约束、索引等等数据库对象以及其他一些编码规则。如果企业有自己的命名规则，ETL组应该遵守企业的命名规则。当企业的命名规则不能完全满足需求时，ETL组可以制定补充规则或者新的规则。对企业命名规则的改变需要有详细的文档记录，并提交企业相关部门审核。
2．架构
在ETL组开始工作前，架构应该先被设计好。例如ETL引擎是和数据仓库放在同一台服务器上还是单独设立服务器；数据准备区是建立成临时的还是持久的；数据仓库是基于维度建模的还是3NF建模的。并且这些内容应该有详细的文档记录。
3．基础结构
系统的基础结构也应该先确定好。例如解决方案是基于Windows的还是基于UNIX的。这些企业基础结构元数据应该在ETL组开始工作前制定好。这些内容也应该有详细的文档记录。
在ETL的开发中，制定好元数据标准并能很好的遵守，那么建立好的数据仓库的元数据就可以很好的完成共享功能
