Compare commits

...
2 Commits
Author SHA1 Message Date
ddmitry 2a06582062 Merge pull request 'docs(handbook): раздел DDS главы о хранилище дополнен сессией и примером' (#235) from 234-dds-chapter into main
Reviewed-on: #235
2026-09-06 18:03:43 +03:00
ddadminandClaude Fable 5.1 e07484e9c2 docs(handbook): раздел DDS главы о хранилище дополнен сессией и примером
- Зачем:
  - ТЗ ступени 3 отправляет в главу за определением визита и доводом, почему
    стенд считает сессии сам; раздел давал о сессии одно предложение.
- Что:
  - в разделе «DDS: язык бизнеса» описаны договоренность о визите, роль
    Метрики и эталон VisitID, session_id и чтение через dds.session_v.
  - в «Посмотрите сами» добавлен запрос сессий дня между примерами ODS и DM,
    итоговая фраза переписана на три запроса.
- Проверка:
  - make lint; запрос к dds.session_v выполнен на стенде под analyst.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-06 10:59:35 -04:00
+33 -7
View File
@@ -48,9 +48,17 @@ DDS — детальный слой на языке бизнеса. Здесь
карта идентичностей. Карта связывает посетителя, то есть куку `ClientID`, с карта идентичностей. Карта связывает посетителя, то есть куку `ClientID`, с
пользователем магазина из заказа. пользователем магазина из заказа.
Сессия не приходит готовой из Kafka. Стенд сам выделяет ее из последовательных В стенде визитом считают подряд идущие события одной куки без пауз
событий одного посетителя. Здесь собраны сущности, с которыми дальше работают дольше 30 минут. Визит не пересекает границу модельных суток.
аналитики. Аналитик называет такой визит сессией.
В бою Метрика нарезает визиты сама и добавляет готовый `VisitID` в
события. Стенд играет ее роль: считает сессии из событий заново, а `VisitID`
оставляет эталоном для проверки. Иначе сборка сессий свелась бы к группировке
по чужому полю, и учиться было бы не на чем. Идентификатор сессии
`session_id` чеканит стенд: в событии его нет. Готовые сессии читайте через
`dds.session_v`. В `dds.event_v` поля `VisitID` нет: так сессии можно собрать
самому и сравнить с эталоном.
## DM: данные для дашбордов ## DM: данные для дашбордов
@@ -95,7 +103,7 @@ DM — слой витрин. Витрина — готовый набор по
Подключитесь к ClickHouse по инструкции из разделов [«Адреса и Подключитесь к ClickHouse по инструкции из разделов [«Адреса и
пароли»](../../README.md#адреса-и-пароли) и [«Подключиться из пароли»](../../README.md#адреса-и-пароли) и [«Подключиться из
DBeaver»](../../README.md#подключиться-из-dbeaver). В обоих примерах DBeaver»](../../README.md#подключиться-из-dbeaver). Во всех трех примерах
`2026-06-01` — это D0, первый день [стартового `2026-06-01` — это D0, первый день [стартового
мира](../../CONTEXT.md). Чтобы посмотреть другой день, замените мира](../../CONTEXT.md). Чтобы посмотреть другой день, замените
эту дату в условии. Первый запрос покажет эту дату в условии. Первый запрос покажет
@@ -114,7 +122,25 @@ ORDER BY UTCEventTime
LIMIT 20; LIMIT 20;
``` ```
Второй запрос покажет готовую выручку по категориям за тот же день: Второй запрос покажет сессии того же дня. Они рассчитаны из событий
первого запроса:
```sql
SELECT
client_id,
started_at,
finished_at,
events_total,
pageviews,
purchases,
entry_url
FROM dds.session_v
WHERE session_date = '2026-06-01'
ORDER BY events_total DESC
LIMIT 20;
```
Третий запрос покажет готовую выручку по категориям за тот же день:
```sql ```sql
SELECT SELECT
@@ -127,8 +153,8 @@ WHERE report_date = '2026-06-01'
ORDER BY revenue DESC; ORDER BY revenue DESC;
``` ```
Оба запроса читают поверхности `_v`. Первый показывает данные на языке Все три запроса читают поверхности `_v`. Первый показывает данные на языке
источника, второй — готовый ответ витрины. источника, второй — расчетную сущность, третий — готовый ответ витрины.
## Куда дальше ## Куда дальше