Дмитрий Кузьмин | Инженерия данных

🆙 В понедельник, 10 августа, стартует пятый поток DE-практикума.

🧩 Если совсем простыми словами, мы берём сырые CSV-файлы и постепенно превращаем их в нормальный работающий проект: принимаем данные, чистим ошибки, раскладываем по слоям, запускаем обработку и доводим всё до отчёта для бизнеса.

По пути поднимаем Docker-стенд, работаем с PostgreSQL, Spark, Airflow, MinIO и BI. Хочется, чтобы в конце ты действительно понимал, как движутся данные, зачем нужен каждый слой, где искать ошибку и как перезапустить пайплайн, если что-то пошло не так.

Я собирал этот практикум примерно так, как сам хотел бы изучать Data Engineering: на одном цельном проекте, руками и с возможностью задать вопрос, когда застрял. Для меня это давно уже не просто записанный курс. Я постоянно что-то дополняю, переписываю и стараюсь проще объяснять места, на которых участники спотыкаются.

🆕 Буквально вчера полностью обновил модуль по основам Spark. Добавил Spark UI, карту архитектуры и задания по чтению Jobs, Stages, Tasks и Executors.

Теперь можно легко посмотреть, что происходило внутри, как распределилась работа и где искать проблему, если обработка начала тормозить.

В пятом потоке этот модуль уже будет. Участникам предыдущих потоков тоже добавлю обновление в течение недели.

🔎 Заранее знать Spark и Airflow не нужно. Достаточно базы SQL, немного Python и желания разобраться. При этом нужно быть готовым выделять на практикум примерно 6–8 часов в неделю и действительно работать руками.

Если что-то непонятно, будем разбираться вместе. Я много отвечаю участникам и остаюсь на связи до полного прохождения, а не только до формального окончания потока. Мне правда важно, чтобы человек не просто получил доступ, а смог собрать проект до конца.

⏰ Старт 10 августа.

Программа и короткая диагностика

💬 Если интересно, но остались сомнения или вопросы, просто напиши мне: @dim4eg91. Посмотрим на твою текущую базу и решим, комфортно ли тебе заходить сейчас.

#путь_DE

Docker и Airflow: небольшая практика руками

🙂А помните, я недавно делал опрос, что сильнее всего тормозит при изучении DE. Больше всего ответов набрали Docker и Airflow.

Поэтому собрал небольшое упражнение, которое можно пройти на готовом проекте 🎧

Поднимите стенд и попробуйте разобраться:
🟢 Какие контейнеры запущены и за что отвечает каждый?
🟢 Где Airflow берет DAG и из каких задач он состоит?
🟢 В каком порядке выполняются задачи?
🟢 В какие таблицы записываются данные после каждого шага?
🟢 Как проверить, что загрузка прошла правильно?

После запуска DAG откройте Postgres и посмотрите данные по слоям. Проверьте количество строк, дубли, пустые ключи и итоговую витрину. Потом специально сломайте один шаг: поменяйте название таблицы или файла, снова запустите DAG и найдите ошибку в логах.

Это открытое демо DE-практикума. Внутри Docker, Postgres, Airflow, несколько слоев данных, готовый DAG и задачи руками. Проект небольшой, поэтому можно пройти весь маршрут за небольшое время и посмотреть, как компоненты работают вместе.

📁 Открыть Демо на GitHub (также ссылка в закрепе)

🩵 Если попробуете, напишите, на чем споткнулись: Docker, Airflow, DAG или проверка данных.

#путь_DE

💬 Что я проверяю в DE-практикуме

Когда речь заходит про проверку в учебном треке по Data Engineering, многие представляют следующее: сошлось или не сошлось, запустилось или упало, зелёный статус или красный. Плюс со стороны не всегда вообще понятно, как такие задачи проверяются, особенно когда внутри и SQL, и Python, и слои данных, и orchestration.

На самом деле у проверки здесь всегда есть два слоя, и если видеть только один из них, половина смысла просто теряется.

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

💡 Но есть и второй слой, который для меня даже важнее. Это про то, насколько студент понимает, что именно он сделал и почему оно работает именно так. Потому что в DE проблема обычно не в том, что кто-то вообще ничего не сделал, а в том, что шаг выполнен, результат как будто есть, а понимание размыто. Человек поставил partition или repartition, но пока слабо чувствует, что именно после этого меняется. Добавил проверки data quality, но не до конца понимает, что именно они страхуют и почему их место именно после построения слоя, а не где попало. Выбрал один способ перезаливки, но пока не очень различает, где уместен replace by date, где нужен инкремент, а где полная перезагрузка просто ломает логику и делает систему хрупкой.

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

Хорошая проверка в таком треке для меня всегда отвечает на два вопроса. Первый: что у тебя получилось руками. Второй уже важнее: что ты по дороге реально понял, а что пока только повторил.

Именно поэтому часть проверки в практикуме сделана в формате свободного ответа с моей рецензией - многие важные вещи в DE невозможно нормально проверить одним автоматическим тестом. Тест покажет, что шаг формально выполнен. А вот насколько точно человек понимает логику, где у него слабое место и что он сам пока объясняет себе слишком поверхностно, это уже видно только в разборе ответа.

Мне как раз важно, чтобы по ходу практикума у человека постепенно собиралась связная картина: от источника до витрины, от загрузки до слоя, от SQL и Python до orchestration и дальше уже до спокойного понимания, где здесь слабое место и чем его проверять.

⤵️ Если у вас уже есть SQL-база, но цельная картина пока не складывается, страницу практикума можно посмотреть здесь.

⤴️ А если просто есть вопросы по курсу, пишите в личку, отвечу и подскажу.

#путь_DE