docs(handbook): упрощен язык путеводителя по стенду

Зачем: помочь учащемуся понять путь данных и работу служб перед выполнением заданий.

Что: вычитаны оглавление и пять глав, пояснены термины, убраны внутренние метафоры и повторы. Уточнены пояснения к SQL и показателям мониторинга.

Проверка: 62 локальные ссылки и 6 входящих ссылок на разделы проверены; 8 блоков SQL и схем сохранены. git diff --cached --check прошел.

docs/handbook/storage-layers.md

@@ -2,7 +2,8 @@
 
 В хранилище приходят два потока из Kafka: в топике `hits` — события
 кликстрима, в `orders` — заказы магазина. Оба проходят один путь: STG → ODS →
-DDS → DM. Каждый слой отвечает на свой вопрос.
+DDS → DM. В STG сообщения сохраняются как есть, в ODS разбираются по полям,
+в DDS из них собираются события, заказы и сессии, а в DM — витрины для отчетов.
 
 ```mermaid
 flowchart LR
@@ -11,54 +12,54 @@ flowchart LR
 
 ## Как читать имена
 
-Для обычного чтения выбирайте объекты с суффиксом `_v`. Это представления:
-их устройство может поменяться, а ваш запрос останется прежним. Суффиксы
-`_rep`, `_dist`, `_kafka` и `_mv` относятся к внутреннему
-устройству хранилища. Они нужны для загрузки, обслуживания и диагностики.
-У словарей есть исключение: у `dic.products` нет суффикса, потому что
-различать нечего — объект один.
+Для обычного чтения выбирайте представления с суффиксом `_v`. Они позволяют
+менять устройство таблиц, сохраняя привычные запросы к данным.
+Суффиксы `_rep`, `_dist`, `_kafka` и `_mv` относятся к внутреннему устройству
+хранилища. Эти объекты нужны для загрузки, обслуживания и диагностики.
+У словаря товаров `dic.products` суффикса нет.
 Подробный разбор имен есть в [справочнике
 хранилища](../architecture/storage.md#имена-объектов).
 
 ## STG: как поступило
 
-STG — сырой слой. Он сохраняет сообщение целой строкой, без разбора. Рядом
-лежат метаданные доставки: топик, партиция, смещение и время приема. Поэтому в
-STG можно увидеть, что именно приехало из Kafka, даже если сообщение
-испорчено.
+STG — сырой слой. Он сохраняет сообщение целой строкой, без разбора. Вместе
+с ним записываются сведения о доставке: топик, партиция, смещение и время
+приема. Содержимое сообщения сохраняется в STG, даже если в нем есть ошибки.
 
-Срок хранения — трое суток реального времени. Этого хватает для расследования
-и повторного разбора, но старые строки не занимают диск вечно. Точное правило
-— в [справочнике
+Сырые сообщения хранятся трое суток реального времени. В течение этого срока
+их можно использовать для поиска ошибок и повторной обработки. Затем они
+удаляются по правилу из [справочника
 хранилища](../architecture/storage.md#срок-жизни-сырых-данных).
 
 ## ODS: язык источника
 
-ODS — слой разобранных данных. Строка получает типы: дата становится датой,
-число — числом. Имена полей остаются на языке источника. Например, событие
-сохраняет колонки `WatchID`, `ClientID` и `EventDate`.
+В ODS содержимое сообщения разбирается на колонки с нужными типами данных:
+датами, числами, строками. Колонки сохраняют имена из источника. Например,
+в таблице событий есть `WatchID`, `ClientID` и `EventDate`.
 
 Испорченное сообщение не останавливает загрузку. Оно попадает в таблицу
-`*_errors` вместе с сырой строкой и классом ошибки. Так брак остается виден, а
-годные строки продолжают движение.
+`*_errors` вместе с исходной строкой и классом ошибки. Правильно записанные
+сообщения обрабатываются дальше.
 
 ## DDS: язык бизнеса
 
-DDS — детальный слой на языке бизнеса. Здесь есть событие, заказ, сессия и
-карта идентичностей. Карта связывает посетителя, то есть куку `ClientID`, с
-пользователем магазина из заказа.
+DDS — детальный слой: в нем данные подготовлены для анализа событий,
+заказов и сессий. Здесь же хранится карта идентичностей — таблица связей
+между идентификатором посетителя `ClientID` и пользователем магазина
+из заказа. `ClientID` хранится в cookie браузера: по нему можно узнать
+браузер посетителя, но не всегда самого человека.
 
-В стенде визитом считают подряд идущие события одной куки без пауз
-дольше 30 минут. Визит не пересекает границу модельных суток.
-Аналитик называет такой визит сессией.
+В стенде визитом, или сессией, считают подряд идущие события одного
+`ClientID` без пауз дольше 30 минут. Визит не пересекает границу модельных суток.
 
-В бою Метрика нарезает визиты сама и добавляет готовый `VisitID` в
-события. Стенд играет ее роль: считает сессии из событий заново, а `VisitID`
-оставляет эталоном для проверки. Иначе сборка сессий свелась бы к группировке
-по чужому полю, и учиться было бы не на чем. Идентификатор сессии
-`session_id` чеканит стенд: в событии его нет. Готовые сессии читайте через
-`dds.session_v`. В `dds.event_v` поля `VisitID` нет: так сессии можно собрать
-самому и сравнить с эталоном.
+Источник передает готовый идентификатор визита `VisitID` по образцу
+Яндекс Метрики. В учебном хранилище сессии рассчитываются заново по времени
+событий; каждой присваивается `session_id`. Поле `VisitID` остается
+эталоном для проверки. Так в заданиях вы сможете самостоятельно определить
+границы сессий и сравнить их с результатом источника.
+
+Готовые сессии читайте через `dds.session_v`. События для самостоятельного
+расчета доступны в `dds.event_v`: в этом представлении `VisitID` скрыт.
 
 ## DM: данные для дашбордов
 
@@ -70,32 +71,31 @@ DM — слой витрин. Витрина — готовый набор по
 путь расчета. Состав готовых витрин смотрите в [карте
 таблиц](../architecture/storage.md#карта-таблиц).
 
-## Сбоку цепочки: зона `dic`
+## Справочные данные: зона `dic`
 
-Зона `dic` стоит вне пути STG → ODS → DDS → DM. В ней живут справочные данные,
-которые хранилище получает готовыми. Ни один слой их не производит, а читать
-может любой.
+В базе `dic` хранятся готовые справочные данные. Они загружаются отдельно
+от событий и заказов и могут использоваться в расчетах любого слоя.
 
-Первый справочник стенда — каталог товаров `dic.products`. Его ключ `sku` —
+Каталог товаров `dic.products` — один из таких справочников. Его ключ `sku` —
 артикул товара. По нему можно узнать название, бренд и категорию товара. Как
 устроена зона, смотрите в [разделе о
 справочниках](../architecture/storage.md#справочники).
 
 ## Сквозные ключи
 
-Один и тот же смысл проходит через слои под разными именами: имя меняется
-вместе с языком слоя. Таблица показывает исходное имя и то, где искать тот же
-смысл дальше.
+Идентификаторы позволяют связать данные из разных слоев. При переходе в DDS
+часть колонок переименовывается: например, `WatchID` становится `event_id`.
+В таблице указано, как найти соответствующие колонки и соединить по ним данные.
 
 | Колонка | Что означает | Что соединяет |
 |---|---|---|
 | `WatchID` | Идентификатор события | Событие ODS с событием DDS, где колонка называется `event_id` |
-| `ClientID` | Посетитель, то есть кука | События ODS с событиями, сессиями и картой идентичностей DDS; в DDS колонка называется `client_id` |
+| `ClientID` | Идентификатор посетителя из cookie браузера | События ODS с событиями, сессиями и картой идентичностей DDS; в DDS колонка называется `client_id` |
 | `order_id` | Идентификатор заказа | Заказ ODS с заказом DDS и витриной сверки `dm.purchase_vs_orders_v` |
 | `sku` | Артикул товара в каталоге | Справочник `dic.products` с позициями заказа DDS, где артикулы лежат в `item_sku`; через категорию товара — с витриной выручки DM |
-| `EventDate` | День на [оси модельного времени](../../CONTEXT.md), который счетчик сайта проставляет в [своем часовом поясе](../architecture/storage.md#часовые-пояса) | Событие ODS с событием DDS, где колонка называется `event_date`, и дневными расчетами DM |
+| `EventDate` | Дата события в [модельном времени](../../CONTEXT.md), указанная счетчиком сайта в [его часовом поясе](../architecture/storage.md#часовые-пояса) | Событие ODS с событием DDS, где колонка называется `event_date`, и дневными расчетами DM |
 
-Что здесь значит «посетитель» и чем кука отличается от человека, объясняет
+Почему идентификатор посетителя не равнозначен человеку, объясняет
 [словарь понятий](../../CONTEXT.md#язык). Точные имена объектов и полей сверяйте с
 [картой таблиц](../architecture/storage.md#карта-таблиц).
 
@@ -104,10 +104,10 @@ DM — слой витрин. Витрина — готовый набор по
 Подключитесь к ClickHouse по инструкции из разделов [«Адреса и
 пароли»](../../README.md#адреса-и-пароли) и [«Подключиться из
 DBeaver»](../../README.md#подключиться-из-dbeaver). Во всех трех примерах
-`2026-06-01` — это D0, первый день [стартового
-мира](../../CONTEXT.md). Чтобы посмотреть другой день, замените
-эту дату в условии. Первый запрос покажет
-события одного модельного дня:
+`2026-06-01` — первый день работы учебного магазина. В документации он
+обозначается D0; подробнее — в [словаре понятий](../../CONTEXT.md).
+Чтобы посмотреть другой день, замените дату в условии.
+Первый запрос покажет 20 событий за выбранный день:
 
 ```sql
 SELECT
@@ -122,8 +122,8 @@ ORDER BY UTCEventTime
 LIMIT 20;
 ```
 
-Второй запрос покажет сессии того же дня. Они рассчитаны из событий
-первого запроса:
+Второй запрос покажет 20 сессий того же дня с наибольшим числом событий.
+Сессии рассчитаны по всем событиям дня:
 
 ```sql
 SELECT
@@ -153,14 +153,13 @@ WHERE report_date = '2026-06-01'
 ORDER BY revenue DESC;
 ```
 
-Все три запроса читают поверхности `_v`. Первый показывает данные на языке
-источника, второй — расчетную сущность, третий — готовый ответ витрины.
+Все три запроса читают представления `_v`.
 
 ## Куда дальше
 
 Откройте [интерактивную карту](architecture-map.html) из своей копии
 репозитория и проследите путь данных.
 Список объектов, сроки хранения и устройство таблиц — в [справочнике
-хранилища](../architecture/storage.md). Как данные переносят между слоями — в
+хранилища](../architecture/storage.md). Как данные обрабатываются между слоями — в
 следующей главе: [потоки Airflow и даги модельного
 времени](airflow-dags.md).