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

New Issue

2026-08-16T19:17:07+03:00

ddmitry commented

2026-08-16 19:17:07 +03:00

Part of #69.

Вопрос

Нужно ли сохранять _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, когда у служебной колонки появится конкретный
читатель.

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

резолюцию тикета
«Брак в слепке: куда уходит и по каким классам»;
docs/architecture/storage.md, раздел «Служебные колонки»;
docs/adr/0008-order-ingestion.md.

Part of #69. ## Вопрос Нужно ли сохранять `_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 added a new dependency 2026-08-16 19:19:49 +03:00

#80 Брак в слепке: куда уходит и по каким классам

ddmitry referenced this issue

2026-08-16 19:20:43 +03:00

Карта: проектирование заказов бэкенда (этап 3) #69

ddmitry referenced this issue

2026-08-16 19:22:04 +03:00

Брак в слепке: куда уходит и по каким классам #80

ddmitry referenced this issue

2026-08-16 22:14:42 +03:00

Собрать спеку заказов из решений развилок #87