|
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。
如果前面各部分都没有问题，最后需要检测是目标数据库的性能问题。可以找个文件代替数据库，如果性能提高很多，需要仔细检测目标数据库的加载过程中的操作。例如是否关闭了所有的约束，关闭了所有的索引，是否使用了批量加载工具。如果性能还没有提高，可以考虑使用并行加载策略。
|
|
Describe how to estimate the load time of a large ETL job. 简述如何评估大型ETL数据加载时间。 答：评估一个大型的ETL的数据加载时间是一件很复杂的事情。数据加载分为两类，一类是初次加载，另一类是增量加载。 在数据仓库正式投入使用时，需要进行一次初次加载，而这次初次加载需要的时间一般较难预料。在数据仓库的日常使用和维护中，每天需要对数据仓库进行增量加载。增量加载的数据量要比初次加载小很多。 下面以初次加载为例来谈谈如何评估大型ETL的数据加载时间。 对初次加载的加载时间进行预估，需要将整个ETL过程分成抽取、转换和加载三部分，分别对这三部分进行评估。 1．对抽取时间的评估。 抽取通常占用的ETL的大部分时间，而且对这部分需要时间的评估也是非常困难的。为了对这部分时间进行评估，我们可以将查询时间分成两部分，一部分是查询响应时间，另一部分是数据返回时间。查询响应时间指从查询开始执行到结果开始返回这段时间。数据返回时间指第一条记录返回到最后一条记录返回的时间。 另外，初次加载的数据量太大，我们可以考虑选择其中的一部分来评估整体的时间，实际处理中，可以选择事实表的一个分区。一般来说各个分区的数据量差不多，评估出一个分区的时间，乘上分区数可以作为整体的评估时间。 2．对数据转换时间的评估 数据转换工作通常在内存中完成，一般来说都有着非常快的速度，占总体时间的比重比较小。如果要评估这部分需要的时间的话，最简单的评估方法是先评估出抽取时间和加载时间，然后运行整个过程，用整体时间减去抽取时间和加载时间。 3．对加载时间的评估 很多原因都可能影响加载时间，其中最重要的两个分别是索引和日志。 对加载时间的评估，也可以像评估抽取时间时一样，选择加载数据的一部分，如1/200进行加载，计算出时间后乘以200来作为整体加载时间。 总之，大型ETL数据的加载时间的评估是很困难的，我们采用的方法主要是类比评估，即选择一部分数据减少整体时间进行评估。在进行评估时要注意到测试环境和生产环境的配置等的差别会引起评估结果的偏差。虽然这种对时间的评估一定会有误差，但是可以做为整体加载时间的一个参考。 |
浅析实时ETL的架构选择
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中作出选择或者进行组合。
|
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分钟左右，支持数据整合的复杂程度较高。保存历史数据。
上面列出了一些实时数据仓库架构的选择，写的不是很详细，只是提出个思路，供大家自己去找资料学习。
|
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．前端展现工具的数据刷新方式如何确定。