简述ETL机组的工艺流程。

正确答案：
答：事实表从粒度的角色来划分可以分为三类，分别是交易粒度事实表（Transaction Grain）、周期快照粒度事实表（Periodic Snapshot）和累计快照粒度事实表（Accumulating Snapshot）。在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
交易粒度事实表的来源伴随交易事件成生的数据，例如销售单。在ETL过程中，以原子粒度直接进行迁移。
周期快照事实表是用来记录有规律的，固定时间间隔的业务累计数据，例如库存日快照。在ETL过程中，以固定的时间间隔生成累计数据。
累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息。在ETL过程中，随着业务处理过程的步骤逐步完善该表中的记录。

正确答案：
答：数据仓库上线后，ETL组需要为保证ETL工作的正常运行提供技术支持。通常这种技术支持工作分为四个级别。
1．第一级别的技术支持通常是电话支持人员，属于技术支持服务窗口（Help Desk）类型。如果数据迁移出现错误或者用户发现数据有问题，问题通过电话反映到第一级别的技术支持处。第一级别支持人员通过ETL项目组提供的一些问题的解决办法尽可能的解决发现的问题，阻止问题升级。
2．第二级别的技术支持通常是系统管理员和DBA。如果第一级别不能解决问题，问题反映到第二级别。第二级别的人员通常技术上比较强，硬件基础结构和软件架构上的问题都可以解决。
3．第三级别的技术支持通常是ETL项目负责人。如果第二级别不能解决问题，问题反映到第三级别。ETL项目负责人应该具备足够的知识，能够解决生产环境中的绝大部分问题。ETL项目负责人在必要时可以和开发人员或者外部产品提供商对某些问题进行交流，以便找出解决问题的办法。
4．第四级别的技术支持通常是ETL的实际开发人员。如果第三级别不能解决问题，问题反映到第四级别。ETL的实际开发人员可以对代码进行跟踪分析并找到问题的解决办法。如果问题出现在产品供应商的应用中，还需要供应商提供技术支持。
在小一些的数据仓库环境中，也是通常的情况下，第三级别和第四级别可以合并在一起。合并后对第二级别的要求会高一些。不建议每次出现问题都找ETL的开发人员。第一级别的技术支持人员不应该仅仅提供电话支持服务，在将问题反映给下一个级别前，要尽自己的能力去解决问题。

正确答案：
答：评估一个大型的ETL的数据加载时间是一件很复杂的事情。数据加载分为两类，一类是初次加载，另一类是增量加载。
在数据仓库正式投入使用时，需要进行一次初次加载，而这次初次加载需要的时间一般较难预料。在数据仓库的日常使用和维护中，每天需要对数据仓库进行增量加载。增量加载的数据量要比初次加载小很多。
下面以初次加载为例来谈谈如何评估大型ETL的数据加载时间。
对初次加载的加载时间进行预估，需要将整个ETL过程分成抽取、转换和加载三部分，分别对这三部分进行评估。
1．对抽取时间的评估。
抽取通常占用的ETL的大部分时间，而且对这部分需要时间的评估也是非常困难的。为了对这部分时间进行评估，我们可以将查询时间分成两部分，一部分是查询响应时间，另一部分是数据返回时间。查询响应时间指从查询开始执行到结果开始返回这段时间。数据返回时间指第一条记录返回到最后一条记录返回的时间。
另外，初次加载的数据量太大，我们可以考虑选择其中的一部分来评估整体的时间，实际处理中，可以选择事实表的一个分区。一般来说各个分区的数据量差不多，评估出一个分区的时间，乘上分区数可以作为整体的评估时间。
2．对数据转换时间的评估
数据转换工作通常在内存中完成，一般来说都有着非常快的速度，占总体时间的比重比较小。如果要评估这部分需要的时间的话，最简单的评估方法是先评估出抽取时间和加载时间，然后运行整个过程，用整体时间减去抽取时间和加载时间。
3．对加载时间的评估
很多原因都可能影响加载时间，其中最重要的两个分别是索引和日志。
对加载时间的评估，也可以像评估抽取时间时一样，选择加载数据的一部分，如1/200进行加载，计算出时间后乘以200来作为整体加载时间。
总之，大型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分钟左右，支持数据整合的复杂程度较高。保存历史数据。
上面列出了一些实时数据仓库架构的选择，写的不是很详细，只是提出个思路，供大家自己去找资料学习。

正确答案：
答：元数据是ETL项目组面对的一个非常重要的主题，对于整个数据仓库项目也是非常重要的一部分。对于元数据的分类和使用没有很确定的定义。
通常来说，我们可以把元数据分为三类，分别为业务元数据（Business Metadata），技术元数据（Technical Metadata）和过程处理元数据（Process Execution Metadata）。
业务元数据，是从业务的角度对数据的描述。通常是用来给报表工具和前端用户对数据进行分析和使用提供帮助。
技术元数据，是从技术的角度对数据的描述。通常包括数据的一些属性，如数据类型、长度、或者数据概况分析后一些结果。
过程处理元数据，是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。
如果前面各部分都没有问题，最后需要检测是目标数据库的性能问题。可以找个文件代替数据库，如果性能提高很多，需要仔细检测目标数据库的加载过程中的操作。例如是否关闭了所有的约束，关闭了所有的索引，是否使用了批量加载工具。如果性能还没有提高，可以考虑使用并行加载策略。

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

正确答案：C