ddmitry/clickstream-data-platform
1
0 Fork 0
Code Issues 5 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Трассировка загрузки: нужен ли _load_id выше ODS #85

New Issue
Closed
opened 2026-08-16 19:17:07 +03:00 by ddmitry · 2 comments
ddmitry commented 2026-08-16 19:17:07 +03:00
Owner
Copy link
Copy source

Отложенный вопрос этапа 4 (#6): решается при проектировании dds.order, когда у служебной колонки появится читатель. С карты #69 выведен за границу — её маршрут кончается нарезкой этапа 3.

Вопрос

Нужно ли сохранять _load_id заказа выше ODS и, если да, какой смысл он имеет
после преобразований DDS и агрегаций DM?

Почему вопрос появился

«Брак в слепке: куда уходит и по каким классам»
определил _load_id как run_id Airflow: по нему одна прочитанная порция
связывает сырьё, годные строки и ошибки. На границе ODS читатель у этой
координаты назван. Выше одна строка может быть собрана из нескольких загрузок,
поэтому механическое копирование одного идентификатора уже может врать.

Что решить

  • нужен ли _load_id в dds.order или достаточно служебных времён и
    бизнес-версии updated_at;
  • если преобразование объединяет несколько загрузок, хранится один победивший
    запуск, множество запусков или отдельная связь происхождения;
  • доходит ли эта координата до DM либо заканчивается на технических слоях.

Границы

  • Не пересматривать принятый смысл _load_id в STG и ODS.
  • Не строить универсальную систему происхождения данных ради одного источника.
  • Не выбирать здесь способ чтения ODS (FINAL, argMax или инкрементальный
    приём): это часть проектирования самой загрузки DDS.

Когда решать

Вместе с устройством dds.order, когда у служебной колонки появится конкретный
читатель.

Сначала прочитать

Отложенный вопрос этапа 4 (#6): решается при проектировании `dds.order`, когда у служебной колонки появится читатель. С карты #69 выведен за границу — её маршрут кончается нарезкой этапа 3. ## Вопрос Нужно ли сохранять `_load_id` заказа выше ODS и, если да, какой смысл он имеет после преобразований DDS и агрегаций DM? ## Почему вопрос появился [«Брак в слепке: куда уходит и по каким классам»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/80) определил `_load_id` как `run_id` Airflow: по нему одна прочитанная порция связывает сырьё, годные строки и ошибки. На границе ODS читатель у этой координаты назван. Выше одна строка может быть собрана из нескольких загрузок, поэтому механическое копирование одного идентификатора уже может врать. ## Что решить - нужен ли `_load_id` в `dds.order` или достаточно служебных времён и бизнес-версии `updated_at`; - если преобразование объединяет несколько загрузок, хранится один победивший запуск, множество запусков или отдельная связь происхождения; - доходит ли эта координата до DM либо заканчивается на технических слоях. ## Границы - Не пересматривать принятый смысл `_load_id` в STG и ODS. - Не строить универсальную систему происхождения данных ради одного источника. - Не выбирать здесь способ чтения ODS (`FINAL`, `argMax` или инкрементальный приём): это часть проектирования самой загрузки DDS. ## Когда решать Вместе с устройством `dds.order`, когда у служебной колонки появится конкретный читатель. ## Сначала прочитать - резолюцию тикета [«Брак в слепке: куда уходит и по каким классам»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/80); - `docs/architecture/storage.md`, раздел «Служебные колонки»; - `docs/adr/0008-order-ingestion.md`.
ddmitry added the wayfinder:grilling label 2026-08-16 19:17:07 +03:00
ddmitry self-assigned this 2026-08-17 22:12:49 +03:00
ddmitry commented 2026-08-17 22:17:21 +03:00
Author
Owner
Copy link
Copy source

Выведен за границу карты #69: вопрос решается вместе с устройством dds.order, а это этап 4 (#6) — на карте заказов у служебной колонки читателя нет. Тикет остаётся открытым и ждёт входа в этап 4, постановка в теле самодостаточна. Указатели принятой спеки (docs/architecture/orders/ingestion.md, orders/README.md) продолжают показывать сюда — потому не закрыт: закрытие прозвучало бы как «решён».

Выведен за границу карты #69: вопрос решается вместе с устройством `dds.order`, а это этап 4 (#6) — на карте заказов у служебной колонки читателя нет. Тикет остаётся открытым и ждёт входа в этап 4, постановка в теле самодостаточна. Указатели принятой спеки (`docs/architecture/orders/ingestion.md`, `orders/README.md`) продолжают показывать сюда — потому не закрыт: закрытие прозвучало бы как «решён».
ddmitry removed their assignment 2026-08-17 22:17:26 +03:00
ddmitry added the wontfix label 2026-08-20 11:46:29 +03:00
ddmitry commented 2026-08-20 11:46:42 +03:00
Author
Owner
Copy link
Copy source

Резолюция

У задачи нет самостоятельного предмета решения. Состав dds.order и данные, которые он читает из ods.order_v, определяются вместе с моделью DDS. Если _load_id понадобится конкретному читателю, это будет видно при проектировании модели; отдельный общий вопрос заранее не нужен.

Смысл _load_id в STG и ODS не меняется. Задача закрывается с wontfix.

## Резолюция У задачи нет самостоятельного предмета решения. Состав `dds.order` и данные, которые он читает из `ods.order_v`, определяются вместе с моделью DDS. Если `_load_id` понадобится конкретному читателю, это будет видно при проектировании модели; отдельный общий вопрос заранее не нужен. Смысл `_load_id` в STG и ODS не меняется. Задача закрывается с `wontfix`.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No labels wayfinder:grilling wontfix
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#80 Брак в слепке: куда уходит и по каким классам
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#85