Я не знаю о внутреннем алгоритме, но в несортированном режиме для Aggregator нормально хранить все строки в кеше и ждать последнюю строку, потому что это может быть первая, которая должна быть возвращается согласно Агрегатору правил! Aggregator никогда не будет жаловаться на порядок входящих строк. При использовании кеша он сначала сохраняет строки в памяти, а затем, когда выделенная память заполнится, он помещает кэш sh на диск. Если ему не хватает места на диске, сеанс не удастся (и, возможно, другие из-за этого полного диска). Вам нужно будет очистить эти файлы вручную.
В режиме сортировки такой проблемы не возникает: строки объединяются в группы, готовые к агрегированию, и агрегированная строка выводится go, как только все строки в группе принимаются, что обнаруживается при изменении одного из значений ключей. Агрегатор будет жаловаться и останавливаться, если строки не в ожидаемом порядке. Однако это поднимает проблему вверх к части сортировки, которая может быть Sorter , которая может использовать много самого кеша, или база данных с предложением ORDER BY в запросе SQL, который может занять ресурсы на стороне базы данных.
Также обратите внимание, что SQL ORDER BY может использовать язык, отличный от Informatica.