zoukankan      html  css  js  c++  java
  • ETL开发

    要进入开发阶段,了解不同的ETL产品。

    整个ETL系统中,时间或更精确的,吞吐量是主要关心的内容。这种转换处理任务设计的主要目的归根结底是使得数据装载到展现表中最快并使得最终用户能快速的从这些表中得到响应。

    推或者拉:推,是源系统主动把文件推向ETL服务器,拉是ETL服务器主动从文件服务器上抽取文件。无论是推拉都得保证数据没有错误,传输完成,确保传输完全的一个简单的标志是使用标志(信号)文件。标志仅仅表示它相关的文件的可读性。

    预装载中的数据排序

    源数据在数据库中的时候,排序很容易通过数据库,查询数据的order by来实现,但是如果源数据来自平面文件,那么开始ETL处理之前需要一个排序的程序:在主机系统中排序

    使用数据库的块加载工具加速数据插入

    用排序,抽取,聚合等方法把数据源的数据尽快的加载到ETL服务器之后,你将面临把大量的必要的数据加载到数据仓库。这个时候用到了数据库管理系统中的块加载功能。在数据库交互方面,块加载器比普通的sql语句效率更高。

    Oracle 的 sql loader如何提升的性能:1 SQL Loader对表使用一个排他锁,防止其他的操作  2 在直接模式中不能强制使用数据库约束(主键和唯一键约束,外键约束等)如果发生冲突,相关的索引将处于不稳定的状态,在重建索引之前需要手动清除 3 外键约束在直接加载过程中不可用,在加载后才可以重新启用 4 在直接模式中,插入触发器在行插入时候不被启动  

    Oracle  是  sql loader    SQL Server是 BulkCopyProgram 

    尽管在使用块加载夹在数据到数据仓库之前,你必须花费更多的IO性能来将数据写到物理文件中,但是他比数据直接访问数据库并用insert语句来加载要块的多

    管理数据特性来提高性能

    数据库有强大的特性 如索引,视图,触发器,主外键约束等,区别于平面文件。当数据库增长时管理这些特性将消耗大量的系统资源,结果是大大降低了ETL装载过程的性能。

    提高装载性能的选项:

    1 加载数据之前去除 主外键(参考完整性)约束。在外键约束的时候,每一行加载到数据库系统的外键列的数据都要与其浮标的主键值进行比较。通过去除多外间约束的事实表中的外键约束可以大大提高性能。(当加载完数据之后启用外键约束时数据库校验表中的每一行)

    2保持数据库统计表详细到天。(数据库统计表由数据库管理系统管理,他跟踪所有表的大小,索引中唯一值的大小和数量以及其他关于数据如何有效存储在数据库中的事实,当一个sql语句提交到数据库管理系统,他使用这些统计表来判断提供请求的数据的最快的访问路径,最理想的是每次加载完之后更新统计表)加载处理是经常性的。分区存储大表能提高更新统计表的速度,因为统计表不必刷新所有的静态分区而仅仅是当前的分区

    3在数据库中重组碎片数据,当经常性的更新或者删除会使得表变成碎片,导致响应时间变慢。处理大事实表的时候,最小化发生类似碎片的一种方法是创建分区表。一般根据时间分区

    次序

    当加载一个数据仓库的时候,一个批处理中作业的排列次序是至关重要的,主要原因是ETL需要在数据仓库中强制参考完整性(RI)。ETL处理要避免在数据仓库中创建孤儿(外建不存在主建)

    执行参考完整性:数据仓库的数据是通过一个可控的过程-ETL系统以块的方式加载的。数据进入数据仓库的入口是可控的和可管理的环境,数据库级别的RI约束一般在数据仓库中不起作用,因为数据仓库以来ETL来保证其完整性。RI在数据仓库中一般不用的另外一个原因是这样会在数据库级最小化管理费用来增加加载性能。当数据库中的RI启用的时候,每行数据在插入之前都要测试是否符合RI,也就是每一个外建都有一个父在他所要参考的表中。数据仓库的RI比交易系统的简单,交易系统中每个表和其他的表相关,引起相关表的复杂网。在纬度的数据仓库中规则很简单:事实表的每一个外建都必须在纬度表中有一个相关的主建,纬度表中的每个主建不必再事实表中有一个相关的外建。实际上,事实可能与一个纬度中的多个记录向关联(纬度可能是雪花形)

    以下的列表提供一个对一个假设的数据集市的加载过程的顺序位置的指导。1 子维度(支架2维度3桥连接表4事实表5层次映射6聚合(缩小的)维度7聚合事实表

    子纬度: 一个子纬度,是直接将一个纬度附加到另外一个纬度上,这个时候可以叫做雪花模型。子纬度一般地一个加载到数据仓库中,因为依赖关系链始于最远的表,也就是子纬度。事实表依赖惟独,而惟独依赖子纬度。

    纬度:一旦子惟独加载了,你就可以加载惟独了,唯独需要用子惟独中的代理建来做对照,因此它可以在加载过程中插入到惟独中。纬度家在必须在继续处理之前完全成功,如果失败,调度程序必须在那个失败点上停止加载过程来阻止剩下的作业的加载。

    桥连接表:当一个事实表的记录对应多个纬度记录的时候,桥连接表位于惟独表和事实表之间,桥连接表也可以用在唯独表和多个子惟独表关系中。这些标在惟独表完成之hou事实表加载之前开始立即加载

    事实表:在这里RI是强制的,因此必须确保事实表中每一个外建都有来自相关纬度或者桥连接表的相应的主建。事实表一般在数据仓库加载中是各种表类型中最耗时的;你应该在所有与这个事实表相关的表都已经加载后才开始加载事实表。不要等到数据仓库中所有的维度表加载完成才开始进行事实表的加载。由于存储在事实表中的数据容量一般非常大,以并行处理来加载是不错的思路。调度程序应该将ETL 过程分为多个线程,这样可以同时运行并从并行处理获益。

    层次影射表:层次影射表专门设计来在惟独中的层次中来回移动。层次影射表不依赖于事实或者桥连接表(除非事实表包本身含层次)。一般来说,层次表可以紧跟在与之相关的惟独表后加载。无论层次在批处理中物理位置如何,他的成功失败都不影响这个皮处理中的其他的处理。不要因为层次影射表失败就终止已经开始的事实表的处理,影射表可以独立的重新开始任何事实表的加载。

    聚合和分组对性能的影响:聚合函数和group by语句要求数据库利用大量的临时表空间。临时表空间是DBMS管理的一个特殊的区域,用来存储需要处理的某些包含排序查询的工作表。SQL在执行它的服务器上进行处理。这就意味着如果你试图在你的抽取查询中进行数据聚合,你将很可能撑破源交易系统分配的临时表空间。当你需要建立一个聚合表时,比较好的处理是利用ETL 引擎或第三方工具的特殊功能来加快排序数据的速度。你应该使用支持增量更新到聚合的专门工具来逐步调整你的聚合。

    不要试图用带Group By 语句的SQL 在你的数据抽取查询中执行聚合。GroupBy语句用语句中所有的列来建立一个隐含排序。交易系统一般不会配置来处理巨大的排序操作,因为这样的查询可能摧毁源数据库。抽取必要的原子级数据并随后在ETL 管道中利用ETL 引擎或专用排序程序来聚合

     使用标量函数对性能的影响:函数有参数,会给查询施加压力,尤其那些必须一个字符一个字符的评估值的函数。如SUBSTR(),CONCAT(),TRIM(),ASCII().数据库在处理函数方面变得越来越好。Oracle 已经引入基于函数的索引,这样对包含基于函数约束的查询的响应时间就加快了。

     避免使用触发器

    克服ODBC瓶颈:第3 章提供深入分析开放数据库连接管理器(ODBC)的各个层。在你的ETL 引擎和数据库之间进行通信时ODBC 并不是必须的,它可以—应该—避免。ODBC 在每个SQL 语句上增加代码层。它相当于在引导一个类时使用一个转换器。这个消息最终可以通过但是这是很慢的过程。因此有时候,时间就耗费在这个转换上了。在处理中尝试获得本地驱动程序来参与在ETL 引擎和数据库之间的通信。记住,就像一条链子,它的强度取决于它的最薄弱的一环一样,ETL 只是与它的最慢的部分一样快。

     利用并行处理的优势:以并行方式处理ETL是提高性能的最强大的方法。一次同时多个操作。

     1 并行抽取查询:大多数DBMS 有并行处理查询的能力,实际上它是同样的处理同时集约的管理内存。最优化并行解决方案一般由两种技术组成—产生几个抽取查询,每个有不同范围的值,接着以数据库特定的并行查询技术来并行执行每一个处理。那些支持它的每个数据库都有它本身执行并行查询的语法。在Oracle 中,通过在建表时设置degree 参数来启用并行功能

     2 并行转换:购买一个可以进行本地并行操作的工具,手动复制一个过程,分割输入数据,然后并行执行这些过程。如果你确实有大量的数据需要放入数据仓库,顺序的处理所有的ETL操作是不够的,那就必须找到一种ETL工具,可以提供天然的并行方式处理多个操作来获得最佳的吞吐量(这里并行功能是转换引擎直接内置的,不是执行并行扩展)

    3 并行最终加载:产生sql loader多处理,每个分区一个,并且并行运行,当执行许多sql loader处理的时候,必须设计parallel的参数为true。

    性能问题纠错

    当发现一个奇怪的作业使得性能相当缓慢的时候,不要删除他,直接采取一种程序化的方法来找出处理中引起瓶颈的操作并标出那个特殊的操作。监视如CPU,内存,I/O和网络流量这些地方来判断任何高层次的瓶颈。如果没有任何瓶颈,那么需要深入代码分析,使用排除过程来缩小潜在的瓶颈范围。但整个SQL语句手工编写,分割会很困难,实际上所有的ETL工具都提供一种用来把处理分割成独立部分的机制以帮助判断无法预知的瓶颈。最佳策略是:从抽取开始,顺序沿着每个激素,对照,聚合,筛选等转换操作,最后测试实际数据加载到数据仓库的IO。

    可以按照下列步骤来标志出瓶颈:1 隔离并执行抽取查询 2 关闭筛选 3去掉查找 4 谨慎的排序和聚合,很多时候在数据库和ETL工具之外(操作系统中)进行排序或预先排序更快 5 隔离和分析每个计算或转换,隔离和分析每个计算或转换是检测和补救瓶颈的一个好方法 6消除更新策略 7 检查数据库IO

    增长的ETL吞吐量。ETL小组都期望有最大吞吐能力的ETL流程,为此,推荐10个规则来帮厨ETL提高水平。

    1 减少I/O ,以管道的方式处理ETL流程,保证数据从开始抽取阶段到最后装载都是在内存中处理

    2消除数据库读写,当把数据写入磁盘的时候,最好用平面文件代替数据库表

    3尽可能的过滤,尽可能的在处理的上游减少记录数目,避免不必要的数据进入数据仓库目标表

    4分区和并行,多线程并行处理,用并行DML在源系统中并行查询,用管道方式并行处理数据,分区设计,并行装载目标表

    5更新增量聚合,重构聚合对处理消极影响很大,尽量避免,只是更新

    6只抓去需要的行列,避免不需要的记录

    7块装载/减少日志,使用数据库块转换功能,减少更新操作,用删除插入代替,关闭日志,把direct设置为true

    8删除数据库约束和索引,如果必须外键,那么ETL处理之前先删除,之后在后置任务上再加上

    9消除网络拥堵。保证文件是在本地磁盘,ETL服务器放置在数据仓库服务器。

    10 让ETL系统处理工作,最小化对数据库功能依赖。避免存储过程,函数。

  • 相关阅读:
    树链剖分 (模板) 洛谷3384
    ST表 (模板) 洛谷3865
    IOI 2005 River (洛谷 3354)
    IOI 2005 River (洛谷 3354)
    poj1094 Sorting It All Out
    poj1094 Sorting It All Out
    spfa(模板)
    HAOI 2006 受欢迎的牛 (洛谷2341)
    HAOI 2006 受欢迎的牛 (洛谷2341)
    洛谷1850(NOIp2016) 换教室——期望dp
  • 原文地址:https://www.cnblogs.com/zourui4271/p/5151764.html
Copyright © 2011-2022 走看看