ETL 的一些概念

1. What is a logical data mapping and what does it mean to the ETL team? 
什么是逻辑数据映射?它对ETL项目组的做用是什么? 
答:逻辑数据映射(Logical Data Map)用来描述源系统的数据定义、目标数据仓库的模型以及将源系统的数据转换到数据仓库中须要作操做和处理方式的说明文档,一般以表格或Excel的格式保存以下的信息: 
目标表名: 
目标列名: 
目标表类型:注明是事实表、维度表或支架维度表。 
SCD类型:对于维度表而言。 
源数据库名:源数据库的实例名,或者链接字符串。 
源表名: 
源列名: 
转换方法:须要对源数据作的操做,如Sum(amount)等。 
逻辑数据映射应该贯穿数据迁移项目的始终,在其中说明了数据迁移中的ETL策略。在进行物理数据映射前进行逻辑数据映射对ETL项目组是重要的,它起着元数据的做用。项目中最好选择能生成逻辑数据映射的数据迁移工具。 
逻辑数据映射分为两种:
1 : 模型映射:
从源模型到DW目标模型之间的映射类型有:
一对一:一个源模型的数据实体只对应一个目标模型的数据实体。若是源类型与目标类型一致,则直接映射。若是二者间类型不同,则必须通过转换映射。
一对多:一个源模型的数据实体只对应多个目标模型的数据实体。在同一个数据存储空间,经常出现会一个源实体拆分为多个目标实体的状况下。在不一样的存储空间中,结果会对应到不一样的存储空间的实体。
一对零:一个源模型的数据实体没有与目标模型的数据实体有对应,它不在咱们处理的计划范围以内。
零对一:一个目标模型的数据实体没有与任何一个源数据实体对应起来。例如只是根据设计考虑,时间维表等。
多对一:多个源模型的数据实体只对应一个目标模型的数据实体。
多对多:多个源模型的数据实体对应多个目标模型的数据实体。

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

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

开发设计者能够轻松的回答如下的问题:
一、这些数据从那里来?
二、这样的结果经过什么样的计算和转化得来?
三、这些数据是如何组织的?
四、数据项之间有什么联系?
五、若是源发生变化,有那几个系统,目标受影响?前端

2. What are the primary goals of the data discovery phase of the data warehouse project? ios

在数据仓库项目中,数据探索阶段的主要目的是什么? 数据库

答:在逻辑数据映射进行以前,须要首先对全部的源系统进行分析。对源系统的分析一般包括两个阶段,一个是数据探索阶段(Data Discovery Phase),
另外一个是异常数据检测阶段。 数据探索阶段包括如下内容: 1.收集全部的源系统的文档、数据字典等内容。 2.收集源系统的使用状况,如谁在用、天天多少人用、占多少存储空间等内容。 3.判断出数据的起始来源(System-of-Record)。 4.经过数据概况(Data Profiling)来对源系统的数据关系进行分析。 数据探索阶段的主要目的是理解源系统的状况,为后续的数据建模和逻辑数据映射打下坚实的基础。

3. How is the system-of-record determined? 
如何肯定起始来源数据? 
编程

答: 这个问题的关键是理解什么是System-of-Record。System-of-Record和数据仓库领域内的其余不少概念同样,
不一样的人对它有不一样的定义。在Kimball的体系中,

System-of-Record是指最初产生数据的地方,即数据的起始来源。在较大的企业内,数据会被冗余的保存在不一样的地方,在数据的迁移过程当中,会出现修改、
清洗等操做,致使与数据的起始来源产生不一样。 起始来源数据对数据仓库的创建有着很是重要的做用,尤为是对产生一致性维度来讲。咱们从起始来源数据的越下游开始创建数据仓库,
咱们遇到垃圾数据的风险就会越大。

 

Architecture 

4. What are the four basic Data Flow steps of an ETL process? 
在ETL过程当中四个基本的过程分别是什么? 
windows

