Disclaimer: В статье речь идет о личном мнении, которое может не совпадать с позицией компании, где трудоустроен автор :)
Apache Spark уже давно перестал быть просто технологией и превратился в своего рода стандарт для обработки больших данных. Этот фреймворк, сочетающий в себе скорость, надежность и масштабируемость, вышел далеко за пределы простого инструмента, превратившись в надежного партнера для огромного числа проектов. Поэтому, когда речь заходит о масштабных вычислениях и эффективной обработке данных, Spark - первое, что приходит на ум. Отсюда и большой интерес к нему, в том числе со стороны начинающих инженеров.
В мире Apache Spark начинающим точно не пропадешь: статьи, уроки, курсы - на любой вкус. Что хабр, что медиум, а также другие онлайн-платформы просто завалены статьями, где вам в 100500-ый раз говорят про SparkContext, Driver и Executor, приводят тривиальные примеры кода из официальной документации (ок-ок, поправлюсь - часто все же с небольшими изменениями), читают уже заезженный датасет с поездками такси в Нью-Йорке и делают какие-то тривиальные агрегации, рассуждают с умным видом про разницу coalesce и repartition и т.п. Не отстают и производители курсов класса "Войти в ИТ" - как известные онлайн-школы, так и "частники" на порталах типа Udemy, Pluralsight и т.п. Выбор курсов по Spark там очень велик.
Я ни в коем случае не хэйтю вышеупомянутых "ребят" - не поймите меня неправильно! Многие хорошие инженеры начинали свой путь с их помощью. Я и сам проходил когда-то курс на Udemy, а потом периодически обращался к Гуглу, который в свою очередь переадресовал меня на такой контент - если я 2 последних года не использовал какой-нить spark.sql.functions.explode, а тут вдруг понадобилось, то нет ничего плохого в просмотре верного синтаксиса (сейчас для этого уже проще использовать какой-нить ChatGPT 🙂 )
Но вот загвоздка: когда дело доходит до чего-то менее поверхностного, тут как будто вдруг пусто. Идет 2024 год, а статьи типа "RDD vs DataFrame vs DataSet" все еще в тренде... Опытным пользователям Spark приходится буквально искать иголку в стоге сена или читать обсуждения на stackoverflow и подобных. Отсутствие контента "не для чайников" в итоге приводит к тому, что "чайники", освоив базу, так и не могут вырасти и остаются по сути "чайниками", сами того не замечая. Вот и получаются мидлы по “погонам” (а то и синьоры), а пишут код как джуны…
Я это почувствовал еще несколько лет назад, когда вдруг осознал, что уже долго не могу найти какой-либо продвинутый контент не только по Spark, но и вообще для Data Engineer’ов. Даже 2-х дневный оффлайн курс для архитекторов Big Data от одного известного поставщика (на который меня послал мой тогдашний работодатель и, благо для моего кошелька, оплатил его) оказался невысокого качества в плане контента: 50% контента я бы мог сам рассказать без какой-либо подготовки, другие 50% - после дневной предварительной подготовки и освежения в памяти. Хорошее овервью базовых вещей и структуризация знаний, но ничего с претензией на глубину или продвинутость.
Еще более остро на меня накатило это чувство перед прошедшим новым годом. В нашей компании были открыто две вакансии для опытных Data Engineer’ов, и я помогал HR скринить CV, проверять assessments и проводить собеседования. Было немало кандидатов с неплохим CV, но вот уровень выполнения тестового задания... (ремарка: у нас тестовое, ИМХО, простое - могу судить, так как когда сам когда искал работу, решал не только его же, но еще 5-6 других; поэтому если кандидат настроен серьезно, то у него есть возможность показать свой уровень вниманием к мелочам). Большинство решений были написаны линейным кодом с использованием самых примитивных конструкций и подходов - прям как в курсах/статьях "Spark для чайников". Такое сойдет для быстрого ad hoc запроса в каком-нить ноутбуке, но не в assessment на позицию опытного инженера с первоначальной воронкой 100+ человек на место в крупную известную компанию. Хотя... Вполне возможно, кандидаты искренне думали, что такой код является вполне приемлемым - в конце концов же даже Databricks (очень уважаемый вендор!) всячески продвигает ноутбуки для написания Spark-джобов…
Еще больше проблем возникает при проведении технического собеседования. То, что я еще года два назад считал essential для junior+ позиций, сейчас знает не каждый кандидат с 7+ лет опыта. Вот какую оценку поставить ему, если он не знает, что такое pure function в Scala или в чем разница между coalesce и repartition? Это, к сожалению, реальные кейсы!
Виноваты ли инженеры в сложившейся ситуации? Ответ, как всегда, непростой - ИМХО, и да, и нет!
"Нет" - потому что они выросли как специалисты в таком "окружении" и "рынке", когда их знаний "Spark для чайников" полностью хватает для закрытия рабочих задач, работодателя это полностью устраивает, и он им дает очередные погоны "middle - senior - и т.п." за успешное закрытие бизнес-запросов и прокачку софт-скилов. А “технических долг” по хард-скилам между тем все копиться. Эффект Даннинга — Крюгера, только без видимых ошибок и серьезных последствий. Если ты получаешь положительную обратную связь о своей работе, зарабатываешь 100500 единиц денег в минуту и вдобавок эта сумма еще и регулярно повышается, откуда возьмется мотивация быть лучше? Ты УЖЕ считаешь, что ты ТОП! Да и вообще, в "интернетах" вон все CSV-файлик с Нью-Йоркским такси агрегируют, а у тебя parquet / iceberg / delta !
"Да" - потому что, ИМХО, любой хороший инженер должен быть профессионалом и стремиться развиваться. Работодатель в лице кого-нить менеджера часто не имеет достаточных компетенций (да и желания) для оценки качества кода - для этого у него есть мы. Именно опытные разработчики должны задавать стандарты разработки, определять архитектуру и т.п. В свое время я многому научился именно наблюдая, как работают более опытные коллеги, следуя “спущенным” ими стандартам разработки и ковыряясь в их коде, делая очередную доработку или исправляя какой-то баг (и порою удивляясь “Вау! А так тоже можно было?”). Так же хорошо бы регулярно обмениваться опытом с коллегами и самим шарить опыт. В конце концов, ведь джуны пишут статьи на тему "В чем разница между coalesce и repartition" (может даже уважаемый читатель написал подобную в прошлом), так почему нам, опытным, не написать то же что-нить, только менее тривиальное?
В общем, как эпилог. Давайте, мы, опытные инженеры, будем активнее делиться своим опытом, знаниями и подходами в сети и в оффлайне. Это же в конце концов в наших же интересах. Иначе нам же потом работать с коллегами, которые будут писать "выколи мне глаз"-код, нам же править за ними баги и рефакторить, нам же отучать их от "ноутбук"-стайл разработки и показывать, как правильно организовывать и структурировать приложение и т.п.
PS. Хм, сейчас перечитал еще раз и понял, что, пожалуй, написанное можно отнести к разработке вообще, а не только к дата инженерии. Там ситуация такая же?
PSS. Если у кого-то есть хорошие примеры ресурсов/статей по Spark'у хорошего уровня, то киньте плиз ссылки в комментариях.
