ddadmin
4693bc5af9
- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок. - Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки. - Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.
96 lines
7.1 KiB
Markdown
96 lines
7.1 KiB
Markdown
# Задание 1: события для анализа, `dm.events_enriched_v`
|
||
|
||
Вы подготовите представление с полями для анализа событий. Оно будет
|
||
добавлять вычисляемые поля при чтении, сохраняя одну строку на событие.
|
||
|
||
## Подготовка
|
||
|
||
- [«Хранилище и его слои»](../handbook/storage-layers.md).
|
||
- [Выполнение SQL в DBeaver](README.md#выполнение-sql-в-dbeaver): файл для решения
|
||
и подключение с правами на создание витрины.
|
||
|
||
## Данные для анализа событий
|
||
|
||
В `dds.event_v` 44 колонки, включая технические поля источника и массивы
|
||
товаров. Для анализа событий в Superset нужны сведения о посетителе и его
|
||
действиях, а также три вычисляемых поля: час события, путь страницы и домен,
|
||
с которого пришел посетитель. Тогда вам не придется
|
||
повторять эти выражения в каждом запросе.
|
||
|
||
Витрины следующих заданий читают DDS напрямую. Использовать
|
||
`dm.events_enriched_v` как источник для них не нужно: задания независимы, их
|
||
можно выполнять в любом порядке.
|
||
|
||
## Создание представления
|
||
|
||
Создайте обычное представление `CREATE VIEW dm.events_enriched_v`.
|
||
Единственный источник: `dds.event_v`. Каждой строке источника должна
|
||
соответствовать ровно одна строка витрины: одно событие.
|
||
|
||
Представление выполняет запрос при чтении и не хранит отдельную копию данных.
|
||
Для него не нужно создавать таблицы или добавлять задачу в `dm_transform`.
|
||
|
||
Укажите колонки явно. Иначе новая колонка источника попадет в витрину
|
||
автоматически. Отчет получит ее, даже если вы не собирались менять его набор
|
||
полей.
|
||
|
||
| Группа | Колонки |
|
||
|---|---|
|
||
| Время и посетитель | `event_date`, `event_time`, `event_hour`, `client_id`, `event_id` |
|
||
| Действие | `event_type` (`pageview`, `add_to_cart`, `purchase`), `url`, `page_path`, `referer`, `referer_host`, `title` |
|
||
| UTM-метки | `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term` |
|
||
| Устройство и регион | `device_category`, `browser`, `operating_system`, `region_country`, `region_city` |
|
||
| Товары и покупка | `product_id`, `product_name`, `product_category`, `product_price`, `product_quantity`, `product_event_type`, `purchase_id`, `purchase_revenue`, `purchase_coupon` |
|
||
|
||
Три колонки вычислите в представлении. Остальные возьмите из источника без
|
||
изменений, сохранив массивы `product_*`.
|
||
|
||
| Колонка | Как считается | Для чего нужна |
|
||
|---|---|---|
|
||
| `event_hour` | `toHour(event_time)` | Анализ событий по часам суток |
|
||
| `page_path` | путь `url` без домена и параметров | Группировка по странице |
|
||
| `referer_host` | домен `referer` | Анализ источников перехода |
|
||
|
||
Не добавляйте `_load_id` и `_load_ts`. Их нет и у `dds.event_v`: события в
|
||
DDS читают из ODS без отдельной загрузки. Эти служебные поля указывают на
|
||
запуск, который записал строку на диск. Представление ничего не загружает.
|
||
|
||
## Типичная ошибка
|
||
|
||
Не разворачивайте массивы товаров через `ARRAY JOIN`. У события с тремя
|
||
позициями получится три строки вместо одной.
|
||
|
||
Главная опасность — потеря событий с пустым массивом товаров: `ARRAY JOIN`
|
||
исключает их из результата. Товары есть только в событиях корзины и покупки.
|
||
Поэтому исчезнет большинство событий — девятнадцать строк из двадцати.
|
||
Запрос выполнится без ошибки, а витрина по имени и составу колонок
|
||
по-прежнему будет выглядеть таблицей событий.
|
||
|
||
Сохраните массивы как в источнике. Для анализа отдельных товарных позиций
|
||
нужна отдельная витрина, где одна строка соответствует товарной позиции.
|
||
|
||
## Проверка результата
|
||
|
||
После применения DDL откройте Airflow по [адресу из README](../../README.md#адреса-и-пароли),
|
||
найдите даг `homework_check` и запустите его вручную. В новом запуске откройте
|
||
задачу `events_enriched`: она должна завершиться успешно. Если задача
|
||
красная, откройте ее журнал (`Logs`) — там будет причина ошибки, а при
|
||
расхождениях с источником — дни и примеры несовпадений. Задачи еще не
|
||
созданных витрин будут красными; это ожидаемо и не мешает проверке первой.
|
||
|
||
Выберите день и прочитайте его события из `dds.event_v` и своей витрины.
|
||
Сопоставьте строки по `event_id` через `FULL OUTER JOIN`.
|
||
Найдите события, которые есть только с одной стороны, и события, у которых
|
||
различаются перенесенные из источника поля. Расхождений должно быть ноль.
|
||
|
||
Отдельно сверьте `event_hour`, `page_path` и `referer_host` с теми же
|
||
выражениями, рассчитанными прямо по `dds.event_v`.
|
||
|
||
## Результат работы
|
||
|
||
- [ ] у вас есть `dm.events_enriched_v` с явно перечисленными колонками;
|
||
- [ ] вы сверили число строк и набор `event_id` с `dds.event_v` за каждый
|
||
прожитый день; расхождений нет;
|
||
- [ ] проверка `events_enriched` в `homework_check` прошла успешно;
|
||
- [ ] витрина работает без физической таблицы и задачи в `dm_transform`.
|