From 94a1ffeee26596d1316ca45456fb4c57258d7948 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sat, 22 Aug 2026 04:28:51 -0400 Subject: [PATCH] =?UTF-8?q?docs(ods):=20=D0=BE=D0=BF=D0=B8=D1=81=D0=B0?= =?UTF-8?q?=D0=BD=D0=B0=20=D1=81=D0=B5=D0=BC=D0=B0=D0=BD=D1=82=D0=B8=D0=BA?= =?UTF-8?q?=D0=B0=20snapshot=5Fdate=20=D0=BF=D0=BE=D1=81=D0=BB=D0=B5=20?= =?UTF-8?q?=D1=81=D1=85=D0=BB=D0=BE=D0=BF=D1=8B=D0=B2=D0=B0=D0=BD=D0=B8?= =?UTF-8?q?=D1=8F=20=D0=B2=D0=B5=D1=80=D1=81=D0=B8=D0=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - проверка #137 показала: у заказа, не менявшегося несколько дней, версию выбирает только updated_at, и какая из одинаковых строк переживёт схлопывание — не обещано; snapshot_date выжившей строки означал не то, что обещала документация (у 86 заказов стартового мира выжил серединный день наблюдения). - Что: - в docs/architecture/orders/ingestion.md записано: snapshot_date, _load_id и _load_ts выжившей строки — координаты одного из наблюдений версии, не обязательно последнего; допущение «уточнение поднимает updated_at» названо допущением с границей применимости. - та же оговорка — в комментарии DDL ods.order_rep. - Проверка: - замеры на живом стенде: во всех 3034 парах строк с равным updated_at деловые поля совпали побайтово; монотонность updated_at по слепкам — без нарушений; ods.order_v сошёлся с эталоном argMax из сырья построчно. Co-Authored-By: Claude Opus 5 (1M context) --- docs/architecture/orders/ingestion.md | 19 +++++++++++++++++++ sql/ddl/20-ods-tables.sql | 5 ++++- 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/docs/architecture/orders/ingestion.md b/docs/architecture/orders/ingestion.md index 321d8a5..1a612e3 100644 --- a/docs/architecture/orders/ingestion.md +++ b/docs/architecture/orders/ingestion.md @@ -106,6 +106,25 @@ JSON-объектом с точным набором ключей: `order_id`, ` - `_load_id` — какой запуск Airflow принял строку; - `_load_ts` — когда строка приехала в хранилище. +У выжившей после схлопывания строки три последние координаты означают меньше, +чем кажется. Версию выбирает только `updated_at`; заказ, не менявшийся +несколько дней, приезжает в нескольких слепках одинаковыми деловыми полями, и +какая из этих строк переживёт схлопывание — не обещано. Поэтому её +`snapshot_date` — *один из* дней, когда источник показывал эту версию, не +обязательно последний; то же с `_load_id` и `_load_ts`. Замер 22 августа +2026 года (#137): у 86 заказов стартового мира выжил даже не крайний день, а +серединный. Вопрос «когда заказ наблюдался в последний раз» задаётся сырью STG, +пока его не съел срок жизни, — а не одной строке ODS. + +Вся схема версий стоит на одном свойстве источника: уточнение заказа поднимает +`updated_at`. Наш генератор моделирует источник с триггерной меткой и это +свойство гарантирует; замеры 22 августа 2026 года его подтвердили — во всех +парах строк с равным `updated_at` деловые поля совпали побайтово, а по слепкам +метка не убывала ни разу. Это допущение, а не закон природы: источник, умеющий +уточнить строку тихо — правка мимо приложения, миграция, ручной `UPDATE`, — +эту схему ломает, и тогда версии по метке времени уже не хватает, нужна сверка +самих полей (в терминах dbt snapshots — стратегия `check` вместо `timestamp`). + Обычное чтение `_dist` показывает физически сохранившиеся версии и нужно для диагностики. Их число зависит от фоновых слияний: ODS не служит архивом истории. `ods.order_v` сохраняет те же источник-ориентированные поля без обогащения diff --git a/sql/ddl/20-ods-tables.sql b/sql/ddl/20-ods-tables.sql index 3e56a52..35070c4 100644 --- a/sql/ddl/20-ods-tables.sql +++ b/sql/ddl/20-ods-tables.sql @@ -163,7 +163,10 @@ ENGINE = Distributed('clickstream_cluster', 'ods', 'event_errors_rep', cityHash6 -- updated_at — какая бизнес-версия новее; snapshot_date — в слепке какого -- модельного дня источник показал строку; _load_id — какой запуск Airflow её -- принял; _load_ts — когда она приехала в хранилище. Ключом сущности не --- становится ни одна из трёх последних: они про наблюдение и загрузку. +-- становится ни одна из трёх последних: они про наблюдение и загрузку. Версию +-- выбирает только updated_at, поэтому у выжившей после схлопывания строки +-- snapshot_date — один из дней, когда источник показывал эту версию, не +-- обязательно последний (docs/architecture/orders/ingestion.md). -- -- PARTITION BY toDate(created_at) — по дню создания строки в источнике. Он -- неизменен у всех версий заказа, поэтому версии лежат в одной партиции и