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

Привет, Хабр! Меня зовут Александр Маркачев и я — Data Engineer команды Голосовой Антифрод в билайн. Расскажу, как борьба с мошенниками может обернуться личным вызовом.

Все техники сопровождаются объяснениями, примерами и рекомендациями для самостоятельного повторения.

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

У нас получилось! Мы снизили количество данных на диске в 3 раза, при этом ускорив их обработку. И сейчас расскажу как. Меня зовут Александр Маркачев, я Data Engineer команды Голосовой Антифрод в beeline. В статье затронем тему форматов ORC и Parquet, как их правильно использовать и хранить, чтобы всем было хорошо.

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.