🛠 Как я стал дата-инженером? Как вкатиться?
Хочу поделиться своей историей перехода в мир дата-инженерии — возможно, кого-то это вдохновит и поможет сделать первые шаги 🤝
💡 Изначально меня привлекал Data Science с точки зрения ML - обучение моделей, участие в хакатонах по компьютерному зрению, ранжированию и NLP 🤖. Я активно изучал ML, экспериментировал и набирался опыта.
Но всё изменилось, когда я устроился в геномный центр 🧬. Именно там я впервые столкнулся с инженерной стороной данных. Вокруг были свои форматы, специфичные инструменты и оркестраторы, разработанные специально для работы с геномными данными. Объёмы данных были по-настоящему впечатляющими: более 10 000 человеческих геномов (каждый весом около 100 ГБ), хранившихся на ленточных хранилищах 📼.
🧩 Там я начал писать свои первые пайплайны — настраивал сбор и обработку данных. Постепенно понял, что такая разработка мне реально нравится. Даже больше, чем обучение моделей. Было интересно копаться в инструментах, разбираться, как всё устроено, и делать так, чтобы система работала чётко и надёжно. Именно тогда я и решил двигаться в сторону дата-инженерии.
📚 Чтобы вкатиться по-настоящему, мне пришлось подтянуть базовые навыки:
✅ SQL — базовый навык, который спрашивают на каждом собеседовании. Отличный интерактивный курс на Stepik помог разобраться с этим языком запросов.
✅ Python — умение писать простенькие алгоритмы, знать основы структур данных и объектно-ориентированного программирования. Здесь очень помогли открытые курсы от МФТИ по алгоритмам и структурам данных и ООП(с 5ого по 9ый модули) , хорошо бы освоить хотя бы на теории.
✅ Решение задач уровня medium на Leetcode — отличный способ подготовиться к собеседованиям и улучшить алгоритмическое мышление.
✅ Чтение статей про HDFS, Airflow, СУБД, Spark — чтобы понять, с какими инструментами приходится работать в реальной инженерной практике. О них всех и о том какие этапы я проходил расскажу в следующих постах.
Об этих всех инструментах и о том, какие собеседования я проходил я расскажу в следующих постах.
Если вам интересно узнать — ставьте 🔥, и я с радостью поделюсь подробностями!
Хочешь стать дата-инженером и нужна помощь? Переходи на https://dataengineers.pro/mentors/artyompodvalny
Хочу поделиться своей историей перехода в мир дата-инженерии — возможно, кого-то это вдохновит и поможет сделать первые шаги 🤝
💡 Изначально меня привлекал Data Science с точки зрения ML - обучение моделей, участие в хакатонах по компьютерному зрению, ранжированию и NLP 🤖. Я активно изучал ML, экспериментировал и набирался опыта.
Но всё изменилось, когда я устроился в геномный центр 🧬. Именно там я впервые столкнулся с инженерной стороной данных. Вокруг были свои форматы, специфичные инструменты и оркестраторы, разработанные специально для работы с геномными данными. Объёмы данных были по-настоящему впечатляющими: более 10 000 человеческих геномов (каждый весом около 100 ГБ), хранившихся на ленточных хранилищах 📼.
🧩 Там я начал писать свои первые пайплайны — настраивал сбор и обработку данных. Постепенно понял, что такая разработка мне реально нравится. Даже больше, чем обучение моделей. Было интересно копаться в инструментах, разбираться, как всё устроено, и делать так, чтобы система работала чётко и надёжно. Именно тогда я и решил двигаться в сторону дата-инженерии.
📚 Чтобы вкатиться по-настоящему, мне пришлось подтянуть базовые навыки:
✅ SQL — базовый навык, который спрашивают на каждом собеседовании. Отличный интерактивный курс на Stepik помог разобраться с этим языком запросов.
✅ Python — умение писать простенькие алгоритмы, знать основы структур данных и объектно-ориентированного программирования. Здесь очень помогли открытые курсы от МФТИ по алгоритмам и структурам данных и ООП(с 5ого по 9ый модули) , хорошо бы освоить хотя бы на теории.
✅ Решение задач уровня medium на Leetcode — отличный способ подготовиться к собеседованиям и улучшить алгоритмическое мышление.
✅ Чтение статей про HDFS, Airflow, СУБД, Spark — чтобы понять, с какими инструментами приходится работать в реальной инженерной практике. О них всех и о том какие этапы я проходил расскажу в следующих постах.
Об этих всех инструментах и о том, какие собеседования я проходил я расскажу в следующих постах.
Если вам интересно узнать — ставьте 🔥, и я с радостью поделюсь подробностями!
Хочешь стать дата-инженером и нужна помощь? Переходи на https://dataengineers.pro/mentors/artyompodvalny
Stepik: online education
Интерактивный тренажер по SQL
В курсе большинство шагов — это практические задания на создание SQL-запросов. Каждый шаг включает минимальные теоретические аспекты по базам данных или языку SQL, примеры похожих запросов и пояснение к реализации.
🔥22❤8😁6🤮1
Data Engineer Lab pinned «🛠 Как я стал дата-инженером? Как вкатиться? Хочу поделиться своей историей перехода в мир дата-инженерии — возможно, кого-то это вдохновит и поможет сделать первые шаги 🤝 💡 Изначально меня привлекал Data Science с точки зрения ML - обучение моделей, участие…»
Data Engineer Lab pinned «Всем привет! Меня зовут Артем Подвальный, я Data Engineer в Ozon Tech. Моя основная специализация – инженерия данных, в том числе подготовка датасетов для обучения моделей поиска. До этого я работал Data Engineer'ом в SMlab, где занимался инженерными задачами…»
🚀 Как я получил оффер на джуна в ML ?
Возвращаясь к предыдущему посту — я упоминал, что изначально меня привлекал Data Science с уклоном в ML. Поэтому не могу сказать, что сразу отказался от этого направления.
У меня был выбор между ML и Data Engineering, и я проходил собесы на джуна по обоим направлениям.
Однажды наткнулся на вакансию по Computer Vision в Telegram-канале. Составил резюме, написал в личку HR — и меня пригласили на техэтап. Я приятно пообщался с тимлидом около часа, решил задачки, ответил на все его вопросы — и вскоре после собеса я получил оффер 🎉
Теперь — что мне реально помогло, и что стоит знать, чтобы пройти собесы по ML.
Давайте по порядку 👇
🐍 1. Python и алгоритмы
Нужны везде. Это база.
📌 Я выше уже делился хорошими курсами постом выше — обязательно посмотрите, если ещё нет.
📈 2. Статистика и теория вероятностей
Если собеседование связано с классическим ML, то темы статистики и теории вероятностей почти всегда поднимаются.
Примеры типичных вопросов по статистике и теории вероятностей.
Они помогут вам не только подготовиться, но и выявить пробелы. Просто прочитайте и попробуйте решить — станет понятно, на чём стоит сосредоточиться
📘 3. Теория ML
Очень рекомендую учебник Яндекса по ML. Всё супер понятно.
‼️ Обращайте внимание на метрики! Их спрашивают на всех уровнях(от стажера до сеньора) — просто с разной глубиной.
🎯 4. Углубление в направление
После того, как вы освоите базу, имеет смысл выбрать конкретное направление, в котором хотите развиваться.
Наиболее популярны — Computer Vision (CV) и Natural Language Processing (NLP). Именно по ним проще найти курсы, соревнования и вакансии для джунов.
Однако, это далеко не всё. Есть и другие не менее интересные области — например, рекомендательные системы, временные ряды, обработка табличных данных, временные ряды, и т.д. Выбор зависит от ваших интересов и целей.
По NLP могу посоветовать отличный курс и репозитории — сам им пользовался, также у этих авторов были записи на ютубе( надеюсь остались).
🧑🏫 5. Про CV отдельно
Отдельно выделю курс от ШАДа, он очень понятный.
Я не решал ноутбуки, просто смотрел лекции — но и этого оказалось достаточно.
😲 Интересно, что многие вопросы на собесе были точь-в-точь как кейсы, которые рассматривал лектор, так что — must-watch!
🏆 6. Хакатоны и Kaggle
Очень рекомендую участвовать в хакатонах и соревнованиях на Kaggle.
На момент собесов у меня было уже 3–4 участия, две из которых — студенческие хакатоны от этого сообщества
Они регулярно анонсируют интересные мероприятия — советую следить.
📌 Такие соревнования реально считаются за полноценный проект, и работодатели обращают на это внимание. Даже просто участие — отличная строчка в резюме.
Если вы только начинаете путь в ML не бойтесь, всё реально. Главное системность и интерес к теме. Ставьте 🔥 если пост был для вас полезным.
Пишите вопросы в комментариях💬
Возвращаясь к предыдущему посту — я упоминал, что изначально меня привлекал Data Science с уклоном в ML. Поэтому не могу сказать, что сразу отказался от этого направления.
У меня был выбор между ML и Data Engineering, и я проходил собесы на джуна по обоим направлениям.
Однажды наткнулся на вакансию по Computer Vision в Telegram-канале. Составил резюме, написал в личку HR — и меня пригласили на техэтап. Я приятно пообщался с тимлидом около часа, решил задачки, ответил на все его вопросы — и вскоре после собеса я получил оффер 🎉
Теперь — что мне реально помогло, и что стоит знать, чтобы пройти собесы по ML.
Давайте по порядку 👇
🐍 1. Python и алгоритмы
Нужны везде. Это база.
📌 Я выше уже делился хорошими курсами постом выше — обязательно посмотрите, если ещё нет.
📈 2. Статистика и теория вероятностей
Если собеседование связано с классическим ML, то темы статистики и теории вероятностей почти всегда поднимаются.
Примеры типичных вопросов по статистике и теории вероятностей.
Они помогут вам не только подготовиться, но и выявить пробелы. Просто прочитайте и попробуйте решить — станет понятно, на чём стоит сосредоточиться
📘 3. Теория ML
Очень рекомендую учебник Яндекса по ML. Всё супер понятно.
‼️ Обращайте внимание на метрики! Их спрашивают на всех уровнях(от стажера до сеньора) — просто с разной глубиной.
🎯 4. Углубление в направление
После того, как вы освоите базу, имеет смысл выбрать конкретное направление, в котором хотите развиваться.
Наиболее популярны — Computer Vision (CV) и Natural Language Processing (NLP). Именно по ним проще найти курсы, соревнования и вакансии для джунов.
Однако, это далеко не всё. Есть и другие не менее интересные области — например, рекомендательные системы, временные ряды, обработка табличных данных, временные ряды, и т.д. Выбор зависит от ваших интересов и целей.
По NLP могу посоветовать отличный курс и репозитории — сам им пользовался, также у этих авторов были записи на ютубе( надеюсь остались).
🧑🏫 5. Про CV отдельно
Отдельно выделю курс от ШАДа, он очень понятный.
Я не решал ноутбуки, просто смотрел лекции — но и этого оказалось достаточно.
😲 Интересно, что многие вопросы на собесе были точь-в-точь как кейсы, которые рассматривал лектор, так что — must-watch!
🏆 6. Хакатоны и Kaggle
Очень рекомендую участвовать в хакатонах и соревнованиях на Kaggle.
На момент собесов у меня было уже 3–4 участия, две из которых — студенческие хакатоны от этого сообщества
Они регулярно анонсируют интересные мероприятия — советую следить.
📌 Такие соревнования реально считаются за полноценный проект, и работодатели обращают на это внимание. Даже просто участие — отличная строчка в резюме.
Если вы только начинаете путь в ML не бойтесь, всё реально. Главное системность и интерес к теме. Ставьте 🔥 если пост был для вас полезным.
Пишите вопросы в комментариях💬
Telegram
Phystech.Career
Career chanel
🔥17👍6😁4💩2❤1🤮1🤡1
🎛 Что такое оркестратор данных и зачем он вообще нужен?
Оркестратор — это как дирижёр в мире сервисов и задач. Он управляет их запуском, следит, чтобы всё шло по плану, масштабирует, перезапускает упавшее и показывает красивую визуализацию 💡
Без него автоматизация, стабильность и масштаб — просто невозможны.
🔧 Что умеет оркестратор:
⚙️ Автоматизирует рутину — ETL, моделирование, деплой
📦 Управляет контейнерами (Docker, Kubernetes)
🔍 Следит за задачами — мониторинг, логирование, алерты
🔐 Обеспечивает безопасность — доступы, роли, шифрование
🧩 Интегрируется с чем угодно — CI/CD, базы, системы аналитики
📌 Где применяют:
🔬 Биоинформатика
Первый оркестратор с которым я познакомился — WDL от Broad Institute. Вся логика пайплайна задаётся текстом, визуализации почти нет, но зато удобно для сложных задач вроде GATK или RNA-seq. Работает через Cromwell — и локально, и в облаке ☁️
💼 В индустрии
В SMlab (Спортмастер) я впервые попробовал Airflow — и это было откровение.
Визуальный интерфейс, удобные DAG'и, отслеживание ошибок, ручной перезапуск — работать с пайплайнами стало гораздо легче.
Использовал его для автоматизации SQL-расчётов, ETL и запуска приложений, которые отслеживают поведение пользователей в рекомендательных системах.
🎯 Рекомендательные системы
Оркестратор управляет сбором фичей, переобучением моделей, логированием, A/B-тестами и выкладкой в прод.
Сейчас через Airflow собираю пользовательские данные ежедневно — чтобы датасеты всегда были свежими.
☁️ DevOps и облако
Всё, что связано с микросервисами, CI/CD, безостановочными обновлениями — это тоже зона ответственности оркестратора.
Инструменты: AWS ECS/EKS,и др.
🚀 Популярные оркестраторы:
• Apache Airflow — лидер в Data/ML/ETL
• Prefect — современный, python-friendly, вот его сравнение с Airflow
• WDL + Cromwell — стандарт в геномике
• KubeFlow — для Kubernetes-сред
• Luigi — проверенный временем
💬 Почему важно разбираться:
Оркестратор — это основа современной data-инфраструктуры.
Хочешь автоматизировать процессы, не бояться падений, легко масштабироваться и не держать всё в голове — без оркестратора не обойтись.
В следующих постах расскажу про Airflow подробнее.Понравился пост? Ставьте реакции🔥, пишите комментарии)
#оркестратор #dataengineering #airflow #etl #автоматизация #bigdata
Оркестратор — это как дирижёр в мире сервисов и задач. Он управляет их запуском, следит, чтобы всё шло по плану, масштабирует, перезапускает упавшее и показывает красивую визуализацию 💡
Без него автоматизация, стабильность и масштаб — просто невозможны.
🔧 Что умеет оркестратор:
⚙️ Автоматизирует рутину — ETL, моделирование, деплой
📦 Управляет контейнерами (Docker, Kubernetes)
🔍 Следит за задачами — мониторинг, логирование, алерты
🔐 Обеспечивает безопасность — доступы, роли, шифрование
🧩 Интегрируется с чем угодно — CI/CD, базы, системы аналитики
📌 Где применяют:
🔬 Биоинформатика
Первый оркестратор с которым я познакомился — WDL от Broad Institute. Вся логика пайплайна задаётся текстом, визуализации почти нет, но зато удобно для сложных задач вроде GATK или RNA-seq. Работает через Cromwell — и локально, и в облаке ☁️
💼 В индустрии
В SMlab (Спортмастер) я впервые попробовал Airflow — и это было откровение.
Визуальный интерфейс, удобные DAG'и, отслеживание ошибок, ручной перезапуск — работать с пайплайнами стало гораздо легче.
Использовал его для автоматизации SQL-расчётов, ETL и запуска приложений, которые отслеживают поведение пользователей в рекомендательных системах.
🎯 Рекомендательные системы
Оркестратор управляет сбором фичей, переобучением моделей, логированием, A/B-тестами и выкладкой в прод.
Сейчас через Airflow собираю пользовательские данные ежедневно — чтобы датасеты всегда были свежими.
☁️ DevOps и облако
Всё, что связано с микросервисами, CI/CD, безостановочными обновлениями — это тоже зона ответственности оркестратора.
Инструменты: AWS ECS/EKS,и др.
🚀 Популярные оркестраторы:
• Apache Airflow — лидер в Data/ML/ETL
• Prefect — современный, python-friendly, вот его сравнение с Airflow
• WDL + Cromwell — стандарт в геномике
• KubeFlow — для Kubernetes-сред
• Luigi — проверенный временем
💬 Почему важно разбираться:
Оркестратор — это основа современной data-инфраструктуры.
Хочешь автоматизировать процессы, не бояться падений, легко масштабироваться и не держать всё в голове — без оркестратора не обойтись.
В следующих постах расскажу про Airflow подробнее.Понравился пост? Ставьте реакции🔥, пишите комментарии)
#оркестратор #dataengineering #airflow #etl #автоматизация #bigdata
🔥20👍8👏6
OLTP и OLAP: две стороны дата-инженерии, о которых стоит знать👨💻
В последние годы бизнес стал чётко понимать, насколько важны данные. Причём не только «что происходит прямо сейчас», но и вся история: как вёл себя пользователь месяц назад, когда упал спрос, какие товары чаще всего покупают в пятницу вечером.
Те компании, которые научились собирать и использовать такие данные, вырываются вперёд. Остальные — гадают на кофейной гуще.
Вот тут и появляются два типа баз, с которыми мы, как дата-инженеры, работаем каждый день: OLTP и OLAP.
🌐 Представь, что ты заказываешь еду в приложении. Ты жмёшь кнопку — и заказ уходит в базу. Вводишь номер карты — сохраняется платёж. Все эти действия происходят в реальном времени — и проходят через OLTP.
OLTP (Online Transaction Processing) — это базы, которые: быстро записывают и обновляют информацию,справляются с тысячами одновременных действий, строго следят за целостностью данных/
Примеры: PostgreSQL, Oracle, MySQL
Они хорошо подходят для продуктовых систем, но не предназначены для анализа больших массивов данных.
💻 OLAP — это уже про аналитику
Теперь представь, что маркетологу нужно понять: как часто люди заказывают роллы по пятницам, сколько заказов в среднем в декабре и как это отличается от января.
Вот такие запросы уже не про одно событие, а про тенденции. Для них нужны другие базы — это OLAP.
OLAP (Online Analytical Processing) — это базы, которые: хранят исторические данные, быстро считают метрики и строят агрегаты,отлично подходят для аналитических дашбордов, BI-систем и витрин
Примеры: ClickHouse, Vertica, Redshift
Эти базы заточены под чтение по столбцам — поэтому отлично справляются с запросами вроде: “покажи средний чек за последние полгода по категориям”.
👨💻 И вот что важно: на первый взгляд синтаксис в OLTP и OLAP может быть похож — SQL есть SQL, но «под капотом» они работают абсолютно по-разному.
Запрос, который в Oracle выполнится за 50 мс, может в ClickHouse грузиться минуту. И наоборот.
Поэтому одна из ключевых задач дата-инженера — писать оптимальные запросы под конкретную архитектуру. Тут важны не только JOIN’ы и WHERE’ы, но и как ты хранишь данные, как распределяешь, по каким полям сортируешь и партиционируешь.
А какими СУБД вы пользовались и какие возникали проблемы?
#sql #olap #oltp #clickhouse #postgresql #bigdata #analytics
В последние годы бизнес стал чётко понимать, насколько важны данные. Причём не только «что происходит прямо сейчас», но и вся история: как вёл себя пользователь месяц назад, когда упал спрос, какие товары чаще всего покупают в пятницу вечером.
Те компании, которые научились собирать и использовать такие данные, вырываются вперёд. Остальные — гадают на кофейной гуще.
Вот тут и появляются два типа баз, с которыми мы, как дата-инженеры, работаем каждый день: OLTP и OLAP.
OLTP (Online Transaction Processing) — это базы, которые: быстро записывают и обновляют информацию,справляются с тысячами одновременных действий, строго следят за целостностью данных/
Примеры: PostgreSQL, Oracle, MySQL
Они хорошо подходят для продуктовых систем, но не предназначены для анализа больших массивов данных.
Теперь представь, что маркетологу нужно понять: как часто люди заказывают роллы по пятницам, сколько заказов в среднем в декабре и как это отличается от января.
Вот такие запросы уже не про одно событие, а про тенденции. Для них нужны другие базы — это OLAP.
OLAP (Online Analytical Processing) — это базы, которые: хранят исторические данные, быстро считают метрики и строят агрегаты,отлично подходят для аналитических дашбордов, BI-систем и витрин
Примеры: ClickHouse, Vertica, Redshift
Эти базы заточены под чтение по столбцам — поэтому отлично справляются с запросами вроде: “покажи средний чек за последние полгода по категориям”.
Запрос, который в Oracle выполнится за 50 мс, может в ClickHouse грузиться минуту. И наоборот.
Поэтому одна из ключевых задач дата-инженера — писать оптимальные запросы под конкретную архитектуру. Тут важны не только JOIN’ы и WHERE’ы, но и как ты хранишь данные, как распределяешь, по каким полям сортируешь и партиционируешь.
А какими СУБД вы пользовались и какие возникали проблемы?
#sql #olap #oltp #clickhouse #postgresql #bigdata #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡11🏆8❤7🔥2💯1
Сегодня поговорим о технологии, которая изменила мир обработки данных, а именно о MapReduce
🖥 Как мы начали приручать терабайты:
В условиях стремительного роста объёмов информации традиционные методы обработки данных перестали справляться с поставленными задачами. Компании столкнулись с необходимостью обрабатывать терабайты и даже петабайты данных ежедневно. Именно в ответ на этот вызов и появился MapReduce — революционный подход, ставший фундаментом для распределённых вычислений в рамках экосистемы Hadoop.
❓ Что такое MapReduce?
Это способ обработки больших объёмов данных за счёт разбиения задачи на мелкие подзадачи, которые параллельно обрабатываются на разных машинах в кластере.
Как это работает:
Input — на вход подаётся большой массив данных: текст, логи, последовательности ДНК и т.д.
Splitting — данные делятся на фрагменты, которые обрабатываются независимо.
Mapping — каждый фрагмент проходит через функцию map, которая превращает данные в пары «ключ — значение». Например, слово → 1.
Shuffling — все одинаковые ключи группируются: все «Car» — вместе, все «Bear» — вместе и т.д.
Reducing — к каждой группе применяется функция reduce, которая агрегирует значения. Например, считает, сколько раз встретилось каждое слово.
Result — получается финальный список, например:
⛏ Где применяется?
MapReduce активно применялся (и до сих пор используется) в индустриях, где нужно перерабатывать огромные объёмы данных, например:
Поисковые системы — Google применял MapReduce для индексации веб-страниц и подсчёта ссылок (PageRank).
Также один из мощных примеров — анализ геномных данных
Исследования в биоинформатике генерируют терабайты сырых данных: последовательности ДНК, карты мутаций, транскриптомные данные и пр.
✅ Кейс: компания Broad Institute использует MapReduce-подобную архитектуру в своём GATK (Genome Analysis Toolkit) для обработки данных секвенирования человека.
Понимание Map-reduce один из типичных тем на собеседованиях на Дата-инженера.
❓ Частые вопросы на собесах:
⏺ Как работает MapReduce — опишите все этапы?
⏺ Зачем нужен shuffle и почему он дорогой по ресурсам?
⏺ Чем Spark отличается от MapReduce?
⏺ Где работает MapReduce? (в памяти или на диске)
#bigdata #mapreduce #hadoop #собеседование
В условиях стремительного роста объёмов информации традиционные методы обработки данных перестали справляться с поставленными задачами. Компании столкнулись с необходимостью обрабатывать терабайты и даже петабайты данных ежедневно. Именно в ответ на этот вызов и появился MapReduce — революционный подход, ставший фундаментом для распределённых вычислений в рамках экосистемы Hadoop.
Это способ обработки больших объёмов данных за счёт разбиения задачи на мелкие подзадачи, которые параллельно обрабатываются на разных машинах в кластере.
Как это работает:
Input — на вход подаётся большой массив данных: текст, логи, последовательности ДНК и т.д.
Splitting — данные делятся на фрагменты, которые обрабатываются независимо.
Mapping — каждый фрагмент проходит через функцию map, которая превращает данные в пары «ключ — значение». Например, слово → 1.
Shuffling — все одинаковые ключи группируются: все «Car» — вместе, все «Bear» — вместе и т.д.
Reducing — к каждой группе применяется функция reduce, которая агрегирует значения. Например, считает, сколько раз встретилось каждое слово.
Result — получается финальный список, например:
Car — 3
Deer — 2
Bear — 2
MapReduce активно применялся (и до сих пор используется) в индустриях, где нужно перерабатывать огромные объёмы данных, например:
Поисковые системы — Google применял MapReduce для индексации веб-страниц и подсчёта ссылок (PageRank).
Также один из мощных примеров — анализ геномных данных
Исследования в биоинформатике генерируют терабайты сырых данных: последовательности ДНК, карты мутаций, транскриптомные данные и пр.
Понимание Map-reduce один из типичных тем на собеседованиях на Дата-инженера.
#bigdata #mapreduce #hadoop #собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍8⚡3😁1
Теперь буду при обзоре инструментов и технологий добавлять типичный вопросы по ним на технических собеседованиях
👍11🔥9⚡3😁1
Как кластеры делят ядра и гигабайты: управление ресурсами при обработке больших данных?⚙️
📌 На самом первом Hadoop всем процессом командовал один-единственный «дирижёр» — JobTracker. Он принимал каждую задачу MapReduce, держал у себя в памяти всё-всё о каждой джобе, сам решал, на каком сервере что запустить, и следил, чтобы все работали. Пока данных было десятки гигабайт — было норм. Но когда логов и кликов накопились терабайты, JobTracker стал узким горлышком: память забивалась, отчёты об ошибках копились, а падение одной машины могло поставить на паузу весь кластер — ведь дирижёр был один.
🔄 Чтобы разблокировать рост, в Hadoop 2.x придумали YARN (Yet Another Resource Negotiator). Логика была простая: вынесли две задачи — управление вычислительным процессом и управление ресурсами — в разные контуры:
Контур ресурсов
В центре — ResourceManager. Он воспринимает кластер как пул CPU-ядер и гигабайт памяти, ведёт их учёт, применяет выбранную политику планировщика (FIFO, Fair, Capacity) и решает, на каком узле открыть очередной контейнер.
Контур приложений
Для каждого приложения стартует свой ApplicationMaster. Это «директор программы»: оценивает объём работы, запрашивает у ResourceManager контейнеры нужного размера, раздаёт задачи исполнителям(MapReduce, Spark и др.) и отслеживает сбои.
Узловой слой
На каждом сервере работает NodeManager. Он получает команды от ResourceManager, создаёт и завершает контейнеры, следит за фактическим потреблением ресурсов и регулярно отчитывается о здоровье узла.
Контейнер
Контейнер — минимальная единица выполнения: изолированная среда с заданным лимитом CPU и памяти, в которой крутится конкретная задача (Spark-executor, MapReduce-task и т. д.). Это гарантирует, что приложение не выйдет за выделенные ему рамки и не помешает соседям.
✅ Благодаря такому разделению «ресурсы — отдельно, логика — отдельно» исчезло узкое горлышко единственного JobTracker’а. Кластер получил гибкую схему: ResourceManager управляет ресурсами в целом, а десятки ApplicationMaster’ов параллельно руководят своими задачами, не мешая друг другу и не конкурируя за центральный диспетчер.
Пользоваться и следить за ресурсами с помощью YARN очень удобно - у него есть UI -интерфейс, где можно отслеживать статусы своих задачек, смотреть логи, искать ошибки.
❓ Частые вопросы на собесах:
⏺ Как YARN распределяет ресурсы?
⏺ Общие принципы работы YARN?
⏺ Что такое ApplicationMaster и какие типы вы знаете?
#Hadoop #YARN #DataEngineering #MapReduce #Spark
Контур ресурсов
В центре — ResourceManager. Он воспринимает кластер как пул CPU-ядер и гигабайт памяти, ведёт их учёт, применяет выбранную политику планировщика (FIFO, Fair, Capacity) и решает, на каком узле открыть очередной контейнер.
Контур приложений
Для каждого приложения стартует свой ApplicationMaster. Это «директор программы»: оценивает объём работы, запрашивает у ResourceManager контейнеры нужного размера, раздаёт задачи исполнителям(MapReduce, Spark и др.) и отслеживает сбои.
Узловой слой
На каждом сервере работает NodeManager. Он получает команды от ResourceManager, создаёт и завершает контейнеры, следит за фактическим потреблением ресурсов и регулярно отчитывается о здоровье узла.
Контейнер
Контейнер — минимальная единица выполнения: изолированная среда с заданным лимитом CPU и памяти, в которой крутится конкретная задача (Spark-executor, MapReduce-task и т. д.). Это гарантирует, что приложение не выйдет за выделенные ему рамки и не помешает соседям.
Пользоваться и следить за ресурсами с помощью YARN очень удобно - у него есть UI -интерфейс, где можно отслеживать статусы своих задачек, смотреть логи, искать ошибки.
#Hadoop #YARN #DataEngineering #MapReduce #Spark
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍10🤔8
Почему Apache Spark вытеснил MapReduce?🤔
Когда‑то MapReduce был спасением для petabyte‑масштаба, но каждая итерация писала данные на диск → заново читала → снова писала. Итеративный ML, стриминг или сложные ETL превращались в марафон с кофе‑брейками. Нужно было что‑то быстрее.
Spark появился в 2009‑м в UC Berkeley и сказал:
«Давайте держать данные в памяти и давать разработчику нормальный API!»
Результат — ускорение ×10‑100 и код в пару строк вместо гирлянды map/reduce‑скриптов.
🖥 Архитектура Apache Spark
Driver Program
• инициализирует SparkContext
• строит DAG вычислений
• делит работу на задачи и шлёт их в кластер
SparkContext
• общается с Cluster Manager’ом
• следит, чтобы tasks дошли до финиша
Cluster Manager (Standalone / YARN / K8s / Mesos)
• ведёт учёт ресурсов
• назначает worker‑узлы
• стартует executors
Worker Node
• хостит один или несколько executors — грузит работу, кэширует данные
Executor
• выполняет tasks параллельно
• кладёт горячие данные в память
• шлёт результаты Driver’у
Task
• самый мелкий кусочек работы - обрабатывает партицию данных
Cache / Persistence
• RAM (или SSD) для повторного использования данных без дискового тормоза
⌛ Как бежит ваш job
1️⃣ Пишем код на RDD / DataFrame / Dataset.
2️⃣ Запускаем — Driver поднимает SparkContext.
3️⃣ Spark лениво строит DAG всех операций.
4️⃣ Оптимизатор режет DAG на stages, те — на tasks.
5️⃣ Cluster Manager раздаёт executors по worker‑ам.
6️⃣ Tasks летят параллельно 🔼 , данные шаффлятся только между stages.
7️⃣ .cache() → Spark держит данные в памяти, ускоряя итерации.
8️⃣ Завершили — результаты собираются у Driver’а и пишутся туда, куда нужно (HDFS / S3 / БД).
—
Сохраняйте, чтобы не забыть, и делитесь с теми, кто ещё путает Driver с Executor!
❓ Частые вопросы на собесах:
⏺ Что такое Executor и Driver?
⏺ Что такое ленивая модель вычислений в Spark?
⏺ Какие операции выполняются на Executors, а какие на Drivers?
⏺ Для чего в Spark используется cache?
⏺ Где выполняются операции в Spark( на диске или в памяти)?
⏺ Из-за чего Spark быстрее Map-reduce и чем удобнее?
Поставьте 🔥, если ,было полезно! Делитесь в комментариях своими кейсами по работе со Spark!
#ApacheSpark #BigData #DataEngineering #SparkArchitecture #RDD
Когда‑то MapReduce был спасением для petabyte‑масштаба, но каждая итерация писала данные на диск → заново читала → снова писала. Итеративный ML, стриминг или сложные ETL превращались в марафон с кофе‑брейками. Нужно было что‑то быстрее.
Spark появился в 2009‑м в UC Berkeley и сказал:
«Давайте держать данные в памяти и давать разработчику нормальный API!»
Результат — ускорение ×10‑100 и код в пару строк вместо гирлянды map/reduce‑скриптов.
Driver Program
• инициализирует SparkContext
• строит DAG вычислений
• делит работу на задачи и шлёт их в кластер
SparkContext
• общается с Cluster Manager’ом
• следит, чтобы tasks дошли до финиша
Cluster Manager (Standalone / YARN / K8s / Mesos)
• ведёт учёт ресурсов
• назначает worker‑узлы
• стартует executors
Worker Node
• хостит один или несколько executors — грузит работу, кэширует данные
Executor
• выполняет tasks параллельно
• кладёт горячие данные в память
• шлёт результаты Driver’у
Task
• самый мелкий кусочек работы - обрабатывает партицию данных
Cache / Persistence
• RAM (или SSD) для повторного использования данных без дискового тормоза
—
Сохраняйте, чтобы не забыть, и делитесь с теми, кто ещё путает Driver с Executor!
Поставьте 🔥, если ,было полезно! Делитесь в комментариях своими кейсами по работе со Spark!
#ApacheSpark #BigData #DataEngineering #SparkArchitecture #RDD
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍9❤6🤯1
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
YouTube
UPDATE Курса(RoadMap, агрегатор информации) на Data Engineer. v_2_1
Настало время максимально актуализировать информацию в RoadMap. Каждый раз внося изменения будет выходить видео подобного формата.
Здесь вы узнаете, какие изменения вошли в версию 2.1 + узнаете дальнейшие планы на будущее как самого курса, так и идей каналов…
Здесь вы узнаете, какие изменения вошли в версию 2.1 + узнаете дальнейшие планы на будущее как самого курса, так и идей каналов…
В этом видео:
Если у тебя есть идеи, предложения, обратная связь и т.д., можешь написать, как в комментариях под этим постом
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥6👏6
Стал соавтором роадмапа для дата-инженеров! Там очень хорошо расписан материал по различным темам👨💻 Полезно для всех, так что читайте, прокачивайте скиллы!⛏ Постепенно будем расширять эту базу, добавлять другие полезные материалы😊
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍6💯6
«Сердце» фреймворка. Отвечает за распределение задач по узлам, управление памятью и отказоустойчивость. Именно здесь живёт модель RDD — неубиваемые распределённые коллекции, которые можно хранить в RAM или на диске. Всё остальное в Spark просто вызывает возможности Core, поэтому без него ничего не поедет.
Тонкая прослойка‑упрощение над RDD. Представляет данные как привычные таблицы и даёт SQL‑подобный синтаксис (select, where, join). Внутри работает оптимизатор Catalyst: он переставит фильтры, уберёт лишние колонки и построит эффективный план выполнения. Результат — меньше строчек кода и быстрее запросы.
Spark SQL.Распределённый SQL‑движок поверх DataLake: привычные SELECT‑запросы выполняются параллельно и оптимизируются.
Spark Streaming - Тот же DataFrame‑синтаксис, но для непрерывных потоков (Kafka, файловые папки). Решает задачи near‑real‑time ETL и мониторинга.
MLlib. Набор распределённых алгоритмов ML (регрессии, бустинг, ALS‑рекомендации). Позволяет обучать и применять модели на кластере без ручного шардирования данных.
GraphX / GraphFrames. Фреймворк для графовых вычислений.Используется для анализа соц‑графов, логистических сетей и взаимосвязей транзакций.
Spark Packages. Каталог сторонних расширений — коннекторы, форматы, алгоритмы (например, ClickHouse Connector или t‑SNE).
Универсальный «шлюз» к данным. Одной строчкой читаем и пишем в HDFS, Hive‑таблицы, HBase, Postgres, MySQL, Parquet, JSON, Avro, Elasticsearch и кучу других форматов.
Scala — родной для Spark, максимальная производительность.
Java — удобно интегрировать в legacy‑экосистемы.
Python (PySpark) — де‑факто стандарт для дата‑сайентистов
R (SparkR) — для тех, кто в экосистеме tidyverse и Shiny.
Итого: Spark складывается как конструктор. Core даёт масштабирование, DataFrame — удобный SQL, поверх — стриминг, ML и графы, а Data Source API тянет данные откуда угодно.
Всё это доступно сразу на четырёх языках, так что команда аналитиков и инженеров работает в одной экосистеме без барьеров.
Было полезно? Ставьте 🔥
#ApacheSpark #BigData #DataEngineering #SparkSQL #StructuredStreaming #PySpark
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍5❤2
Описал свой опыт в посте, интересно узнать ваш!
Заходите в комментарии, пишите, что думаете, — обсудим!
Заходите в комментарии, пишите, что думаете, — обсудим!
Telegram
Ozon Tech
Какой период вы считаете оптимальным, чтобы качественно вырасти от стажёра до мидла в вашей профессии?
Сегодня в рубрике #ozontech_вопросы история нашего дата-инженера и автора канала о DS Артёма Подвального.
Присоединяйтесь к дискуссии в комментариях…
Сегодня в рубрике #ozontech_вопросы история нашего дата-инженера и автора канала о DS Артёма Подвального.
Присоединяйтесь к дискуссии в комментариях…
👍12🔥3❤1
В современных системах, особенно построенных на микросервисной архитектуре, важно обеспечить надёжный и масштабируемый обмен данными. Прямые вызовы между сервисами создают жёсткую связность, сложную поддержку и риск отказов при сбоях.
Зачем они нужны?
Асинхронность - продюсер отправляет сообщение и продолжает работу. Консьюмер обработает его позже — когда сможет.
Снижение связности - сервисы не зависят друг от друга напрямую. Это делает систему гибкой, её проще развивать и масштабировать.
Масштабируемость - брокеры позволяют обрабатывать миллионы сообщений в секунду, распределяя нагрузку между несколькими получателями.
Надёжность - сообщения не теряются при сбоях. Брокер может временно хранить их и доставить, когда консьюмер снова станет доступен.
Apache Kafka — для потоковой обработки и больших объёмов данных.
RabbitMQ — универсальный брокер с гибкой маршрутизацией сообщений.
Amazon SQS / Google Pub/Sub — облачные брокеры с auto-scale и отказоустойчивостью.
Где применяются
➤События с фронта поступают в Kafka, затем в аналитический пайплайн.
➤ Подсчёт просмотров, лайв-метрики, алерты.
➤ Kafka + Kafka Connect → выгрузка в S3 или Vertica.
Брокеры сообщений — это клей микросервисов и движок стриминговых данных. Без них невозможно представить современную архитектуру, особенно в data-driven продуктах.Они обеспечивают гибкость, надёжность и высокую производительность всей системы.
Расскажите, какими брокерами вы чаще всего пользовались или с какими хотели бы поработать?
#архитектура #dataengineering #messagebroker #kafka #rabbitmq #etl #streaming #системы
Please open Telegram to view this post
VIEW IN TELEGRAM
💯7👍5🔥5❤2
Если вы на распутье, хотите расти, менять стек или просто не знаете, с чего начать — я могу помочь.
Что делаю:
— Аудит навыков и опыта
— Индивидуальный roadmap под вашу цель
— Навигация по стеку и индустрии
— Подбор нужных материалов и регулярные созвоны
— Теория + практика: учим только то, что реально нужно
— Поддержка при откликах и выборе вакансий
— Правка резюме под стек и позицию
— Разбор типовых задач и собесов
— Мок-собеседования
— Обсуждение прошедших собеседований и разбор ошибок
— Помощь на испытательном сроке
Дополнительно:
-Мок-собес по вашему стеку
-Ревью резюме
-Консультация по развитию, стеку, задачам
Пишите в личку @ampodvalniy если чувствуете, что пора что-то менять. Вместе соберём план и дойдём до сочного оффера, который реально радует
Если вас интересует разработка на GO , то рекомендую своего друга-ментора:
Диму Урина
#менторство #dataengineering #датаинженерия #DE #DS
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤4👍3👎3
• Real-time: задержка 1–10 мс → онлайн-аналитика и алерты.
• Очень быстро: миллионы сообщений в секунду.
• Гибкое хранение: задаёшь, сколько дней или ГБ держать.
• Рост без боли: добавил брокер — и кластер сам расширился.
• Topic — «папка» для событий.
• Partition — линейный лог внутри топика; порядок гарантирован только здесь.
• Offset — номер сообщения; консьюмер знает, где продолжить.
Продюсер (Producer) — кто отправляет данные в Kafka.
Примеры: микросервис «Заказы», агент логов, IoT-датчик, Debezium.
Консьюмер (Consumer) — кто читает данные из Kafka.
Примеры: Spark-job, сервис e-mail-уведомлений, ClickHouse-sink, ML-пайплайн.
Один топик можно читать многими независимыми группами консьюмеров.
✔️ Данные лежат на разных брокерах → легко расширять кластер.
✔️ Несколько консьюмеров читают параллельно → выше скорость.
✔️ Параллельная запись/чтение → огромный throughput.
Kafka — это центральная артерия большинства современных data-platform. Хотите near-real-time данные в DWH, фичи для онлайн-ML или просто «подложку» под микросервисы — скорее всего, в середине стека крутится Kafka
Более подробно про кафку я расписал тут
Ставьте 🔥 если пост был интересным и полезным)
#Kafka #DataEngineering #StreamProcessing #RealTime #BigData #CDC #ETL #ApacheKafka #DevOps #Microservices
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👍10❤6
Data Engineer Lab pinned «➡️ Оказываю менторские услуги в Дата Инженерии Если вы на распутье, хотите расти, менять стек или просто не знаете, с чего начать — я могу помочь. Что делаю: 💬 Менторство от точки “где я сейчас” до оффера и помощи на испытательном сроке, а именно: 📝 Анализ…»
В предыдущем посте я рассказывал об оркестраторах https://news.1rj.ru/str/dataengineerlab/15, теперь хотелось бы уделить внимание "золотому стандарту" среди них, а именно Apache Airflow✈️
🕐 Что такое Apache Airflow и зачем он нужен?
Airflow — это оркестратор задач. Он запускает пайплайны данных по расписанию или по событиям, следит, чтобы всё выполнялось в нужном порядке, и даёт удобный интерфейс для мониторинга.
Используется в:
— ETL/ELT пайплайнах
— ML-процессах (тренировка, инференс, мониторинг)
— CI/CD для данных
— обработке логов, API, файлов и всего, что можно автоматизировать
🖱 Основная идея: всё описывается как DAG (направленный ацикличный граф) — граф задач, где узлы = задачи, а стрелки = зависимости. Всё пишется на Python 🐍
🖥 Компоненты Airflow:
• Tasks (задачи) — отдельные шаги: например, скачать файл, преобразовать, залить в S3.
• Operators — готовые блоки:
PythonOperator — запускает ваш питоновский код
BashOperator — команда в терминале
EmailOperator, S3Operator, MySqlOperator и др.
• Sensors — ждут условия (например, появления файла в папке или завершения другого DAG-а)
• Hooks — интерфейсы к внешним системам (Postgres, GCP, AWS и т.д.)
🧬 Кастомизация:
Airflow легко расширяется — можно писать свои CustomOperator или CustomSensor, если не хватает встроенных.
🛠 UI и Monitoring:
У Airflow отличный web-интерфейс. Там видно:
• какие DAG-и активны
• какие задачи упали
• сколько заняло времени
• можно перезапустить всё вручную
🕐 Запуск DAG-ов
Пайплайны можно запускать:
• по расписанию (cron, @daily, @hourly)
• по появлению данных
• вручную (через UI или CLI)
Почему он крутой?
Airflow = масштабируемость + контроль + гибкость.
❓ Частые вопросы по Airflow:
⏺ Что такое DAG в контексте Airflow?
⏺ Чем отличаются Operator, Task, Hook, Sensor?
⏺ Какие типы операторов ты использовал (PythonOperator, BashOperator и т.д.)?
⏺ Что такое Xcom?
Понравился пост? Ставьте🔥
Также я провожу консультации по инструментам (Airflow, Spark, Kafka и др.) — пишите в личку, помогу разобраться.
#Airflow #DataEngineering #ETL #MLops #Python #Orchestration #DAG #DataPipeline
Airflow — это оркестратор задач. Он запускает пайплайны данных по расписанию или по событиям, следит, чтобы всё выполнялось в нужном порядке, и даёт удобный интерфейс для мониторинга.
Используется в:
— ETL/ELT пайплайнах
— ML-процессах (тренировка, инференс, мониторинг)
— CI/CD для данных
— обработке логов, API, файлов и всего, что можно автоматизировать
• Tasks (задачи) — отдельные шаги: например, скачать файл, преобразовать, залить в S3.
• Operators — готовые блоки:
PythonOperator — запускает ваш питоновский код
BashOperator — команда в терминале
EmailOperator, S3Operator, MySqlOperator и др.
• Sensors — ждут условия (например, появления файла в папке или завершения другого DAG-а)
• Hooks — интерфейсы к внешним системам (Postgres, GCP, AWS и т.д.)
Airflow легко расширяется — можно писать свои CustomOperator или CustomSensor, если не хватает встроенных.
class MyAwesomeOperator(BaseOperator):
def execute(self, context):
# ваша логика тут
У Airflow отличный web-интерфейс. Там видно:
• какие DAG-и активны
• какие задачи упали
• сколько заняло времени
• можно перезапустить всё вручную
Пайплайны можно запускать:
• по расписанию (cron, @daily, @hourly)
• по появлению данных
• вручную (через UI или CLI)
Почему он крутой?
Airflow = масштабируемость + контроль + гибкость.
Понравился пост? Ставьте🔥
Также я провожу консультации по инструментам (Airflow, Spark, Kafka и др.) — пишите в личку, помогу разобраться.
#Airflow #DataEngineering #ETL #MLops #Python #Orchestration #DAG #DataPipeline
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥10⚡6❤3
Если очень просто — это не про папки и файлы, а про объекты. Хранилище, где каждый файл — это объект с данными, метаданными и уникальным ключом. Похоже на key-value хранилище, только для больших данных: фото, видео, бэкапы, логи и т.д.
Объектное хранилище — это не просто «папки и файлы», а совершенно другая логика:
Нет реальных папок — используется плоская структура, где «пути» — это просто части ключей объектов.
Доступ по уникальному ключу, как к записи в базе.
Масштабируется горизонтально — можно добавлять хосты/диски почти без ограничений.
Работает через HTTP API, чаще всего REST-интерфейс, совместимый с Amazon S3.
Каждый объект хранится внутри бакета - логического контейнера, в котором сгруппированы объекты. Он
имеет уникальное имя и определяет правила доступа.
Объекты внутри бакета не имеют вложенности — всё в одной плоскости. Тем не менее, с помощью префиксов в ключах (/) можно имитировать структуру директорий (logs/2024/march.json).
Объект — это не просто файл. Он включает в себя:
Данные — содержимое: картинка, видео, архив и т.д.
Метаданные — описание: тип контента, дата, кастомные теги.
Object Key — путь к объекту внутри бакета, например images/2023/product.jpg.
Ключ и бакет вместе формируют уникальный адрес объекта в хранилище.
Медиафайлы: фото, видео, обложки, аудио
Бэкапы: базы данных, снапшоты, конфиги
Аналитика и логи: nginx, ClickHouse, Prometheus
Микросервисы: хранение индексов, моделей, статуса
Лендинги и фронтенд: статика сайтов, HTML/JS/CSS
🔐 S3 и версии объектов:
Можно включить версионирование. Тогда каждый PUT создает новую версию, и вы:
Можете восстановить старую
Перезаписать без потери истории
Удалить конкретную версию при необходимости
💡 Почему не RAID?
RAID — это про локальные диски. А Object Storage:
Легко масштабируется
Реплицирует данные по серверам / ДЦ
Сам себя лечит после сбоев
Идеален для неструктурированных данных
Было интересно? Ставьте 🔥
#ОбъектноеХранилище #ObjectStorage #S3 #AmazonS3 #MinIO #Ceph
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19✍6🤯5