答:Kimball数据仓库构建方法中,ETL的过程和传统的实现方法有一些不一样,
主要分为四个阶段,分别是抽取(extract)、清洗(clean)、一致性处理(comform)和交付(delivery),简称为ECCD。 1.抽取阶段的主要任务是:   读取源系统的数据模型。   链接并访问源系统的数据。   变化数据捕获。   抽取数据到数据准备区。 2.清洗阶段的主要任务是:   清洗并增补列的属性。   清洗并增补数据结构。   清洗并增补数据规则。   增补复杂的业务规则。   创建元数据库描述数据质量。   将清洗后的数据保存到数据准备区。 3.一致性处理阶段的主要任务是:   一致性处理业务标签,即维度表中的描述属性。   一致性处理业务度量及性能指标,一般是事实表中的事实。   去除重复数据。   国际化处理。   将一致性处理后的数据保存到数据准备区。 4.交付阶段的主要任务是:   加载星型的和通过雪花处理的维度表数据。   产生日期维度。   加载退化维度。   加载子维度。   加载一、二、3型的缓慢变化维度。   处理迟到的维度和迟到的事实。   加载多值维度。   加载有复杂层级结构的维度。   加载文本事实到维度表。   处理事实表的代理键。   加载三个基本类型的事实表数据。   加载和更新汇集。   将处理好的数据加载到数据仓库。 从这个任务列表中能够看出,ETL的过程和数据仓库建模的过程结合的很是紧密。换句话说,ETL系统的设计应该和目标表的设计同时开始。
一般来讲,数据仓库架构师和ETL系统设计师是同一我的。

5. What are the permissible data structures for the data staging area? Briefly describe the pros and cons of each. 
在数据准备区中容许使用的数据结构有哪些?各有什么优缺点? 
安全

答: 
1.固定格式的文本文件。(Flat File) 
Flat File指的是一种保存在系统上的一种文本文件格式,它以相似数据库的表的方式用行和列来保存数据。
这种文件格式常常用来进行数据交换。用于保存数据不太合适。 2.XML数据集。 多用于数据交换,用户保存数据不太合适。 3.关系数据库的表。 保存数据的较理想选择。 4.独立的数据库表。 独立的数据库表通常指创建的表和其余表没有外键约束关系。这样的表多用于数据处理。 5.三范式或者关系型模型。 6.非关系型数据源。 非关系型数据源通常包括COBOL copy books、VSAM文件、Flat文件、Spreadsheets等。 7.维度模型。 8.原子事实表和汇集事实表。 9.代理键查找表。


6. When should data be set to disk for safekeeping during the ETL? 
简述ETL过程当中哪一个步骤应该出于安全的考虑将数据写到磁盘上? 
答: 
Staging的意思就是将数据写到磁盘上。出于安全及ETL能方便从新开始,在数据准备区(Staging Area)中的每一个步骤中都应该将数据写到磁盘上,即生成文本文件或者将创建关系表保存数据,而不该该以数据不落地方式直接进行ETL。 

例如,在数据抽取阶段,咱们须要链接到源系统,为了对源系统的影响尽可能小,咱们须要将抽取的数据保存成文本文件或者放入数据准备区的表中,这样,当ETL过程出现错误而失败时,咱们就能够从这些文本文件开始ETL,而不须要再次影响源系统。 

Extract 
7. Describe techniques for extracting from heterogeneous data sources. 
简述异构数据源中的数据抽取技术。 
答:在数据仓库项目中,须要抽取的数据常常来自不一样的数据源,它们的逻辑结构和物理结构均可能不一样,即称之为异构数据源。 
在对异构数据源进行整合抽取时,咱们须要作的事情依次是标识出全部的源系统,对源系统进行概况分析,定义数据匹配逻辑,创建筛选规则,生成一致性维度。 
对于源数据的操做系统平台和数据平台各不相同的状况,咱们须要根据实际状况来肯定如何进行数据抽取,一般的方法有创建ODBC链接、定义接口文件、创建DBLINK等方法。 

8. What is the best approach for handling ERP source data? 
从ERP源系统中抽取数据最好的方法是什么? 
答:ERP系统的产生是为了解决企业内异构数据的整合。这个问题也是数据仓库系统面临的主要问题。ERP的解决方案是将企业内的各个应用(包括销售、会计、人力资源、库存和产品等)创建在相同的平台和相同的应用框架下,即在应用操做层将企业内的数据进行了一致性处理。而数据仓库是在应用操做层之上创建一致性的规则并进行一致性处理。目前比较流行的ERP系统有SAP、PeopleSoft、Oracle、Baan和J.D.EDwards(大部分没接触过)。 

若是企业内只有一套ERP系统,那么数据就已是一致的了,为数据抽取提供了方便。若是企业内除了ERP外还有其余系统,则数据抽取会变得复杂。由于目前的ERP系统的数据模型都很是复杂,可能有几百几千个表,而且较难理解。直接在ERP系统上创建数据捕获和抽取是很是复杂的。最好的办法是购买能针对ERP系统数据抽取提供功能的ETL工具,将ERP内部的复杂性留给ETL厂商处理。 

