В этом видео я покажу лучший пет-проект для дата-инженера, который можно добавить в свой опыт. Вместе мы создадим полноценную инфраструктуру: Apache Airflow, PostgreSQL, MinIO (S3), Metabase и Docker. Покажу, как организовать пайплайны, DAG'и, витрины, использовать git и best practices для data engineering проектов.
📌 Что вы узнаете:
- Как устроена типовая задача дата-инженера
- Как создать рабочую инфраструктуру под pet project
- Как управлять зависимостями и конфигурацией
- Как создать витрины данных и визуализации
- Как применять подходы Data Governance
📂 Полный проект на GitHub: https://github.com/k0rsakov/pet_project_earthquake
👨💻 Подходит для начального уровня, junior и middle дата-инженеров, ищущих реальный опыт и сильное портфолио.
🔔 Подписывайтесь и ставьте лайк, если хотите больше практических видео!
Менторство/консультации по IT – https://korsak0v.notion.site/Data-Engineer-185c62fdf79345eb9da9928356884ea0 TG канал – https://t.me/DataLikeQWERTY Instagram – https://www.instagram.com/i__korsakov/ Habr – https://habr.com/ru/users/k0rsakov/publications/articles/
Тайм-коды:
- 00:00 Начало
- 04:46 Непосредственно к ролику (описание проекта)
- 05:44 Типовая задача дата-инженера
- 08:38 Создание проекта в GitHub
- 09:37 Клонирование проекта
- 10:31 Изменение git-конфига
- 11:30 Создание виртуального окружения
- 13:48 Правила формирования коммитов в проекте
- 15:13 Создание инфраструктуры проекта (аирфлоу/AirFlow)
- 16:14 Создание инфраструктуры проекта (постгрес/PostgreSQL)
- 17:22 Создание инфраструктуры проекта (минио/Minio S3)
- 17:48 Рекомендации про работу с версиями
- 17:22 Создание инфраструктуры проекта (метабазе/Metabase)
- 22:00 Настройка минио/Minio S3 (создание бакета, ключей и пр)
- 23:48 Первый взгляд на аирфлоу/AirFlow
- 25:13 Первый DAG
- 25:20 Как именовать DAG
- 26:30 Добавление пакетов в виртуальное окружение
- 30:35 Объяснение логики DAG
- 33:25 Объяснение контекста DAG
- 40:25 Добавление python-пакета в сборку
- 41:22 Как работать с зависимостями в проекте
- 42:58 Добавление Variables в аирфлоу/AirFlow
- 44:10 Первый запуск DAG
- 45:20 Объяснение идемпотентности
- 47:05 Зависимости dag между собой в аирфлоу/AirFlow
- 47:25 Создание второго DAG
- 51:33 Создание схем и таблицы в постгрес/PostgreSQL
- 53:26 Объяснение типизации в постгрес/PostgreSQL (двх/dwh)
- 54:20 Первый запуск второго DAG
- 54:25 Просмотр зависимостей DAG
- 55:17 Просмотр данных в постгрес/PostgreSQL
- 56:00 Объяснение, что такое витрина
- 57:35 Создание первой витрины
- 01:01:53 Создание второй витрины
- 01:04:02 Создание подключение к постгрес/PostgreSQL в аирфлоу/AirFlow
- 01:04:50 Объяснение подключений в аирфлоу/AirFlow
- 01:05:50 Первый запуск первой витрины
- 01:06:05 Создание таблицы для первой витрины
- 01:08:05 Просмотр идемпотентности для первой витрины
- 01:08:47 Первый запуск второй витрины
- 01:09:00 Просмотр зависимостей DAG в проекте
- 01:09:52 Создание таблицы для второй витрины
- 01:11:28 Создание визуализаций в метабазе/Metabase
- 01:16:10 Пояснение наших этапов, что мы сделали в этом проекте
- 01:16:25 Разбор проекта в разрезе Data Governance
- 01:17:38 1. Data Architecture
- 01:17:44 2. Data Modeling & Design
- 01:18:18 3. Data Storage & Operations
- 01:19:34 4. Data Security
- 01:20:03 5. Data Integration & Interoperability
- 01:20:26 6. Documents & Content
- 01:20:41 7. Reference & Master Data
- 01:22:18 8. Data Warehousing & Business Intelligence
- 01:24:55 9. Meta-data
- 01:25:31 10. Data Quality
- 01:28:20 Прощание
#dataengineer #petproject #airflow #postgresql #minio #metabase #dwh #python #dataengineering #etl #docker #portfolio #датаинженер
python3.12 -m venv venv && \
source venv/bin/activate && \
pip install --upgrade pip && \
pip install -r requirements.txtdocker-compose up -d- Лучший пет-проект для дата-инженера (The best pet-project for a data-engineer)
- Описание работы API
- Описание полей из API
- airflow docker-compose
Lakehouse
flowchart LR
subgraph API
direction LR
API_E["Earthquake API"]
end
subgraph ETL
direction LR
AirFlow
end
subgraph Storage
direction LR
S3
end
subgraph DWH
direction LR
subgraph PostgreSQL
direction LR
subgraph model
direction LR
ods["ODS Layer"]
dm["Data Mart Layer"]
end
end
end
subgraph BI
direction LR
MetaBase
end
API_E -->|Extract Data| AirFlow
AirFlow -->|Load Data| S3
S3 -->|Extract Data| AirFlow
AirFlow -->|Load Data to ODS| ods
ods -->|Extract Data| AirFlow
AirFlow -->|Transform and Load Data to DM| dm
dm -->|Visualize Data| MetaBase
style API fill: #FFD1DC, stroke: #000000, stroke-width: 2px
style ETL fill: #D9E5E4, stroke: #000000, stroke-width: 2px
style Storage fill: #FFF2CC, stroke: #000000, stroke-width: 2px
style DWH fill: #C9DAF7, stroke: #000000, stroke-width: 2px
style PostgreSQL fill: #E2F0CB, stroke: #000000, stroke-width: 2px
style BI fill: #B69CFA, stroke: #000000, stroke-width: 2px
Не применяется звезда, снежинка или другое, потому что в этом нет необходимости. Данных немного. Состояние измениться не может, поэтому создаём модель по типу "AS IS".
Cold, Warm Storage – S3 Hot Storage – PostgreSQL
DuckDB – Data Lake PostgreSQL – DM layer
Безопасность настраивается на уровне пользователей в S3 и ролевой модели в PostgreSQL. В Airflow задаётся безопасность через роли.
Здесь может быть использован LDAP
В данном случае не занимаюсь этим пунктом, потому что для демонстрации и текущей реализации достаточно, но для "правильной" работы необходимо ods слой "приводить" к нужным типам.
К примеру, сейчас:
...
time varchar
...А нужно:
...
time timestamp
...Документация в виде видео, дополнительно могут быть комментарии, описание на внутренних ресурсах и прочее
В данном случае у нас данные, которые находятся в Data Lake S3, являются "золотыми". Мы их взяли из источника "как есть" и не модифицируем, тем самым вероятность их потерять в нашем пайплайне равно 0%. Но это не говорит, что изменение данных невозможно/запрещено. Разрешено в других "слоях", на уровне dwh или в своих реализациях.
Как было сказано выше "горячее" хранение у нас в PostgreSQL.
Для BI-системы мы используем Metabase.
Из общих рекомендаций по данному пункту:
- Задавать "жизнь" для витрин. Потому что сейчас бизнесу нужна витрина
N, а через месяц нет. И чтобы она не крутилась просто так необходимо проводить "уборки". - Определить роли для отчётов и допустимых зон. К примеру C-уровень должен видеть Все отчёты. А уровень курьеров не должен видеть витрины по опционам и выручке компании
- Сформировать правила формирования витрин
- Один показатель – одна витрина
- Один показатель – одна вью/мат.вью
- Широкая витрина
- Одна таблица, которая содержит все показатели и её вид примерно такой: дата-день, тип показателя, значение
- Мониторинг активности и нагрузка
- Автоматическое обновление. Исключить "ручной" труд
Сейчас мета-данных нет, но их можно задать к примеру через комментарии к столбцам в DWH.
Вот к примеру описание всех колонок – Описание полей из API
Для уровня Data Lake явно должны быть свои инструменты для формирования мета-данных.
Тут необходимо искать удобный для вашей команды дата-каталог: OpenMetaData, DataHub и прочее.
Дата кволити сейчас нет. Потому что опять же долго реализуется и это большая тема. Возможно ей будет посвящено отдельное видео, если поддержите лайком.
Но из основного:
- Нужно смотреть "долетели" ли данные (ACID).
- Смотреть SLA доставки данных
- Определить важные дашборды. И повешать разные алерты на них.
- Стараться при возможности смотреть на "источник". Условно Если у на источнике 1000 строк, а у нас в Data Lake/DWH 999 строк мы должны узнать об этом сразу, а не через месяц.
- Нужен процесс, который позволит исправлять такие ошибки
- Если витрина Очень важная, то проводить свои тесты перед попаданием их на прод. Смотреть на дельту между значениями, смотреть на среднее значение и прочее. Критерии "качества" необходимо выяснять у бизнеса.
SQL схемы:
CREATE SCHEMA ods;
CREATE SCHEMA dm;
CREATE SCHEMA stg;DDL ods.fct_earthquake:
CREATE TABLE ods.fct_earthquake
(
time varchar,
latitude varchar,
longitude varchar,
depth varchar,
mag varchar,
mag_type varchar,
nst varchar,
gap varchar,
dmin varchar,
rms varchar,
net varchar,
id varchar,
updated varchar,
place varchar,
type varchar,
horizontal_error varchar,
depth_error varchar,
mag_error varchar,
mag_nst varchar,
status varchar,
location_source varchar,
mag_source varchar
)DDL dm.fct_count_day_earthquake:
CREATE TABLE dm.fct_count_day_earthquake AS
SELECT time::date AS date, count(*)
FROM ods.fct_earthquake
GROUP BY 1DDL dm.fct_avg_day_earthquake:
CREATE TABLE dm.fct_avg_day_earthquake AS
SELECT time::date AS date, avg(mag::float)
FROM ods.fct_earthquake
GROUP BY 1 