java - 监视服务和 Java EE 批处理

Question

上下文

我正在制定一个解决方案，将一个巨大的 PL/SQL 系统迁移到 Java。第一步是迁移一些 ETL 作业:

1. 从多个 ftp/sftp 源读取 CSV、XML(XLS，这是一项新要求)和位置文件
2. 根据存储在数据库中的规则处理文件，并将结果写入数据库表。

目前这是由几个存储过程和作业完成的。

我的公司乐于接受建议(如果它可以在 GlassFish 4 中运行并共享其日志记录和连接池机制以及管理控制台，那就更好了)。

我做了一些研究，以下选项引起了我的注意:

1. Java EE 7 Batch Processing ，听起来很简单，特别适合 GlassFish 4。
2. Spring Batch在某种程度上更成熟，并且与 Java EE 7 标准(可能基于它)非常相似。
3. Apache Camel , 听起来很强大，可以让我们免于摆弄诸如 Apache POI 之类的库，但它看起来也有些复杂。此外，我不确定它是否最适合这项工作(大文件的 ETL)。
4. 自己做饭。我可以创建一个 Application Client 来运行 Quartz/Spring Scheduler 甚至 EJB Timers

虽然我仍然对建议持开放态度(建议会很好)，但到目前为止最合适的似乎是 Java EE 7 批处理。

还有一件事，基础架构团队有一个解决方案，可以将文件从每个 ftp 源移动到本地目录，因此 FTP 真的不是问题。

问题

我读过一些关于 Java EE 批处理的教程，在所有这些教程中，某种 Servlet 或 EJB 计时器负责启 Action 业:

JobOperator jobOperator = BatchRuntime.getJobOperator(); 
jobOperator.start("job", properties);

我可以很容易地上传一个 web/ejb 项目并保持汇集以进行更改。但我在考虑推送模型:

1. Application client控制台应用程序
2. 主类 watches directories对于新文件
3. 当有一个新文件时，它会开始一个新的工作。

我的疑问是:

1. 此策略可行/可取吗？
2. 中间是否需要 JMS 队列或某种生产者/消费者策略，或者我是否应该为每个文件调用 jobOperator.start 并信任批处理层来管理应用程序资源？换句话说，如果一千个文件一次传送到我的文件夹并且我调用 jobOperator.start 一千次，GlassFish 4 会进行某种智能排队还是我应该创建某种门以便不超过 n 个作业同时运行？

Answer 1

我已经在 Wildfly (Jboss AS) 中实现了一个批处理项目。我不熟悉 Glassfish 的配置细节(不再使用它，因为它已经放弃了企业支持)，但是我可以根据我的经验为您提供一些见解和指导。另外，请注意 Spring 和 Batch 规范。在 EE 7 上非常相似，您决定使用任何一种技术必须取决于除了批处理之外您希望通过应用程序实现的“其他目标”。您想要一个易于维护的 Web 界面吗？是否要开发 REST api？等。

您描述的 ETL 作业完全符合 EE 7 规范中的步骤和 block 模型，因此如果您已经尝试开发一些测试，您可能已经注意到您仍然需要编写文件读取器和每个文件规范的映射器。您的阅读资源非常标准，您可以轻松找到一个图书馆来读取/流式传输它们并处理它们的数据。

我实现的项目非常简单。客户上传需要处理的文件以提供给数据仓库。该服务在“云”上。文件具有定义的规范，并且必须采用 CSV 格式。大多数处理结果是维度“Upserts”和事实“删除之前插入”。用户有一个 Web 界面，必须在该界面上显示文件和批处理元数据(处理状态、日期、拒绝的项目等)。因为它是云服务，所以文件不能驻留在每个服务器本地(使用 S3)。

所以首先要设计的是 block 步骤。我不想为每个文件规范都有一个实现，所以我所做的是设计一个“适合所有情况”的实现，根据文件中包含的元数据以及作业配置本身来处理文件。这是简单的部分。第二件要考虑的事情是处理和元数​​据管理。在这里，我开发了一个 REST api 和一个使用它的 Web 界面。毕竟，它会扩展吗？ Wilfly 具有用于批处理的线程配置参数，您可以增加或减少 JobOperator 的线程可用性。如果没有足够的可用线程，则不会提交作业。那么这些请求发生了什么？好吧，它们可以驻留在内存中，可以开发一个备份的有状态 session ，您绝对可以实现排队处理请求的 MQ 监听器。我所做的要简单得多。公司没有维护集群的资源，所以做了一个弹性配置，可以根据 cpu 消耗和请求量进行扩展。到目前为止，该应用程序已处理来自 15 个客户的 10 TB 数据，并且在最大请求/处理峰值时，已启动 3 个弹性实例。

文件监听器是一个有趣的想法。您可以监听目录并将处理请求放入队列或立即放入 BatchRuntime。这将取决于您希望如何扩展它、您需要的响应时间、可用资源等。

有什么问题随时问我。

问候。

编辑:忘了说。我真的不建议使用应用程序客户端，除非您已经在您的组织中部署了一些东西。最近的安全限制和 Java SE 更新机制给维护这类部署带来了真正的麻烦。想想网络。