ODI学习笔记2--ODI产品架构

Posted 2020-08-01 lclc

ODI学习笔记2--ODI产品架构

ODI产品架构：

 

ODI提供了以下几种管理工具：
Designer 用于定义数据转换逻辑，这是最常用的开发工具，大部分的开发任务，包括data store的定义，interface(数据映射关系)和package（相当于workflow）的创建等，都是在Designer中完成。
Operator用于管理和监控数据转换任务的执行情况，在设计阶段，也可用于调试(debugging)
Topology Manager用于定义物理和逻辑基础架构，如work repository的创建和管理等。
Security Manager用于管理用户权限
以及一个计划代理程序：
Schedule Agent计划代理，用于调度执行数据转换任务。计划代理同时也带有一个数据转换引擎，但是ODI采用E-LT架构，所以基本上计划代理只是将任务传递给目标库，其数据转换引擎很少用到。

  

可扩展的知识模型（Knowledge Modules）

ODI能够从各种异构的数据库平台和基于信息队列的技术（Web services）加载、转换数据，并且具有灵活性、可扩展性和有效性等，主要是依靠知识模型；

知识模型作为ODI的插件，封装了各种针对面向特定数据源和Target的ETL过程。ODI提供了六种知识模型，如下图所示：

  

 

RKM：完成从源系统和目标系统的数据结构的反向工程来形成数据模型的功能。

JKM：完成捕获CDC，执行增量抽取以及工作任务安排的数据模型功能。

LKM：LKM完成从源数据库数据加载到临时表。

CKM:CKM完成数据质量检查。
IKM：IKM完成从临时表的数据加载到目标表。
SKM：SKM完成ODI和WEB服务接口的功能。

 

Data-Quality Firewalls

通过使用CKM知识模型，仅仅允许那些符合业务规则的数据进入集成进程，以此能够把不符合规则的数据拦在数据源端，从而保证数据质量！

 

Support for Changed-Data Capture

JKM知识模块负责监测源数据库变化的数据，有些数据库供应商，比如Oracle直接支持CDC，另外一些供应商则通过比如触发器技术捕获DML语句。

Oracle Data Integrator in Relation to Oracle Warehouse Builder

OWB在涉及SOA和非Oracle 数据源方面上无能为力，但两者又是互补的关系，看下图：

ODI能过从基础各种各样异构的数据源，包括Web Services和基于事件的架构。一旦数据被集成复制进入DW Staging area，OWB开始接管接下来的任务，包括创建ODS以及多维模型等。

参见：

http://www.oracle.com/technology/pub/articles/rittman-odi.html

http://snipkingderek.spaces.live.com/blog/cns!EE24905211C3FFD!399.entry