语境
我正在绘制一个将庞大的 PL/SQL 系统迁移到 Java 的解决方案。第一步是迁移一些 ETL 作业:
- 从多个 ftp / sftp 源读取 CSV、XML、(XLS,这是一个新要求)和位置文件
- 根据存储在数据库中的规则处理文件并将结果写入数据库表。
目前这是由几个存储过程和作业完成的。
我的公司愿意接受建议(如果它可以在 GlassFish 4 中运行并共享它的日志记录和连接池机制,以及管理控制台,那就太好了)。
我做了一些研究,以下选项引起了我的注意:
- Java EE 7 批处理,听起来很简单,特别适合 GlassFish 4。
- Spring Batch更加成熟,并且与 Java EE 7 标准(可能基于它)非常相似。
- Apache Camel听起来很强大,可以让我们免于大量摆弄诸如 Apache POI 之类的库,但它看起来也有些复杂。此外,我不确定它是否最适合这项工作(ETL 处理大文件)。
- 什么都自己煮。我可以创建一个应用程序客户端来运行 Quartz / Spring Scheduler 甚至 EJB Timers
虽然我仍然对建议持开放态度(建议会很好),但迄今为止最合适的似乎是 Java EE 7 批处理。
还有一件事,基础设施团队有一个解决方案,可以将文件从每个 ftp 源移动到本地目录,所以 FTP 真的不是问题。
问题
我已经阅读了一些关于 Java EE 批处理的教程,并且在所有这些教程中,某种Servlet
或EJB
Timer 负责启动作业:
JobOperator jobOperator = BatchRuntime.getJobOperator();
jobOperator.start("job", properties);
我可以很容易地上传一个 web / ejb 项目并保持汇集变化。但我在考虑一个推送模型:
我的疑问是:
- 这种策略可行/可取吗?
- 我是否需要一个 JMS 队列或中间的某种生产者/消费者策略,还是应该只调用
jobOperator.start
每个文件并信任批处理层来管理应用程序资源?换句话说,如果一千个文件一次传送到我的文件夹并且我调用jobOperator.start
了一千次,GlassFish 4 是否会进行某种智能排队,或者我应该创建某种门以便n
同时运行多个作业?