文章
数据仓储
| |||
|
从 Oracle Warehouse Builder 迁移至 Oracle Data Integrator 12c
作者：Stewart Bryson
分阶段迁移到 Oracle Data Integrator 12c 的详细指南
2014 年 1 月
简介
自从 2000 年 2.0.4 版发布以来，Oracle 客户一直使用 Oracle Warehouse Builder (OWB) 部署解决方案。由于它与 Oracle Database 紧密集成并依赖 Oracle PL/SQL 作为部署机制，因而成为倾向采用后端解决方案而不是更异构工具解决方案的数据仓库和 BI 店的热门选择。
Oracle Data Integrator (ODI) 发布 12c 版本后，现在对面向数据库和面向工具的群体都具有很大的吸引力。ODI 12c 这个新版本令人瞩目，除了数据集成功能有重大改进，还针对打算切换到 ODI 的 OWB 客户增添了一些功能。首先，有一个被称作“OWB 运行时集成”的新特性，允许 ODI 代理编排和执行 OWB 流程。此外，还新增了一个 OWB 到 ODI 迁移实用程序，可以将 OWB 开发构件子集转换成对应的 ODI 构件。
在本文中，我们将介绍这两种从 OWB 迁移到 ODI 12c 的方法：集成和迁移。首先将介绍一个相当标准的 ODI 安装，其中包括 JEE 代理配置。最后介绍分阶段迁移，它同时利用了 ODI 12c 中的集成和迁移功能。
ODI 安装
我们的环境为 Oracle Linux 6.4，通过 Red Hat Kernel 而不是 Unbreakable Linux Kernel 进行安装。因为环境中还安装了 Oracle Database，所以额外包括几个特定于该安装的包，但这些包不是 ODI 所必需的。安装和运行 ODI 12c 所需的第一个组件是 Java Development Kit (JDK)。ODI 12c 只支持 JDK 版本 7，因此我安装了 JDK 1.7.0_21（可从 http://java.oracle.com 下载）。我们的 Linux 环境有几个不同的 Java 安装，因此我们在 .bash_profile 中添加以下内容以确保始终使用 Oracle JDK：
export JAVA_HOME=/usr/java/jdk1.7.0_21
ODI Universal Installer
确保已成功设置 JAVA_HOME，执行以下 jar 可执行文件启动 Universal Installer for ODI：
==> java -jar odi_121200.jar
下面列出 ODI 安装中几个值得注意的步骤：
第 1 步：Welcome
在欢迎屏幕上，我们看到以下消息：
“If you plan to install the JEE Agent, then ensure that you have installed Oracle Fusion Middleware Infrastructure 12c.”
忽略此消息；ODI 企业安装将在后台安装 WebLogic Server (WLS) 和融合中间件 (FMW) 基础架构库。
第 2 步：Installation Location
选择 /app/oracle/product/odi_1 作为 ODI ORACLE_HOME 的位置。
第 3 步：Installation Type
我们需要在新的 ODI 12c 企业安装中运行 JEE 代理或独立的共存代理。值得注意的是，单纯的独立代理（根本不需要 WLS）仍然受支持，可以使用 Standalone Installation 选项安装。JEE 代理是事实上的生产环境标准配置，因为它们提供 WLS 所提供的所有故障切换和可扩展性；实在没有理由不使用 JEE 代理。因此，我们选择 Enterprise Installation 选项，但在安装完成后将研究如何配置 JEE 代理。如前所述，WLS 12.1.2 和 FMW Infrastructure 库 12.1.2 也是安装的一部分，如图 1 中的 Internal Features 所示。安装过程中的其余屏幕只显示信息，不需要输入。
补丁
Universal Installer 在 ODI 12c 安装过程中还创建一个名为 odi_1212_opatch.zip 的 zip 存档，解压缩后包括三个补丁：16926420、17053768 和 17170540。我们需要解压缩这个文件，导航到每个补丁的目录，然后应用补丁。下面演示如何应用补丁 17170540：
==> cd 17170540/ ==> $ORACLE_HOME/OPatch/opatch apply Oracle Interim Patch Installer version 13.1.0.0.0 Copyright (c) 2013, Oracle Corporation. All rights reserved. Oracle Home : /app/oracle/product/odi_1 Central Inventory : /app/oraInventory from : /app/oracle/product/odi_1/oraInst.loc OPatch version : 13.1.0.0.0 OUI version : 13.1.0.0.0 Log file location : /app/oracle/product/odi_1/cfgtoollogs/opatch/17170540_Jan_02_2014_15_48_01/ apply2014-01-02_15-47-56PM_1.log OPatch detects the Middleware Home as "/app/oracle/product/odi_1" Applying interim patch '17170540' to OH '/app/oracle/product/odi_1' Verifying environment and performing prerequisite checks... All checks passed. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/app/oracle/product/odi_1') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files... Patching component oracle.as.common.clone, 12.1.2.0.0... Verifying the update... Patch 17170540 successfully applied Log file location: /app/oracle/product/odi_1/cfgtoollogs/opatch/17170540_Jan_02_2014_15_48_01/ apply2014-01-02_15-47-56PM_1.log OPatch succeeded. ==>
Repository Creation Utility
Oracle Business Intelligence 企业版 (OBIEE) 和其他一些 FMW 产品安装软件之前需要运行 Repository Creation Utility (RCU)，而 ODI 实际上将 RCU 作为基本产品安装的一部分进行安装。RCU 可执行文件位于 $ORACLE_HOME/oracle_common/bin 中，启动方法如下所示，稍后将介绍其中一些值得注意的的步骤。
==> $ORACLE_HOME/oracle_common/bin/rcu
第 1 步：Create Repository
我们当然需要创建新的信息库，因此首先选中主选项 Create Repository。我们需要在此步骤中创建数据库对象（而不是生成稍后运行的脚本），因此选择第二个选项 System Load and Product Load。
第 2 步：Select Components
与 FMW RCU 中的标准做法一样，我们选择一个模式前缀将我们的特定 FMW 模式与同一数据库中可能存在的其他模式区分开。我选择默认值 DEV，然后选择 Oracle Data Integrator 组件下的 Master and Work Repository 子组件。这将自动预先选择支持 ODI 所需的所有选项，如图 2 所示。
第 3 步：Custom Variables
我们为 ODI 中的内置管理员帐户 SUPERVISOR 提供密码。我们还需要将 Work Repository Type 指定为默认值 (D) Development，将 Work Repository Name 设置为默认值 WORKREP。
第 4 步：Map Tablespaces
在此步骤中，我们为 RCU 创建的每个模式定义默认表空间和临时表空间。由于没必要每个模式都拥有单独的表空间，我创建一个用于所有 FMW 模式的表空间 REPO（信息库），还创建默认临时表空间 TEMP，如图 3 所示。
JEE 代理配置
域配置
安装了 ODI 并创建了数据库信息库之后，该配置 JEE 代理了，首先需要配置一个 FMW 域。配置脚本位于 $ORACLE_HOME/oracle_common/common/bin 中，其执行过程如下所示，稍后将介绍其中一些值得注意的步骤。
==> $ORACLE_HOME/oracle_common/common/bin/config.sh
第 1 页：Create Domain
我们将新域命名为 odi_domain，并在默认位置 $ORACLE_HOME/user_projects/domains 中创建。我们向 universal installer 提供的完整路径值为：/app/oracle/product/odi_1/user_projects/domains/odi_domain。
第 2 页：Templates
为了便于针对不同 FMW 产品部署标准功能，配置实用程序包含用于在域中配置和部署不同应用程序的模板。我们选择的第一个模板是 Oracle Enterprise Manager Plugin for ODI - 12.1.2.0 [em]，这将自动选择以下模板：
- Oracle Enterprise Manager - 12.1.2.0 [em]
- Oracle JRF - 12.1.2.0 [oracle_common]
- WebLogic Coherence Cluster Extension - 12.1.2.0 [wlserver]
接着，我们选择名为 Oracle Data Integrator - Agent - 12.1.2.0 [odi] 的模板，这将自动选择以下模板：
- Oracle Data Integrator - Agent Libraries - 12.1.2.0 [odi]
- Oracle Data Integrator SDK Shared Library Template - 12.1.2.0 [odi]
尽管我们在本文中要配置 JEE 代理，但还是包括了模板 Oracle Data Integrator - Standalone Collocated Agent - 12.1.2.0 [odi]，这样还可以选择部署独立的共存代理。我们还包括 Oracle Data Integrator - Console - 12.1.2.0 [odi]。
第 3 页：Application Location
Configuration Utility 将根据第 1 页上为 Domain 位置选择的选项建议默认的 Application 位置（.ear 文件的位置）。接受默认值即可。
第 5 页：Domain Mode and JDK
我们需要 boot.properties 文件，因此将创建一个 Development 域。但 boot.properties 文件非常容易创建，因此 Production 域也是一个明智的选择。
注意，Configuration Utility 将根据 JAVA_HOME 环境变量的值获知 JDK 的位置。这正是我们要使用的 JDK。
第 6 页：Database Configuration Type
我们选择 RCU Data 选项，这样可以使用 Service Table 模式（本例中即 DEV_STB）自动配置特定模板所需的数据源。实在没有理由不采用此选项。
第 9 页：Credentials
我们使用此屏幕配置 FMW 凭证库中的两个条目。第一个密钥已部分填充：SUPERVISOR 密钥用于 SUPERVISOR 用户名和密码。第二个密钥要通过单击 Add 按钮添加，然后指定域名以及该域的管理用户名和密码，如图 4 所示。
第 10 页：Advanced Configuration
在此屏幕中，我们选择以下选项：Administration Server、Node Manager and Managed Servers、Clusters and Coherence。其他选项不是必需的。
第 11 页：Administration Server
JEE 代理部署需要一个管理服务器。除需要提供特定监听地址之外，其余各项保留默认值。我们可以使用主机名或 IP；选择主机名 oracle.localdomain。
第 13 页：Managed Servers
JEE 代理还需要受管服务器为代理提供 JEE 容器。这部分全部保留默认值，按图 5 所示指定以下值。
| Server Name： | ODI_server1 |
| Listen Address： | oracle.localdomain（IP 地址或主机名） |
| Listen Port： | 15101（默认受管服务器端口） |
| Enable SSL： | 未选中 |
| SSL Listen Port： | Disabled |
| Server Groups： | JRF-MAN-SVR |
第 14 页：Clusters
为我们的 FMW 集群选择一个唯一名称，本例中使用 ODI_cluster1。Cluster Address 属性保留为空。
第 15 页：Assign Servers to Clusters
将 ODI_server1 分配到 ODI_cluster1。
第 16 页：Coherence Clusters
默认值 defaultCoherenceCluster 和 0 保留不变。
第 17 页：Machines
我们需要配置 FMW 机器。由于环境为 Linux，因此在 Unix Machine 选项卡中选择以下选项：
| Name： | oracle（集群中的任何名称都是唯一的） |
| Enable Post Bind GID： | 未选中 |
| Post Bind GID： | nobody |
| Enable Post Bind UID： | 未选中 |
| Post Bind UID： | nobody |
| Node Manager Listen Address： | oracle.localdomain（IP 地址或主机名） |
| Node Manager Listen Port： | 5556（默认的 Node Manager 端口） |
第 18 页：Assign Servers to Machines
我们将 AdminServer 和 ODI_server1 移至 Oracle Unix Machine 下。
其余屏幕只是显示信息，一路单击，即可完成域配置并将应用程序部署到受管服务器，我们可将其用于 JEE 代理。为方便将来操作，向 .bash_profile file 添加 DOMAIN_HOME 环境变量，如下所示：
export DOMAIN_HOME=$ORACLE_HOME/user_projects/domains/odi_domain
创建代理拓扑
我们现在准备在 ODI Studio 中配置 JEE 代理以使用新部署的 FMW 应用程序。使用以下命令行调用打开 ODI Studio：
==> $ORACLE_HOME/odi/studio/odi.sh
使用 ODI Topology Navigator，在 Physical Architecture 下右键单击 Agents，然后选择 New Agent。指定以下参数值，如图 6 所示。
| Name： | OracleDIAgent |
| Host： | oracle.localdomain（IP 地址或主机名） |
| Port： | 15101（默认受管服务器端口） |
作为以上域配置的一部分，Node Manager 可能已经在运行。如果未运行，为便于日后参考，可使用以下命令启动 Node Manager：
==> nohup $DOMAIN_HOME/bin/startNodeManager.sh > nm.out& [1] 31642
一旦确定 Node Manager 正在运行，可使用以下命令启动管理服务器：
==> nohup $DOMAIN_HOME/bin/startWebLogic.sh > admin.out& [2] 32359
管理服务器处于 RUNNING 模式，现在可以启动受管服务器。可以通过类似启动 Node Manager 和管理服务器的方式从命令行执行，也可以使用 Fusion Middleware Control (FMC) 用以下 URL 模式完成此操作：
http://administration_server_host:administration_server_port/em
对于本环境，这相当于：
http://oracle.localdomain:7001/em
为了进行演示，我们使用 FMC。在 WebLogic Domain 树下，依次选择 odi_domain、ODI_cluster1 和 ODI_server1。在结果页中，可以单击 Start Up 按钮：
一旦成功运行受管服务器，JEE 代理现在应该可用了。返回 ODI Studio 中的 Topology Navigator，右键单击 Physical Architecture 窗格中的 OracleDIAgent 并选择选项 Test，它应给出代理可用的反馈。最后一项任务只需在 Logical Architecture 窗格中创建一个代理，通过上下文映射到物理代理；本例中，使用 Global Context。
OWB 运行时集成
ODI 12c 已安装且可运行，JEE 代理配置正确，现在可以研究与 OWB 的第一个集成点：运行时集成。将现有 OWB 工作区配置成 ODI Topology 中的一个元素，并让 ODI 使用 ODI 包执行 OWB 流程，即可实现。讨论技术细节之前，先从高级层面看看现有 OWB 项目，看看如何将其并入 ODI。
销售主题区域
我们要加载一个比较标准的数据仓库来存储销售数据，包括一个名为 SALES_FACT 的事实表和一系列维度表：STAFF_DIM、STORE_DIM、PRODUCT_DIM 和 CUSTOMER_DIM。每个表都加载了映射，且使用流程构建了加载的编排。其中有一个名为 COMMON_WF 的流程模块，它包含一个名为 SBATCH 的流程包，根据我们的命名标准，代表“标准批处理”。此流程包中有三个单独的流程：LOAD_DIMS、LOAD_FACTS 和 MAIN_LOAD，如图 8-10 所示。MAIN_LOAD 只是一个顺序执行维度加载和事实加载的高级流程。
常见的设计方法是将元素分成 OWB 中独立的流程：这样可以灵活编排整体批量加载，并且允许执行整个批量加载的细粒度片段以进行单元测试。
运行时拓扑
我们现在需要配置与现有 OWB 工作区的集成。与 ODI Topology 中的任何其他元素一样，我们首先在 Topology Navigator 的 Physical Architecture 窗格中添加一个数据服务器。ODI 12c 提供了一种名为 OWB 运行时信息库的新技术。右键单击该技术并选择 New Data Server，这将打开 Data Server Definition 选项卡，如图 11 所示。我们提供数据库服务器名称，并在 Connection 下提供 OWB 工作区所有者的用户名和密码。根据数据服务器所驻留的 Oracle 数据库实例将其命名为 ORCL（任何唯一名称均可），并提供工作区所有者名称 OWBREP 及相关密码。
在 JDBC 选项卡中，我们使用 oracle.jdbc.OracleDriver 驱动程序并提供容纳 OWB 工作区的 Oracle 数据库的连接详细信息。单击 Save 按钮，然后在 Physical Architecture 窗格中右键单击新的数据服务器并选择 New Physical Schema，这将打开 Definition 选项卡。从下拉列表中选择正确的 Workspace (Schema) 值（本例中为 OWBREP.OWBREP），然后其余部分接受默认值，如图 12 所示。
创建数据服务器和物理模式之后，需要创建一个逻辑模式并通过上下文为其分配物理模式。在 Topology Navigator 中选择 Logical Architecture 窗格，再次右键单击 OWB Runtime Repository Technology，选择 New Logical Schema，这将打开 Definition 选项卡。我们只使用 Global Context，因此将新逻辑模式（本例中名为 OWBREP）映射到先前创建的物理模式，即完成拓扑配置。
包工具：OdiStartOwbJob
配置好拓扑之后，现在可以使用 ODI 包执行任何 OWB 流程，包括 OWB 映射或流程：任何可以由 OWB Control Center 执行的内容均可。由于整个加载过程已使用 OWB 流程进行编排，因此最简单的办法是配置一个只执行 MAIN_LOAD 流程的包。在 ODI Designer 中，右键单击 Packages 并选择 New Package。在 Package Editor 中，有一个名为 OdiStartOwbJob 的新 Tool 选项，将其作为 Package Step 添加到 Package Editor 面板。然后用以下信息配置 Package Step General 选项卡，如图 13 所示。
| Workspace Name： | OWBREP |
| Location Name： | OWF_MGR（流程位置的 Oracle 工作流所有者） |
| Object Name： | SBATCH/MAIN_LOAD |
| Object Type： | ProcessFlow |
单击 Package Step 中的 Command 选项卡，查看前面提供的值生成的 ODI Tool 命令：
OdiStartOwbJob "-WORKSPACE=OWBREP" "-LOCATION=OWF_MGR" "-OBJECT_NAME=SBATCH/MAIN_LOAD" "-OBJECT_TYPE=PROCESSFLOW"
完成包之后，就可以轻松创建一个 ODI 方案并使用 JEE 代理执行。在图 14 中可以看到，ODI 和 OWB 审计现在已经完全集成，ODI 知道 OWB Control Center 执行的所有流程和子流程以及执行结果，包括执行时间和影响的记录数。
并行方法
此功能的价值很容易理解：OWB 中原有的 ETL 流程可与新的 ODI 流程一起管理和集成，二者在一致的数据集成策略下协同工作。我们称之为并行方法：将原有的 OWB 流程作为整体 Oracle 数据集成解决方案的一个集成元素继续运行。仅当 OWB 流程是真正的原有流程时，并行方法才真正起效：可以将其留在 OWB 中（因为没办法，它们就是有效）并接受这一事实。业务并未规划任何必须“接触”任何这些流程的增强功能，因为利益相关方提供了新的业务智能计划，可以完全在 ODI 中开发。这样，OWB 代码就与几乎任何其他原有代码（无论是 PL/SQL、Perl 还是其他）一样，只不过是 Oracle 出品了全面的集成平台。但如果 OWB 代码不是纯粹的原有代码怎么办？如果围绕此代码的开发蓬勃发展怎么办？这正是 OWB 到 ODI 迁移实用程序的用武之地。
OWB 到 ODI 迁移实用程序
补丁应用
为了支持新的迁移实用程序，我们需要再安装几个补丁，仍然采用上面的 opatch 方法。第一个是补丁 17053768，应用到 ODI ORACLE_HOME；第二个是补丁 17830453，需要为 OWB 安装。OWB 补丁要么应用于与 Oracle 数据库关联的 ORACLE_HOME，要么应用于独立的 OWB ORACLE_HOME（如果适用），且只在 OWB 版本 11.2.0.4 上有效。下面演示如何应用 OWB 补丁：
==> cd 17547241/ ==> opatch apply Oracle Interim Patch Installer version 11.2.0.3.4 Copyright (c) 2012, Oracle Corporation. All rights reserved. Oracle Home : /app/oracle/product/11.2.0/dbhome_1 Central Inventory : /app/oraInventory from : /app/oracle/product/11.2.0/dbhome_1/oraInst.loc OPatch version : 11.2.0.3.4 OUI version : 11.2.0.4.0 Log file location : /app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/ 17547241_Dec_25_2013_13_30_17/apply2013-12-25_13-30-17PM_1.log Applying interim patch '17547241' to OH '/app/oracle/product/11.2.0/dbhome_1' Verifying environment and performing prerequisite checks... All checks passed. Backing up files... Apply mode Patching component oracle.owb.rsf, 11.2.0.4.0... Verifying the update... Apply mode Patch 17547241 successfully applied Log file location: /app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/ 17547241_Dec_25_2013_13_30_17/apply2013-12-25_13-30-17PM_1.log OPatch succeeded. ==>
由于我们使用的是 Linux 环境，补丁 17547241 在 OWB ORACLE_HOME 中安装了一个名为 migration.sh 的新命令行实用程序。准确位置为 $OWB_HOME/bin/unix，本环境下的准确位置如下所示：
/app/oracle/product/11.2.0/dbhome_1/owb/bin/unix
执行迁移
此命令行实用程序结合使用命令行选项与配置文件，指定要迁移的对象以及与这些对象关联的特定配置选项。并不是什么都迁移。以下文档中指定了完整列表：http://docs.oracle.com/middleware/1212/odi/ODIMG/understanding.htm#CHDCIDDG。一些并不迁移但值得注意的项包括：
- 维度建模元数据以及使用该元数据的任何映射，包括维度和多维数据集
- 流程
- 配置
- 数据质量、数据配置文件和数据审计
应特别注意此列表中的第三项（流程）。如果选择将整个项目迁移到 ODI，迁移完成时将只有映射及相关联的元数据。因此值得注意的是，我们需要使用 ODI 包和/或加载计划在迁移后开发新的编排策略。许多情况下，这项工作并不轻松。本文稍后将研究一些与此相关的策略。
迁移实用程序有三种运行模式：
- FAST_CHECK：对 OWB 信息库执行只读检查，报告可以迁移和不能迁移的项。
- DRY_RUN：使用 ODI 12c SDK 执行到 ODI 的迁移，但在过程结尾时不执行提交。
- RUN（默认）：执行迁移并将迁移的对象提交到目标 ODI 12c 信息库。
运行模式是在迁移配置参数中指定的。由于文件位置是在执行实用程序时指定的，因此配置参数的名称随意且可放在任何位置。迁移实用程序补丁安装还在 $OWB_HOME/bin/admin 目录下创建一个名为 migration.config 的示例配置文件。下面列出配置文件中的一些特定驱动程序属性：
ODI_MASTER_USER=DEV_ODI_REPO ODI_MASTER_URL=jdbc:oracle:thin:@oracle.localdomain:1521:orcl ODI_MASTER_DRIVER=oracle.jdbc.OracleDriver ODI_USERNAME=SUPERVISOR ODI_WORK_REPOSITORY_NAME=WORKREP OWB_WORKSPACE_OWNER=OWBREP OWB_URL=oracle.localdomain:1521:orcl OWB_WORKSPACE_NAME=OWBREP MIGRATION_LOG_FILE=/app/oracle/product/11.2.0/dbhome_1/owb/bin/unix/migration.log MIGRATION_MODE=RUN MIGRATE_DEPENDENCIES=true MIGRATION_OBJECTS=PROJECT.GCBC_SALES.MODULE.ETL;
请注意最后两个迁移属性：MIGRATE_DEPENDENCIES 和 MIGRATION_OBJECTS。可以使用这两个参数指定要迁移的内容。MIGRATION_OBJECTS 使用点表示法指定要迁移的 OWB 项目，更细致地，还可以指定要迁移的单个对象或块对象。在以下文档中可以看到支持的参数：http://docs.oracle.com/middleware/1212/odi/ODIMG/migrating.htm#CHDIDBDH。
我们要迁移名为 ETL 的 OWB 模块。在我们的工作区中，这个模块中包含了整个项目的 OWB 映射，因此全部都要迁移。但 MIGRATE_DEPENDENCIES 的指定值将指示该实用程序还要迁移相关对象，如表元数据、序列元数据、位置等。
.迁移实用程序还要接受几个命令行选项（主要是密码，因此它们并不显式写在配置文件中）以及配置文件路径。下面指定命令行选项和顺序：
- ODI 主信息库密码：配置文件中指定的 ODI_MASTER_USER 的密码
- ODI 用户密码：配置文件中指定的 ODI_USERNAME 的密码
- OWB 工作区密码：配置文件中指定的 OWB_WORKSPACE_OWNER 的密码
- 迁移配置文件：上面创建的配置文件的路径。
我们在命令行输入以下命令来执行迁移实用程序：
==> ./migration.sh welcome1 welcome1 welcome1 gcbc_sales.config
使用参数 MIGRATION_LOG_FILE 指定迁移日志文件的位置时，这还将指定迁移报告文件的名称和位置（根据配置文件，名称将为 migration.report）。报告顶部显示迁移实用程序的聚合结果，迁移的特定对象则列在报告中更下面的位置（为简洁起见，此处省略）：
Statistics
------------
Total Projects Migrated: 2
********************************************************************************
PROJECT: PUBLIC_PROJECT
Object Types Migrated Not-Migrated
--------------- --------- -------------
LOCATION: 1 0
********************************************************************************
PROJECT: GCBC_SALES
Object Types Migrated Not-Migrated
--------------- --------- -------------
SEQUENCE: 4 0
TABLE: 17 0
MAPPING_MODULE: 4 0
MODULE: 4 0
MAPPING: 5 0
此处项目较小，但 ETL 模块中的所有映射均已成功迁移。表和序列的工作区元数据也被迁移，成为 ODI Designer 中的模型内容。
ODI Topology
通过查看 ODI Topology 及迁移的 OWB 位置和模块，我们现在可以看到迁移过程的结果，如图 15 所示。为 OWB 映射中表示的所有模块都创建了 ODI 数据服务器、物理模式和逻辑模式：GCBC_CRM、GCBC_EDW、GCBC_POS 和 GCBC_STAGING。
需要注意一点：尽管许多 OWB 位于同一物理 Oracle 数据库中，迁移实用程序还是为每个 OWB 位置创建单独的 ODI 数据服务器。虽然这一开始似乎有些麻烦，但是很容易借助 ODI Topology 来纠正这种情况。如果需要，可以使用多个物理模式创建新的数据服务器，然后重新映射到逻辑模式，ODI 获悉了这些模式位于同一个数据库中，就可以生成更高效的代码。类似用例是 ODI Topology 抽象物理模式和逻辑模式的主要原因，因此我们不应太在意迁移实用程序采用这种处理方式。
保持迁移实用程序创建的物理架构，但需要一些小改动。迁移实用程序并未从 OWB 位置取来密码，因此需要在数据服务器配置的 Connection 部分提供这些密码，如图 16 所示。还必须为映射涉及的所有物理模式设置工作模式，如图 17 所示。
研究单个映射：MAP_SALES_FACT
我们来看一个 OWB 映射，详细了解迁移实用程序在另一端给出什么结果。在图 18 中，可以看见一个源 OWB 映射 MAP_SALES_FACT。
此映射从 GCBC_POS 模式中的两个表中提取数据，这两个表使用联接器组件联接在一起。然后将结果数据与 GCBC_EDW 模式（报告目标模式）中的维度表一起映射到另一联接器，以便在最终将数据加载到 SALES_FACT 表之前查询代理键。所有维度表通过一个名为 SURROGATE_PIPELINE 的联接器联接到源数据集。映射中还有两个单独的表达式组件：一个就叫 EXPRESSION，另一个名为 GET_DATE_KEY。还有映射前流程和映射后流程组件，这在 OWB 映射中很常见。如果没有 ODI 中的知识模块 (KM) 架构功能，OWB 开发人员往往只能用这些映射内组件向其 OWB 映射添加自定义的可重复流程。图 19 显示了迁移的 ODI 映射 MAP_SALES_FACT，下一节将对此进行讨论。
组件和组件式 KM
迁移实用程序现在得以存在的原因之一是更易于在 ODI 12c 中构建。这两个工具都使用基于流程的设计，利用面板上组件进行构建。ODI 中有许多与 OWB 中相同或类似的组件。ODI 中的组件较少，如图 20 所示。因为 ODI 架构中的其他元素（包括拓扑和 KM 框架）减少了所需单个组件的数量，所以只用较少数量的组件即可完成开发。
观察图 19 中的迁移映射，注意 OWB 中的 SURROGATE_PIPELINE 联接器，它将所有维度表联接到源数据，被转换为 ODI 中四个不同的 Join 组件。ODI join 组件支持有两个以上的传入连接，但迁移实用程序不会照此方式生成设计器元数据。不必过于在意：ODI 12c 中新的组件式 KM 使用四个不同的 join 组件生成与 OWB 相当的代码，几乎与使用单个 join 组件时 ODI 生成的代码相同。
表达式是 ODI 12c 的一个新特性，保留了与 OWB 中表达式类似的功能。严格声明式设计范例使用 ODI 11g 中的接口，没地方容纳组件，更不用说表达式组件了。但 ODI 12c 混合了声明式设计和基于流程的设计。目标组件中的每个属性都使用内置的位置配置声明式转换逻辑，但是可以使用表达式组件显式呈现转换逻辑且使其可重用，还可帮助迁移实用程序转换 OWB 映射。
在 ODI 中，KM 是使用 ODI Substitution API 控制针对源和目标生成的代码的可插拔模板。组件式 KM 是新的免费代码生成工具，封装了特定组件特定的模块化、可重用逻辑片段。这样可以仅在需要的地方使用基于模板的 KM：而不是像 ODI 11g 中那样针对整个映射。为了查看或修改映射中特定目标的加载 KM (LKM) 的分配，我们切换到物理视图，单击该目标的访问点。这是从源延伸到目标的箭头的“接触点”。对于 MAP_SALES_FACT，访问点为 GET_EFFECTIVE_DATE 表达式，如图 21 所示。
迁移实用程序为所有转换的映射选择了一个组件式 LKM：LKM Oracle to Oracle Pull (DB Link)。这个新的 KM 是一个明智的选择，因为 OWB 总是使用一个数据库链接从远程服务器提取数据。我们对迁移的映射略作修改，即将数据库链接硬编码成 KM 中的 SOURCE_ACCESS_DB_LINK 选项，这样就无需在每次运行时重复地删除和创建数据库链接，如图 21 所示。
如果不喜欢数据库链接方法（虽然我不确定可能的原因），可以将一个与其他 ETL 工具中常见的加载技术（源和目标数据库使用单独连接）类似的 KM 与基于阵列的处理结合使用。图 22 显示选择了 LKM SQL to SQL (Built-In)。切记，数据库链接的性能通常由于基于阵列的处理，与其他 ETL 工具相比，这是部署 ODI 时的一个重要增值点。
乍一看，似乎映射前和映射后流程组件在迁移中丢失。它们在逻辑映射面板上当然不可见，也不是图 20 所示组件列表中的选项。进一步调查显示不应该在逻辑映射视图上找。而是应该再看看物理映射视图以及新的组件式 KM 中可用的某些选项。为了查看映射后流程，我们单击目标表 SALES_FACT，导航到 Properties 窗格中的 Extract Options 部分，查看 BEGIN_MAPPING_SQL 选项：
下面列出 OWB 映射后流程中的原始 PL/SQL 调用：
BEGIN
"TRANS_ETL"."END_MAPPING"(REPLACE(GET_MODEL_NAME, '"', NULL) , );
END
此 PL/SQL 过程对表执行几个自定义加载后选项，并使用单个映射名称从配置表提取选项以决定运行哪些流程。有了 ODI 的自定义能力，我们不可能选择用这种方式编码加载后选项，但此类更改不可能一蹴而就，因此能够从一开始就以类似方式执行 PL/SQL 过程非常重要。OWB 映射中的 GET_MODEL_NAME 常量（上面进行了演示）总是返回带有双引号的映射名称，因此可以用来消除硬编码值。在 ODI 中需要一个等同物，使用 Substitution API 就可以办到。下面列出修改后的调用：
BEGIN
TRANS_ETL.END_MAPPING('<%=odiRef.getPop("POP_NAME")%>');
END
找到映射前流程稍难一些，表面上看很随意。尽管目标端联接了多个维度表，但自定义 PL/SQL 调用放在 CUSTOMER_DIM 表的 Extract Options 中，我们只能假定是按字母数字顺序选择的。不管怎样，对 PL/SQL 调用进行类似修改给出了我们想要的结果。进行小的调整后，图 24 显示从 ODI Operator 执行映射的结果。
迁移方法
大爆发式方法：一次性
迁移实用程序是一项引人注目的功能。尽管需要在迁移后对映射稍作改进，但所有复杂的源到目标逻辑保持不变，归根结底，这才是我们最关心的。迁移实用程序大大加快了工作进度，但它并不是一个完整的迁移解决方案。老实说，提供一个完整的、从头到尾的迁移实用程序所需的代码行的数量，想想就令人生畏。
考虑迁移实用程序不支持的 OWB 内容名单，最值得注意的就是流程。尽管 Oracle 正确地选择首先专注于映射，我们还是需要使用某些加载计划和包的组合重新编排加载流程。根据 OWB 中当前数据集成流程的范围和复杂性，这一过程可能包括从不舒服到难以忍受的各种感受，尤其是在考虑数据验证驱动的正式 QA 和回归测试过程时。
考虑基于 OWB 的完整迁移所需的项目，下面列出了完成此类迁移的必需步骤和可选步骤：
必需的迁移步骤
- 配置和执行迁移实用程序。
- 建立拓扑并更改数据服务器和物理模式。
- 针对相应的数据库链接、映射前和映射后流程等调整每个映射中的组件式 KM 参数。
- 设计一个编排流程，使用包和加载计划替换流程。
- 单元测试选择代表特定设计模式的映射，确保成功完成。
- 回归测试完成加载过程，包括数据协调，确保 ODI 产生与 OWB 完全相同的结果。
可选的迁移步骤
- 用更强健的基于 ODI 的功能代替自定义的 PL/SQL 流程，包括自定义 KM、ODI 包和过程，以及加载计划功能。
- 用 Groovy 脚本代替开发过程中包含的任何自定义 TCL 流程（自动生成某些类型的映射或流程）。
对于某些 OWB 实现，可能最好冒险尝试进行一次性投资，执行所有必需的步骤，可能还要执行一些可选步骤。销售和支持完整数据仓库解决方案的组织可能会考虑推出该解决方案的一个新版本，只能在 ODI 上运行。这种迁移的一个示例是 Oracle 的商务智能应用产品 (OBIA)，虽然该迁移不是从 OWB 而是从 Informatica 迁移。部分加载例程采用 Informatica，其他部分加载例程采用 ODI，不适合试图最大程度获得企业软件采购投资回报 (ROI) 的客户。
类似地，利用商务智能能力中心 (BICC) 的组织认识到标准化和减少空间占用的巨大价值。引入某种混合解决方案，解决方案的原有部分仍运行在 OWB 上，新增部分则用 ODI 实现，这样可能因为增加支持和维护成本而降低解决方案的整体价值。
分阶段方法：增值
因此，大爆发式方法对企业软件生产商和使用 BICC 的组织很有吸引力。其余人怎么办？组织已经在少花钱多办事，尽量用当前规划满足利益相关方的日常需求。审批通过新的工具迁移项目似乎遥不可及。另一种极端做法是采用并行方法，将 OWB 流程降级到“原有”状态，任其自生自灭。
也许我们该考虑第三种选择：一种利用运行时集成和迁移实用程序的方法，将迁移到 ODI 12c 的长期目标与提供业务价值的短期目标相融合。我们称之为“分阶段方法”，其使命宣言很简单：
“任何旨在将 OWB 的内容迁移到 ODI 的任务将为 BI 利益相关方提供立竿见影的价值。”
也许这种使命宣言看似自相矛盾。有可能为将功能从一个平台迁移到另一个平台的流程增值吗？显然，当要迁移的 OWB 流程需要增强时，可以立即见到附加价值。能不能进一步延伸分阶段方法，在特性并无增强打算时也找到迁移机会呢？
我们来研究一下此时分阶段方法会变成什么样子。使用这种方法进行交付需要采取以下操作：
- 首先制定 ODI 方案，以合理的粒度方式在加载计划中执行 OWB 流程。
- 将 OWB 工作区置于“维护模式”，只在紧急“热修补”需要时才允许开发。使用 ODI Designer 内容开发所有新的 BI 规划，包括映射、过程、包、加载计划和自定义 KM 开发。以前用 TCL 编写的自动生成任务将改用 Groovy。此时，并未远离并行方法。
- 计划增强的当前 OWB 内容将使用迁移实用程序迁移到 ODI，并根据新增强中包含的 OWB 流程数量决定是一次性迁移还是分批迁移。我们将调整迁移的内容以实现最佳执行（类似于前面使用迁移实用程序时进行的调整），然后根据利益相关方的要求开发增强功能。
- 只要认为可以为业务带来立竿见影的价值，我们就会随时对流程进行任何其他增强（包括使用 ODI 特性重新设计部分 OWB 流程）。
流程的细粒度执行
图 13 显示执行 MAIN_LOAD 的 ODI 包和方案，这是用于启动完整加载的高级入口点流程。
方法中的第 1 个操作规定了流程的构建方案，但构建时应尽可能细化。例如，我们将在同一加载计划中用不同步骤执行图 9 和图 10 中的 LOAD_DIMS 和 LOAD_FACTS 流程，而不是以单一步骤执行 MAIN_LOAD，如图 25 所示。其原因稍后自明。
新 ODI 开发
方法中的第 2 个操作建议将 OWB 工作区置于“维护模式”，这样除紧急情况外无需任何新的开发。在此例中，我们将使用一个名为可重用映射的新特性来封装业务逻辑核心内容，创建一个 ODI 映射在 BI 系统中加载一个名为 SURVEYS_FACT 的新事实表，如图 26 所示。
完成后，我们需要将 MAP_SURVEYS_FACT 编排到批量加载流程（第 3 个操作）中，这通过为映射生成在加载计划中添加一个新步骤的方案实现，如图 27 所示。生成方案时，使用了前缀 ODI_ 和 OWB_ 区分映射所在的环境。
但是考虑第 4 个操作时，还要利用此机会在新特性请求中的请求内容之外进一步增值。我们继续执行，为此主题区域中的所有 OWB 映射生成包和对应方案，并将其添加为加载计划中的各个步骤，而不是以单一步骤执行 OWB 流程。
为什么要这么做？因为 ODI 加载计划提供了一个 OWB 流程所没有的重要特性：重新启动性。“restart from failed children”设置允许在执行失败时从容恢复。如果一个维度加载失败，可以纠正这个映射的问题，然后重新启动加载计划，任何已成功执行的映射在此重新启动中不会再次运行。如此可最大限度减少与恢复失败的运行相关的时间和精力，为利益相关方提供立竿见影的增值，并实现使命宣言。
零散迁移：“实时”开发
现在，我们发现需要修改 OWB 映射 MAP_SALES_FACT 中的逻辑。业务要求改进折扣的计算方式，因此 SALES_FACT 表中的 DISCOUNT 量度需要新的逻辑。需要遵循方法中的上述操作 3)，使用迁移实用程序获取此映射的 ODI 版本，以便更改特定计算。调整迁移实用程序配置文件中 MIGRATION_OBJECTS 的值（如下所示）以执行单一映射的迁移：
MIGRATION_OBJECTS=PROJECT.GCBC_SALES.MODULE.ETL.MAPPING.MAP_SALES_FACT;
首先是迁移的 ODI 映射，如图 19 所示。新的折扣计算逻辑封装在可重用映射中（如图 28 所示），这样需要提取此源数据的任何后续流程可以使用联接逻辑，就像单个统一流程中的对应折扣计算一样。
总结
12c 提供了大量新功能，首先是新的基于流程的声明式设计范例，其他 ETL 工具（尤其是 OWB）的开发人员将感到很熟悉。对于 OWB 开发人员，此范例所要求的转变比先前版本的 ODI 要轻松得多。结合使用运行时集成及迁移实用程序，OWB 客户多年在 OWB 上的投资现在很安全。这正是向 ODI 迁移的最佳时间，本文概述了组织可以采用的三种不同方法。
打个地理上的比喻，如果用一个海岸表示大爆发式方法，用另一个海岸表示并行方法，则分阶段方法类似于“天桥州”，将在不同类型的组织中找到知音。这些方法都具有不同价值，采取不同方式为客户提供 ROI。无论 OWB 投资本质上是严格原有的还是新兴、活跃的，现在都可以迁移到 ODI 的未来世界，降低迁移风险，增添适合组织需要的特定价值。
关于作者
Stewart Bryson 是 Rittman Mead 的首席创新官，是专注于商务智能的 Oracle ACE。他是一位多产作家，经常在 Oracle 社区活动中发表演讲，包括甲骨文全球大会、ODTUG Kaleidoscope、IOUG Collaborate、RMOUG 培训日和 UKOUG 大会暨展览会。
Printer View