From e07484e9c2c48fae0586094a884ddcb264e835c1 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sun, 6 Sep 2026 10:59:35 -0400 Subject: [PATCH] =?UTF-8?q?docs(handbook):=20=D1=80=D0=B0=D0=B7=D0=B4?= =?UTF-8?q?=D0=B5=D0=BB=20DDS=20=D0=B3=D0=BB=D0=B0=D0=B2=D1=8B=20=D0=BE=20?= =?UTF-8?q?=D1=85=D1=80=D0=B0=D0=BD=D0=B8=D0=BB=D0=B8=D1=89=D0=B5=20=D0=B4?= =?UTF-8?q?=D0=BE=D0=BF=D0=BE=D0=BB=D0=BD=D0=B5=D0=BD=20=D1=81=D0=B5=D1=81?= =?UTF-8?q?=D1=81=D0=B8=D0=B5=D0=B9=20=D0=B8=20=D0=BF=D1=80=D0=B8=D0=BC?= =?UTF-8?q?=D0=B5=D1=80=D0=BE=D0=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - ТЗ ступени 3 отправляет в главу за определением визита и доводом, почему стенд считает сессии сам; раздел давал о сессии одно предложение. - Что: - в разделе «DDS: язык бизнеса» описаны договоренность о визите, роль Метрики и эталон VisitID, session_id и чтение через dds.session_v. - в «Посмотрите сами» добавлен запрос сессий дня между примерами ODS и DM, итоговая фраза переписана на три запроса. - Проверка: - make lint; запрос к dds.session_v выполнен на стенде под analyst. Co-Authored-By: Claude Fable 5.1 --- docs/handbook/storage-layers.md | 40 +++++++++++++++++++++++++++------ 1 file changed, 33 insertions(+), 7 deletions(-) diff --git a/docs/handbook/storage-layers.md b/docs/handbook/storage-layers.md index 3494bfe..780af86 100644 --- a/docs/handbook/storage-layers.md +++ b/docs/handbook/storage-layers.md @@ -48,9 +48,17 @@ DDS — детальный слой на языке бизнеса. Здесь карта идентичностей. Карта связывает посетителя, то есть куку `ClientID`, с пользователем магазина из заказа. -Сессия не приходит готовой из Kafka. Стенд сам выделяет ее из последовательных -событий одного посетителя. Здесь собраны сущности, с которыми дальше работают -аналитики. +В стенде визитом считают подряд идущие события одной куки без пауз +дольше 30 минут. Визит не пересекает границу модельных суток. +Аналитик называет такой визит сессией. + +В бою Метрика нарезает визиты сама и добавляет готовый `VisitID` в +события. Стенд играет ее роль: считает сессии из событий заново, а `VisitID` +оставляет эталоном для проверки. Иначе сборка сессий свелась бы к группировке +по чужому полю, и учиться было бы не на чем. Идентификатор сессии +`session_id` чеканит стенд: в событии его нет. Готовые сессии читайте через +`dds.session_v`. В `dds.event_v` поля `VisitID` нет: так сессии можно собрать +самому и сравнить с эталоном. ## DM: данные для дашбордов @@ -95,7 +103,7 @@ DM — слой витрин. Витрина — готовый набор по Подключитесь к ClickHouse по инструкции из разделов [«Адреса и пароли»](../../README.md#адреса-и-пароли) и [«Подключиться из -DBeaver»](../../README.md#подключиться-из-dbeaver). В обоих примерах +DBeaver»](../../README.md#подключиться-из-dbeaver). Во всех трех примерах `2026-06-01` — это D0, первый день [стартового мира](../../CONTEXT.md). Чтобы посмотреть другой день, замените эту дату в условии. Первый запрос покажет @@ -114,7 +122,25 @@ ORDER BY UTCEventTime 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 SELECT @@ -127,8 +153,8 @@ WHERE report_date = '2026-06-01' ORDER BY revenue DESC; ``` -Оба запроса читают поверхности `_v`. Первый показывает данные на языке -источника, второй — готовый ответ витрины. +Все три запроса читают поверхности `_v`. Первый показывает данные на языке +источника, второй — расчетную сущность, третий — готовый ответ витрины. ## Куда дальше -- 2.54.0