我的问题是（1）是否有一个更好的策略来解决我的问题（2）是否有可能调整/改进我的解决方案以使其有效并且不会以可靠的方式分割聚合（3不太重要的一个） ）我怎样才能更智能地调试它？弄清楚聚合器正在做的wtf是很困难的，因为它只会因为它们的大小而难以调试的大批量失败。任何这些的答案都非常有用，最重要的是前两个。
我认为问题是我没有正确表达我需要它来处理单个块中的CSV文件，我不希望聚合器停止直到所有记录都已聚合。
我正在编写一条路线来消化一百万行CSV文件，然后拆分然后聚合一些关键主要字段上的数据，然后将聚合记录写入表格
unforuntaely表的主要约束被违反（也对应于聚合键），这意味着聚合器不等待整个输入完成。
它适用于几千条记录的小文件，但实际上它将在生产中面临的大尺寸（1,000,000条记录）失败。
首先，在CSV解组后，它在分割时出现JavaHeap内存错误。我用.streaming（）来解决这个问题。这会影响聚合器，聚合器“过早完成”。
说明：
A 1
A 2
B 2
--- aggregator split ---
B 1
A 2
--> A(3),B(2) ... A(2),B(1) = constraint violation because 2 lots of A's etc.
when what I want is A(5),B(3)
以100,1000等示例，记录它工作正常。但是当它处理1,000,000条记录时，它需要处理的是实际大小，首先split（）获取OutOfJavaHeapSpace异常。
我觉得简单地改变堆大小将是一个短期解决方案，只是将问题推回到记录的下一个上限，所以我通过使用.streaming（）来解决它。分裂。
不幸的是现在，聚合器正在被记录下来，而不是将它们放在一个大的污泥中，它似乎在提前完成并进行另一次聚合，这违反了我的主要约束
from( file://inbox )
.unmarshall().bindy().
.split().body().streaming()
.setHeader( "X" Expression building string of primary-key fields)
.aggregate( header("X") ... ).completionTimeout( 15000 )
etc.
我认为问题的部分原因在于我依赖于流媒体分割而不是超过固定时间的时间，这不是万无一失的 - 例如系统任务可能会合理地导致这种情况，等等。每次我增加此超时时，它都会使调试和测试这些东西的时间越来越长。
可能更好的解决方案是读取进入的CSV文件的大小，并且不允许聚合器完成，直到每个记录都被处理完毕。我不知道我怎么用骆驼表达这个。
很可能我只是对我应该如何处理/描述这个问题有一个基本的政治误解。可能有一种更好（更简单）的方法，我不知道。
还有如此大量的记录进入，我无法亲自调试它们以了解正在发生的事情（我也在打破聚合器的超时时间，我怀疑）
答案 0 :(得分：2)
您可以逐行拆分文件，然后将每行转换为CSV。然后，您可以在流模式下运行拆分器，因此内存消耗较低，并且能够读取具有一百万条记录的文件。
此页面http://camel.apache.org/articles中有一些关于在Camel中拆分大文件的博客链接。它们虽然涵盖了XML，但也与拆分大型CSV文件有关。