ETL工具中ELT 特点、局限性和缺陷

一、ETL概念

        ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据， ETL是BI（商业智能）项目重要的一个环节。

二、E-T-L架构分类

        ETL所描述的过程，一般常见的作法包含ETL或是ELT（Extract-Load-Transform），并且混合使用。

        E T L 为独立软件产品代表（Informatica 、Beeload ）E L T 依赖数据库引擎代表：ODI (甲骨文收购)

三、E-L-T架构

       在ELT架构工具典型代表即ODI提供了call web service的机制，并且ODI的接口也可以暴露为web service，从而可以和SOA环境进行交互。ODI能够检测事件，一个事件可以触发ODI的一个    接口流程，从而完成近乎实时的数据集成。ODI的主要功能特点有：
      a.使用CDC作为变更数据捕获的捕获方式。 
      b.代理支持并行处理和负载均衡。
     c.完善的权限控制、版本管理功能。
     d.支持数据质量检查，清洗和回收脏数据。
    e.支持与JMS消息中间件集成。

    f.支持Web Service。

四、E-L-T 架构 VS E-T-L架构

        ODI最大的特点是提出了知识模块的概念(Knowledge Module)

        ODI在功能，性能，UI友好性，场景适应等方面存在的不足。本身架构的限制，很多功能还是难以实现，即使可以实现也显得不灵活，或实现过程过于复杂。下面是在POC中经常遇到功能场景，可以说明ODI的局限性和缺陷。

 

序号	项目		（E-L-T）架构 ODI ：Oracle Data Integrator	(E-T-L) 架构 Informatica Beeload
1	来源		Oracle在2006年收购Sunopsis被重新命名成Oracle Data Integrator	原厂开发 Informatica（入华2005） Beeload   （V1.0 2004）
2	产品架构		多数功能、性能依赖于数据库引擎 （如 开放API调度EDQ任务执行，EDQ有自己的处理引擎，可脱离ODI独立运行。）	独立数据整合平台
3	实时同步		不支持 （需要与Oracle 收购的Golden Gate集成，GoldenGate并不是直接将实时数据投递给ODI，中间需要数据落地，ODI通过周期性的调度任务实现从GoldenGate的落地数据抽取数据，再向目标同步数据。	支持
4	跨机构实时数据交换		难实现，无法保证数据的一致性	支持
5	元数据转换		编写程序完成 （在异构数据库环境下，数据迁移，当目标数据库为空库时，只能该项工作）	转换知识库中表的数据库类型实现DDL语法的转换。
6	断点续传		不支持 （当发生异常时，如断电，网络抖动或中断，服务器宕机，人为操作失误等问题时，尤其在源数据记录特别庞大时）	支持
7	列行转换		无法直接实现 编写存储过程来实现	支持 图形配置即可
8	工作流设计		未达到	支持
9	非结构化转换		编写Java程序实现：花费 时间/人力 （没有针对非结构化和半结构化数据转换为结构化或XML格式的功能，复杂的报表表头的处理更是一件非常麻烦的事情。	提供图形化操作方式 非结构化和半结构化数据向XML格式的转换，提供图形化操作方式
10	自定义函数调用		编写自定义的函数或者Java，C等程序来实现	内涵丰富自定义函数 无需额外程序的编写
11	UI人性化		页面布局过分拥挤，不直观很多编辑项深埋看不到	界面简洁，布局合理
12	性 能 比 较	输出为文本文件	编写脚本，与核心工作无关，只做简单调度	图形配置
		读-转换-写	数据库SQL的串行执行	同时工作且实现且partitioning功能，即“流式处理”方式
		磁盘I/O	需要更多磁盘I/O 一条SQL解决不了问题，这样处理过程数据需要落地为文件（必然带来磁盘的I/O消耗） 依赖数据库能力完成	CPU和I/O 都不会成为瓶颈
		拆分文件	编写多份脚本实现 每多拆分出一份就需要多定义一个package，在文件合并的时候，还需要多定义一个事件触发条件	自动
		接口方式	仅JDBC方式	JDBC方式 Native Driver

 

五、ODI不适宜的场景

     通过上面内容的阐述，我们会发现在数据集成这个领域，ODI他的强项应该是和具有强大处理能力的数据库结合在一起，且最好所有处理都在一个数据库内完成，不能出库，如Exadata，Teradata等，如果数据量非常大，一旦遇到输出为文件，异构数据库间的数据整合，那么，ODI的性能就会受到影响，因此，也就很难将其放在企业级数据集成平台的重要组成部分位置，理由就是，除了工作流调度之外，所有最核心的功能全部需要依靠数据库实现。

     下面几点是数据集成中经常遇到的场景，也成为了ODI最不适宜的场景。

1、文件处理

2、业务逻辑复杂，流程环节较多

3、异构大数据量数据整合

4、不同数据库间元数据转换，元数据交换和血缘分析

5、数据整合过程中需要数据质量监控

6、对目标数据库影响大