我必须重写遗留的ETL作业（5年，逐渐发展），将数据从Oracle DB聚合到mySQL DB以进行开票和报告 . 现有作业使用自定义构建框架以Java编写 . 该框架可用于从Datasource A读取，处理和写入数据到Datasource B.该配置基于XML，在某些方面类似于Spring批处理 . 这些是框架的核心功能
-
作业需要指定源和目标数据源 . 物化视图用作源表，并且针对它运行非常复杂的SQL查询以进行聚合 .
-
必须在XML中指定要从源复制并保存在目标中的列
-
在处理器中，可以验证和/或转换数据
-
SQL由框架生成，并且事务由它管理
-
如果作业失败，可以在给定的时间段（通常是一个月）重新启动它，它会清理上一次运行并从头开始重做它的工作
我们对当前解决方案的主要瓶颈如下：
-
XML已经变得混乱，许多特殊的业务规则表示为SQL片段 - 不容易测试或维护
-
在 生产环境 中，每月运行一次工作，随着数量的增加，它变得越来越慢，越来越难以每月运行一次，并且在同一工作日得到结果，因为我们有来自客户的紧迫期限 .
如何重新设计这项工作我处于两难境地 . 我可以重写Spring中的Job批处理或只是另一个自定义解决方案 - 这将帮助我摆脱嵌入式SQL的XML，并将业务规则转移到更易于维护的SQL或其他整洁可测试和可维护的服务 . 但如何解决第二个问题呢？我想的是每天运行工作而不是每月运行，然后使用另一个月工作来累计每天 - 这将帮助我们获得错误的每日反馈，我们可以修复它们并重新启动 . 但在这里它变得棘手 . 由于每个输入行是基于多个列的组的聚合结果，我无法想象我怎么可能再次"read"那些失败的行 . 我可能必须重新启动整个过程，这也是低效的 . 目前，我正在考虑一个解决方案：我没有一个只加入很多表的物化视图，我也会有 the materialized view present itself with aggregated data . 该表中的每一行也将具有技术PK . 然后作业将从此视图读取，处理数据并写入 . 将捕获错误并将其与导致问题的行的PK一起记录到另一个表中 . 这是设计跨数据库复制数据的作业的好方法，尤其是当源数据不仅仅是简单的选择时？
1 回答
作为问题＃2的解决方案，我建议从ETL切换到ELT . 您可以每天从源系统中提取（E）原始数据，将其加载（L）到数据仓库的阶段区域，然后通过每月汇总舞台区域中的数据来转换（T）它 .
你得到了什么样的错误？在从源系统提取数据或聚合数据时，这些错误主要发生吗？在任何情况下，使用建议的方法，您可以保留每日数据提取的副本，然后在清理或修复源系统中的数据时回填缺少的日期 . 如果在聚合期间发生错误，您可以每天测试聚合部分结果，并尽早获得有关问题的通知，而不是在交付截止日当天 .