Занятия. Менторство. Консультации.

"Поступашки" проводят индивидуальные/ групповые занятия, менторство и консультации по подготовке к собеседованиям по дисциплине Data Engineering. В эту дисциплину входят такие темы и инструменты как: Hadoop, Spark, SQL, NoSQL, Airflow, Python для разработки пайплайнов и обработки больших данных.

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

Гарантии
Наш проект существует уже более 10 лет. У наших преподавателей очень богатый человеческий капитал: академики всех наук, большой преподавательский стаж, опыт работы в коммерции (как квант, аналитик и тд) или в разработке.

Цена
Цена очень доступная и является одной из самых низких на рынке для сегмента карьеры в другом месте за индивидуальный подход и авторские материалы с вас сдерут в 2 раза больше, а в других местах вас будут учить по общедоступным задачам и материалам из интернета, создавая иллюзию подготовки, хотя в карманах таких преподавателей оказываются вполне реальные ваши деньги.
Цена наших курсов определяется следующим образом

— 2500 рублей за час индивидуальных занятий;
— 1500 рублей за час занятий в паре с одного ученика;
— 1200 рублей за час занятий в группе из трёх человек

Лучший вариант для групповых занятий: взять к себе в напарники коллегу/ однокурсника или знакомого. Это позволяет обеспечить сплочённость группы и сопоставимый уровень учеников. Также отмечу, что занятия включают себя программу менторства: вы получаете материалы, дз, поддержку преподавателя и тд.

Менторство
Также если занятия вам сильно не по карману, то есть вариант менторства: примерно каждую неделю или по мере продвижения вам высылают теоретические материалы и задачи под ваш уровень и цель, отвечают на любые вопросы и проверяют решения задач (ежедневная связь). Общение происходит только текстом/войсами (созвониться можно лишь по стандартной ставке). Стоимость менторства: 10000 рублей за 4 недели.

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

Пробное собеседование
Для тех, кто хочет получить реальный боевой опыт в прохождении собеседований по конкретной секции в конкретные компании от ведущих специалистов, которые сами провели десятку собесов (прошли еще больше). После собеседования вы получите внимательный анализ вашего уровня, код ревью и оценку шансов на успешное прохождение, а также все инсайды и советы как увеличить эти шансы. Стоимость 3000 рублей за собеседование.

По всем вопросам и записи на занятия: @postypashkaDE

Какие технологии Big Data стоит изучать в 2025 году?

Новый год уже наступил, какие же технологии изучать, чтобы оставаться востребованным специалистом и модным-молодежным? Давайте же разберемся!

Основная тройка для Big Data остается также неизменной:
⚡️ Apache Spark
Spark остается одним из главных инструментов для распределенной обработки данных. Конечно, появляются и другие фреймворки для похожих задач, но Spark уже проверен временем, поддерживается и регулярно дорабатывается такими крупными компаниями, как Databricks и Snowflake, так что в ближайшее время он никуда не уйдет.
🐘 Hadoop
Хотя я и слышал мнение, что Hadoop "умирает", он продолжает использоваться практически во всех крупных компаниях в различных сборках, и ему трудно предложить замену благодаря его надежности и стабильности, в обозримой перспективе вряд ли его что-то заменит.
💠Apache Airflow
Airflow является основным инструментом для оркестрации процессов, отслеживания их выполнения, он активно развивается, и в него активно добавляются новые фичи, так что он скорее всего так и останется самым популярным решением благодаря своей простоте, нативности и удобству.
А теперь перейдем к технологиям поновее. Начнем с двух СУБД, которые на данный момент чаще всего встречаются на российском рынке: Greenplum и Clickhouse.
🔎 ClickHouse
Стал популярным благодаря открытости кода и скорости своей работы. Он активно развивается нашими друзьями из Яндекса, сообщество очень живое и сам Clickhouse активно внедряется и используется во многих компаниях.
🍃 Greenplum
Также стал популярным благодаря открытости кода, но в этот раз был подхвачен ребятами из Arenadata и Т-Банка. Greenplum является распределенной СУБД, которая может хранить и обрабатывать огромные объемы данных, работает стабильно, и сейчас кластер Greenplum стоит в любом банке.
🌐 Trino
Довольно новый инструмент, который начали внедрять компании, решившие сделать у себя Data Lakehouse. Trino позволяет обрабатывать данные из различных источников, включая S3, HDFS и базы данных, не перенося их в единое хранилище, и делает это очень быстро.
💾 S3 и объектные хранилища
Хотя Amazon и ушел из России, S3 и облачные решения остаются стандартом для хранения больших объемов данных благодаря своей надежности, низкой стоимости и интеграции с инструментами Big Data, и сейчас S3 предоставляют такие компании, как Яндекс, ВК, Cбер. В сочетании с такими технологиями, как Trino, S3 становится одним из решений для замены Hadoop.
Кроме того, облачные решения часто используют небольшие компании, поскольку это является более дешевым и оптимизированным решением, чем покупать себе сервера и ставить все самим.

