niusouti.com
参考答案和解析
正确答案:
答:事实表从粒度的角色来划分可以分为三类,分别是交易粒度事实表(Transaction Grain)、周期快照粒度事实表(Periodic Snapshot)和累计快照粒度事实表(Accumulating Snapshot)。在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。
交易粒度事实表的来源伴随交易事件成生的数据,例如销售单。在ETL过程中,以原子粒度直接进行迁移。
周期快照事实表是用来记录有规律的,固定时间间隔的业务累计数据,例如库存日快照。在ETL过程中,以固定的时间间隔生成累计数据。
累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息。在ETL过程中,随着业务处理过程的步骤逐步完善该表中的记录。
更多“Name the three fundamental fact grains and describe an ETL approach for each.简述三种 ”相关问题
  • 第1题:

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

  • 第2题:

    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中作出选择或者进行组合。

  • 第3题:

    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.前端展现工具的数据刷新方式如何确定。

  • 第4题:

    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数据的加载时间的评估是很困难的,我们采用的方法主要是类比评估,即选择一部分数据减少整体时间进行评估。在进行评估时要注意到测试环境和生产环境的配置等的差别会引起评估结果的偏差。虽然这种对时间的评估一定会有误差,但是可以做为整体加载时间的一个参考。

  • 第5题:

    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分钟左右,支持数据整合的复杂程度较高。保存历史数据。
    上面列出了一些实时数据仓库架构的选择,写的不是很详细,只是提出个思路,供大家自己去找资料学习。