ddadminandClaude Opus 4.6
0ae83cecdb
- Зачем: - закрыты 3 вспомогательных артефакта из course_program.md §3.3: glossary, cheat sheet, mentor notes. - README переписан с фокусом на ценность для студента. - Что: - создан docs/glossary.md (16 терминов, сгруппированных по темам с параллелями к DWH). - создан docs/mentor_notes.md (тайминг, типичные вопросы, checkpoint-ы, формат «менти работает сам»). - добавлена секция «Краткая шпаргалка» в docs/stack_reference.md (S3-пути, таблицы, SQL-команды, маунты). - README.md переписан: лид с навыками, убрано дублирование со stack_reference. - обновлены перекрёстные ссылки в AGENTS.md, course_program.md, maintainer_guide.md. - Проверка: - все ссылки между документами валидны (glossary.md, mentor_notes.md существуют). - термины glossary и команды шпаргалки верифицированы по содержимому ноутбуков. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
138 lines
9.4 KiB
Markdown
138 lines
9.4 KiB
Markdown
# Глоссарий курса
|
||
|
||
Краткий справочник терминов, сгруппированных по темам. Если нужен полный технический reference стенда, используй [stack_reference.md](./stack_reference.md).
|
||
|
||
## Архитектура Lakehouse
|
||
|
||
### Storage
|
||
|
||
Физическое хранилище файлов. Хранит data files, metadata-файлы Iceberg и raw-данные.
|
||
|
||
**В этом курсе:** MinIO (`s3a://lakehouse/`).
|
||
**Параллель с DWH:** каталог `pg_data` в PostgreSQL, только вынесенный за пределы СУБД.
|
||
**Где в курсе:** Модули 1, 2, 3.
|
||
|
||
### Catalog
|
||
|
||
Реестр метаданных таблиц: какие таблицы существуют, где лежат их данные, какова текущая схема. Не хранит сами данные.
|
||
|
||
**В этом курсе:** PostgreSQL (JDBC catalog `lakehouse`).
|
||
**Параллель с DWH:** системный каталог `pg_catalog` в PostgreSQL.
|
||
**Где в курсе:** Модули 2, 4, 6.
|
||
|
||
### Compute
|
||
|
||
Вычислительный движок, который читает метаданные из каталога и данные из хранилища для выполнения запросов. Не владеет ни данными, ни метаданными.
|
||
|
||
**В этом курсе:** Spark (запись и чтение), Trino (чтение и ad hoc SQL).
|
||
**Параллель с DWH:** процесс СУБД PostgreSQL/Greenplum, но в Lakehouse движков может быть несколько одновременно.
|
||
**Где в курсе:** Модули 1, 2, 6.
|
||
|
||
### Table format
|
||
|
||
Спецификация, определяющая, как таблица организована на уровне файлов: какие data files входят в таблицу, где лежат метаданные, как работают snapshot-ы. Это не база данных и не хранилище — это набор правил.
|
||
|
||
**В этом курсе:** Apache Iceberg.
|
||
**Параллель с DWH:** ближайший аналог — формат хранения таблицы (heap / AppendOnly в Greenplum), но table format в Lakehouse делает больше: он управляет историей, схемой и файлами.
|
||
**Где в курсе:** Модули 2, 4.
|
||
|
||
### Decoupled compute
|
||
|
||
Принцип, при котором вычислительные движки не зависят друг от друга и от хранилища. Один движок может писать, другой — читать те же данные без копирования, потому что оба обращаются к общему каталогу и хранилищу.
|
||
|
||
**В этом курсе:** Spark пишет таблицу, Trino читает ту же таблицу через общий JDBC-каталог.
|
||
**Параллель с DWH:** в классическом DWH вычислитель один, поэтому проблема не возникает.
|
||
**Где в курсе:** Модуль 6.
|
||
|
||
## Структура Iceberg-таблицы
|
||
|
||
### Namespace
|
||
|
||
Логическая группа таблиц внутри каталога. Используется для организации таблиц по слоям или доменам.
|
||
|
||
**В этом курсе:** `bronze`, `silver`, `default` — namespace-ы внутри каталога `lakehouse`.
|
||
**Параллель с DWH:** `schema` в PostgreSQL.
|
||
**Где в курсе:** Модули 4, 5.
|
||
|
||
### Metadata
|
||
|
||
JSON-файлы, описывающие текущее состояние таблицы: схему, свойства, список snapshot-ов. Лежат в каталоге `metadata/` рядом с data files в хранилище.
|
||
|
||
**В этом курсе:** файлы в `s3a://lakehouse/warehouse/<namespace>/<table>/metadata/`.
|
||
**Параллель с DWH:** системные таблицы `pg_catalog`, но вынесенные в файлы.
|
||
**Где в курсе:** Модули 2, 4.
|
||
|
||
### Manifest
|
||
|
||
Avro-файл со списком data files и их статистиками (количество строк, диапазоны значений колонок). Позволяет движку пропускать ненужные файлы при чтении.
|
||
|
||
**В этом курсе:** видны при осмотре структуры таблицы в MinIO.
|
||
**Где в курсе:** Модуль 4.
|
||
|
||
### Manifest list
|
||
|
||
Avro-файл со списком manifest-ов, составляющих один snapshot. Каждый snapshot ссылается на свой manifest list.
|
||
|
||
**В этом курсе:** видны как часть внутренней структуры Iceberg при исследовании MinIO.
|
||
**Где в курсе:** Модуль 4.
|
||
|
||
### Snapshot
|
||
|
||
Неизменяемая версия таблицы, зафиксированная в момент операции с данными (INSERT, overwrite, delete). Каждый snapshot определяет, какие data files составляли таблицу в конкретный момент. Как коммит в git.
|
||
|
||
**В этом курсе:** `SELECT * FROM table.snapshots` показывает историю snapshot-ов.
|
||
**Параллель с DWH:** бэкап или PITR (Point-In-Time Recovery), но значительно легче: snapshot-ы создаются автоматически и не требуют копирования данных.
|
||
**Где в курсе:** Модули 4, 7, 8.
|
||
|
||
## Операции
|
||
|
||
### Time travel
|
||
|
||
Чтение таблицы в состоянии на момент определённого snapshot-а. Позволяет сравнить текущие данные с предыдущими или восстановить потерянную информацию. В Spark: `VERSION AS OF <snapshot_id>`, в Trino: `FOR VERSION AS OF <snapshot_id>`.
|
||
|
||
**В этом курсе:** демонстрация на демо-таблице в Модуле 7.
|
||
**Параллель с DWH:** восстановление из бэкапа (pg_dump / PITR), но без остановки сервиса и без восстановления всей базы целиком.
|
||
**Где в курсе:** Модуль 7.
|
||
|
||
### Schema evolution
|
||
|
||
Изменение схемы таблицы (добавление, переименование, удаление колонок) без перезаписи data files. Метаданные обновляются, данные остаются на месте.
|
||
|
||
**В этом курсе:** `ALTER TABLE ADD COLUMNS`, `ALTER TABLE RENAME COLUMN`.
|
||
**Параллель с DWH:** `ALTER TABLE` в PostgreSQL, но в Iceberg старые data files не перезаписываются — новые колонки возвращают NULL для существующих строк.
|
||
**Где в курсе:** Модули 7, 8.
|
||
|
||
### Compaction (rewrite_data_files)
|
||
|
||
Объединение множества мелких data files в меньшее количество крупных. Решает проблему деградации чтения после множества мелких INSERT-ов. Данные не меняются, только реорганизуются файлы.
|
||
|
||
**В этом курсе:** `CALL lakehouse.system.rewrite_data_files(table => '...')`.
|
||
**Параллель с DWH:** `ALTER TABLE ... REORGANIZE` в Greenplum AppendOnly.
|
||
**Где в курсе:** Модуль 8.
|
||
|
||
### Vacuum (expire_snapshots)
|
||
|
||
Удаление старых snapshot-ов и связанных с ними data files из хранилища. Освобождает место, но делает невозможным time travel к удалённым snapshot-ам. Необратимая операция.
|
||
|
||
**В этом курсе:** `CALL lakehouse.system.expire_snapshots(table => '...', retain_last => N)`.
|
||
**Параллель с DWH:** `VACUUM` в PostgreSQL/Greenplum (удаление мёртвых строк).
|
||
**Где в курсе:** Модуль 8.
|
||
|
||
## Слои данных
|
||
|
||
### Raw
|
||
|
||
Неизменяемые исходные файлы, загруженные из внешнего источника. Хранятся в S3 как обычные файлы (Parquet, CSV), а не как Iceberg-таблицы. Точка воспроизводимости: если что-то пошло не так на следующих слоях, всегда можно перестроить пайплайн от raw.
|
||
|
||
**В этом курсе:** `s3a://lakehouse/raw/nyc_taxi/` — Parquet-файлы NYC Taxi.
|
||
**Параллель с DWH:** staging-зона (stg), внешние таблицы.
|
||
**Где в курсе:** Модуль 3.
|
||
|
||
### Bronze / Silver
|
||
|
||
Управляемые Iceberg-таблицы с разным уровнем обработки. Bronze — данные «как есть» из raw, загруженные в Iceberg-таблицу. Silver — очищенные и трансформированные данные, готовые для анализа.
|
||
|
||
**В этом курсе:** `lakehouse.bronze.nyc_taxi_yellow` (bronze), `lakehouse.silver.nyc_taxi_yellow` (silver).
|
||
**Параллель с DWH:** ODS (bronze) / DDS (silver).
|
||
**Где в курсе:** Модули 4 (bronze), 5 (silver), 8 (финальная практика).
|