9. Explain the pros and cons of communicating with databases natively versus ODBC. 
简述直接链接数据库和使用ODBC链接数据库进行通信的优缺点。 
答:一般链接数据库的方式分为两类,一类是直接链接,另外一类是经过ODBC链接。 
直接链接的方式主要是经过COBOL、PL/SQL、Transact-SQL等方式链接数据库。这种方式的优势是运行性能高,可使用DBMS提供的一些特殊功能。缺点是通用性差。 

ODBC是为windows应用程序访问数据库提供的一组接口。ODBC的优势是灵活性,经过改变驱动和链接方式可使用不一样的数据库。ODBC方式的缺点是性能差。使用ODBC链接方式实现ETL的话,在ETL程序和至少要有两层,分别是ODBC Manager层和ODBC Driver层。另外,使用ODBC方式不能使用DBMS提供的一些特殊的功能。 
10. Describe three change data capture (CDC) practices and the pros and cons of each. 
简述出三种变化数据捕获技术及其优缺点。 服务器

答: 变化数据捕获(CDC)技术是ETL工做中的重点和难点,一般须要在增量抽取时完成。实现变化数据捕获时最理想的是找到源系统的DBA。若是不能找到,
就须要ETL项目组本身进行检测数据的变化。
下面是一些经常使用的技术。 1.采用审计列 审计列指表中如“添加日期”、“修改日期”、“修改人”等信息的字段。应用程序在对该表的数据进行操做时,同时更新这些字段,或者创建触发器来更新这些字段。
采用这种方式进行变化数据捕获的优势是方便,容易实现。缺点是若是操做型系统没有相应的审计字段,须要改变已有的操做型系统的数据结构,
以保证获取过程涉及的每张表都有审计字段。 2数据库日志 DBMS日志获取是一种经过DBMS提供的日志系统来得到变化的数据。它的优势是对数据库或访问数据库的操做系统的影响最小。缺点是要求DBMS支持,而且对日志记录的格式很是了解。 3.全表扫描 全表扫描或者全表导出文件后进行扫描对比也能够进行变化数据捕获,尤为是捕获删除的数据时。这种方法的优势是,思路清晰,适应面广,缺点是效率比较差。 Data Quality

11. What are the four broad categories of data quality checks? Provide an implementation 
technique for each. 
数据质量检查的四大类是什么?为每类提供一种实现技术。 
网络

答:数据质量检查是ETL工做中很是重要的一步,主要关注一下四个方面。 
1.正确性检查(Corret) 
检查数据值及其描述是否真实的反映了客观事务。例如地址的描述是否彻底。 
2.明确性检查(Unambiguous) 
检查数据值及其描述是否只有一个意思或者只有一个解释。例如地名相同的两个县须要加区分方法。 
3.一致性检查(Consistent) 
检查数据值及其描述是否统一的采用固定的约定符号来表示。例如币别中人民币用'CNY'。 
4.彻底性检查(Complete) 
彻底性有两个须要检查的地方,一个是检查字段的数据值及其描述是否彻底。例如检查是否有空值。
另外一个是检查记录的合计值是否彻底,有没有遗忘某些条件。

12. At which stage of the ETL should data be profiled? 
简述应该在ETL的哪一个步骤来实现概况分析? 
答:数据概况分析是对源数据内容的概况进行分析,应该在项目的开始后尽早完成,它会对设计和实现有很大的影响。在完成需求收集后就应该当即开始数据概况分析。 
数据概况分析不光是对源系统的数据概况的定量描述,并且为ETL系统中须要创建的错误事件事实表(Error Event Table)和审计维度表(Audit Dimension)打下基础,为其提供数据。 

13. What are the essential deliverables of the data quality portion of ETL? 
ETL项目中的数据质量部分核心的交付物有那些? 
数据结构

