docs(labs): упрощен язык учебных заданий
- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок. - Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки. - Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.
This commit is contained in:
ddadmin committed
1 parent
3c3eb825e1
commit
4693bc5af9
24 files changed
+782
-684
No files matched your search
@@ -1,28 +1,42 @@
|
||||
# Задание 4: `dm.dq_errors_daily`
|
||||
# Задание 4: ошибки загрузки по дням, `dm.dq_errors_daily`
|
||||
|
||||
**Чему учит:** считать брак по дню загрузки и сохранять сводку дольше
|
||||
исходных строк.
|
||||
Вы соберете дневную сводку ошибок загрузки. Ее итоги должны сохраниться
|
||||
и после того, как исходные сообщения будут удалены из хранилища.
|
||||
|
||||
## Сначала прочитать
|
||||
## Подготовка
|
||||
|
||||
- [«Хранилище и его слои»](../handbook/storage-layers.md);
|
||||
- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
|
||||
|
||||
## Для чего нужна витрина
|
||||
## Ошибки загрузки и их источники
|
||||
|
||||
Сводку открывают при росте брака в потоке: смотрят, каких ошибок стало
|
||||
больше и сколько строк забраковано. Причину конкретной ошибки исследуют
|
||||
в `ods.event_errors_dist` и `ods.order_errors_dist`, где есть сырой текст и
|
||||
координаты доставки.
|
||||
Если сообщение не удалось разобрать, стенд записывает его в таблицу ошибок.
|
||||
Такие строки дальше называются браком. Вы соберете сводку, по которой можно
|
||||
увидеть, каких ошибок стало больше и сколько строк забраковано.
|
||||
|
||||
## Что сделать
|
||||
Источники сводки:
|
||||
|
||||
Зерно — **день загрузки × источник × класс брака**. В источнике зерно —
|
||||
строка брака. Зерно новое, поэтому витрина хранится готовым агрегатом — см.
|
||||
[«Как принято на ступени 1»](README.md#как-принято-на-ступени-1). Создайте
|
||||
пять объектов: `dm.dq_errors_daily_rep` / `_dist`, донор `_stage_rep` /
|
||||
`_stage_dist` и публичное представление `dm.dq_errors_daily_v`. Ключ
|
||||
партиции — день загрузки.
|
||||
- `ods.event_errors_dist`: ошибки разбора событий;
|
||||
- `ods.order_errors_dist`: ошибки разбора выгрузки заказов.
|
||||
|
||||
В этих таблицах есть исходный текст сообщения и сведения о его доставке:
|
||||
они пригодятся при поиске причины ошибки. Представлений `_v` у таблиц ошибок
|
||||
нет, создавать их для задания не нужно. Чтение локальной таблицы `_rep`
|
||||
даст строки только одного шарда из двух, поэтому используйте `_dist`.
|
||||
|
||||
## Создание сводки
|
||||
|
||||
В результате нужна одна строка на день загрузки, источник и класс ошибки.
|
||||
Например, ошибки `field_invalid` в заказах за один день загрузки попадут
|
||||
в одну строку с их количеством.
|
||||
|
||||
Создайте пять объектов по [общим правилам ступени 1](README.md#создание-и-обновление-витрин):
|
||||
|
||||
- основные таблицы `dm.dq_errors_daily_rep` и `dm.dq_errors_daily_dist`;
|
||||
- промежуточные таблицы `dm.dq_errors_daily_stage_rep` и `dm.dq_errors_daily_stage_dist`;
|
||||
- представление для чтения `dm.dq_errors_daily_v`.
|
||||
|
||||
Разбейте данные на партиции по дням загрузки.
|
||||
|
||||
### Состав колонок
|
||||
|
||||
@@ -41,16 +55,17 @@
|
||||
Служебная `_load_ts` витрины описывает сборку сводки; ее дата может
|
||||
отличаться от `load_date`.
|
||||
|
||||
У событий и заказов свои классы брака. `source` входит в зерно, чтобы
|
||||
одинаковые имена классов с разным смыслом не объединялись в одну строку.
|
||||
У событий и заказов свои классы брака. Группируйте строки также по `source`,
|
||||
чтобы одноименные классы разных источников не объединялись.
|
||||
|
||||
### Ритм пересборки
|
||||
### Пересчет и хранение итогов
|
||||
|
||||
Брак хранится месяц по `TTL`, сырые данные — трое суток. Сводка хранится
|
||||
бессрочно: итоги нужны и после удаления исходных строк.
|
||||
Правило `TTL` удаляет строки брака через месяц, сырые данные через трое суток.
|
||||
Сводку храните бессрочно: итоги нужны и после удаления исходных строк.
|
||||
|
||||
Получите список дней загрузки, еще имеющихся в источниках. Соберите их в
|
||||
донор и замените только эти партиции, сохранив остальные.
|
||||
Получите список дней загрузки, еще имеющихся в источниках. Рассчитайте их
|
||||
итоги в промежуточной таблице и замените только эти партиции основной таблицы.
|
||||
Более старые итоги сохраните.
|
||||
|
||||
В течение текущих суток ошибки еще поступают: пересчитайте этот день на
|
||||
следующем прогоне.
|
||||
@@ -60,36 +75,23 @@
|
||||
Выберите ключ самостоятельно. Классов брака у событий и заказов вместе
|
||||
меньше десятка. Объясните, насколько существенен перекос при таком объеме.
|
||||
|
||||
Ключ донора — тот же, что у цели (см. [«Как принято на ступени
|
||||
1»](README.md#как-принято-на-ступени-1) и раздел «Раскладка по шардам»
|
||||
[справочника хранилища](../architecture/storage.md)).
|
||||
|
||||
## Источники: таблицы `_dist`
|
||||
|
||||
Только это задание читает данные не через `_v`: брак нужен для диагностики
|
||||
приема и не входит в бизнес-модель. Публичных представлений у таблиц ошибок
|
||||
нет, создавать их для задания не нужно. Источники:
|
||||
|
||||
- `ods.event_errors_dist` — ошибки разбора событий;
|
||||
- `ods.order_errors_dist` — ошибки разбора слепка заказов.
|
||||
|
||||
Чтение локальной `_rep` даст строки одного шарда из двух: часть брака не
|
||||
попадет в сводку, хотя запрос выполнится без ошибки.
|
||||
У основной и промежуточной таблиц должен быть одинаковый ключ шардирования:
|
||||
см. [общие правила ступени 1](README.md#создание-и-обновление-витрин).
|
||||
|
||||
## Типичная ошибка
|
||||
|
||||
Если заменить всю таблицу данными из нового донора, исчезнут итоги дней,
|
||||
истекших по `TTL` источника. Восстановить их неоткуда.
|
||||
Если заменить всю сводку новым расчетом, исчезнут итоги дней, за которые
|
||||
исходные строки уже удалены по `TTL`. Восстановить эти итоги неоткуда.
|
||||
|
||||
## Как проверить себя
|
||||
## Проверка результата
|
||||
|
||||
Деловой ключ — `source` и `error_class` внутри `load_date`. Проверяйте дни,
|
||||
оставшиеся хотя бы в одной таблице ошибок. Если дня за пределами `TTL` уже
|
||||
нет в источнике, это не ошибка: сверять его уже не с чем.
|
||||
Сопоставляйте строки по `load_date`, `source` и `error_class`. Проверяйте дни,
|
||||
оставшиеся хотя бы в одной таблице ошибок. Старые итоги, для которых исходные
|
||||
строки уже удалены по `TTL`, сверять не с чем.
|
||||
|
||||
Посчитайте строки прямо в обеих таблицах ошибок и соедините результат с
|
||||
`dm.dq_errors_daily_v` полным внешним соединением по ключу. Затем посчитайте
|
||||
строки, где ключ отсутствует с одной из сторон или различается `error_rows`.
|
||||
`dm.dq_errors_daily_v` через `FULL OUTER JOIN` по этим трем полям. Посчитайте
|
||||
строки, которые есть только с одной стороны или у которых различается `error_rows`.
|
||||
Расхождений должно быть ноль.
|
||||
|
||||
Сумма `error_rows` по проверяемым дням равна общему числу строк в
|
||||
@@ -99,10 +101,10 @@
|
||||
Если в источниках нет брака, витрина должна быть пустой. В этом случае
|
||||
расхождений тоже ноль и проверка успешна.
|
||||
|
||||
## Что должно получиться
|
||||
## Результат работы
|
||||
|
||||
- [ ] у вас есть пять объектов витрины; донор объявлен через `AS` и
|
||||
использует ключ шардирования целевой таблицы;
|
||||
- [ ] у вас есть пять объектов витрины; промежуточная таблица объявлена через
|
||||
`AS` и использует ключ шардирования основной;
|
||||
- [ ] сводка включает ошибки событий и заказов из таблиц `_dist`;
|
||||
- [ ] ваш запрос пересобирает только дни, еще доступные в источниках,
|
||||
сохраняя более старые итоги;
|
||||
|
||||
Reference in new issue
Block a user