ODI技术白皮书_可编辑.docVIP

  1. 1、本文档共25页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

OracleDataIntegrator技术白皮书第PAGE2页

OracleDataIntegrator

技术白皮书

TOC\o1-3\h\z1 介绍 2

2 E-LT体系结构 3

2.1 传统的ETL 3

2.2 E-LT 4

3 声明设计(DECLARATIVEDESIGN) 6

3.1 传统的ETL设计 6

3.2 声明设计(DeclarativeDesign) 6

4 知识模块(KNOWLEDGEMODULES) 9

4.1 知识模块的类型 9

4.2 设计阶段和运行阶段的知识模块 9

4.3 灵活性和可扩展性 10

5 面向事件的集成 11

5.1 面向消息的集成 11

5.2 变化数据捕获 11

5.3 发布和订阅模型 12

5.4 处理变化数据集的一致性 12

6 支持SOA框架 14

6.1 数据和转换服务 14

6.2 WebServices访问 15

7 数据完整性 16

7.1 为数据完整性声明规则 16

7.2 在集成过程中的数据完整性防火墙 17

7.3 强制规则 17

7.4 使用第三方姓名及地址清洗工具 18

8 体系结构 19

8.1 用户界面 19

8.2 代理 20

8.3 存储库 20

8.4 元数据导航器/轻量级设计器 21

9 方案(SCENARIOS) 22

9.1 数据仓库和商业智能 22

9.2 面向服务的集成 23

9.3 主数据管理 24

10 结论 25

介绍

整合整个企业的数据和应用,并将它们在一个统一的视图中进行展现是一个复杂的任务。大量的不一致性不仅仅体现在技术、数据结构和应用功能上,而且在整体的体系结构上也存在着基本的差距。有一些集成需求是面向数据的,尤其是那些对大数据量的需求。还有一些其它的集成项目是基于事件驱动的体系架构(EDA)或者面向服务的体系架构(SOA),如异步或同步的集成。

许多组织针对这些多样化需求采用了广阔的工具和技术,结果就会造成杂乱的集成项目而无法将它们进行综合利用和统一起来。这些工具不符合整体的性能、灵活性和模块化的需求。

OracleDataIntegrator提供了一个集成平台包括的所有数据集成的功能:基于数据的、基于事件的和基于服务的。通过高效地转换大数据量的能力、用先进的变化数据捕获(CDC)在实时环境中处理事件,以及提供数据服务给OracleSOA套件,OracleDataIntegrator统一了各种孤立的集成技术。它还提供了强大的数据完整性控制能力,确保数据的一致性和正确性。

采用不同于传统工具的独特核心特性—异构E-LT、声明设计和知识模块等—OracleDataIntegrator符合高性能、灵活性、高生产率、模块化和热插拔的集成平台的需求。

E-LT体系结构

传统的ETL

传统的ETL工具的运行方式是,首先从多种数据源抽取数据,然后在一个专有的、中间层的ETL引擎转换数据,最后装载转换后的数据到数据仓库或集成服务器中。因此“ETL”不仅仅是个名称还表现了操作的顺序。

迄今为止,ETL过程的数据转换是计算密集型最大的步骤,并且执行的整个过程完全是由专有ETL引擎在专用服务器上完成的。ETL引擎执行数据转换(有些时候还要进行数据质量检查)是基于行级进行的,因此,在整个过程中很容易变成瓶颈。另外,数据一定要在网络移动两次,一次是数据源和ETL服务器之间,一次是ETL服务器和目标数据仓库之间。因此,如果用户想要确保参照完整性,例如通过从数据仓库比较数据发现违反参照完整性的值,那被参照的数据一定要从目标下载到ETL服务器,这样就更增加了网络负载及下载时间并导致额外的性能问题。

例如,让我们看一下传统的ETL任务如何从目标数据仓库寻找记录去匹配数据源的数据。为了执行这样一个任务,一个传统的ETL工具可能会使用下列三个方法之一:

装载Look-up表到内存:整个look-up表被从目标服务器上检索并被装载到ETL引擎的内存中。在作为结果的被转换的数据写回目标服务器之前,用源数据记录匹配(或连接)这个look-up数据是在内存中完成的。如果look-up表是相当大的,那么这个操作将需要在ETL引擎中耗费大量的内存和长时间的数据装载,以及重建索引。

即时执行,逐行查找:对于每一行,ETL引擎都要送一个查询到位于目标服务器上的look-up表。查询的结果将返回一行已匹配(或已连接)当前行的记录。如果look-up表包含50万行记录,ETL引擎将送50万个查询。这种处理

您可能关注的文档

文档评论(0)

159****7226 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档