2014-02-24 124 views
1

我是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文件只有一個記錄。請分享您的意見。

感謝

回答

2

可能爲這種情況的最好的初步實踐是使用 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根據您的提交間隔自動完成的,當然更寬的提交間隔需要更多的內存才能工作(設置平衡的提交間隔可以大幅提高性能) –

相關問題