Особенности JOIN
В интерфейсе создания датасета можно объединять данные, перетаскивая таблицы на рабочую область и настраивая связи между ними через оператор JOIN
. Для таблиц YTsaurus такое объединение вызывает ошибку. Ошибка возникает из-за структуры хранения таблиц и схемы выполнения запросов в YTsaurus по умолчанию. Чтобы избежать ошибки, используйте SQL-запрос к источнику.
Хранение табличных данных
Схема хранения таблиц в YTsaurus принципиально отличается от таковой в ClickHouse®:
-
В YTsaurus базовый примитив хранения данных — статическая таблица, строки которой лежат по чанкам, произвольным образом распределенным по кластеру. По умолчанию данные распределяются по шардам согласно некоторому ключу шардирования. Статические таблицы крайне неэффективны в задачах, которые требуют точечного чтения данных.
Примечание
В ClickHouse® шардирование обеспечивает локальность строк с одним значением выражения шардирования на одной машине.
-
В YTsaurus поддерживается понятие сортированной таблицы — в схеме таблицы может учитываться, что ее строки сортированы по некоторому префиксу колонок. Такие колонки называются ключевыми. Это более эффективный примитив хранения данных — динамическая таблица.
Примечание
В YTsaurus сортировка обеспечивает локальность строк с одним значением ключа в одном чанке (либо в наборе подряд идущих).
Простой SELECT-запрос в CHYT
SELECT-запрос, не содержащий оператора JOIN
, по своей сути является потоковым. В нем происходит чтение данных из единственного источника и последующая обработка строк. Возможно применение к полям функций и агрегаций.
В CHYT такой запрос реализован следующим образом:
- На некоторый инстанс клики поступает такой запрос. Данный инстанс называется координатором запроса, так как он определяет дальнейший план выполнения.
- Координатор отправляет в каждый инстанс по внутреннему tcp-протоколу переписанный запрос. В этом запросе вместо названия входной таблицы подставлена закодированная последовательность
chunk slice
, гдеchunk slice
это некоторый диапазон внутри одного чанка. (Диапазон задается граничными номерами строк или ключами.) - Каждый инстанс исполняет переписанный запрос, и возвращает координатору результат исполнения, тот производит финальную агрегацию (если нужно) и уже отвечает пользователю.
Виды запросов с JOIN в ClickHouse®
Как и в случае с простым запросом, SELECT-запрос с использованием оператора JOIN
поступает на инстанс клики, который называется координатором запроса. Координатор запроса определяет дальнейший план выполнения, а распределение нагрузки между инстансами определяется вариантом исполнения конструкции lhs JOIN rhs USING/ON
:
-
Distributed local JOIN выполняется в ClickHouse® по умолчанию. Если таблицы шардированы одинаковым образом, то совпадающая пара ключей не может оказаться на разных машинах. Таким образом,
lhs
иrhs
на каждом инстансе интерпретируются как соответствующие им локальные таблицы. При этом разбитый координатором на части запрос можно исполнять независимо на каждом инстансе.Примечание
Метод требует использование одинаковой схемы шардирования на таблицах.
-
GLOBAL JOIN выполняется, если использовать ключевое слово
GLOBAL
рядом сJOIN
. На координаторе запроса полностью исполняется и материализуется правый аргументrhs
. Затем его сериализованное представление рассылается вместе с запросом по инстансам. Инстансы используют это представление для получения правой части в своей памяти. Подробнее см. в документации .Примечание
- Данный метод эффективен, когда
rhs
сравнительно небольшого размера, а инстансов сравнительно немного. Иначе может возникнуть нехватка ресурсов при выполненииrhs
на координаторе, или при раздаче координатором по сети сериализованного представления с подзапросом. - Метод не требует никаких дополнительных условий на согласованность схемы хранения/шардирования на таблицах.
- Данный метод эффективен, когда
-
JOIN via subqueries. ClickHouse® позволяет заключить
lhs
и/илиrhs
в скобки, и это существенно влияет на план исполнения:Окружить lhs в скобкиОкружить rhs в скобки- На координаторе независимо исполняется левая часть.
- Независимо исполняется правая часть.
- Правая часть помещается в оперативную память в хеш-таблицу.
- Происходит полное исполнение
JOIN
только на координаторе.
-
На координаторе независимо исполняется левая часть, как если бы запрос выглядел просто как SELECT
lhs
. -
Координатор отправляет на инстансы свои запросы, оставив
JOIN
(rhs
) как есть. -
Каждый инстанс исполняет
rhs
независимо.Примечание
Это может привести к кратно большей нагрузке, так как каждый инстанс будет материализовывать правую часть независимо. Поэтому защитный механизм в ClickHouse® по умолчанию запрещает такое поведение и приводит к ошибке
Double-distributed IN/JOIN subqueries is denied
.
Особенность запросов с JOIN в CHYT
При выполнении SELECT-запроса с использованием оператора JOIN
в CHYT по умолчанию действует логика Sorted JOIN. Она основана на одинаковой схеме сортировки колонок. Используется обычная конструкция lhs JOIN rhs USING/ON
.
При этом на lhs
и rhs
налагаются дополнительные ограничения:
- Части
lhs
иrhs
должны быть сортированными таблицами. - В условии
USING/ON
должны использоваться только отсортированные колонки.
Например:
- Пусть
lhs
отсортирована по колонкамl1, l2, ..., ln
, аrhs
— по колонкамr1, r2, ..., rm
. - Условие
JOIN
ON
должно выглядеть как набор равенствl1 = r1 , ..., lk = rk
для некоторогоk
(сами равенства могут идти в произвольном порядке). - Это может быть выражено как набором равенств в условии
ON
, так и набором общих ключевых колонок в конструкцииUSING
, но не набором равенств в условииWHERE
.
При соблюдении этих условий координатор запроса формирует пары соответствующих диапазонов из lhs
и rhs
и распределяет их по инстансам в подзапросах.
Если же это условие не выполнено, выходит ошибка. В этом случае следует либо использовать GLOBAL JOIN
, либо заключать правую часть (rhs
) в подзапрос.
ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc