Merge pull request 'docs(labs): ТЗ ступени 3 «Нарежь сессии сам»' (#233) from 232-lab-sessions into main
Reviewed-on: #233
This commit was merged in pull request #233.
This commit is contained in:
ddmitry committed
commit
4c95dc3a5b
2 files changed
+91
-2
No files matched your search
@@ -0,0 +1,89 @@
|
||||
# Нарежь сессии сам
|
||||
|
||||
**Чему учит:** собрать сессии из событий и сверить их число с внешним
|
||||
эталоном. Найти причину расхождения в отдельных строках.
|
||||
|
||||
## Сначала прочитать
|
||||
|
||||
- [Хранилище и его слои, раздел DDS](../handbook/storage-layers.md#dds-язык-бизнеса);
|
||||
- [формат события: Идентификаторы и время](../formats/clickstream-event.md#идентификаторы-и-время).
|
||||
|
||||
## Роль сессии
|
||||
|
||||
Визит, или сессия, объединяет действия посетителя за один заход на сайт.
|
||||
По визитам аналитик считает длительность и глубину просмотра.
|
||||
В хранилище сессии собираются из отдельных событий.
|
||||
Сверьте самостоятельный расчет с `VisitID`, чтобы увидеть, как из событий
|
||||
получается сессия.
|
||||
|
||||
## Что сделать
|
||||
|
||||
### Нарезка
|
||||
|
||||
В SQL Lab или DBeaver под `analyst` напишите запрос к `ods.event_v`.
|
||||
Для своей нарезки и эталона возьмите одни и те же строки за все доступные
|
||||
дни: для расследования понадобятся события соседних дней.
|
||||
Выберите `ClientID`, `UTCEventTime`, `EventDate`, `EventType` и `VisitID`.
|
||||
В `dds.event_v` эталонного `VisitID` нет.
|
||||
|
||||
Для начала считайте визитом последовательные события одной куки (`ClientID`);
|
||||
пауза дольше 30 минут открывает новый визит.
|
||||
Учитывайте события всех типов. Упорядочите их по `UTCEventTime`.
|
||||
Присвойте каждому событию номер своей сессии внутри куки.
|
||||
Подсказка: оконные функции.
|
||||
|
||||
Днем сессии считайте `EventDate` ее первого события: дата из `UTCEventTime`
|
||||
отличается от `EventDate` для части событий, поэтому берите `EventDate`.
|
||||
При сверке останутся расхождения из-за еще одной договоренности стенда.
|
||||
|
||||
### Сверка с эталоном
|
||||
|
||||
В эталоне посчитайте число визитов каждой куки за модельный день:
|
||||
|
||||
```sql
|
||||
SELECT ClientID, EventDate, uniqExact(VisitID) AS reference_sessions
|
||||
FROM ods.event_v
|
||||
GROUP BY ClientID, EventDate
|
||||
ORDER BY EventDate, ClientID;
|
||||
```
|
||||
|
||||
Посчитайте свои сессии по куке и дню сессии.
|
||||
Соедините два готовых агрегата через `FULL OUTER JOIN` по куке и дню.
|
||||
В результате полного соединения останутся ключи обеих сторон: при расхождении
|
||||
на вашей стороне ключа может не быть совсем. Учтите такие строки при сравнении.
|
||||
Выведите сводку по дням с числом разошедшихся кук и список этих кук
|
||||
с днем и обоими значениями счета. Общая сумма за день могла бы скрыть
|
||||
взаимную компенсацию ошибок разных кук. По списку видно, у кого искать причину.
|
||||
|
||||
Расхождений будет всего несколько. Если их нет, мир прожил мало дней.
|
||||
Прогоните несколько дней через [даги модельного времени](../handbook/airflow-dags.md#даги-мира)
|
||||
и повторите сверку.
|
||||
|
||||
### Расследование
|
||||
|
||||
Выберите одну разошедшуюся куку. Выведите ее события за два соседних дня
|
||||
с `UTCEventTime`, `EventDate`, `VisitID` и номером своей сессии.
|
||||
Сопоставьте сессии через события: общего ключа у двух нарезок нет,
|
||||
зато у каждого события есть и `VisitID`, и присвоенный вами номер.
|
||||
Найдите два соседних события, между которыми границы визитов разошлись.
|
||||
Запишите куку, день, время обоих событий и причину одним предложением.
|
||||
Уточните определение визита и добейтесь нуля расхождений во всех днях.
|
||||
|
||||
## Как проверить себя
|
||||
|
||||
Результат задания проверяется глазами, поэтому задачи в `homework_check`
|
||||
для него нет. Таблицы и представления создавать не нужно.
|
||||
Сохраните исходный и уточненный расчеты, результаты сверки и найденные строки.
|
||||
|
||||
**Предупреждение.** В `sql/dds/session_rebuild.sql` и
|
||||
`sql/dq/sessions_vs_reference.sql` лежат готовые запросы нарезки и сверки.
|
||||
Откройте их после собственного решения и расследования. Сравните запросы
|
||||
со своими: копирование готового SQL пропускает расследование.
|
||||
Сопоставление со стендовой нарезкой по `session_id` остается на ступень 4.
|
||||
|
||||
## Приемка
|
||||
|
||||
- [ ] запрос нарезает все события `ods.event_v` за все доступные дни;
|
||||
- [ ] сверка через `FULL OUTER JOIN` дает сводку по дням и список кук;
|
||||
- [ ] при разборе расхождения указаны кука, день, два события и причина;
|
||||
- [ ] уточненный расчет дает ноль расхождений во всех днях.
|
||||
+2
-2
@@ -10,13 +10,13 @@
|
||||
|---|---|---|
|
||||
| 1 | Пять витрин слоя DM | построить результат для потребителя хранилища; уроки каждой витрины — в таблице ниже |
|
||||
| 2 | [Свой график в Superset](2-1-superset-chart.md) | превратить свой результат из хранилища в отчет в BI |
|
||||
| 3 | Нарежь сессии сам | сравнить свою нарезку визитов с эталоном по числу сессий и найти причину расхождения в отдельных событиях |
|
||||
| 3 | [Нарежь сессии сам](3-1-sessions-by-hand.md) | сверить число сессий в своей нарезке с эталоном и найти события, из-за которых оно расходится |
|
||||
| 4 | Перепиши нарезку стенда | изменить расчетную сущность внутри готового конвейера и проверить ее внешним эталоном |
|
||||
| 5 | Сначала сторож, потом ломай: заказы | написать проверки качества до рискованного изменения, а не после первой поломки |
|
||||
| 6 | Разбери сырые события и сверь результат со стендом | изучить разбор потока отдельно от живого приема и сверить его со стендовым результатом |
|
||||
| 7 | Мониторинг: куда смотреть | выбрать, куда и на что смотреть в живой системе |
|
||||
|
||||
ТЗ для ступеней 3–7 появятся по мере продвижения программы.
|
||||
ТЗ для ступеней 4-7 появятся по мере продвижения программы.
|
||||
|
||||
## Ступень 1: пять витрин слоя DM
|
||||
|
||||
|
||||
Reference in new issue
Block a user