docs(course): обновлён PRD и переименован файл
- Зачем: - зафиксировать согласованную рамку курса по Lakehouse и сделать имя документа проще и единообразнее. - Что: - переработан PRD курса: уточнены ЦА, learning outcomes, scope, dataset strategy и out of scope. - добавлены checkpoints, acceptance criteria и методические принципы курса. - файл docs/PRD_Course.md переименован в docs/course_prd.md. - Проверка: - проверен итоговый diff и содержимое Markdown-документа; код и тесты не затрагивались.
This commit is contained in:
@@ -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 на больших объемах данных.
|
|
||||||
@@ -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` на уровне спецификации.
|
||||||
Reference in New Issue
Block a user