Это лишь часть всего того, что может использовать Data Engineer, и я буду продолжать рассказывать вам об этом зоопарке в следующих постах, а пока ставьте огонечки и делитесь вашим мнением в комментариях😎

@bigdata_postupashki

Задача с секции Аналитики Яндекс
Дана таблица с сообщениями пользователей messages, где колонками являются:
message_id — айдишник сообщения
sender_id — айдишник отправителя
receiver_id — айдишник получается
reply_message_id — айдишник того сообщения, для которого данное является ответом (может быть null, если это первое сообщение)
Нужно найти наибольшую длину треда (последовательноти сообщений, которые отвечают последовательно друг на друга) для каждого пользователя.
Пример:
message_id, sender_id, receiver_id, reply_message_id
7 3 4 null
17 4 3 7
В этом случае для пользователей 3 и 4 максимальной длиной треда будет 2, т.к. в треде всего 2 сообщения (7 -> 17)
Решение:
Подобные задачи на поиск глубины чего-либо лучше решать с помощью рекурсивной cte. В ней отбираем в начале первое сообщение (reply_message_id = NULL) и после этого производим JOIN c самой собой по ключам message_id и reply_message _id (т.к. все NULL случаи мы отобрали, то переджоинятся только сообщения, которые являются ответами друг на друга). В результате получим таблицу с последовательной длиной тредов для каждой пары sender_id, receiver_id и останется только объединить повторяющиеся пары и сгруппировать, чтобы отобрать максимальную длину треда.
Код решения с собеседования в комментариях.


А еще больше задач сможете увидеть и научиться решать на курсе по инженерии данных. Всех ждем и всем рады, товарищи 😎 А еще поставьте огоньки, если интересно еще больше таких задач с собеседований

@bigdata_postupashki

SQL на стажировку в Т-банк

Дедлайн 30 января. Ответы на тест по SQL, условие, а ответы ниже:

1. LEFT, RIGHT, FULL (1,2,4)
2. SELECT(1), FROM(2),WHERE(3),GROUP BY(4), HAVING(5), ORDER BY(6)
3. 2
4. 5
5. 2
6. 3
7. 3
8. 3
9.
3 — SELECT emp_id FROM staffinfo WHERE emp_nm = “Petrov” AND end_dt is null
7 — SELECT emp_id FROM staffinfo WHERE emp_nm = “Petrov” INTERSECT SELECT emp_id FROM staffinfo WHERE end_dt is null
10. 4

А разбор задач уже на нашем курсе дата инженер.

@bigdata_postupashki

⚡️ Почему тебе нужно изучать Spark?! 😎

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

Полезные статьи:
Apache Spark… Это база – как понятно из названия, это самая база для понимания с примерами взаимодействия
Big Data: Анализ данных с помощью Apache Spark – практическое руководство по Spark SQL, включая агрегатные функции и работу с DataFrame.
Как отслеживать и анализировать задания Spark — руководство по тому, как работать со Spark UI, анализировать выполнение вашего запроса и прочие очень полезные штуки.
Как работает Join в Apache Spark SQL — база по развенчанию магии внутренней работы Spark c Join
A Comprehensive Guide to Optimizing Spark Queries – хорошая статья для того, чтобы понять, какие могут быть проблемы при обработке больших данных и как их избегать.
Практика использования Spark SQL – очень полезная статья из практики, в которой рассказаны стратегии ускорения аналитических запросов и избегания ошибок.
Руководство по Apache Spark не для начинающих — продвинутым методы оптимизации производительности Spark, включая управление схемой данных, кэширование, управление партициями и выбор эффективных операций.

Если хотите больше материалов о технологиях для работы с большими данными, ставьте огоньки 🔥
Также про это все и больше будет на нашем курсе по дата инженерии

@bigdata_postupashki

Курс по аналитике стартует уже в это воскресение (еще можно записаться)! Как материал для подготовки записаны вот такие вводные уроки, где разбираем всю необходимую теорию на конкретных примерах, задачах из тех же самых собесов и рабочих кейсов. Такие вводные уроки дополняют и расширяют материал каждого занятия в 2 раза. Ведь Поступашки реально хотят научить ребят, дать им качественное образование, а не просто взять деньги и послать куда подальше!!

