Проверка практики SparkSession в модуле 3

Дата: 2026-09-15. Задача: #2. База: 00942c2, результат закрытой #1 прочитан вместе с комментариями.

Что проверялось

Фактические ячейки notebooks/03_raw_ingest_and_first_read.ipynb выполнялись через jupyter_client.KernelManager в контейнере jupyter, Spark 3.5.1. Менеджер запускал настоящее IPython-ядро и перезапускал его через restart_kernel(now=True). Проверка не подменяла создание сессии общим helper-ом.

Порядок воспроизведения:

Поднять стенд и получить стандартный bundle по START_HERE.md.
В новом ядре выполнить демонстрацию, вывод настроек, опыт с часовым поясом, повторный builder и остановку сессии.
Заполнить три пропуска шаблона, выполнить его дважды и сравнить контекст и applicationId. Выполнить опубликованное контрольное решение (при проверке извлекалось из блока session-solution).
Выполнить проверку master/appName и дважды создать, прочитать и удалить временную таблицу.
Перезапустить ядро. Убедиться, что переменные spark и CLUSTER_MASTER отсутствуют; выполнить контрольное решение, проверку подключения и таблицы.
Продолжить исходный raw-ingest до spark.stop(), заполнив самостоятельные упражнения с lookup, top-5 локаций и ещё одной аномалией.
Отдельно проверить заполненный шаблон в новом ядре и повторную загрузку уже существующих raw-файлов.

Результаты

Проверка	Результат
Демонстрационная сессия	Master `spark://spark-master:7077`, appName `module-03-session-demo`, сумма 0…9 = 45
Настройки каталога	`SparkCatalog`, `JdbcCatalog`, URI PostgreSQL и warehouse соответствуют общему файлу; Hadoop endpoint `http://minio:9000`, path-style `true`
Изменяемая настройка	`spark.sql.session.timeZone` допускает изменение; Unix-время 0 отображается как `1970-01-01 00:00:00` в UTC и `1970-01-01 03:00:00` в Москве
Восстановление	В `finally` восстановлено исходное `Etc/UTC`, проверено через assert
Повторный builder с другим appName	Тот же объект сессии и контекста, фактическое имя остаётся `module-03-session-demo`
Создание после stop	Новое имя `module-03-raw-ingest-and-first-read`, master кластерный
Повторение шаблона и контрольного решения	Контекст и applicationId не меняются
Заполненный шаблон в отдельном новом ядре	Master и appName верны, распределённая сумма 0…9 = 45
Перезапуск ядра	Переменные исчезли, сессия создана заново; ID изменился с `app-20260915125347-0001` на `app-20260915125511-0002`
Iceberg до и после перезапуска	Три независимые таблицы с уникальными именами; каждый раз прочитаны `[0, 1]`, после PURGE таблица отсутствует в каталоге
Raw-ingest	Январь: 2 964 624 строки; январь–март: 9 554 778 строк, 19 колонок
Профилирование	Схема, null-доли, describe и четыре проверки аномалий выполнены без ошибок
Самостоятельное задание raw	Lookup: 265 строк; подсчёт зон по Borough и top-5 pickup с названиями зон выполнены; найдено 180 поездок с отрицательной длительностью
Повторная загрузка raw в отдельном ядре	Все четыре файла пропущены с `skipped_same_size`; снимки всех объектов и каталога до/после совпали

Код исходного raw-ingest после ячейки подготовки не изменён, что проверено сравнением ячеек с базовым коммитом. Из подготовки убрано только создание сессии: она теперь приходит из новой практики.

Время и ограничения

Машинный прогон блока настройки: 179,27 с. Сюда вошли дополнительные повторы шаблона и таблицы, а также настоящий перезапуск ядра.
Исходная часть модуля, включая заполненные самостоятельные упражнения: 70,41 с. Полный основной прогон: 250,02 с (около 4 минут 10 секунд).
Запуск контейнеров и скачивание bundle в замер не входят. Это время выполнения кода; чтение объяснений, самостоятельное заполнение и ответы студента не измерялись.
Ориентир новой практики 20–30 минут, модуля целиком около 2 часов. Общую оценку 12–15 часов оставили предварительной; машинного замера недостаточно для её уточнения. Нужен самостоятельный проход студента.
Кнопки Jupyter/VS Code, отображение раскрывающегося решения и UI сервисов не проверялись. Перезапуск выполнен менеджером ядра через API, а не кнопкой.
Остальные семь ноутбуков и Trino smoke не выполнялись: runtime-конфигурация не менялась, проверялся модуль 3.

Сохранность данных

До основного прогона в каталоге было 0 таблиц, в bucket — 4 объекта. После прогона исходные объекты сохранили ETag и размер, состав каталога не изменился. Это проверка на имевшемся состоянии стенда, а не на копии заполненного студентом курса.

Добавлены четыре исходных файла Taxi в raw/nyc_taxi/, как предусмотрено уроком; они оставлены для модуля 4. Локальный bundle сохранён в игнорируемом data/. Файлы данных и метаданных трёх временных таблиц удалены через PURGE. Hadoop S3A оставил шесть нулевых маркеров data/ и metadata/; при завершении проверки удалены только эти шесть зафиксированных объектов. В трёх префиксах практики осталось 0 объектов. Volumes не сбрасывались. Поднятый для проверки стенд остановлен через docker compose down без -v.

Статические проверки

git diff --check;
docker compose config --quiet;
проверка ноутбука через nbformat.validate и синтаксиса Python-ячеек через AST;
относительные ссылки изменённых документов и ноутбука;
сохранение восьми модулей и маршрута README → START_HERE → программа → ноутбук.

После редакторской правки по ревью повторно проверены ссылки, нумерация разделов и синтаксис Python. Все исполняемые ячейки, их порядок и контрольное решение совпадают с проверенной версией. Стенд повторно не запускался.

9.1 KiB Raw Permalink Blame History Unescape Escape