Комментарии 21
С учётом того факта, что для 97.78% пользователей Spark он ограничивается Spark SQL, очень странно к ним взывать.
Если хочется залезть поглубже — ну так берёшь и залазишь в исходники. Они открыты ведь. Но внутренний уровень Spark, кроме разработчиков чего-то кастомного на нижнем уровне API, никому не интересен. Мне вот нужен, так что можете мои статьи посмотреть, например. Но таких, как я, совсем мало.
Большинству же, работающему с SQL, это всё незачем. Потому они и не знают, что .reparttition это .coalece(shuffle = true).
Да, это печальный факт... На днях медиум на вкладке "в тренде" порекомендовал мне статью, где автор призывает как раз использовать со Спарком только SparkSQL...
Поглубже в исходники - о таком можно только мечтать. Я не вижу (по кандидатам в нашей воронке) даже банального - например намек на функциональный подход: надо переименовать 5-10 колонок, значит будет 5-10 раз withColumnRename вместо чего-нить типа renameMap.foldLeft... Примеров таких массу могу надергать из ассесментов..
withColumnsRenamed более читабельно. renameMap.foldLeft какой-то выигрыш в производительности даёт?
По производительности - нет. Вот по читабельности кода и удобству сопровождения - да. Если конечно код организован нормально. Например добавляем через имплисит класс новый метод renameColumns для DataFrame, который принимает на вход renameMap и под капотом через foldLeft переименовывает поля. И потом в коде вызываем что-то типа
df.renameColumns(renameMap)
Просто, читабельно, масштабируемо, да еще и красиво
А причем тут Spark SQL? Если знать что под капотом творится, какая разница на чем писать? А если не знаешь, то и на Python/Scala хрень можно написать. Что за высокомерие?
Тем более что SQL более понятен аналитикам, бизнесу его дешевле поддерживать, поэтому я чаще всего на проектах слышу от бизнеса требование код писать на SQL. В 99% случаев можно спокойно им обойтись. А для остальных редких случаев можно почитать spark internals, либо в исходники залезть.
Что от статьи, что от первых комментариев несёт каким-то высокомерием и пижонством, особенно про собеседования. Все вокруг тупые, один вы Д'артаньян
Автор статьи сетует на то, что а) кроме spark internals ничего про нижний уровень толком не найти, и б) впрочем, даже и его всё равно никто не читает перед собеседованием.
Я же иронизирую над ситуацией (очевидно же, что проценты придуманы от балды), чего вы, по всей видимости, не выкупаете. Какое ещё высокомерие? Какое нафиг пижонство? Расслабьтесь, тут нет никакого наезда.
SQL - бесспорно "межгалактический язык для работы с данными", но Spark далеко не ограничивается им. Если в 99% случаев вам хватает SparkSQL, то значит скорее всего у вас структурированные данные (и тут кстати тогда вопрос, почему бы вообще не хранить их в MPP-СУБД какой-нить?). Ну и если человек все пишет на Spark SQL, то наверное не совсем корректно заявлять в CV, что он хорошо знает Spark? Как считаете?
Ну есть масса примеров, когда на Spark SQL получается менее производительно и более громоздко. Свежий пример из практики - агрегация с предобработкой, которая требует 1-2 вложенных подзапроса/CTE и/или оконных функций, что в свою очередь приводит к шафлингу большого количества данных. Альтернатива - UDAF, которая делает то же самое в одну строчку и где шафлиться на порядок меньше данных.
Возможно, если обрабатывается пара десятков гигабайт, разницы вы не заметите. Но у меня был проект, где кластер состоял из 1000+ машин, а ежедневная дельта только одного из дата-сетов была 500 Гб...
UDAF, которая делает то же самое в одну строчку
А можно поподробнее про это? Может, даже статью?
Upd: Хотя вот нашел https://habr.com/ru/articles/586724/ - это оно?
Это старая моя статья)
Да, имею в виду их. Можете поэксперементировать и сравнить планы запросов, написанных на использовании стандартных функций org.apache.spark.sql.functions (не важно DataFrame API или Spark SQL - они и там и там одни и те же "под капотом") и через UDAF. Сравнивать при этом надо конечно-же не простые астандарные агрегации. В прнципе на учебном примере с популярным словом из твитов из упомянутой статьи уже видна разница в плане - попробуйте реализовать поиск самого популярного слова на SQL и сравните план с реализацией на UDAF из статьи.
Вот именно, что когда данные не строго структурированные, тогда и начинается всё самое интересное.
Но таких кейсов на порядок меньше, чем со схемой, вот и выросло поколение, которое не умеет в интересное, потому как оно ему не нужно.
Еще поните, что при использовании SparkSQL все syntax errors и analysis errors проявятся только в рантайме, в то время, как использование DataSet - при компиляции (ну и промежуточный вариант - DataFrame - syntax errors при компиляции, а analysis errors - в рантайме)
Я это почувствовал еще несколько лет назад, когда вдруг осознал, что уже долго не могу найти какой-либо продвинутый контент не только по Spark, но и вообще для Data Engineer
Так поменяйте "spark" на что угодно и ситуация не изменится. На медиуме на серьезных щщах в 2023 году рассказывают, что такое стримы в джаве. Фича в 2014 вышла, на минуточку.
Почти весь контент по чему угодно - перепечатки мануалов. Хочется глубже - уже надо читать книги и смотреть конфы. Еще глубже - стараться попасть в коллективы, где задачи уровня hard. И по-другому вряд ли будет.
Есть курс "Инженер данных" у одного крупного образовательного проекта, который ещё и ИТ компания. В курсе смешано много технологий и спарк там рассматривается в середине курса. В плане спарка там инфа была для меня самая интересная из многого, что я видел: много про оптимизацию джоб, чтобы они запускались на больших датасетах, а её игрушка. Это было похоже на подытожевания разрозненных фактов, которые я изучил на опыте.
Если есть желание - давайте организуем телеграм / дискорд чат для обсуждения более серьезных вещей и внутренней реализации. Я разрабатываю и поддерживаю коннектор Spark для Tarantool и мне тоже очень не хватает литературы и обмена мнениями. Фактически единственное, чем остаётся пользоваться - это документация Spark Internals (сильно устаревшая местами и неполна) и исходники.
Я попытался немного исправить ситуацию, и сделал доклад по внутренней части Spark по результатам своих раскопок (https://jpoint.ru/talks/84b0f81d9de64bf2a0ea2d20e1304bd1/) - надеюсь, этот материал можно будет улучшить и развить до новой версии Spark Internals.
Пишите в личку или в другие контакты, буду рад.
https://t.me/hadoopusers — почти 5к участников. Уровень разный, есть очень опытные товарищи. Если хотите аудиторию, начните оттуда.
Как показывает практика, лучше старого-доброго форума для обсуждения "более серьезных веще" ничего не придумано пока...
Я это почувствовал еще несколько лет назад, когда вдруг осознал, что уже долго не могу найти какой-либо продвинутый контент не только по Spark, но и вообще для Data Engineer’ов.
Более того, ситуация на самом деле еще критичнее. Добавлю мои 5 копеек в общую копилку. После некоторого, довольно солидного по времения стажа (более 3 лет) работы со Spark мне как-то пришло в голову, а не поискать ли, что предлагают не курсы, а вполне солидные ВУЗы под катом "бакалавриат" или даже "магистратура" по этой теме. Догадайтесь с первого раза, что я нашел? Причем я подробно раскапывал ссылки на учебные программы, вытаскивал их, а иногда и запрашивал подробности через контакты ВУЗов. Нашел те же самые базовые + средние знания, мало привязанные к практике и без подробных глубоких продуктовых use cases в процессе обучения. Печально, но в ВУЗах тот же не очень высокий уровень, что и на умеренно длинносрочных курсах. Так пока что ничего и не выбрал, что могло бы мне помочь глубже, чем просто доступная литература на английском и чтение документации + поисковики по запросам. А очень хотелось получить дорожную карту иного уровня, не "как стать мидлом с нуля за полгода-год", а что-то вроде "50 примеров продуктовой разработки высочайшего уровня для senior-ов, которые хотят стать экспертами". Печалька. Грустно жить на этом свете, господа. Понятно, что собственный путь в продуктиве неизбежно приведет к заданной цели, но хотелось бы получить сильно сокращенную "королевскую дорогу" в суперпродвинутый Spark, пусть даже и ценой солидных денег за обучение и собственных учебных усилий. Учебных программ, неважно - курсов или вузовских, именно такого уровня катастрофически не хватает.
Да, понимаю вас. Тоже по крупицам собираю из собственных проектных кейсов и найденных решений, редких обрывков в интренете, подсмотренного на проектах кода (или случайно увиденного на гитхабе у кого-то) в личную коллекцию набор удачных примеров, кейсов и подходов, которые, как мне кажется, должен знать и исопльзовать Сеньор.
Вы искали бакалавриат/магистратуру именно по Spark? Не знаю, бывает ли такое вообще по отдельно взятой технологии. Но думаю, что в UC Berkeley что-то точно должно быть - там создатели спарка работают, но это будет просто частью какой-нибудь Computer Science программы.
"50 примеров продуктовой разработки высочайшего уровня для senior-ов, которые хотят стать экспертами"
Такое изучается только в компаниях, которые эти продукты разрабатывают, и не 50, а 1-2.
Spark не для чайников: где?