Использует ли Spark's limitByKey постоянный объем памяти или линейный по количеству ключей?

Насколько я знаю, существуют решения внешней сортировки и / или в Hadoop MapReduce, которые позволяют использовать постоянный объем памяти, не более, при сортировке / группировке данных по ключам для дальнейшей передачи через функции агрегирования для каждого ключа.

Предполагая, что состояние сокращения также является постоянной величиной, как сложение.

Доступна ли эта группировка / сортировка с постоянной памятью для Apache Spark или Flink, и если да, то есть ли какая-либо конкретная конфигурация или программный способ запроса такого способа обработки с постоянной памятью в случае reduByKey или aggregateByKey?

Всего 1 ответ


Обе системы должны неявно выполнять операцию, поскольку процессы Java получают только фиксированный объем основной памяти. Обратите внимание, что когда данные для сортировки становятся намного больше, данные должны быть размещены на диске. В случае сортировки и в зависимости от вашего запроса это может означать, что полный набор данных должен быть материализован в основной памяти и на диске.

Если вы спрашиваете, можете ли вы ограничить потребление памяти конкретным оператором, то все выглядит намного сложнее. Вы можете ограничить свое приложение одной конкретной операцией и использовать глобальную настройку памяти, чтобы ограничить потребление, но это приведет к сложной настройке.

Имеете ли вы в виду конкретный вариант использования, где вам нужно было бы ограничить память конкретной операции?

Кстати, вы можете рассмотреть Spark и Flink, чтобы заменить Hadoop MapReduce. Есть только пара крайних случаев, когда MapReduce может превзойти системы следующего поколения.


Есть идеи?

10000