etl - 通过 ODI (Oracle Data Integrator) 调用选择脚本

Question

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

谢谢，拉杰尼什

标签： etldata-integrationoracle-data-integrator

Answer 1

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

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

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

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

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