Зачем: убрать механические повторы в итогах и избежать ложных расхождений при проверке графика Superset. Что: уточнены правила итоговых списков и название задания о проверках заказов. В разборе событий разделены учет повторных доставок и выбор событий ODS для сравнения. Первый график Superset и проверочный SQL используют весь период витрины. Проверка: git diff --check, локальные ссылки и переходы к измененным заголовкам прошли. Блоки кода и таблицы требований сохранены. Согласованность периода графика с SQL проверена по тексту; повторный проход через интерфейс Superset не выполнялся.
7.1 KiB
Задание 1: dm.events_enriched_v
Чему учит: подготовить удобный для анализа набор полей события и обойтись представлением, сохранив одну строку на событие.
Сначала прочитать
- «Хранилище и его слои».
- Как применить свой DDL: файл для решения и подключение с правами на создание витрины.
Для чего нужна витрина
В 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. У события с тремя
позициями получится три строки. Зерно изменится. Витрину с новым зерном на
стенде хранят готовым агрегатом — причины описаны в разделе «Как принято на
ступени 1».
Главная опасность — потеря событий с пустым массивом товаров: ARRAY JOIN
исключает их из результата. Товары есть только в событиях корзины и покупки.
Поэтому исчезнет большинство событий — девятнадцать строк из двадцати.
Запрос выполнится без ошибки, а витрина по имени и составу колонок
по-прежнему будет выглядеть таблицей событий.
Сохраните массивы как в источнике. Для анализа отдельных товарных позиций нужна другая витрина с другим зерном и именем.
Как проверить себя
После применения DDL откройте Airflow по адресу из README,
найдите даг homework_check и запустите его вручную. В новом запуске откройте
задачу events_enriched: она должна завершиться успешно. Если задача
красная, откройте ее журнал (Logs) — там будет причина ошибки, а при
расхождениях с источником — дни и примеры несовпадений. Задачи еще не
созданных витрин будут красными; это ожидаемо и не мешает проверке первой.
Деловой ключ — event_id внутри дня. Получите результат прямо из
dds.event_v за тот же день. Соедините его с витриной полным внешним
соединением по event_id. Посчитайте строки, где ключ отсутствует с одной
из сторон или различаются значения деловых колонок. Расхождений должно быть
ноль.
Отдельно сверьте event_hour, page_path и referer_host с теми же
выражениями, рассчитанными прямо по dds.event_v.
Что должно получиться
- у вас есть
dm.events_enriched_vс явно перечисленными колонками; - вы сверили число строк и набор
event_idсdds.event_vза каждый прожитый день; расхождений нет; - проверка
events_enrichedвhomework_checkпрошла успешно; - витрина работает без физической таблицы и задачи в
dm_transform.