Комментарии 5
Спасибо за статью!
Небольшая оптимизация которую можно сделать в одном из ваших примеров:
Фильтрация после первого соединения. После первого соединения выполняем фильтрацию, оставляя только записи с возрастом больше 30. Это ещё больше уменьшает объём данных.
Вместо фильтрации после первого join можно сделать фильтрацию до него, тогда уже сразу во время join данные отфильтруются. В случае с маленькой таблицей это будет скорее всего не важно, но все равно выглядит более логично
"На дворе конец 20 века, а у нас в избе одини валенки на двоих" (с)
Не видел использование RDD-api уже лет 7. Почему люди все еще с умным видом пишут про него?
Без кэширования/персистенции. Для каждого действия (например, count или filter)
filter всё-таки не действие, а трансформация, лучше поправить в тексте на условную функцию show.
Я правда всего месяц со спарком возился, но по моему опыту попытки вручную что-то кэшировать вообще ничего не давали, а то и хуже делали. Он и так кеширует промежуточные данные, если есть свободная память, поэтому попытки вручную сохранить тот набор данных, к которому потом будешь несколько раз обращаться, ничего не дают. А если свободной памяти нет, то ручное кэширование делает ещё хуже только - Спарк сначала тратит время на запоминание данных, а потом он всё-равно из памяти их выкидывает.
А вот грамотный порядок фильтрации это да, он решает. Если удачно фильтровать данные, сразу оставляя минимум в памяти, то всё быстро и чётко работает и память лишними данными не забивается.
Руководство по Apache Spark не для начинающих: оптимизация