Определить место словарей в структуре ClickHouse #105

New Issue

2026-08-19T07:32:00+03:00

ddmitry commented

2026-08-19 07:32:00 +03:00

Контекст

В #95 и PR #104 словарь товаров создан как dds.products: это соответствует текущей карте объектов в мастер-спеке, но отдельного решения «почему словари принадлежат DDS» нет. Словарь — одновременно бизнес-справочник и механизм ClickHouse, а будущий словарь регионов может иметь другого владельца и других потребителей.

Нужно отделить случайно унаследованное место первого словаря от общего правила. Учебный вопрос: должен ли менти читать словарь как часть слоя модели данных, как самостоятельные справочные данные или как инфраструктурный объект — и какую дополнительную конструкцию он платит за это различие.

Цель

Решить, где должны находиться словари ClickHouse и нужно ли одно правило для всех словарей. Если dds остаётся домом, обосновать его наравне с альтернативами, а не принимать текущую реализацию за доказательство.

Веер для рассмотрения

Веер не ограничивает исследование, но обязан включать как минимум:

текущий вариант: все бизнес-словари живут в dds;
отдельную базу справочников вне цепочки STG → ODS → DDS → DM;
размещение рядом с владельцем данных или предметной областью;
размещение рядом с главным потребителем;
отказ от единого правила: место определяется происхождением и жизненным циклом конкретного словаря;
нулевой вариант: не вводить правило до появления второго реального словаря.

До оценки дополнить веер хотя бы одним вариантом, который оспаривает рамку «база ClickHouse — главный способ выразить принадлежность словаря».

Критерии решения

чему расположение учит менти и сколько новых исключений или баз заставляет его держать в голове;
не врёт ли место словаря о направлении данных между слоями;
кто владеет содержимым, DDL и политикой обновления;
кто читает словарь: etl, bi, analyst, объекты DDS и витрины DM;
как решение ведёт себя для каталога товаров и будущего словаря регионов;
насколько ясно устроены имена, права, документация и поиск объекта в клиенте;
какова цена переноса уже созданного dds.products.

Критерии приёмки

Сначала построен полный веер вариантов, затем отдельным проходом выполнена оценка.
Каждый вариант проверен по всем критериям выше; у отклонённых записана причина.
Дана одна рекомендация и названы условия, при которых её придётся пересмотреть.
Решение не выводится только из того, где сейчас лежит dds.products.
Итог записан в ADR; при изменении текущего решения тем же PR согласованы мастер-спека и docs/architecture/storage.md.
Если нужен перенос объектов, для него создана отдельная задача с командами проверки; в эту задачу реализация не входит.

Границы

Не переносить и не переименовывать dds.products в рамках исследования.
Не проектировать содержимое будущего словаря регионов.
Не менять слои, роли и права ради удобства одного варианта.
Не заводить универсальную абстракцию словарей: предмет решения — дом и правило принадлежности, а не новый механизм.

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

CONTEXT.md: «Хранилище», «Каталог товаров».
мастер-спека docs/specs/2026-07-30-stand-v2-realism.md, разделы 3 и 7;
docs/architecture/storage.md, разделы «Словарь товаров», «Раскладка SQL», «Карта таблиц»;
ADR 0005 — направление слоёв;
ADR 0006 — имена объектов и исключение для словарей;
ADR 0007 — границы доступа etl, bi, analyst.

Способ работы

Вести развилку через brainstorm-with-docs: сначала веер без оценки, затем конвергенция. До принятого решения никаких правок DDL и инфраструктуры.