答:ETL项目中数据质量部分的核心的交付物主要有下面三个: 
1.数据概况分析结果 
数据概况分析结果是对源系统的数据情况的分析产物,包括如源系统中有多少个表,每一个表有多少字段,其中多少为空,表间的外键关系是否存在等反映源系统数据质量的内容。
这些内容用来决定数据迁移的设计和实现,
并提供给错误事件事实表和审计维度表须要的相关数据。 2.错误事件事实表 错误事件事实表及相关的一系列维度表是数据质量检查部分的一个主要交付物。粒度是每一次数据质量检查中的错误信息。
相关维度包括日期维度表、迁移信息维度表、错误事件信息维度表,
其中错误事件信息维度表中检查的类型、源系统的信息、涉及的表信息、检查使用的SQL等内容。错误事件事实表不提供给前台用户。 3.审计维度表 审计维度表是给最终用户提供数据质量说明的一个维度表。它描述了用户使用的事实表的数据来源,数据质量状况等内容。

 

14. How can data quality be quantified in the data warehouse? 
如何来量化数据仓库中的数据质量? 
答:在数据仓库项目中,一般经过不规则数据的检测工做(Anomaly Detection)来量化源系统的数据质量。除非成立专门的数据质量调查项目组,不然这个工做应该由ETL项目组完成。一般能够采用分组SQL来检查数据是否符合域的定义规则。 
对于数据量小的表,能够直接使用相似下面的SQL完成。 
select state, count(*) from order_detail group by state 
对于数据量大的表,通常经过采样技术来减小数据量,而后进行不规则数据检测。相似SQL以下。 
select a.* from employee a, (select rownum counter, a.* from employee a) B where a.emp_id = b.emp_id and mod(b.counter, trunc((select count(*) from employee)/1000,0)) = 0 
若是能够采用专门的数据概况分析工具进行的话,能够减小很大的工做量。 
Building mappings 

15. What are surrogate keys? Explain how the surrogate key pipeline works. 
什么是代理键?简述代理键替换管道如何工做。 
答:在维度表的迁移过程当中,有一种处理方式是使用无心义的整型值分配给维度记录并做为维度记录的主键,这些做为主键的整型值称为代理键(Surrogate Key)。使用代理键有不少好处,如隔离数据仓库与操做环境,历史记录的保存,查询速度快等。 

同时,在事实表的迁移过程当中,为了保证参照完整性也须要进行代理键的替换工做。为了代理键替换的效率高一些,咱们一般在数据准备区中创建代理键查找表(Surrogate Mapping Table or Lookup Table)。代理键查找表中保存最新的代理键和天然键的对应关系。在对事实表进行代理键替换时,为了保证效率高,须要把代理键查找表中的数据加载到内存中,并能够开多线程依次替换同一记录的中的不一样代理键,使一条事实记录在全部的代理键都替换完后再写如磁盘中,这样的替换过程称为代理键替换管道(Surrogate Key Pipeline)。 

16Why do dates require special treatment during the ETL process? 
为何在ETL的过程当中须要对日期进行特殊处理? 
答:在数据仓库的项目中,分析是主导需求,而基于日期和时间的分析更是占了很大的比重。而在操做型源系统中,日期一般都是SQL的DATETIME型的。若是在分析时,使用SQL对这种类型的字段临时处理会出现一些问题,如效率不好,不一样的用户会采用不一样的格式化方法致使报表不统一。因此,在数据仓库的建模时都会创建日期维度表和时间维度表,将用到的和日期相关的描述都冗余到该表中。 
可是,并非全部的日期都被转化为日期维度表的外键。日期维度表中的记录是有限的,有些日期如生日等可能会比日期维度表中记录的最小日期还要早,这类字段能够直接在数据仓库中保存SQL的DATETIME型。而像购买日期等与分析的业务紧密相关的一般都须要转化为日期维度表的外键,能够用日期维度表中统一的描述信息进行分析。 
17. Explain the three basic delivery steps for conformed dimensions. 
简述对一致性维度的三种基本的交付步骤。 
多线程

答:数据整合的关键就是生成一致性维度,再经过一致性维度未来自不一样数据源的事实数据合并到一块儿,供分析使用。一般来讲,生成一致性维度有以下三个步骤: 
1.标准化(Standardizing) 
标准化的目的是使不一样数据源的数据编码方式,数据格式等相同,为下一步数据匹配打下基础。 
2.匹配(Matching and Deduplication) 
数据匹配的工做有两种,一种是将不一样数据源的标识同一事物的不一样属性匹配到一块儿,是数据更完善;另外一种是将不一样数据源的相同数据标识成重复,为下一步的筛选打下基础。 
3.筛选(Surviving) 
数据筛选的主要目的是选定一致性维度做为主数据(Master Data),也就是最终交付的一致性维度数据。

