niusouti.com
Describe how to estimate the load time of a large ETL job.Real Time ETL简述如何评估大型ETL数据加载时间。
题目
Describe how to estimate the load time of a large ETL job.
Real Time ETL
简述如何评估大型ETL数据加载时间。
相似考题
更多“Describe how to estimate the load time of a large ETL job.Real Time ETL简述如何评估大 ”相关问题
-
第1题：
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。
如果前面各部分都没有问题，最后需要检测是目标数据库的性能问题。可以找个文件代替数据库，如果性能提高很多，需要仔细检测目标数据库的加载过程中的操作。例如是否关闭了所有的约束，关闭了所有的索引，是否使用了批量加载工具。如果性能还没有提高，可以考虑使用并行加载策略。
-
第2题：
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分钟左右，支持数据整合的复杂程度较高。保存历史数据。
上面列出了一些实时数据仓库架构的选择，写的不是很详细，只是提出个思路，供大家自己去找资料学习。
-
第3题：
能获取系统当前时间分钟数的方法是以下哪个？
A．time.strftime(“% m”, time.localtime())
B．time.strftime(“%M”, time.localtime())
C．time.strftime(“%t”, time.localtime())
D．time.strftime(“%T”, time.localtime())
A -
第4题：
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中作出选择或者进行组合。 -
第5题：
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．前端展现工具的数据刷新方式如何确定。