💠 Почему тебе нужно изучать Apache Airflow?
Apache Airflow давно стал стандартом в мире Big Data и MLOps. Его используют дата-инженеры, ML-инженеры, аналитики и дата-сайентисты как для построения ETL-пайплайнов, так и для сборки отчетов, и обучения моделей машинного обучения, и мониторинга за этими процессами.
Поэтому каждому будет полезно узнать про него, и для этого решил подготовить пост с подборкой материалов для безболезненного знакомства 😎

Что же классного в Airflow?
Простота — написан на Python, легко интегрируется с другими инструментами
Наглядность — удобный UI для мониторинга и отладки DAG'ов.
Гибкость — поддержка множества плагинов, которых написали огромное количество для всех ситуаций, и возможность легко сделать свой, если не нашел подходящий

Статьи:
Все, что нужно знать об Airflow (Часть 1, Часть 2, Часть 3) – Целая серия статей, посвященная Airflow, и затрагивающая практически все темы: введение в архитектуру, ключевые компоненты и концепции, создание и настройка DAGs, операторы, сенсоры и много всего еще, довольно исчерпывающий гайд.
Лучшие практики дата-инженера по работе с Airflow – Как писать DAG’и правильно, оптимизировать их исполнение и избегать типичных ошибок.
Как и любую технологию, Airflow хорошо бы самому пощупать, поэтому следующие две статьи как раз про это: Быстрый старт с Apache Airflow – Настройка и запуск Airflow с нуля с примерами кода.
Написание первого DAG – Подробное руководство по созданию DAG
Что такое Airflow Executor и Executors in Apache-Airflow — хорошие статьи для тех, кто хочет чуть побольше узнать о том, как работает Airflow внутри
Также факультативно рекомендую разобраться с такой интересной темой, как написание своих операторов, для этого могу порекомендовать сразу несколько статей: раз, два, три, четыре

Курсец
Курсов по этой технологии не так много, еще меньше бесплатных, поэтому могу порекомендовать один хороший Apache Airflow 2.2, где подробно разбираются ключевые концепции Airflow, принципы работы DAGs, взаимодействие с API, сенсоры и т.д. на довольно свежей версии.

А если хотите еще больше материалов, то ставьте огоньки и реакции под этим постом!
Также про Airflow, и не только про него, будет рассказываться на нашем курсе по дата инженерии

@bigdata_postupashki

Мой путь вката в Биг Дату

Так как сейчас активно идет набор на стажировки, я решил рассказать вам, как происходил мой путь вкатывания в айти в целом и в дата-инженерию в частности. Откинем курсы и прочее обучение, смотря на реальный опыт

На третьем курсе ВМК я начал задумываться о том, чтобы начать уже получать реальные практические навыки, потому что одним обучением в вузе я вряд ли смогу этим добиться. Я пробовался на различные стажировки: всем известные Тинькофф, Яндекс, Сбер и менее известные компании на самые хайповые направления: аналитика, дата саенс и в целом все, что связано с данными, потому что это мне нравилось и чувствовал, что это мое.
И в один момент прошел на стажировку Spark-разработчика, иначе говоря — Дата Инженера, в одной консалтинговой компании, где вначале шло обучение, а после, в случае успешной сдачи экзамена и дополнительных собеседований — прием в штат.
Конечно же поначалу всё казалось сложным: распределённые вычисления, кластеры, партиции, обучение Scala, Hadoop, Spark с нуля. Но, пройдя все эти этапы, успешно справился со всем, и после этого начал работать на проекте ВТБ, где набрался опыта реальной разработки ETL, занимался сборкой витрин и работой с продуктовыми большими данными.
С тех пор дата-инженерия и биг дата стали моими родными сферами. После этого уже я спокойно переходил на работу непосредственно в банки — тот же ВТБ и Сбер, и ритейлы — Ozon и текущее место работы

Что же я хочу сказать этим постом?
Не всегда стоит начинать с самых известных компаний — очевидно, конкуренция и уровень нагрузки будут запредельными, так что можно рассмотреть те же консалтинги, которые специализируются на том, чтобы активно набирать людей
Не стоит также ограничиваться одним направлением — на начальном этапе ты не знаешь, в чем ты действительно хорош и чем будешь заниматься в реальности. И с опытом смежной профессии перейти в другую будет легче, чем пытаться честно с 0 пройти весь путь, и, как правило, в рамках одной компании это сделать проще.

Если у вас остались вопросы задавайте их в комментариях и ставьте реакции!
Ну а если хочешь получить помощь в подготовке к собеседованиям и обучению, то рекомендую записываться на наши консультации!

@bigdata_postupashki

ETL vs ELT

