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

GLOBAL JOIN двух Distributed-таблиц на стенде #129

New Issue
Closed
opened 2026-08-22 10:26:15 +03:00 by ddmitry · 1 comment
ddmitry commented 2026-08-22 10:26:15 +03:00
Owner
Copy link
Copy source

Part of #127.

Вопрос

Как ведёт себя соединение двух Distributed-таблиц на нашем кластере: где
выполняется JOIN, что даёт GLOBAL для правой части, как влияет
distributed_product_mode — и что из этого следует для двух построек
этапа 4: сборки dds.identity_map (заказы подтягиваются через GLOBAL
JOIN, спека §5) и витрины сверки purchase_vs_orders_v
(FULL OUTER GLOBAL JOIN, спека §7).

Это хвост раздела 11 мастер-спеки («эмпирически на стенде», остаток #14).

Как проверять

  • Эмпирически на стенде, читающими запросами по существующим
    Distributed-таблицам событий и заказов: EXPLAIN и живое соединение
    на малом срезе; смотреть, куда уходят подзапросы
    (system.query_log — чтение, не запись).
  • Документация ClickHouse через MCP Context7: GLOBAL JOIN,
    distributed_product_mode, ко-локация по ключу шардирования.

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

  • мастер-спека, разделы 5 и 7;
  • docs/architecture/storage.md, раздел «Раскладка по шардам».
Part of #127. ## Вопрос Как ведёт себя соединение двух Distributed-таблиц на нашем кластере: где выполняется JOIN, что даёт `GLOBAL` для правой части, как влияет `distributed_product_mode` — и что из этого следует для двух построек этапа 4: сборки `dds.identity_map` (заказы подтягиваются через GLOBAL JOIN, спека §5) и витрины сверки `purchase_vs_orders_v` (FULL OUTER GLOBAL JOIN, спека §7). Это хвост раздела 11 мастер-спеки («эмпирически на стенде», остаток #14). ## Как проверять - Эмпирически на стенде, читающими запросами по существующим Distributed-таблицам событий и заказов: `EXPLAIN` и живое соединение на малом срезе; смотреть, куда уходят подзапросы (`system.query_log` — чтение, не запись). - Документация ClickHouse через MCP Context7: `GLOBAL JOIN`, `distributed_product_mode`, ко-локация по ключу шардирования. ## Сначала прочитать - мастер-спека, разделы 5 и 7; - `docs/architecture/storage.md`, раздел «Раскладка по шардам».
ddmitry added the wayfinder:research label 2026-08-22 10:26:18 +03:00
ddmitry self-assigned this 2026-08-22 10:28:23 +03:00
ddmitry commented 2026-08-22 10:39:40 +03:00
Author
Owner
Copy link
Copy source

Проверено на живом стенде (26.3.17.56, читающие запросы, следы в system.query_log по log_comment r129-*) и по документации ClickHouse через Context7.

Вывод: обычный JOIN/IN двух Distributed режется заводским distributed_product_mode='deny'; GLOBAL собирает правую часть один раз на инициаторе и рассылает временную таблицу data* на шарды (видно в журнале второй ноды); режим local верен только при настоящей ко-локации, иначе молча занижает ответ. Подзапрос слева переносит всё соединение на инициатор — GLOBAL и режим тогда ни на что не влияют. FULL OUTER с голой левой Distributed задваивает непарные строки правой части (по разу с шарда); с подзапросами с обеих сторон — верно, и purchase_vs_orders_v это условие выполняет естественно. Для identity_map GLOBAL JOIN заказов корректен и дёшев.

Попутная находка: ко-локация заказов по cityHash64(order_id) сломана — 1189 из 1662 заказов лежат на обоих шардах, count() по ods.order_dist даёт 2851 при 1662 заказах. Причина — заводское parallel_distributed_insert_select=2: INSERT…SELECT из Distributed в Distributed пишется локально на шардах, и заказы унаследовали раскладку сырья. События целы. Починка — отдельным тикетом.

Заметка: docs/research/2026-08-22-distributed-join.md, влита в main (PR #140).

Проверено на живом стенде (26.3.17.56, читающие запросы, следы в system.query_log по log_comment r129-*) и по документации ClickHouse через Context7. Вывод: обычный JOIN/IN двух Distributed режется заводским distributed_product_mode='deny'; GLOBAL собирает правую часть один раз на инициаторе и рассылает временную таблицу _data_* на шарды (видно в журнале второй ноды); режим local верен только при настоящей ко-локации, иначе молча занижает ответ. Подзапрос слева переносит всё соединение на инициатор — GLOBAL и режим тогда ни на что не влияют. FULL OUTER с голой левой Distributed задваивает непарные строки правой части (по разу с шарда); с подзапросами с обеих сторон — верно, и purchase_vs_orders_v это условие выполняет естественно. Для identity_map GLOBAL JOIN заказов корректен и дёшев. Попутная находка: ко-локация заказов по cityHash64(order_id) сломана — 1189 из 1662 заказов лежат на обоих шардах, count() по ods.order_dist даёт 2851 при 1662 заказах. Причина — заводское parallel_distributed_insert_select=2: INSERT…SELECT из Distributed в Distributed пишется локально на шардах, и заказы унаследовали раскладку сырья. События целы. Починка — отдельным тикетом. Заметка: docs/research/2026-08-22-distributed-join.md, влита в main (PR #140).
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:research
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees ddmitry
1 Participants
Notifications
Due Date
No due date set.
Blocks
#133 Сборка identity_map: трансформация и повторы
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#129