# Учебные задания по стенду Этот документ собирает в одном месте задания для менти. Он разбит на блоки: от базовой работы с CSV‑pipeline до более продвинутого сценария с демо‑БД bookings и слоем STG в Greenplum. Если вы только начинаете, выполняйте задания по порядку. К разделу про bookings можно вернуться позже. --- ## 1. Базовый CSV‑pipeline (csv_to_greenplum) Основная цель этого блока — понять, как устроен простой ETL: генерация данных через pandas, сохранение в CSV и загрузка в Greenplum. ### 1.1. Разбор готового pipeline 1. Найдите DAG `csv_to_greenplum` в `airflow/dags/csv_to_greenplum.py`. 2. Ответьте себе на вопросы (можно коротко в отдельном файле/блокноте): - какие задачи (tasks) входят в DAG и что делает каждая из них; - какие таблицы создаются в Greenplum; - где физически лежат CSV‑файлы; - какие параметры управляют размером датасета. 3. Поднимите стенд и запустите DAG: - `make up` (Airflow инициализируется автоматически при первом старте) - включите и запустите DAG `csv_to_greenplum` в Airflow UI. 4. Проверьте результат в Greenplum: - `make gp-psql` - `SELECT COUNT(*) FROM public.orders;` - `SELECT * FROM public.orders LIMIT 5;` ### 1.2. Изменение параметров генерации 1. Найдите, где задаётся количество строк для генерации (`CSV_ROWS` в `.env` и параметр в DAG). 2. Поставьте другое значение и перезапустите DAG: - оцените, как изменилось количество строк в `public.orders`; - убедитесь, что пайплайн по‑прежнему работает без ошибок. 3. Попробуйте изменить схему данных (добавить колонку в CSV и таблицу в Greenplum): - добавьте новую колонку в генерацию pandas; - обновите DDL/SQL, чтобы колонка появилась в таблице `public.orders`; - перезапустите DAG и убедитесь, что новая колонка заполняется. ### 1.3. Собственные проверки качества данных 1. Найдите DAG `csv_to_greenplum_dq` в `airflow/dags/csv_to_greenplum_dq.py`. 2. Посмотрите, какие проверки уже реализованы (наличие таблицы, схема, дубликаты). 3. Добавьте ещё одну простую проверку, например: - проверка, что в таблице `public.orders` не больше N строк; - проверка, что поле (например, `order_price`) не содержит отрицательных значений; - проверка, что нет строк с `NULL` в ключевых колонках. 4. Запустите DAG `csv_to_greenplum_dq` и убедитесь, что: - новая проверка проходит на «хороших» данных; - при нарушении условия DAG падает с понятной ошибкой. --- ## 2. Greenplum и модель данных (введение) В следующих заданиях мы будем опираться на демо‑БД bookings (Postgres) и слой STG в Greenplum. На этом этапе достаточно бегло посмотреть на структуру и понять общую идею, детальная проработка пойдёт позже. ### 2.1. Знакомство с демо‑БД bookings 1. Прочитайте `bookings/README.md` — какие сервисы и команды относятся к демобазе. 2. Поднимите стенд и выполните: - `make up` - `make bookings-init` 3. Подключитесь к демобазе: - `make bookings-psql` - посмотрите таблицы в схеме `bookings` (например, `\dt bookings.*`). 4. Найдите таблицу `bookings.bookings` и посмотрите на её структуру: - какие типы колонок используются; - какие поля выглядят как ключи, даты, суммы. ### 2.2. Знакомство с STG в Greenplum 1. Прочитайте `sql/stg/bookings_ddl.sql` и мини‑README `docs/internal/bookings_stg_readme.md` (если интересно — `docs/internal/bookings_stg_design.md`). 2. Ответьте себе на вопросы: - чем внешняя таблица `stg.bookings_ext` отличается от внутренней `stg.bookings`; - зачем нужны тех.колонки `src_created_at_ts`, `load_dttm`, `batch_id`; - чем слой STG отличается от итоговых витрин (DDS/DM) с точки зрения моделирования. 3. Выполните `make ddl-gp`, затем зайдите в Greenplum (`make gp-psql`) и проверьте наличие схемы и таблиц: - `\dn` и `\dt stg.*` - `SELECT * FROM stg.bookings LIMIT 5;` (после запуска соответствующего DAG). ### 2.3. Как генерируются учебные данные bookings 1. Откройте файл `bookings/generate_next_day.sql` и ответьте себе на вопросы: - с какой даты начинается генерация данных (посмотрите на GUC `bookings.start_date` и переменную `v_start_cfg`); - сколько дней генерируется при первой установке (переменная `bookings.init_days`); - что происходит, если таблица `bookings.bookings` уже не пустая. 2. В демобазе (`make bookings-psql`) выполните: - `SELECT min(book_date), max(book_date) FROM bookings.bookings;` - затем запустите `make bookings-generate-day` и повторите запрос — как изменился максимальный день? 3. Откройте `sql/src/bookings_generate_day_if_missing.sql` и обратите внимание, что: - логическая дата запуска DAG (`{{ ds }}`) не влияет на выбор дня генерации; - скрипт всегда смотрит на `max(book_date)` и добавляет **следующий** день (или несколько стартовых дней, если база пуста). 4. Сделайте вывод: генератор всегда «шагает» по датам вперёд от максимальной даты, поэтому: - при `make bookings-init` вы получаете `BOOKINGS_INIT_DAYS` дней начиная с `BOOKINGS_START_DATE`; - при последующих вызовах (`make bookings-generate-day` или DAG) добавляется ровно один новый день. --- ## 3. DAG bookings_to_gp_stage (заготовка заданий) Этот DAG показывает путь данных от демо‑БД bookings в Postgres до сырого слоя STG в Greenplum. Сейчас он уже реализован как учебный пример, а в будущем вокруг него появятся отдельные задания по моделированию DWH. ### 3.1. Что есть сейчас 1. Откройте `airflow/dags/bookings_to_gp_stage.py`. 2. Найдите в коде ссылки на SQL‑файлы: - `sql/src/bookings_generate_day_if_missing.sql` - `sql/stg/bookings_load.sql` - `sql/stg/bookings_dq.sql` 3. Соотнесите шаги DAG с документом `docs/internal/bookings_stg_readme.md`: - генерация учебного дня в `bookings.bookings`; - загрузка инкремента в `stg.bookings`; - проверка количества строк между источником и STG. 4. Обратите внимание, как в DAG используется логическая дата запуска: - `{{ ds_nodash }}` используется как `batch_id` — метка загрузки в таблице `stg.bookings` для конкретного запуска; - сами даты данных (какие дни есть в `bookings.bookings`) определяются генератором по `max(book_date)`, а не по `ds`. На этом этапе достаточно понять общую цепочку. Детальные задания по переработке модели данных и построению ODS/DDS/DM слоёв будут добавлены позже. ### 3.2. Идеи для будущих заданий (черновик) > Ниже — набросок задач, к которым мы вернёмся, когда базовые темы по Airflow и CSV‑pipeline будут освоены. Планируемые направления: - Спроектировать модель данных для основных сущностей демобазы bookings (рейсы, билеты, перелёты) в слоях ODS/DDS/DM. - Реализовать слой ODS поверх STG, аккуратно работая с временными атрибутами и ключами. - Построить витрины (DM) для типичных аналитических вопросов: загрузка рейсов, выручка по направлениям, динамика бронирований. - Добавить DAG’и, которые используют `stg.bookings` как источник и строят следующие слои DWH. - Расширить проверки качества данных для потоков bookings → STG → витрины. Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.