spring批处理多个子目录中的多个源文件

问题描述:

我是spring批处理新手,虽然spring批处理并阅读multipartItemReder,但我想multipartItemReader并不适合我的项目。请通过你的想法和公会给予几点。spring批处理多个子目录中的多个源文件

我有超过5000万个xml文件,就像下面的目录结构一样。

GOOD 
    0 
     001/en/1.xml 
     001/jp/1.xml 
     002/en/2.xml 
     003/en/3.xml 
     004/jp/4.xml 
     .... 
     .... 
     999/jp/1.xml 
    1000 
     001/en/1.xml 
     001/jp/1.xml 
     002/en/2.xml 
     003/en/3.xml 
     004/jp/4.xml 
     .... 
     .... 
     999/jp/1.xml 
    2000 
    3000 
    ... 
    .. no limit 
REMAKE/ 
    0 
     001/en/1.xml 
     001/jp/1.xml 
     002/en/2.xml 
     003/en/3.xml 
     004/jp/4.xml 
     .... 
     .... 
     999/jp/1.xml 
PROCLAIMED/ 
... 
    ... 
    .... 
    like 100 directories .. 

每个来源(GOOD,REMAKE,PROCLAIMED等)都有不同的xml文件合成。 1.我需要为每个来源创建Item处理器。 2.每个源代码将会是一个线程,或者根据源文件中的lang文件数////。xml提交事务= 1或线程跨度,有什么更好的选择。 3.我仍然觉得IteamReader是复杂的实现。这里每个xml文件只有一个记录。请分享您的意见。

感谢

可能为这种情况的最好的初步实践是使用 partitioning;我没有尝试过,所以我不能帮忙,但是我认为当你有相同的类型数据进行管理时,分区会很有帮助,而不是在数据混合的情况下。

现在我的2美分...
我会去parallel steps

  1. 每个源管理与使用split/flow
  2. 没有必要有commit-interval等于1独立的线程;你可以使用一个较大的值(或自定义CompletionPolicy如果你想要一个细粒度的承诺)来提高性能
  3. 使用MultiResourceItemReader委托给StaxEventItemReader具体为每一种来源的
  4. 专用处理器的各种物品进行返回读者
  5. 作家(取决于你的需要)

<job id="job1"> 
    <split id="split1" task-executor="taskExecutor" next="lastStep"> 
    <flow> 
     <step id="GOOD" /> 
    </flow> 
    <flow> 
     <step id="REMAKE" /> 
    </flow> 
    <flow> 
     <step id="PROCLAIMED" /> 
    </flow> 
    </split> 
    <step id="GOOD"> 
    <tasklet> 
     <batch commit-interval="100"> 
     // Set MultiResourceItemReader and delegate to specialized StaxEventItemReader for GOOD file structure 
     // Set specialized processor for GOOD object 
     // Set writer (IDK which type) 
     </batch> 
    </step> 
</job> 
+0

感谢您inputs.Really帮助了很多..我有一个multiResourceI疑问temReader。假设我在GOOD/0中只有30,000个文件,如果GOOD/0,GOOD/1000,Good/2000总文件为3 * 30,000。我是否需要进一步将GOOD步骤分割为0,1000,2000 ..如果是,那么problum是.. 0,1000,2000不是内容.. REMAKE下可能只有0 ..或multiresourceIteamReader作品将用于> 90,000条记录。请建议.. – Negation

+0

无需手动分割,因为“分割”是由SB根据您的提交间隔自动完成的,当然更宽的提交间隔需要更多的内存才能工作(设置平衡的提交间隔可以大幅提高性能) –