0

我必须重写一个旧的 ETL 作业（5 岁，逐渐成长），将数据从 Oracle 数据库聚合到 mySQL 数据库，以用于开票和报告目的。现有作业是使用自定义构建的框架用 Java 编写的。该框架可用于从数据源 A 读取、处理和写入数据到数据源 B。配置是基于 XML 的，在某些方面类似于 Spring 批处理。这些是框架的核心功能

  • Job 需要指定源和目标数据源。物化视图用作源表，并针对它运行非常复杂的 SQL 查询以进行聚合。
  • 要从源复制并保存在目标中的列必须在 XML 中指定
  • 在处理器中，可以验证和/或转换数据
  • SQL 由框架生成，事务也由它管理
  • 如果作业失败，它可以在给定的时间段（通常一个月）内重新启动，它会清理最后一次运行并从头开始重做它的工作

当前解决方案的主要瓶颈如下：

  1. XML 已经被许多以 SQL 片段表示的特殊业务规则混杂在一起——测试或维护并不那么容易
  2. 在生产中，作业每月运行一次，随着数量的增加，鉴于我们从客户那里得到的紧迫的最后期限，每月运行一次并在同一工作日获得结果变得越来越慢并且越来越困难。

我在如何重新设计这份工作上进退两难。我可以在 Spring 批处理中重写 Job 或只是另一个自定义解决方案 - 这将帮助我摆脱带有嵌入式 SQL 的 XML 并将业务规则移动到更易于维护的 SQL 或另一个整洁的可测试和可维护的服务。但是如何解决第二个问题？我正在考虑每天而不是每月运行该作业，然后使用另一个每月作业来汇总每日 - 这将有助于我们获得错误的每日反馈，我们可以修复它们并重新启动。但在这里它变得棘手。由于每个输入行都是基于多列分组的聚合结果，我无法想象我怎么能再次“读取”那些失败的行。我可能必须重新启动整个过程，这也是低效的。目前，我正在考虑一种解决方案：物化视图也以聚合数据呈现。此表中的每一行也会有一个技术PK。然后作业将从该视图中读取、处理数据并写入。错误将被捕获并与导致问题的行的 PK 一起记录到另一个表中。这是设计跨数据库复制数据的作业的好方法，尤其是当源数据不仅仅是一个简单的选择时？

4

1 回答 1

1

作为您的问题 2 的解决方案，我可以建议从 ETL 切换到 ELT。您可以每天从源系统中提取 (E) 原始数据，将其加载 (L) 到数据仓库的阶段区域，然后通过每月汇总阶段区域中的数据对其进行转换 (T)。

你得到什么样的错误？这些错误主要发生在从源系统提取数据期间还是在汇总数据时？无论如何，使用建议的方法，您可以保留每日数据提取的副本，然后在源系统中的数据被清理或修复时回填缺失的日期。如果在聚合过程中出现错误，您可以每天测试聚合的部分结果，并尽早收到有关问题的通知，而不是在交付截止日期当天。

于 2013-10-23T17:45:01.157 回答