Особенности JOIN в Yandex DataLens
В интерфейсе создания датасета можно объединять данные, перетаскивая таблицы на рабочую область и настраивая связи между ними через оператор 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. - Условие
JOINONдолжно выглядеть как набор равенствl1 = r1 , ..., lk = rkдля некоторогоk(сами равенства могут идти в произвольном порядке). - Это может быть выражено как набором равенств в условии
ON, так и набором общих ключевых колонок в конструкцииUSING, но не набором равенств в условииWHERE.
При соблюдении этих условий координатор запроса формирует пары соответствующих диапазонов из lhs и rhs и распределяет их по инстансам в подзапросах.
Если же это условие не выполнено, выходит ошибка. В этом случае следует либо использовать GLOBAL JOIN, либо заключать правую часть (rhs) в подзапрос.
ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc