ODI教程

ODI教程ODI--OracleDataIntegrator是一个全面的数据集成平台，它能满足所有数据集成要求，涉及领域包括高容量、高性能批处理、事件驱动的少量传送集成过程以及支持SOA的数据服务,在数据加载过程中也提供了数据质量检查,监控等功能,使数据更符合业务要求.提到ETL大家都很熟悉,数据提取,转换,加载的产品.我们平时自己也会开发一些类似ETL的小工具,把不同数据源汇总到一个目标数据源.但如果数据源很多,表也很多的话,这样的工作就是比较复杂的过程,我们需要做很多定制开发工作.而数据库之间的数据转换接口又很难满足我们对数据质量的要求,数据传输过程中的性能问题也会经常让人头疼.ODI的前身是Sunopsis公司的数据集成产品:2006年10月9日甲骨文宣布收购法国数据集成软件公司SunopsisSASunopsis公司产品用于把数据从不同来源例如数据库以及企业资源计划(ERP)等应用整合到一个目标地方,供数据分析和其他任务使用.Sunopsis总部在法国,成立1998年,客户有环球唱片集团德国公司,道达尔石油集团意大利子公司等.从技术角度来看看ODI特点:1.ODI本身是一种开放的价构,支持几乎所有目前流行的关系数据库.而且它是Java开发的产品,可以跨windows,unix平台,同时还能与中间件融合,可以融合到整个IT架构中.2.ODI推出ELT架构,与传统的ETL架构相比,少了中间的转换引擎.很多ETL产品都需要安装自己的转换引擎,而ODI直接调用源数据或目标数据服务器的数据库端.这样,实际数据处理,相当于数据库与数据库之间的连接处理,而数据库服务器处理效率远高于单独一台转换引擎做转换,因为它始终保持数据在数据库中处理.3.ODI有自己的知识模块,这些知识模块可以根据需求进行选择,而且这些知识模块支持开放式的设计,可以用自己熟悉的数据库语言或者Java语言来实现,可以更好地设计数据库流和业务要求.ODI可以结合数据库的优化模式,可以通过知识模型设计自己的知识模块,使处理数据更快.4.ODI可以把数据发布成服务与SOA进行完美结合,使ODI可以结合到业务流程当中,通过Web服务的方式进行数据实时地查看和修改.ODI几个基本概念ODI安装配置时候,总是有逻辑架构、上下文、物理架构，还有就是Flow.还有一个就是被问的最多的，StagingArea是不是相当于ETL服务器的Transformation.个人理解：Flow:如果用FlowControlOption进行集成控制，必须选择updatekey.updatekey是目标数据源中一个可以唯一识别一行的列集合。UpdateKey可以用来执行更新和流控制。它可能是定义在目标数据源中的Primary/UniqueKeys。在interface中定义。如果目标数据源有主键，在关系图（Diagram)中选择目标数据源，然后选择更新键。Flow:它就是数据从源数据源到目标数据源的路径。这个流检查数据怎样被提取、转换、集成到目标源。StagingArea:是一个独立、专有的在一个关系数据库中用来为ODI创建临时对象的区域。默认它在目标数据库中，如果目标数据源不时一个RDBMS，那么必须把StagingArea定义到一个RDBMS。StagingArea在Interface的Definition中定义。ODI逻辑架构:一个物理模式(physicalschema)由一个ownerschema和一个workschema组成，workschema主要用于一些临时表等对象，考虑单独创建用户维护这个对象．物理架构:一个逻辑模式(logicalschema)是物理模式的别名，防止用户更改数据库服务器IP地址,用户名，数据库服务器密码等信息．可以理解为同义词，避免用户在使用过程中加入数据库dblink.物理模式的修改，不影响逻辑模式．上下文：物理模式信息的修改不影响逻辑模式的引用，但如果物理模式数据库服务器的连接信息改变，就比较麻烦．上下文的出现就是允许逻辑模式通过上下文连接多个物理模式，避免因为连接信息改变而重新定义．当然，上下文是匹配所有物理模式的．ODI在设计开发阶段是通过引用逻辑模式完成的．在执行阶段，通过上下文找到相应的物理模式，然后执行转换．如果需要在上下文中执行一个对象，必须在上下文中匹配逻辑模式．在上下文中，几乎一个逻辑模式匹配一个物理模式．ODI整体架构ODI整体架构没有OracleDatabase复杂，因为它属于程序功能的使用，更多是程序开发和配置的工作，当然ODI的优化涉及到很多数据库优化的工作，从整体架构入手，基础有了，整体把握就会简单很多。首先理解ODI组件的几个组成部分、ODI资料库，最后看组件与资料库的关系。ODI是一个数据整合的平台。简单讲，就是在不同信息系统或者数据库之间做数据传输、转换。ODI也是数据整合的一个开发平台，主要涉及2个方面：1.ODI是服务驱动的模式，也可以理解为时商业驱动的模式，它更多关注怎样符合业务规则，而不是把开发精力集中在技术层面。2.ODI使用ELT方式在数据整合过程中，它自己本身不执行数据整合的处理，所以得执行都是在现有的信息系统或者数据库中完成。ODI是基于元数据管理的。元数据资料库存储是信息系统或者数据库信息以及它们的内容。它们被集中存储在一个资料库。ODI实现了简单快速整合。简单非简约，快速非量小。这个整个架构的核心组件就是资料库(Repository).它存储了IT架构的配置信息、所有应用、项目、情景和执行日志的元数据。资料库可以安装在一个RDBMS，也就是关系型数据库上。资料库也包含ODI架构的信息。管理员、开发人员、执行人员可以用ODI不同的操作界面来访问资料库。安全界面和拓扑管理器界面用于管理架构，设计器用来做元数据反向或者反向工程以及项目开发、接口等，操作器用来调度和执行实时操作。ODI分为设计阶段和执行阶段。在设计阶段，开发者定义元数据、业务规则、约束。这个处理作业由Agent在现有信息系统中完成。它连接到可用的服务器，并利用服务器执行代码。它存储所有返回的代码和消息到资料库中。它也存储一些统计信息，像处理记录的条数、处理时间等信息。不同的资料库是可以同时存在在同一个IT架构中。设计阶段的资料库和执行阶段的资料库是可以同时存在的。开发人员在designer中通过把项目发布成情景传输给生产环境。在生产环境，这些情景被作业调度，被调度代理执行，调度代理存储了所有资料库的信息。Operator操作器是始终可以实时访问和监控数据整合的过程。业务用户也可以像开发人员、管理员和操作员一样，通过Web方式访问ODI的资料库。ODI有一个元数据导航功能，它是一个J2EE的应用服务器，可以直接连接ODI资料库。关于ODIagent的配置部署odi2009-06-1112:25阅读56评论0字号：大中小最近，做了几个ODI项目的部署，发现ODIagent所在的位置对整个E-LT工作的影响还是比较大的，根据Oracle的官方说法，agent一般需要部署在目标端的数据库服务器上，或者repository数据库服务器上（如果repository直接采用目标服务器就更简单了），但在实际的使用中，建议尽量还是将agent部署在目标端所在的服务器上。一、agent的分类在ODI中，有三类agent，一是/bin目录下直接运行agent.sh或agent.bat,该类agent只能被动调用。二是/bin目录下的agentscheduler.sh/agentscheduler.bat,从名字可以看出，它可以自动执行计划好的工作，第三类是designer.bat设计界面，该界面在调试时可以自己作为一个agent来运行。其中第一类和第三类agent不需要修改任何东西。第一类直接运行agent.sh/agent.bat就可以了，第三类什么都不用起，只是在测试interface或者package时才会用到。二、agent不同部署方式带来的区别如上图所示，如果agent部署在repository（以下简称元数据服务器）上，而元数据服务器又和目标数据库不在一个服务器上，那么命令的流向（途中红色线）为：agent首先登录到源数据库，抽取数据，取到元数据库所在的服务器，然后agent再登录到目标服务器，将数据加载到目标数据库。数据的流向为：源数据库到元数据服务器到目标数据库。如果我们将agent部署在目标服务器，如下图所示，此时，数据流会从源直接流向目标，agent在目标端可以利用目标端数据库的内置客户端工具直接将数据加载到数据库，从而避开JDBC调用。Agent说白了就是一个java小程序，既可以通过jdbcdriver作为源和目标数据库的客户端登录到数据库服务器操作，也可以调用本地操作系统的命令，因此odi在数据的E-LT过程中，最简单但效率最低的方法是完全采用JDBC方式抽取、加载数据。最快的方式是采用数据库的内置客户端命令抽取加载数据，如DB2的load，sqlserver的bcp，oracle的sqlloader。当然要调用数据库客户端，agent所在的机器必须有相应数据库的客户端软件。下面是几个agent部署的例子：1.AS400上文件加载到DB2:具体解释请参见上面的英文，这是在oracleopenworld的pdf里面截出来的。2.远程文件入库：此时agent应该安装在文件所在的服务器，而且该机器需要安装目标端数据库的客户端。3.远程同构数据库，该方式下，数据一般是在数据库内部流动，如oracle的dblink，sqlserver的linkedserver，sybase的CIS,agent的位置无所谓，但仍建议在目标端。4.远程异构数据库集成，此时agent的配置是比较讲究的，如果数据的抽取和加载都采用数据库的内置客户端，那么如果agent在源数据库端，则源数据库端需要安装目标数据库的客户端，反之亦然。当然ODI内置了一个基于JDBC数据库抽取工具sqlunload，如果目标端是生产系统，客户不允许部署任何东西，建议采用该工具，效率还是不错的。三、如何安装agentODI的agent安装比较简单：1.将安装ODI机器设计界面的服务器上ODI目录下/bin,/drivers和/lib目录直接拷贝到目标或者源服务器上。2.在服务器上如果没有jdk1.5或以上，建议安装jdk1.5或以上。3.指定ODI_JAVA_HOME环境变量，或者修改odiparams.bat/odiparams.sh到JDK的安装目录。4.如果不需要schedule的工作，直接执行/bin目录下的agent.sh/agent.bat即可，该程序默认端口为20910，如果需要指定别的端口，则运行agent.bat–name=agent_nam-port=port5.如果需要运行schedule的工作，则首先需要修改odiparams.bat/odiparams.sh文件，把其中连接masterrepository的一段修改成您自己的driver和url，如下所示：JDBCdrivertoaccesstheMasterRepository:setODI_SECU_DRIVER=oracle.jdbc.driver.OracleDriverJDBCURLtoaccesstheMasterRepository:setODI_SECU_URL=jdbc:oracle:thin:@1.128.5.52:1521:ORADBDatabaseUsernametoaccesstheMasterRepository:setODI_SECU_USER=odi1013mDatabasePasswordtoaccesstheMasterRepository:setODI_SECU_ENCODED_PASS=b9yHYSNunqZvoreC6aoF0VhefNameoftheWorkRepository:setODI_SECU_WORK_REP=WORKREP1ODIUsernamef