ddadmin
3556566f64
- Зачем:
- README и путеводитель обращаются к читателю на «вы», а ТЗ в docs/labs/
были на «ты»; после пересборки индекса смесь стала заметна.
- Что:
- во всех восьми файлах docs/labs/ местоимения, глаголы и повелительное
наклонение переведены во второе лицо множественного числа.
- названия ступеней в таблице README оставлены как в спеке.
- Проверка:
- grep по формам «ты/твой», 'ё' и 'менти' по docs/labs/ молчит;
git diff --check чистый; ревью диффа свежей сессией.
Учебные задания
Программа состоит из двух частей: основная включает семь ступеней, которые вы проходите по порядку, а факультативы выбираете по желанию. Причины такого порядка и формы заданий описаны в программе учебных лаб.
Основная программа
| Ступень | Задание | Чему учит |
|---|---|---|
| 1 | Пять витрин слоя DM | построить результат для потребителя хранилища; уроки каждой витрины — в таблице ниже |
| 2 | Свой график в Superset | превратить свой результат из хранилища в отчет в BI |
| 3 | Нарежь сессии сам | счет показывает проблему, но причину приходится искать в отдельных строках |
| 4 | Перепиши нарезку стенда | изменить расчетную сущность внутри готового конвейера и проверить ее внешним эталоном |
| 5 | Сначала сторож, потом ломай: заказы | построить сторожей до рискованного изменения, а не после первой поломки |
| 6 | Разбери сырые события и сверь результат со стендом | изучить разбор потока отдельно от живого приема и сверить его со стендовым результатом |
| 7 | Мониторинг: куда смотреть | выбрать, куда и на что смотреть в живой системе |
ТЗ для ступеней 3–7 появятся по мере продвижения программы.
Ступень 1: пять витрин слоя DM
Слой DM в стенде построен наполовину: витрины трех сюжетов дашборда и контроль качества уже построены, остальные пять витрин строите вы. Каждая из них — самостоятельное ТЗ: в нем есть состав витрины, зерно, источники и способ проверки.
| № | Результат | Чему учит |
|---|---|---|
| 1 | events_enriched_v |
слой — это контракт, а не копия данных |
| 2 | top_pages_daily |
зерно сменилось — витрина материализуется и встает в конвейер |
| 3 | session_overview |
зерно решает, на какие вопросы витрина уже не ответит |
| 4 | dq_errors_daily |
у брака свой день и свой срок жизни |
| 5 | utm_effectiveness |
declared_ в имени — предупреждение, а не украшение |
Общее устройство слоя — дока DM. Она отвечает на вопросы «почему так», задание отвечает на вопрос «что сделать».
Общие правила ступени 1
Они одни для пяти заданий по витринам ступени 1, поэтому записаны здесь, а не повторяются в каждом ТЗ.
Читать — через _v. Публичный договор сущности DDS — представление с
суффиксом _v: dds.event_v, dds.session_v. Витрина называет только
его; физические _rep и _dist служат загрузке и обслуживанию. Соседнюю
домашку витрина источником тоже не берет: витрина слоя DM читает договор
DDS, и задания остаются независимыми. Исключение одно и оно оговорено в
задании 4: у таблиц брака публичного договора нет.
Писать — только в _dist. При записи в локальную таблицу раскладку
определяет то, какая нода случайно выполняла код, а не свойство данных.
Правило и его следствия — дока хранилища,
«Раскладка по шардам».
Форма — по зерну. Витрина, меняющая зерно источника, материализуется:
dm.<имя>_rep / _dist, донор dm.<имя>_stage_rep / _stage_dist и
публичное dm.<имя>_v с явным списком колонок. Витрина, сохраняющая зерно,
остается обычным представлением. Довод — дока DM,
«Форма: по зерну, не по цене запроса».
Ключ шардирования — ваше решение. Ни одно ТЗ ключа не называет.
Правило выбора и требование к донору — дока
хранилища, «Раскладка по шардам»: донор
объявляется через AS <цель>_rep и шардируется тем же ключом, что цель,
иначе замена партиции потеряет строку на одном шарде и задвоит на другом.
Названный ключ надо уметь защитить: почему он не дает перекоса и почему
более сложный тут ничего не добавляет. Образец такой защиты —
dm.revenue_daily_dist в sql/ddl/55-dm-tables.sql.
Где лежит код. DDL домашек — свой файл sql/ddl/70-labs.sql: он
применяется после стендовых по порядку имени, и ваши объекты не мешаются
со стендовыми. У агрегатов рядом со стендовыми ложатся еще три запроса —
sql/dm/<витрина>_scope.sql спрашивает у хранилища, какие дни пересобирает
запуск, _rebuild.sql собирает их в донор, _replace.sql заменяет
партицию, — и задача в
dags/dm_transform.py. У разминочного
представления нет ничего из этого: весь его код — одно CREATE VIEW.
Образец на все случаи — витрина revenue_daily: у нее есть все пять
объектов, донор, сборка, замена дневных партиций и задача в конвейере.
Списывать с нее устройство можно и нужно; списывать состав колонок — нет,
он у каждой витрины свой.
Самопроверка ступени 1
Даг homework_check запускается рукой, расписания у него нет. Задача
витрины красная, пока витрины нет или счет не сходится, и зеленая, когда
собрано верно. В сводку качества конвейера dm.dq_summary он не пишет:
это инструмент лабы, а не история качества стенда.
Проверка пяти заданий по витринам устроена одинаково и золотых констант не
содержит: рядом с витриной независимым запросом собирается тот же ответ —
прямо из источника витрины, минуя ее саму. У четырех заданий источник эталона
тот же, что у витрины, dds.session_v или dds.event_v; у задания 4 это
таблицы брака ODS, потому что в DDS у брака представительства нет. Обе стороны
соединяются по деловому ключу через FULL OUTER JOIN, и считается число строк,
где стороны разошлись или одной стороны нет. Ноль — зеленый.
Полное соединение здесь обязательно: при обычном пропавший день или
пропавший ключ просто не попал бы в результат и остался бы незамечен.
Раздел «Как проверить себя» каждого ТЗ по витрине называет деловой ключ и
сравниваемые величины. Тот же прием в стендовом исполнении — даг
dq_check и запросы в sql/dq/.
Предупреждение. Запросы самой проверки лежат в sql/dq/ открыто, и
имена называют витрину и роль сверки. Проверка на инвариантах неизбежно
близка к ответу: чтобы сверить витрину, надо ее пересчитать. Прятать эти
файлы никто не станет — но открыв их до того, как задание сделано, вы
обменяете урок на готовый SQL.
Смотреть туда стоит после своей сборки: сравнить два решения полезно,
списать одно — нет.
Факультативы
Эти задания вы берете по желанию. Полный список сюжетов — в разделе «Факультативы — пять разделов» программы.
Почему выручка не сходится
Открывается после ступени 1. Расхождения между источниками, повторы покупок и день, после которого отчет можно считать окончательным.
Тонкий анализ данных
Открывается после ступени 1. Знание о пользователе на дату и обогащение отчета своим словарем.
Superset и BI
Открывается после ступени 2. Свой дашборд в Superset: свои объекты BI живут отдельно от стендовых.
Инженерия стенда
Открывается после ступени 1. Прием и хранение данных, раскладка по шардам, повторная обработка дня и обновление витрин.
Что делать, когда стенд сломался
Открывается после ступени 7. Поломки стенда и runbook по итогам расследований; весь раздел — повышенная сложность.
Уборка
Черновики и опыты за собой сносить: правило проверок стенда —
дока тестирования. Снесенная витрина обязана
снова покраснить свою задачу в homework_check — если не покраснила,
проверка ничего и не проверяла.