设计一个防弹ETL作业，使用Java、SQL和(可能)Spring批处理聚合数据。

Question

我必须重写一个遗留的ETL (5岁，逐渐增长)，它将数据从Oracle聚合到mySQL DB，以用于发票和报告目的。现有作业是使用自定义构建的框架用Java编写的。该框架可用于从Datasource A到Datasource B读取、处理和写入数据。配置基于XML，在某些方面类似于Spring批处理。这些是框架的核心特性。

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

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

1. XML已经变得杂乱无章，充斥着许多特殊的业务规则，这些规则被表示为SQL代码段--不太容易测试或维护。
2. 在生产中，作业每月运行一次，而且随着工作量的增加，由于客户的截止日期很紧，每月一次并在同一工作日获得结果变得越来越慢和越来越困难。

如何重新设计这份工作，我进退两难。我可以在Spring批处理中重写作业，或者仅仅编写另一个自定义解决方案--这将帮助我使用嵌入式SQL摆脱XML，并将业务规则移动到更易于维护的SQL或另一个整洁、可测试和可维护的服务中。但是如何解决第二个问题呢？我正在考虑每天运行作业，而不是每月运行，然后使用另一个月的工作来聚集超过每日-这将帮助我们获得一个错误的每日反馈，我们可以修复和重新启动。但在这里很棘手。由于每个输入行都是一个基于多列组的聚合结果，我无法想象如何才能再次“读取”那些失败的行。我可能不得不重新启动完整的过程，这也是低效的。目前，我正在考虑一种解决方案:与其拥有一个只连接多个表的物化视图，不如让--物化视图--同时提供聚合数据。此表中的每一行还将有一个技术性PK。然后作业将从此视图读取、处理数据和写入。错误将被捕获并与引起问题的行的PK一起登录到另一个表中。这是否是一种设计跨数据库复制数据的好方法，特别是当源数据不仅仅是一个简单的选择时？

Answer 1

作为第二个问题的解决方案，我可以建议从ETL转到ELT。您可以每天从源系统提取(E)原始数据，将(L)数据加载到数据仓库的阶段区域，然后通过每月从舞台区域聚合数据来转换(T)数据。

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