2014-02-24 119 views
1

我有一個處理流動行的spring批處理作業。我正在使用標準的閱讀器,處理器和編寫器模式。Spring批處理 - 聚合處理器

load_id policy_number slice_numb asset_code surrender_value 
923  V317865  V317865 XXH  XXH   46230.340000 
923  V318291  V318291 XXA  XXA   40664.230000 
923  V318757  V318757 XXA  XXA   73263.360000 
923  V318757  V318757 XXF  XXF   36575.820000 
923  V318757  V318757 XXI  XXI   8723.330000 
923  V318782  V318782 XXI  XXI   9141.550000 
923  V318782  V318782 XXF  XXF   28329.550000 
923  V318782  V318782 XXA  XXA   76776.220000 

對於每一行,我需要爲具有相同policy_number的行獲取SUM(surrender_value)。注意policy_number V318757作爲三行的示例。我需要報告此行提供的總退保價值的百分比。

我有兩個想法如何,我可能實現這一點,但一個不確定哪個是更好的方法

第一種選擇 - 移動SUM /邏輯分組由讀寫器中的SQL查詢。這意味着我需要的所有信息都可用於處理器,但我必須映射一些額外的字段。

第二個選項 - 爲了聚合行,我會添加一個預處理器,它將保持每個policy_number的總計和受影響的行的列表的映射。一旦這個處理器完成,我會將結果數據結構傳遞給第二個處理器,它將執行標準工作。我的關注點在於,當我緩存這麼多行的細節時,內存佔用會變得非常大。

任何意見或指導,將不勝感激。

+1

可能的解決方案在http://stackoverflow.com/questions/19906772/grouping-summarizing-spring-batch-records/19908104#19908104 –

+0

@ballabax謝謝你。我不願意將這個邏輯轉移到作者階段,因爲我覺得它確實屬於處理器階段。我會在稍後發佈一個建議的解決方案 – emeraldjava

+0

也http://stackoverflow.com/questions/18396259/how-to-write-more-then-one-class-in-spring-batch/18411497#18411497;轉向作家是正確的選擇! –

回答

4

我建議在SQL查詢中進行這種類型的聚合。除非數據模型來自非常複雜的情況,否則通過SQL添加這種類型的聚合應該是直接的,並且可以消除像在處理器/寫入器中這樣做的塊邊界之類的問題(例如,如果前兩個記錄對於V318757出現在一個塊中,最後一個出現在另一個塊中,您可能無法獲得正確的數學結果。您可以使用自定義CompletionPolicy來處理此問題,但這會增加複雜性)。