Друзья, после небольшого перерывчика начинаем новую серию постов, в которых мы будем рассматривать всякие теоретические аспекты, которые помогут вам как просто лучше разобраться, так и круто отвечать на собесах 😎
Сегодня у нас на разборе самая база в Больших данных, шесть крутых букв — ETL и ELT. Куда бы вы не попали, везде работа с данными и хранилища будут устроены в одной из этих парадигм. Ну давайте же разбираться!

ETL
Происходит от трех слов(Extract, Transform, Load) – это классический подход к обработке данных, когда данные извлекаются из источников (из различных БД, CRM систем и прочих 1С-ов), затем обрабатываются на промежуточном уровне (Informatica, Debezium, SAP DS) и только после этого загружаются в основное хранилище данных, например, Greenplum, Clickhouse или Postgres.
Такой подход удобен для сценариев, где важны контроль качества данных, строгие схемы и подготовленные агрегированные данные.
Звучит круто, но очевидно, у данного метода есть недостатки, и они довольно очевидны: возникает узкое место в трансформации данных, т.к. приходится сразу чистить от дубликатов, приводить к одной схеме и т.д. И кроме этого эта промежуточная зона должна успевать обрабатывать огромное количество данных!
Поэтому возник другой подход к выстраиванию процессов.

ELT
Как можно понять — это перестановка предыдущих слов: Extract, Load, Transform.
ELT более гибкий метод, при котором сырые данные сначала загружаются в хранилище, а потом уже обрабатываются внутри него и загружаются в целевое хранилище. Такой подход характерен для облачных решений и аналитических платформ, например, в Yandex Cloud/Snowflake/Amazon S3, а также наш любимый Hadoop, где данные можно загружать без предварительной очистки, преобразовывать их внутри, а после этого загружать в тот же Greenplum, Clickhouse(но бывает и без загрузки, мы позже поговорим про подход Data Lakehouse). Плюсы тут понятны: данные у нас всегда доступны, особенно при отслеживании истории(этому помогает SCD, или же Slow Changing Dimensions, тоже очень интересная тема, которую мы рассмотрим в дальнейшем), их можно переиспользовать в будущем без дополнительной нагрузки на источники.

На собеседованиях часто спрашивают, какой подход чаще используется и тут можно смело отвечать, что это ELT: в большинстве компаний используются классическую схему с загрузкой данных в Data Lake, а после этого загрузкой в Data Warehouse.
Также могут спросить минусы у ELT подхода и их два основных: нужно держать целых два хранилища, одно из которых может начать бесконтрольно расти и хранить в себе кучу бесполезных данных, если должным образом не подходить к их хранению.
Из инструментов для ELT чаще всего используют связку Airflow + Spark, Flink и похожие фреймворки для оркестрации и загрузки

Пишите ваши вопросы в комменты, а если хотите продолжения постов про архитектуру построения хранилищ, ставьте реакции и записывайтесь на наши курсы по дата инженерии
Есть еще куча тем, которые мы рассмотрим 😎

@bigdata_postupashki

Интересная задачка с собеседования
Вы работаете со Spark, делаете преобразования над таблицами, но задача валится по OutOfMemory, как решить эту проблему без увеличения общего количества памяти?
Решение
1. Отрегулировать количество партиций
Делается это несколькими способами:
- spark.sql.shuffle.partitions: <количество партиций>
За что отвечает данный параметр: перед запуском shuffle операции Spark все данные распределит в количество партиций, равное числу в этом параметр(по дефолту оно 200). Поэтому, если данных у вас ну уж очень много, то партиции могут стать очень жирными и не влезать в память => надо их количество увеличить
- repartition(<количество партиций>)
Происходит тоже самое, но нужно это делать вручную перед shuffle(например, перед join-ом)
2. Использование Broadcast Join
Broadcast Join работает по очень просто принципу: перемещает меньший датасет(его размер можно установить до 8 Gb) к партициям большого и соединяте, что позволяет избежать shuffle операции.
Но если один из датасетов > 8 гигов, лучше его отключить с помощью параметра
spark.sql.autoBroadcastJoinThreshold: -1
3. Уменьшение количества executor
Допустим, у нас 10 экзекьюторов по 8 гигов и 5 ядер каждый, и при выполнении на них спарк задачи происходит OOM, тогда, можно сделать вместо 10 — 5, но выделить на каждый не по 8 гигов памяти, а 16, и 10 ядер. Общая параллельность не изменится, но партиции начнут влезать в память.
А как бы вы решали данную задачку пишите в комменты 😎
Чтобы узнать больше о работе Spark подписывайтесь на канал, ставьте реакции, а также записывайтесь на наши курсы

@bigdata_postupashki