From f4a5bf0e2a67c2a2b85751869c9a0a51446cbb69 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Fri, 6 Mar 2026 22:39:33 +0300 Subject: [PATCH] =?UTF-8?q?docs(course):=20=D0=BE=D0=B1=D0=BD=D0=BE=D0=B2?= =?UTF-8?q?=D0=BB=D1=91=D0=BD=20PRD=20=D0=B8=20=D0=BF=D0=B5=D1=80=D0=B5?= =?UTF-8?q?=D0=B8=D0=BC=D0=B5=D0=BD=D0=BE=D0=B2=D0=B0=D0=BD=20=D1=84=D0=B0?= =?UTF-8?q?=D0=B9=D0=BB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - зафиксировать согласованную рамку курса по Lakehouse и сделать имя документа проще и единообразнее. - Что: - переработан PRD курса: уточнены ЦА, learning outcomes, scope, dataset strategy и out of scope. - добавлены checkpoints, acceptance criteria и методические принципы курса. - файл docs/PRD_Course.md переименован в docs/course_prd.md. - Проверка: - проверен итоговый diff и содержимое Markdown-документа; код и тесты не затрагивались. --- docs/PRD_Course.md | 58 --------------- docs/course_prd.md | 179 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 179 insertions(+), 58 deletions(-) delete mode 100644 docs/PRD_Course.md create mode 100644 docs/course_prd.md diff --git a/docs/PRD_Course.md b/docs/PRD_Course.md deleted file mode 100644 index ca76cfd..0000000 --- a/docs/PRD_Course.md +++ /dev/null @@ -1,58 +0,0 @@ -# Product Requirements Document (PRD): Учебный курс «Введение в Lakehouse» - -## 1. Product Vision & Value Proposition - -**Видение:** Создать интерактивный практический курс, который "сломает" привычную картину мира монолитных баз данных (PostgreSQL/Greenplum) и плавно перестроит мышление студентов на парадигму распределенных систем (Lakehouse). -**Ценность:** Дать безопасную, наглядную "песочницу" для старта работы с современным Lakehouse, чтобы переход от классических БД к связке S3 + Iceberg + Spark/Trino прошел легко, предсказуемо и с минимальным трением. - -## 2. Target Audience (Целевая аудитория) - -* **Кто:** Junior Data Engineers, менти, студенты. -* **Их текущая картина мира:** Привыкли к классическим СУБД. Для них база данных — это единый "черный ящик", где движок вычислений (Compute) и жесткие диски (Storage) неразделимы, строго реляционны и транзакционны. -* **Бэкграунд:** Уверенно пишут SQL, знают Python, понимают классические слои DWH (Raw, ODS, DDS), умеют работать с Docker. - -## 3. Problem Statement & Jobs-To-Be-Done (JTBD) - -**Ключевая проблема:** -Когнитивный диссонанс при столкновении с Big Data и Lakehouse. Студенты не понимают, как набор Parquet-файлов в папках (S3) может быть "базой данных", зачем нужен отдельный каталог метаданных (Iceberg/Hive) и почему для записи мы используем один инструмент (Spark), а для чтения — другой (Trino). У них нет четкой ментальной модели распределенных систем. - -**Jobs-To-Be-Done (JTBD):** -* *Основной JTBD:* «Когда я перехожу на новый проект или получаю задачу, связанную с Lakehouse, я хочу **быстро понять общую архитектуру и влиться в работу с минимальным трением**, чтобы не чувствовать себя слепым котенком и не сломать прод из-за непонимания распределенной природы данных». -* *Вторичный JTBD:* «Я хочу получить практический обзор современных технологий (Spark, Iceberg, Trino), чтобы уверенно отвечать на вопросы на собеседованиях и расширить свой кругозор за пределы PostgreSQL». - -## 4. Ключевые "Aha-Moments" (Моменты озарения) - -Курс должен быть спроектирован так, чтобы студент через практику испытал следующие инсайты: -1. **Storage is Just Files:** «Ого, таблица в Lakehouse — это просто набор Parquet-файлов в бакете MinIO!» -2. **Decoupled Compute:** «Вау, я могу писать данные Spark'ом, а читать Trino, и они оба смотрят на одни и те же файлы без их копирования!» -3. **The Magic of Metadata:** «Так вот зачем нужен Iceberg! Это просто умный JSON-манифест, который говорит движкам, какие именно файлы читать для Time Travel или партиционирования». - -## 5. Метрики Успеха и Формат (Goals & Success Metrics) - -**Цели продукта:** -1. Студент может пройти курс от начала до конца за **~12 часов** вдумчивой работы в браузере (Jupyter + MinIO UI + Trino UI). -2. Студент может своими словами (на собеседовании или коллегам) объяснить архитектуру Lakehouse (Storage, Compute, Catalog) и зачем нужен табличный формат (Iceberg). -3. Студент умеет самостоятельно реализовать базовый пайплайн (чтение, трансформация, запись) в парадигме Lakehouse. - -**User Experience / Flow (Пользовательский опыт):** -Подход **«50/50 (Теория + Самостоятельная практика)»**. Ноутбуки предоставляют теорию, демистифицирующую Lakehouse (нацеленную на вызов "Aha-Moments"), примеры кода (50%) и заготовки ячеек. Студент изучает пример, а затем самостоятельно дописывает код для решения задачи, закрепляя новые концепции на практике. Финал курса — самостоятельный сквозной мини-пайплайн. - ---- - -## 6. Содержание (Scope) - -Ориентировочная программа на 10 интерактивных уроков (Jupyter Notebooks) вынесена в отдельный документ: **[COURSE_PLAN.md](./COURSE_PLAN.md)**. - ---- - -## 7. Технические Требования и Ограничения - -**Technical Requirements (В скоупе)** -* Использование существующего `docker-compose.yml` (Spark, Trino, MinIO, PostgreSQL, Jupyter). -* Установка дополнительных библиотек в образ Jupyter (например, `trino-python-client`), чтобы студенты могли выполнять запросы к Trino прямо из ноутбука. -* Подготовка небольших, но реалистичных датасетов (CSV/JSON) в папке репозитория. - -**Out of Scope (Вне скоупа / На будущее)** -* Оркестрация пайплайнов (Airflow, Dagster). -* Развертывание в Kubernetes / Облаках. -* Тюнинг производительности Spark на больших объемах данных. diff --git a/docs/course_prd.md b/docs/course_prd.md new file mode 100644 index 0000000..a196303 --- /dev/null +++ b/docs/course_prd.md @@ -0,0 +1,179 @@ +# Product Requirements Document (PRD): Учебный курс «Введение в Lakehouse» + +## 1. Product Vision & Value Proposition + +**Видение:** создать практический курс, который помогает студенту перейти от привычной картины мира классических СУБД к базовой рабочей модели Lakehouse без лишнего стресса и без опасных иллюзий про "магическую" распределенную платформу. + +**Ценность:** дать безопасную и наглядную песочницу на базе локального стенда (`Spark + Trino + Iceberg + MinIO + PostgreSQL`), в которой студент может руками повторить типовые повседневные действия Data Engineer и понять, как устроена современная Lakehouse-архитектура. + +## 2. Target Audience & Prerequisites + +**Основная аудитория:** студент курса [`de-roadmap`](https://github.com/dementev-dev/de-roadmap), который уже прошел или уверенно знает: + +* SQL +* Python +* Git +* Airflow +* Greenplum + +**Дополнительно:** возможно, уже поверхностно знаком с `NiFi` или `Kafka`, но это не является обязательным требованием. + +**Важно:** курс рассчитан не на абсолютного новичка, а на человека, который уже понимает базовые DE-процессы и хочет перенести это понимание в мир Lakehouse. + +## 3. Problem Statement & JTBD + +**Ключевая проблема:** при первом столкновении с Lakehouse студент часто не понимает: + +* как набор файлов в объектном хранилище может быть "таблицей"; +* зачем отдельно нужны `storage`, `catalog` и `compute`; +* почему один движок может писать данные, а другой читать те же самые таблицы; +* как безопасно работать с такими таблицами, не ломая данные и не теряя воспроизводимость пайплайна. + +В результате Lakehouse воспринимается либо как непонятная магия, либо как хаотичный набор технологий без общей модели. + +**Основной JTBD:** «Когда я попадаю в команду, где есть Lakehouse-стек, я хочу быстро понять, как он устроен и как в нем выполнять простые рабочие задачи, чтобы не быть опасным для окружения и не тратить недели на распаковку базовых концепций». + +**Вторичный JTBD:** «Я хочу руками пощупать популярный стек `Spark + Trino + Iceberg + S3-compatible storage`, чтобы увереннее обсуждать такие системы на собеседованиях и в работе». + +## 4. Product Goals + +Курс должен помочь студенту: + +1. Получить практический, а не только теоретический, ввод в Lakehouse. +2. Освоить безопасный набор базовых ежедневных действий, полезных на старте работы. +3. Понять архитектуру ровно настолько, чтобы осознанно пользоваться инструментами и не допускать грубых ошибок. +4. Сопоставить новые концепции с уже знакомой картиной мира `PostgreSQL/Greenplum` и классических DWH-слоев. + +## 5. Learning Outcomes + +После прохождения курса студент: + +1. Понимает различие между `storage`, `catalog` и `compute`, и может объяснить роль `MinIO`, `PostgreSQL`, `Spark` и `Trino` в этом стенде. +2. Умеет поднять локальный стенд, проверить его базовую работоспособность и использовать логи/веб-интерфейсы для первичной диагностики проблем. +3. Умеет загрузить raw-данные, прочитать их в `Spark`, проверить схему и подготовить данные к дальнейшей обработке. +4. Умеет создать и заполнить `Iceberg`-таблицу как основной табличный формат курса. +5. Умеет реализовать простой поток `raw -> bronze -> silver` с базовыми трансформациями и сохранением воспроизводимости шагов. +6. Умеет читать одну и ту же таблицу из `Spark` и `Trino` и понимает, почему это возможно без копирования данных. +7. Умеет выполнить базовые безопасные операции с таблицей: изменение схемы, просмотр snapshot-ов, чтение предыдущего состояния, базовый `compaction` и `vacuum`. + +## 6. Teaching Principles + +**Принцип 1. Практика первична.** Курс не должен превращаться в обзорную лекцию. Теория нужна для объяснения того, что студент делает руками. + +**Принцип 2. Ноутбук как учебник и тренажер.** В ноутбуках должны быть: + +* готовые демонстрационные ячейки с объяснением подхода; +* обязательные самостоятельные задания на похожее действие; +* `checkpoints` с ожидаемым результатом. + +**Принцип 3. Постоянный мостик к знакомому миру.** Новые концепции объясняются через короткие сравнения с `PostgreSQL/Greenplum` и классической нотацией слоев `stg/ods/dds`, где это уместно. + +**Принцип 4. Безопасность важнее глубины.** Курс должен в первую очередь снижать риск типовых ошибок новичка, а не учить всем возможностям стека. + +## 7. Risk Reduction / Common Mistakes + +Курс должен явно учить не допускать следующие ошибки: + +1. Путать `storage`, `catalog` и `compute`, не понимая, где реально лежат данные и кто отвечает за метаданные. +2. Воспринимать Lakehouse как "одну базу данных", скрывающую физическую структуру хранения. +3. Делать разрушительные операции вслепую: неаккуратный `overwrite`, `drop`, неконтролируемую перезапись слоя. +4. Смешивать роли слоев `raw`, `bronze`, `silver`, из-за чего теряется происхождение и воспроизводимость данных. +5. Менять схему и типы данных без понимания влияния на downstream-чтение и на другие движки. + +## 8. Scope + +**В первой версии курса в скоупе:** + +* архитектурная модель `storage + catalog + compute`; +* один основной табличный формат: `Iceberg`; +* работа с raw-данными; +* построение слоев `bronze` и `silver`; +* чтение и запись через `Spark`; +* чтение через `Trino`; +* базовое schema evolution; +* snapshot/time travel на прикладном уровне; +* базовый `compaction/vacuum` с параллелями к `Greenplum AppendOnly`; +* набор практик в Jupyter Notebooks с обязательными заданиями и checkpoints. + +Ориентировочная программа курса вынесена в отдельный документ: **[COURSE_PLAN.md](./COURSE_PLAN.md)**. + +## 9. Dataset Strategy + +**Основной датасет курса:** `NYC TLC Yellow Taxi Trip Records` + `Taxi Zone Lookup`. + +**Почему он выбран:** + +* это узнаваемый и реалистичный DE-кейс; +* он хорошо подходит для слоев `raw -> bronze -> silver`; +* его удобно использовать для демонстрации работы `Spark`, `Trino` и `Iceberg`; +* он поставляется в `PARQUET`, что делает raw-слой ближе к реальной жизни. + +**Режимы использования данных:** + +* `Default`: 3-6 месяцев данных для стандартного прохождения курса; +* `Extended`: до полного года данных для более тяжелого режима или будущего расширения курса. + +**Методическое решение:** курс строится вокруг одного домена данных, но не требует жесткого сквозного проекта. Основной формат курса - набор связанных практик на одном и том же наборе данных. + +## 10. User Experience / Learning Flow + +Курс строится по модели **"объяснение -> демонстрация -> самостоятельное повторение -> checkpoint"**. + +Каждый урок должен: + +1. Коротко объяснить новую концепцию. +2. Показать готовый рабочий пример. +3. Дать студенту похожее задание для самостоятельного выполнения. +4. Заканчиваться проверяемым результатом. + +**Формат прохождения:** желательно с ментором, но курс должен быть самодостаточным и для самостоятельного изучения. + +## 11. Success Metrics & Acceptance Criteria + +**Цели продукта:** + +1. Студент проходит курс за `~12-15 часов` вдумчивой работы. +2. Студент после курса способен безопасно выполнить базовые операции в Lakehouse-стенде без постоянной внешней помощи. +3. Студент может внятно объяснить ключевые архитектурные принципы Lakehouse на уровне junior/middle interview readiness. + +**Acceptance Criteria для учебного результата:** + +1. Студент проходит обязательные `checkpoints` по урокам. +2. Студент самостоятельно выполняет набор практик на одном датасете, включая: + * загрузку raw-данных; + * построение `bronze`; + * построение `silver`; + * создание/чтение `Iceberg`-таблицы; + * чтение одной и той же таблицы через `Spark` и `Trino`; + * демонстрацию базового schema evolution; + * демонстрацию snapshot/time travel; + * демонстрацию базового `compaction/vacuum`. +3. Студент может своими словами объяснить: + * что такое `Lakehouse` и чем он отличается от классической БД; + * как разделены `storage`, `catalog`, `compute`; + * что такое `Iceberg` в практическом смысле; + * почему `Spark` может писать, а `Trino` читать одни и те же таблицы; + * зачем нужны слои `raw -> bronze -> silver`. + +## 12. Technical Requirements + +**В скоупе:** + +* использование существующего `docker-compose.yml` (`Spark`, `Trino`, `MinIO`, `PostgreSQL`, `Jupyter`); +* подготовка учебных датасетов и/или инструкций по их загрузке в репозиторий; +* поддержка выполнения запросов к `Trino` из ноутбуков; +* подготовка Jupyter Notebooks как основного формата учебных материалов; +* наличие воспроизводимых шагов для старта, сброса и повторного прохождения практик. + +## 13. Out of Scope (v1) + +**Вне первой версии курса:** + +* `gold`-слой и полноценные бизнес-витрины; +* `Airflow`, `Kafka`, `NiFi`, `streaming`, `CDC`; +* сложные `MERGE`-сценарии, row-level deletes и update-heavy кейсы; +* глубокий performance tuning; +* production security, governance, multi-user setup; +* Kubernetes / облачное развертывание; +* детальное сравнение нескольких типов catalog; +* глубокий разбор internals `Iceberg` на уровне спецификации.