ETL主要的厂商有（）A、IBMB、InformaticaC、微软D、CA

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

正确答案：
答：元数据是ETL项目组面对的一个非常重要的主题，对于整个数据仓库项目也是非常重要的一部分。对于元数据的分类和使用没有很确定的定义。
通常来说，我们可以把元数据分为三类，分别为业务元数据（Business Metadata），技术元数据（Technical Metadata）和过程处理元数据（Process Execution Metadata）。
业务元数据，是从业务的角度对数据的描述。通常是用来给报表工具和前端用户对数据进行分析和使用提供帮助。
技术元数据，是从技术的角度对数据的描述。通常包括数据的一些属性，如数据类型、长度、或者数据概况分析后一些结果。
过程处理元数据，是ETL处理过程中的一些统计数据，通常包括有多少条记录被加载，多少条记录被拒绝接受等数据

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

参考答案：C

答案：C

解析：

正确答案：
答：在数据仓库的项目中，分析是主导需求，而基于日期和时间的分析更是占了很大的比重。而在操作型源系统中，日期通常都是SQL的DATETIME型的。如果在分析时，使用SQL对这种类型的字段临时处理会出现一些问题，如效率很差，不同的用户会采用不同的格式化方法导致报表不统一。所以，在数据仓库的建模时都会建立日期维度表和时间维度表，将用到的和日期相关的描述都冗余到该表中。
但是，并不是所有的日期都被转化为日期维度表的外键。日期维度表中的记录是有限的，有些日期如生日等可能会比日期维度表中记录的最小日期还要早，这类字段可以直接在数据仓库中保存SQL的DATETIME型。而像购买日期等与分析的业务紧密相关的通常都需要转化为日期维度表的外键，可以用日期维度表中统一的描述信息进行分析。

正确答案：
答：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。
如果前面各部分都没有问题，最后需要检测是目标数据库的性能问题。可以找个文件代替数据库，如果性能提高很多，需要仔细检测目标数据库的加载过程中的操作。例如是否关闭了所有的约束，关闭了所有的索引，是否使用了批量加载工具。如果性能还没有提高，可以考虑使用并行加载策略。

正确答案：
答：在建立数据仓库时，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中作出选择或者进行组合。

参考答案：A,B,C