## Контекст В #95 и PR #104 словарь товаров создан как `dds.products`: это соответствует текущей карте объектов в мастер-спеке, но отдельного решения «почему словари принадлежат DDS» нет. Словарь — одновременно бизнес-справочник и механизм ClickHouse, а будущий словарь регионов может иметь другого владельца и других потребителей. Нужно отделить случайно унаследованное место первого словаря от общего правила. Учебный вопрос: должен ли менти читать словарь как часть слоя модели данных, как самостоятельные справочные данные или как инфраструктурный объект — и какую дополнительную конструкцию он платит за это различие. ## Цель Решить, где должны находиться словари ClickHouse и нужно ли одно правило для всех словарей. Если `dds` остаётся домом, обосновать его наравне с альтернативами, а не принимать текущую реализацию за доказательство. ## Веер для рассмотрения Веер не ограничивает исследование, но обязан включать как минимум: - текущий вариант: все бизнес-словари живут в `dds`; - отдельную базу справочников вне цепочки `STG → ODS → DDS → DM`; - размещение рядом с владельцем данных или предметной областью; - размещение рядом с главным потребителем; - отказ от единого правила: место определяется происхождением и жизненным циклом конкретного словаря; - нулевой вариант: не вводить правило до появления второго реального словаря. До оценки дополнить веер хотя бы одним вариантом, который оспаривает рамку «база ClickHouse — главный способ выразить принадлежность словаря». ## Критерии решения - чему расположение учит менти и сколько новых исключений или баз заставляет его держать в голове; - не врёт ли место словаря о направлении данных между слоями; - кто владеет содержимым, DDL и политикой обновления; - кто читает словарь: `etl`, `bi`, `analyst`, объекты DDS и витрины DM; - как решение ведёт себя для каталога товаров и будущего словаря регионов; - насколько ясно устроены имена, права, документация и поиск объекта в клиенте; - какова цена переноса уже созданного `dds.products`. ## Критерии приёмки - [x] Сначала построен полный веер вариантов, затем отдельным проходом выполнена оценка. - [x] Каждый вариант проверен по всем критериям выше; у отклонённых записана причина. - [x] Дана одна рекомендация и названы условия, при которых её придётся пересмотреть. - [x] Решение не выводится только из того, где сейчас лежит `dds.products`. - [x] Итог записан в ADR; при изменении текущего решения тем же PR согласованы мастер-спека и `docs/architecture/storage.md`. - [ ] Если нужен перенос объектов, для него создана отдельная задача с командами проверки; в эту задачу реализация не входит. ## Границы - Не переносить и не переименовывать `dds.products` в рамках исследования. - Не проектировать содержимое будущего словаря регионов. - Не менять слои, роли и права ради удобства одного варианта. - Не заводить универсальную абстракцию словарей: предмет решения — дом и правило принадлежности, а не новый механизм. ## Сначала прочитать - `CONTEXT.md`: «Хранилище», «Каталог товаров». - мастер-спека `docs/specs/2026-07-30-stand-v2-realism.md`, разделы 3 и 7; - `docs/architecture/storage.md`, разделы «Словарь товаров», «Раскладка SQL», «Карта таблиц»; - ADR 0005 — направление слоёв; - ADR 0006 — имена объектов и исключение для словарей; - ADR 0007 — границы доступа `etl`, `bi`, `analyst`. ## Способ работы Вести развилку через `brainstorm-with-docs`: сначала веер без оценки, затем конвергенция. До принятого решения никаких правок DDL и инфраструктуры.

ddmitry added the ready-for-agent label 2026-08-19 07:32:00 +03:00

ddmitry referenced this issue

2026-08-20 11:35:55 +03:00

Правка настройки ClickHouse не доезжает до контейнера #106

ddmitry referenced this issue from a commit

2026-08-20 11:37:39 +03:00

feat(clickhouse): справочники вынесены в зону dic, словарь читает подложку

ddmitry referenced a pull request that will close this issue

2026-08-20 11:38:01 +03:00

feat(clickhouse): справочники вынесены в зону dic, словарь читает подложку #107

ddmitry closed this issue

2026-08-20 12:26:42 +03:00

ddmitry commented

2026-08-20 12:28:43 +03:00

Закрыто слиянием PR #107. Пять критериев приёмки выполнены и отмечены; шестой
оставлен неотмеченным намеренно.

«Если нужен перенос объектов, для него создана отдельная задача» — снят
владельцем по ходу работы: отдельный тикет ради нескольких строк правки был
признан раздуванием процесса. Перенос dds.products → dic.products уехал
этим же PR вместе с решением.

Там же, вопреки границе «до принятого решения никаких правок DDL», решено и
устройство словаря: под ним появилась подложка dic.products_file на движке
File, а сам словарь читает её источником CLICKHOUSE. Это тоже решение
владельца, принятое после написания постановки.

Итог решения — ADR 0012.
Побочная находка замера вынесена отдельным багом #106: правка файлов настройки
ClickHouse не доезжает до живого контейнера.

Закрыто слиянием PR #107. Пять критериев приёмки выполнены и отмечены; шестой оставлен неотмеченным намеренно. **«Если нужен перенос объектов, для него создана отдельная задача»** — снят владельцем по ходу работы: отдельный тикет ради нескольких строк правки был признан раздуванием процесса. Перенос `dds.products` → `dic.products` уехал этим же PR вместе с решением. Там же, вопреки границе «до принятого решения никаких правок DDL», решено и устройство словаря: под ним появилась подложка `dic.products_file` на движке `File`, а сам словарь читает её источником `CLICKHOUSE`. Это тоже решение владельца, принятое после написания постановки. Итог решения — [ADR 0012](../src/branch/main/docs/adr/0012-dictionary-home.md). Побочная находка замера вынесена отдельным багом #106: правка файлов настройки ClickHouse не доезжает до живого контейнера.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ddmitry/clickstream-data-platform#105