【问题标题】:Invoking an select script through ODI (Oracle Data Integrator)通过 ODI (Oracle Data Integrator) 调用选择脚本
【发布时间】:2020-04-08 12:37:38
【问题描述】:

请问您对以下问题有何看法: 选项 1: 我有一个方便的选择脚本,它通过加入许多源表来获取数据并执行一些转换,如聚合(分组依据)、数据转换、子字符串等。 我可以通过 ODI 映射调用此脚本并将返回结果(转换后的数据输出)插入 ODI 映射的目标吗? 选项2: 通过使用等效的 ODI 转换、函数、查找等将选择脚本转换为等效的 ODI 映射,并使用各种表(连接子句中的表)作为映射源。 基本上开发ODI映射,相当于提供的选择脚本加上一个目标表来插入记录。 我需要知道上面两个选项的优缺点(如果选项 1 是可能的)。 是否仍然可以通过带有选项 1 的 ODI 跟踪转换错误、连接源表和 where 子句条件相关错误等? 映射失败的日志文件将具有选项 2 提供的粒度级别的详细信息? 我仍然可以在知识模块中启用流控制并将选择脚本错误重定向到 ODI 提供的 E$_ 错误表吗?

谢谢, 拉杰尼什

【问题讨论】:

    标签: etl data-integration oracle-data-integrator


    【解决方案1】:

    选项 1:ODI 12c 开箱即用地包含该概念。在映射的物理选项卡上,单击源节点(数据存储)。然后在属性窗格中,“提取选项”菜单下有 CUSTOM_TEMPLATE 选项。这允许输入将使用的自定义 SQL 语句,而不是 ODI 生成的代码。

    但是,随着时间的推移,它可能比选项 2 更难维护。SQL 不如映射组件可视化。此外,如果您需要批量更改它,那将更加棘手。可以使用 SDK 更改多个映射中的组件。更改 SQL 代码需要对其进行解析。您的操作员日志中的信息可能确实较少,因为 SQL 将被视为只是一个代码块。它也不会提供任何血统。

    我相信使用流控制会起作用,但我还没有测试过。

    选项 2 需要更多时间才能完成,但这样您将受益于 ODI 的所有功能。

    我自己的偏好是偶尔将选项 1 用于非常复杂的 SQL 查询,但将选项 2 用于大多数正常用例。

    【讨论】:

    • 感谢杰罗姆,它有帮助!我可以知道更多如下:当您说您将从 ODI 的所有功能中受益时” – 请详细说明/列出所有 ODI 功能将受到选项 1 的损害,除了数据沿袭和可能受到损害的操作员日志?跨度>
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-12-12
    • 1970-01-01
    • 2022-11-24
    • 2013-05-09
    相关资源
    最近更新 更多