18. Name the three fundamental fact grains and describe an ETL approach for each. 
简述三种基本事实表,并说明ETL的过程当中如何处理它们。 
答:事实表从粒度的角色来划分能够分为三类,分别是交易粒度事实表(Transaction Grain)、周期快照粒度事实表(Periodic Snapshot)和累计快照粒度事实表(Accumulating Snapshot)。在事实表的设计时,必定要注意一个事实表只能有一个粒度,不能将不一样粒度的事实创建在同一张事实表中。 
交易粒度事实表的来源伴随交易事件成生的数据,例如销售单。在ETL过程当中,以原子粒度直接进行迁移。 
周期快照事实表是用来记录有规律的,固定时间间隔的业务累计数据,例如库存日快照。在ETL过程当中,以固定的时间间隔生成累计数据。 
累积快照事实表用来记录具备时间跨度的业务处理过程的整个过程的信息。在ETL过程当中,随着业务处理过程的步骤逐步完善该表中的记录。 

19. How are bridge tables delivered to classify groups of dimension records associated to a singlefact? 
简述桥接表是如何将维度表和事实表进行关联的? 
答:桥接表(Bridge Table)是维度建模中的一类比较特殊的表。 
在数据仓库的建模时,会遇到具备层次结构的维度表,对于这样的表有一种建模方式是创建父子表,即每条记录上包括一个指向其父记录的字段。这种父子表的创建在层级深度可变时尤为有用,是一个紧凑而有效的建模方式。可是这种建模方式也有缺点,就是用标准SQL很难对递归结构进行操做。 

与这种递归结构的父子表不一样,桥接表采用不一样的建模方式也能够表示这种层级结构。桥接表是创建在维度表和事实表中间的一个具备较多冗余信息的表,其中的记录包含层级结构中节点到其下面每一个节点的路径。表结构以下所示: 

父关键字 

子关键字 

父层数 

层名 

底端标识 

顶端标识 

在桥接表中,节点与其下面的任意一个节点都创建一个关联记录保存在表中,即父子关系再也不局限在相邻层,如第一层与第三层一样有父子关系,经过父层数能够区分相隔了几层。这样,能够经过父层数和父子关系来进行层级结构的查询。 

固然,桥接表也不是一个完备的解决方案,它只能是在某些状况下是查询变得容易。 



20. How does late arriving data affect dimensions and facts? Share techniques for handling each. 

迟到的数据对事实表和维度表有什么影响?怎样来处理这个问题? 

答:迟到的数据分为两种,一种是迟到的事实表数据,另外一种是迟到的维度表数据。 

对于迟到的事实记录,咱们能够插入到相应的事实表中。在插入的同时,还须要作一些处理。首先,对于具备SCD TYPE 2型维度的事实记录须要在插入前判断该事实记录的发生日期到目前为止,维度记录是否发生过变化,若是有变化,该事实记录须要对应到事实发生时的维度记录上。其次,在事实记录插入完成后,与该事实表相关的汇集事实表和合并事实表须要作相应的处理。 

对于迟到的维度记录,咱们须要作的处理要复杂一些。首先,若是迟到的维度记录是第一次进入数据仓库中,那么须要在维度表中生成一条维度记录,并将与该维度记录对应的事实记录的外键进行更新。其次,若是迟到的维度记录是对原维度进行的修改,那么咱们在维度表中生成一条新记录的同时,还须要找到维度本次变化到下次变化间的事实行,并将其维度外键更新为新加维度的代理关键字。 



Metadata 

21. Describe the different types of ETL metadata and provide examples of each. 
举例说明各类ETL过程当中的元数据。 
答:元数据是ETL项目组面对的一个很是重要的主题,对于整个数据仓库项目也是很是重要的一部分。对于元数据的分类和使用没有很肯定的定义。 
一般来讲,咱们能够把元数据分为三类,分别为业务元数据(Business Metadata),技术元数据(Technical Metadata)和过程处理元数据(Process Execution Metadata)。 
业务元数据,是从业务的角度对数据的描述。一般是用来给报表工具和前端用户对数据进行分析和使用提供帮助。 
技术元数据,是从技术的角度对数据的描述。一般包括数据的一些属性,如数据类型、长度、或者数据概况分析后一些结果。 
过程处理元数据,是ETL处理过程当中的一些统计数据,一般包括有多少条记录被加载,多少条记录被拒绝接受等数据 

