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

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

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

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

XML已经被许多表示为SQL代码片段的特殊业务规则弄得乱七八糟——测试或维护起来并不那么容易

在生产中，工作是每月进行一次的，随着工作量的增加，每月运行一次并在同一个工作日获得结果变得越来越慢，而且越来越困难，因为客户给我们的最后期限很紧 如何重新设计这份工作，我左右为难。我可以在SpringBatch或其他定制解决方案中重写作业—这将帮助我摆脱带有嵌入式SQL的XML，并将业务规则移动到更易于维护的SQL或另一个整洁的可测试和可维护服务。

---

但是如何解决第二个问题呢？我正在考虑每天运行作业，而不是每月运行一次，然后使用另一个每月作业在每天进行汇总-这将帮助我们获得错误的每日反馈，我们可以修复错误并重新启动。但在这里它变得棘手。由于每个输入行都是基于多个列上的group by的聚合结果，因此我无法想象如何再次“读取”这些失败的行。我可能不得不重新启动整个过程，这也是低效的。目前，我正在考虑一种解决方案：我不需要一个只连接多个表的物化视图，而是要物化视图本身也包含聚合数据。此表中的每一行也将有一个技术PK。然后作业将从此视图中读取、处理数据并写入。错误将被捕获并与导致问题的行的主键一起记录到另一个表中。这是设计跨数据库复制数据的作业的好方法吗，特别是当源数据不仅仅是一个简单的选择时

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

---

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

+1获取建议。这些错误是不可恢复的，与输入数据的质量或某些其他配置有关。问题，但只能记录。基于当前的体系结构，跳过并继续是没有帮助的，因为作业只能从头开始重新启动，因此，假设每月最后一天的数据存在某些数据问题，则每月作业将失败。你每天对ELT的建议-我会认真考虑看它是否会变大。在这种情况下，我必须完全复制源代码，而不仅仅是DBA可能无法接受的聚合输出。