2016-05-05 6 views
1

Я не уверен в концепции печати стоп-кадра. При загрузке паркетного файла, например. 1 ГБ и создание RDD из него в Spark, что будет для печати памяти для каждого RDD?RDD Память в искровом свете

ответ

2

Когда вы создаете RDD из файла паркета, ничто не будет загружено/выполнено до тех пор, пока вы не запустите действие (например, сначала, наберите) на RDD.

Теперь объем памяти, вероятно, будет меняться со временем. Скажем, у вас есть 100 разделов, и они одинакового размера (по 10 МБ каждый). Предположим, что вы работаете в кластере с 20 ядрами, а затем в любой момент времени вам нужно иметь только данные 10MB x 20 = 200MB.

Чтобы добавить поверх этого, учитывая, что объекты Java имеют тенденцию занимать больше места, нелегко точно сказать, сколько места займет ваш 1GB-файл в куче JVM (при условии, что вы загрузите весь файл). Это могло бы меня 2x, или это может быть больше.

Один трюк, который вы можете сделать, чтобы проверить это, заставляет ваш RDD кэшироваться. Затем вы можете проверить в Spark UI в разделе Storage и посмотреть, сколько места занимает RDD для кэширования.

+0

Спасибо за ответ marios. Когда вы упоминаете разделы, это RDD, созданные из файла паркета? И поскольку RDD не являются физическими объектами, в основе действий, которые мы выполняем, будут только данные в памяти, правильно ли я это понимаю? Также могут быть и неравные перегородки? –

+1

Все RDD разделены, в противном случае параллелизм отсутствует. Вы правы, RDD не материализованы, пока им не понадобится (они ленивы). Если это один большой файл паркета, он должен быть в равной степени разделен. Да, бывают случаи, когда разбиения разделяются, особенно когда RDD генерируется из большого количества небольших файлов, а не из одного большого. – marios

0

Marios, в вашей проекции памяти вы не принимали во внимание сжатие Паркета. 1Gb может быть очень сжатым.

Смежные вопросы