22. Share acceptable mechanisms for capturing operational metadata. 
简述获取操做型元数据的方法。 

答:操做型元数据(Operational Metadata),也就是过程处理元数据,记录的是ETL过程当中数据迁移状况,如上次迁移日期,加载的记录数等信息。这部分元数据在ETL加载失败时会很是重要。 
通常来讲,对于使用ETL工具的数据加载,像迁移调度时间、迁移调度顺序,失败处理等内容均可以在由在迁移工具中定义生成。像上次迁移日期等数据能够建表保存。 
若是是手工编写ETL程序的话,操做型元数据的处理会麻烦一些,须要本身来获取和存储。获取的方式,不一样的编程方式会不尽相同。

23. Offer techniques for sharing business and technical metadata. 
Optimization/Operations 
简述共享业务元数据和技术元数据的方法。 

答:为了能共享各类元数据,在数据仓库的构建过程当中必需要有一些元数据标准,并在实际开发中遵照这些标准。这些标准包括元数据命名规则、存储规则及共享规则等内容。
有关元数据标准的内容能够参看公共仓库元模型(Common Warehouse Metamodel,CWM)的相关资料 。 在最基本的层面上,企业应该在下面三个方面制定好标准。 1.命名规则 命名规则应该在ETL组开始编码前制定好,范围包括表、列、约束、索引等等数据库对象以及其余一些编码规则。若是企业有本身的命名规则,ETL组应该遵照企业的命名规则。
当企业的命名规则不能彻底知足需求时,ETL组能够制定补充规则或者新的规则。对企业命名规则的改变须要有详细的文档记录,并提交企业相关部门审核。 2.架构 在ETL组开始工做前,架构应该先被设计好。例如ETL引擎是和数据仓库放在同一台服务器上仍是单独设立服务器;数据准备区是创建成临时的仍是持久的;
数据仓库是基于维度建模的仍是3NF建模的。
而且这些内容应该有详细的文档记录。 3.基础结构 系统的基础结构也应该先肯定好。例如解决方案是基于Windows的仍是基于UNIX的。这些企业基础结构元数据应该在ETL组开始工做前制定好。这些内容也应该有详细的文档记录。 在ETL的开发中,制定好元数据标准并能很好的遵照,那么创建好的数据仓库的元数据就能够很好的完成共享功能。

24. State the primary types of tables found in a data warehouse and the order which they must be loaded to enforce referential integrity. 
简述数据仓库中的表的基本类型,以及为了保证引用完整性该以什么样的顺序对它们进行加载。 

答:数据仓库中的表的基本类型有维度表、事实表、子维度表、桥接表等几类。其中子维度表即雪花模型由支架维度技术处理,桥接表用来处理多值维度或层级结构。 

数据仓库中须要加载的各种表之间有相互依赖的关系,因此加载时须要以必定的顺序进行加载。下面是一些加载的基本原则: 

子维度表加载成功后,再加载维度表。 

维度表加载成功后,再加载桥接表。 

子维度表、维度表和桥接表都加载成功后,再加载事实表。 

这个加载顺序能够经过主外键的关系来肯定。 

(注意,此回答为总线架构的数据仓库的表的加载顺序。)

25. 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的开发人员。
第一级别的技术支持人员不该该仅仅提供电话支持服务,在将问题反映给下一个级别前,要尽本身的能力去解决问题。

26. What steps do you take to determine the bottleneck of a slow running ETL process? 
若是ETL进程运行较慢,须要分哪几步去找到ETL系统的瓶颈问题。 

