设计防弹ETL作业以使用Java，SQL和（可能）Spring批处理来聚合数据

Question

我必须重写遗留的ETL作业（5年，逐渐发展），将数据从Oracle DB聚合到mySQL DB以进行开票和报告。现有作业使用自定义构建框架以Java编写。该框架可用于从Datasource A读取，处理和写入数据到Datasource B.该配置基于XML，在某些方面类似于Spring批处理。这些是框架的核心功能

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

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

1. XML已经变得混乱，许多特殊的业务规则表示为SQL片段 - 不容易测试或维护
2. 在生产中，工作每月运行，随着数量的增加，它变得越来越慢，越来越难以每月运行一次，并且在同一个工作日得到结果，因为我们从客户那里获得了紧迫的截止日期。

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

Answer 1

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

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