我使用MergeContent按以下方式「批量」處理來自多個ExecuteSQL的傳入響應。在合併內容處理器中，我將「最小條目數」設置爲1000，「最大條件期限」設置爲30秒。然後我有一個相關屬性名稱，用於分揀傳入的FlowFiles。這似乎按我的預期工作，但我的問題有兩個：批處理流文件進入MergeContent
答：這是一個明智的方法，還是有更好/更有效的方法來做到這一點？也許組合的ListFile/GetFile/MergeContent等...
B.是否存在性能/可伸縮性問題，具有「較大」數量的最小入口數量？
我的最終目標是嘗試將來自ExecuteSQL命令的許多結果合併到單個文件中，並由其相關屬性名稱進行歸檔。
你的方法似乎很紮實。 SplitContent和MergeContent處理器旨在處理大量的流文件（請記住流文件內容實際上並未在堆空間中傳遞，而是存儲在內容存儲庫中，並且流文件充當引用指針）。在很多情況下，我們看到用戶「堆棧」這些處理器 - 即讀取一百萬條記錄的文件，一個初始的SplitContent處理器分裂成每個包含10,000條記錄的流文件，然後第二秒將這些流文件拆分爲單個記錄，而不是去從一個單一的操作100萬到1個。這提高了性能並減少了OutOfMemoryException的可能性。
同樣，您可以使用第二個MergeContent處理器將包含1,000個條目的流文件合併到單個流文件中的較大集合中。這個決定取決於你當前的吞吐量 - 30秒裝箱和1000個條目的結合是否讓你始終擁有1,000個條目的流文件，還是隻有幾百個？您可以評估流程文件的數據來源以確定這一點，並且您可以設置並行流程以基本上A/B測試您的配置。
除了Andy所說的之外，只是想提一下MergeContent在即將到來的Apache NiFi 1.1發行版中的性能改進，JIRA就是這個https://issues.apache.org/jira/browse/NIFI- 2850 –
嘿安迪和布萊恩，謝謝你的額外信息和見解。這1000個條目只是我選擇的任意數字，而目前大部分數據都包含在一些新的Flow文件中。這很大程度上取決於查詢從ExecuteSQL返回的速度，以及這些Flowfiles通過MergeContent處理器的其餘工作流程的速度。我會繼續修改各種配置設置並進行相應的調整。再一次，謝謝你。 – danoyoung