答:ETL系统遇到性能问题,运行很慢是一件较常见的事情,这时要作的是逐步找到系统的瓶颈在哪里。 首先要肯定是由CPU、内存、I/O和网络等产生的瓶颈,仍是由ETL处理过程产生的瓶颈。 若是环境没有瓶颈,那么须要分析ETL的代码。这时,咱们能够采用排除的方法,须要隔离不一样的操做,并分别对它们进行测试。若是是采用纯手工编码方式的ETL处理,隔离不一样的操做要麻烦一些,
这时须要根据编码的实际状况来处理。若是是采用ETL工具的话,目前的ETL工具应该都有隔离不一样处理的功能,隔离起来相对容易一些。 分析最好从抽取操做开始,而后依次分析各类计算、查找表、汇集、过滤等转换环节的处理操做,最后分析加载操做。 实际的处理中,能够按照下面的七个步骤来查找瓶颈。
1.隔离并执行抽取查询语句。 先将抽取部分隔离出来,去掉转换和交付,能够将数据直接抽取到文件中。若是这一步效率不好,基本肯定是抽取SQL的问题。从经验来看,未经调优的SQL是一个最多见的致使ETL效率差的缘由。
若是这步没有问题进入第二步。
2.去掉过滤条件。 这一条是针对全抽取,而后在ETL处理中进行过滤的处理方式而言。在ETL处理中作过滤处理有时会产生瓶颈。能够先将过滤去掉,若是肯定为这个缘由,能够考虑在抽取时进行数据过滤。 3.排除查找表的问题。 参照数据在ETL处理过程当中一般会加载到内存中,目的是作代码和名称的查找替换,也称查找表。有时查找表的数据量过大也会产生瓶颈。能够逐个隔离查找表,来肯定是不是这里出现问题。
注意要将查找表的数据量降到最低,一般一个天然键一个代理键就能够,这样能够减小没必要要的数据I
/O。 4.分析排序和汇集操做。 排序和汇集操做都是很是费资源的操做。对这部分隔离,来判断是否由于它们引发性能问题。若是肯定是由于这个,须要考虑是否能够将排序和汇集处理移出数据库和ETL工具,移到操做系统中来处理。 5.隔离并分析每个计算和转换处理。 有时转换过程当中的处理操做也会引发ETL工做的性能。逐步隔离移除它们来判断哪里出了问题。要注意观察像默认值、数据类型转换等操做。 6.隔离更新策略。 更新操做在数据量很是大时是性能很是差的。隔离这部分,看看是否这里出了问题。若是肯定是由于大批量更新出了性能问题。应该考虑将insert、update和delete分开处理。 7.检测加载数据的数据库I/O。 若是前面各部分都没有问题,最后须要检测是目标数据库的性能问题。能够找个文件代替数据库,若是性能提升不少,须要仔细检测目标数据库的加载过程当中的操做。例如是否关闭了全部的约束,
关闭了全部的索引,是否使用了批量加载工具。若是性能尚未提升,能够考虑使用并行加载策略。


27. Describe how to estimate the load time of a large ETL job. 

Real Time ETL 

简述如何评估大型ETL数据加载时间。 

答:评估一个大型的ETL的数据加载时间是一件很复杂的事情。数据加载分为两类,一类是初次加载,另外一类是增量加载。 在数据仓库正式投入使用时,须要进行一次初次加载,而此次初次加载须要的时间通常较难预料。在数据仓库的平常使用和维护中,天天须要对数据仓库进行增量加载。增量加载的数据量要比初次加载小不少。 下面以初次加载为例来谈谈如何评估大型ETL的数据加载时间。 对初次加载的加载时间进行预估,须要将整个ETL过程分红抽取、转换和加载三部分,分别对这三部分进行评估。 1.对抽取时间的评估。 抽取一般占用的ETL的大部分时间,并且对这部分须要时间的评估也是很是困难的。为了对这部分时间进行评估,咱们能够将查询时间分红两部分,一部分是查询响应时间,另外一部分是数据返回时间。
查询响应时间指从查询开始执行到结果开始返回这段时间。数据返回时间指第一条记录返回到最后一条记录返回的时间。 另外,初次加载的数据量太大,咱们能够考虑选择其中的一部分来评估总体的时间,实际处理中,能够选择事实表的一个分区。通常来讲各个分区的数据量差很少,评估出一个分区的时间,
乘上分区数能够做为总体的评估时间。
2.对数据转换时间的评估 数据转换工做一般在内存中完成,通常来讲都有着很是快的速度,占整体时间的比重比较小。若是要评估这部分须要的时间的话,最简单的评估方法是先评估出抽取时间和加载时间,
而后运行整个过程,用总体时间减去抽取时间和加载时间。
3.对加载时间的评估 不少缘由均可能影响加载时间,其中最重要的两个分别是索引和日志。 对加载时间的评估,也能够像评估抽取时间时同样,选择加载数据的一部分,如1/200进行加载,计算出时间后乘以200来做为总体加载时间。 总之,大型ETL数据的加载时间的评估是很困难的,咱们采用的方法主要是类比评估,即选择一部分数据减小总体时间进行评估。
在进行评估时要注意到测试环境和生产环境的配置等的差异会引发评估结果的误差。虽然这种对时间的评估必定会有偏差,可是能够作为总体加载时间的一个参考。

28. Describe the architecture options for implementing real-time ETL. 
简述在架构实时ETL时的能够选择的架构部件。 

答:在创建数据仓库时,ETL一般都采用批处理的方式,通常来讲是天天的夜间进行跑批。 随着数据仓库技术的逐步成熟,企业对数据仓库的时间延迟有了更高的要求,也就出现了目前常说的实时ETL(Real-Time ETL)。实时ETL是数据仓库领域里比较新的一部份内容。 在构建实时ETL架构的数据仓库时,有几种技术可供选择。 1.微批处理(microbatch ETL,MB-ETL) 微批处理的方式和咱们一般的ETL处理方式很类似,可是处理的时间间隔要短,例如间隔一个小时处理一次。 2.企业应用集成(Enterprise Application Integration,EAI) EAI也称为功能整合,一般由中间件来完成数据的交互。而一般的ETL称为数据整合。 对实时性要求很是高的系统,能够考虑使用EAI做为ETL的一个工具,能够提供快捷的数据交互。不过在数据量大时采用EAI工具效率比较差,并且实现起来相对复杂。 3.CTF(Capture, Transform and Flow) CTF是一类比较新的数据整合工具。它采用的是直接的数据库对数据库的链接方式,能够提供秒级的数据。CTF的缺点是只能进行轻量级的数据整合。一般的处理方式是创建数据准备区,
采用CTF工具在源数据库和数据准备区的数据库之间相链接。数据进入数据准备区后再通过其余处理后迁移入数据仓库。
4.EII(Enterprise Information Integration) EII是另外一类比较新的数据整合软件,能够给企业提供实时报表。EII的处理方式和CTF很类似,可是它不将数据迁移入数据准备区或者数据仓库,而是在抽取转换后直接加载到报表中。 在实际创建实时ETL架构的数据仓库时,能够在MB-ETL, EAI, CTF, EII及一般的ETL中做出选择或者进行组合。


29. Explain the different real-time approaches and how they can be applied in different business scenarios. 
简述几种不一样的实时ETL实现方法以及它们的适用范围。 

答:实时数据仓库在目前来讲还不是很成熟,成功案例也比较少,下面列举了一些实时数据仓库架构的实现方法。 1.EII ONLY 使用EII技术来代替实时的数据仓库,数据延迟能够保证在1分钟左右,支持数据整合的复杂程度较低。没法保存历史数据。 2.EII + Static DW 使用EII技术联合非实时的数据仓库,数据延迟能够保证在1分钟左右,1天内的数据整合的复杂程度较低,1天前的数据整合的复杂程度能够较高。能够保存历史数据。 3.ETL + Static DW 普通的ETL处理,数据延迟在1天。支持复杂程度较高的数据整合。保存历史数据。 4.CTF + Real-Time Partition + Static DW 使用CTF技术创建实时数据仓库,数据延迟可保证在15分钟左右。数据整合的复杂程度较低。保存历史数据。 5.CTF + MB-ETL + Real-Time Partition + Static DW 使用CTF技术和MB-ETL联合处理数据迁移,数据延迟可保证在1小时左右,支持数据整合的复杂程度较高,保存历史数据。 6.MB-ETL + Real-Time Partition + Static DW 直接使用MB-ETL创建实时数据仓库,数据延迟可保证在1小时左右,支持数据整合的复杂程度较高,保存历史数据。 7.EAI + Real-Time Partition + Static DW 使用EAI技术创建实时数据仓库,数据延迟可保证在1分钟左右,支持数据整合的复杂程度较高。保存历史数据。 上面列出了一些实时数据仓库架构的选择,写的不是很详细,只是提出个思路,供你们本身去找资料学习。

30. Outline some challenges faced by real-time ETL and describe how to overcome them. 
简述实时ETL的一些难点及其解决办法。 

答:实时ETL的引入给数据仓库的建设带来了不少新的问题和挑战,下面列举了一些问题,其中有些问题有具体的解决办法,有些只能在实际状况下去斟酌。 1.连续的ETL处理对系统可靠性提出更高的要求。 2.离散快照数据的间隔时间变短。 3.缓慢变化维变成快速变化维。 4.如何肯定数据仓库中数据的刷新频率。 5.目的是只出报表仍是要实现数据整合。 6.作数据整合仍是应用整合。 7.采用点对点的方式仍是集中的方式。 8.前端展示工具的数据刷新方式如何肯定。 
相关文章
相关标签/搜索