7 февраля 2025 года вышел очередной релиз ClickHouse. Знакомимся с его главными новинками: ускорение параллельного хэш-соединения, индексы MinMax на уровне таблицы, автоинкременты полей и улучшенное объединение таблиц с табличной функцией merge.
Улучшение параллельного хэш-соединения в ClickHouse 25.1
В ClickHouse 25.1 добавлено 15 новых функций, 36 улучшений и 77 исправлений ошибок. Одним из наиболее значимых изменений стало ускорение параллельного хэш-соединения. Хотя оно уже было самым быстрым алгоритмом соединения хэш-таблиц в памяти ClickHouse и работало как стратегия по умолчанию с версии 24.11, в новом релизе введена дополнительная оптимизация на низком уровне. Начиная с 24.12 ClickHouse может автоматически определять, какую таблицу в JOIN-запросе следует использовать для параллельного хэш-соединения на этапе сборки. В 25.1 ускорен алгоритм на этапе probe. Раньше параллельное хэш-соединение в ClickHouse выполнялось следующим образом:
- сперва на этапе сборки (build) данные из правой таблицы разделяются и обрабатываются параллельно потоками обработки для параллельного заполнения N экземпляров хэш-таблицы. Каждый поток обработки запускает цикл загрузки следующего необработанного блока строк из правой таблицы и применения хэш-функции к ключам соединения каждой строки, чтобы потом взять результат по модулю числа потоков для определения целевого экземпляра хэш-таблицы. Функция вставки хэша применяется к ключам соединения и использует результат в качестве ключа для вставки данных строки в выбранный экземпляр хеш-таблицы.
- на этапе зондирования (probe) данные из левой таблицы разделяются и обрабатываются параллельно N потоками обработки (количество потоков N регулируется настройкой max_threads). Каждый поток обработки запускает цикл загрузки следующего необработанного блока строк из левой таблицы и применяет вставку хэша, что использовалось на этапе сборки, к ключам соединения каждой строки. Затем берется результат по модулю числа потоков, чтобы определить экземпляр хэш-таблицы поиска. Функция вставки хэша, что использовалась на этапе сборки, применяется к ключам соединения и берется результат для выполнения поиска в выбранном экземпляре хеш-таблицы. Если поиск успешен и значения ключей соединения совпадают, возвращаются объединенные строки.
Этап сборки параллельного хэш-соединения ускоряет обработку за счет одновременного заполнения нескольких хеш-таблиц. Поскольку хэш-таблицы не являются потокобезопасными для параллельных вставок, непараллельное хэш-соединение выполняет все вставки в одном потоке, что может стать узким местом для больших таблиц в запросах на соединение. Однако хэш-таблицы являются потокобезопасными для параллельных чтений, что позволяет этапу probe в непараллельном хэш-соединении эффективно читать данные из одной хэш-таблицы параллельно. Напротив, фаза сборки параллельного хэш-соединения вносит накладные расходы, поскольку входные блоки из левой таблицы сначала должны быть разделены и направлены в соответствующие экземпляры хэш-таблицы. Чтобы решить эту проблему, на этапе probe теперь используется одна общая хэш-таблица, к которой все потоки обработки могут обращаться одновременно, как и в непараллельном хэш-соединении. Это устраняет необходимость в разделении входных блоков, снижает накладные расходы и повышает эффективность.
В новой версии фаза сборки по-прежнему выполняется параллельно. Однако, когда задано максимальное количество потоков (max_threads), равное N, вместо параллельного заполнения N отдельных экземпляров хэш-таблицы процесс теперь использует N двухуровневых экземпляра хэш-таблицы. Их 256 сегментов заполняются параллельно N потоками обработки, но неперекрывающимся образом. Для этого каждый поток обработки запускает цикл загрузки следующего необработанного блока строк из правой таблицы, применения функции вставки хэша к ключам соединения каждой строки и взятия результата по модулю, чтобы определить целевой номер сегмента и определить целевой экземпляр двухуровневой хэш-таблицы. Результат функции вставки хэша самого первого шага используется в качестве ключа для вставки данных строки в выбранный номер контейнера выбранного экземпляра двухуровневой хэш-таблицы.
Заполнение корзин двухуровневых N экземпляров хэш-таблицы без перекрытия во время фазы сборки обеспечивает эффективное (постоянное) время слияние этих N экземпляров в одну общую двухуровневую хэш-таблицу. Это эффективно, поскольку слияние просто включает в себя размещение всех заполненных корзин в новый контейнер двухуровневой хэш-таблицы без необходимости объединять записи по корзинам.
На этапе probe все N потоков обработки могут одновременно читать из этой общей двухуровневой хэш-таблицы, как и в непараллельном хэш-соединении. Каждый поток обработки запускает цикл:
- загрузить следующий необработанный блок строк из левой таблицы;
- применить функцию вставки хэша, что использовалось на этапе сборки, к ключам соединения каждой строки;
- взять результат по модулю 256, чтобы определить номер контейнера для поиска в общей двухуровневой хеш-таблице;
- выполнить поиск в выбранном сегменте;
- если поиск успешен, и значения ключей соединения совпадают, возвращаются объединенные строки.
По сравнению с предыдущей реализацией теперь используется только одна хэш-функция как на этапе сборки, так и на этапе зондирования вместо двух. Косвенность, введенная двухуровневой хэш-таблицей, требует только легких операций по модулю.
Индексы MinMax на уровне таблицы, автогенерация инкрементов и другие новинки
Индекс MinMax хранит минимальные и максимальные значения индексного выражения для каждого блока. Он полезен для столбцов, где данные отчасти отсортированы, но не будет эффективен для случайного порядка данных. До версии 25.1 нужно было указывать этот тип индекса для каждого столбца отдельно. В версии 25.1 введена настройка add_minmax_index_for_numeric_columns, которая применяет индекс ко всем числовым столбцам.
Также в ClickHouse 25.1 добавлена функция generateSerialID, которая реализует именованные распределенные счетчики (хранящиеся в Keeper). Это полезно для автоинкрементируемых полей в таблицах. Новая функция быстрая благодаря пакетированию, а также безопасна для параллельной и распределенной работы.
Еще одним полезным улучшением стала возможность стандартизации типов данных при объединении таблиц с помощью функции merge. До версии 25.1 эта функция принимала структуру первой таблицы по умолчанию, если другая структура не была указана явно. В новом релизе столбцы стандартизированы до общего типа данных или типа Variant, который представляет собой объединение других типов данных. Он позволяет хранить значения различных типов (строки, числа, массивы) в одной колонке, что особенно полезно при работе с неструктурированными или слабо структурированными данными. Это упрощает внесение изменений в структуру данных без необходимости изменения схемы таблицы, что важно для динамически изменяющихся приложений.
Разумеется, это не единственные новинки нового релиза ClickHouse. Добавлено параллельное выполнение DDL-запросов, которые не возвращают никаких выходных данных (CREATE, DROP, RENAME, ALTER, OPTIMIZE и пр.). Это реализовано для ускорения команды RESTORE и может ускорить создание сложных схем баз данных. Добавлен новый, вторичный кэш индекса, управляемый настройками сервера skipping_index_cache_size и skipping_index_cache_max_entries. Наконец, ClickPipes теперь поддерживает переименование столбцов, улучшена надежность JDBC-драйвера, dbt теперь поддерживает обновляемые материализованные представления ClickHouse, а Grafana и клиент Go – типы данных Variant, Dynamic и JSON.
Освойте ClickHouse на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
