Clickhouse 24.8: обзор очередного релиза

обновления ClickHouse, курсы ClickHouse для дата-инженера, инженерия данных примеры курсы обучение, DWH ClickHouse, Школа Больших Данных Учебный Центр Коммерсант

Разработчики ClickHouse с завидной регулярностью радуют новыми релизами. Не прошло и месяца, как опубликован очередной выпуск этой колоночной СУБД, версия 24.8 LTS от 20 августа 2024. О ее главных новинках читайте далее.

Несовместимые изменения

Начнем с самых важных и несовместимых изменений. В релизе ClickHouse 24.8 LTS для clickhouse-client и clickhouse-local теперь по умолчанию используется режим нескольких запросов. Ранее использовался режим одного запроса, поэтому пользователям приходилось вручную добавлять к SELECT-запросу опцию –multiquery или -n. Теперь эта опция устарела. Запросы на вставку данных с несколькими запросами обрабатываются особым образом на основе предложения FORMAT: если FORMAT равен VALUES, что чаще всего, в конце оператора INSERT ставится точкой с запятой. Для всех других FORMAT, например, CSV или JSONEachRow, конец оператора INSERT представлен двумя символами новой строки \n\n в конце запроса.

Исправлены логические ошибки с буфером хранилища распределенных таблиц. Это обратно несовместимое изменение: запросы, использующие распределенную целевую таблицу Buffer, могут перестать работать, если таблица появляется в запросе более одного раза. Это характерно для соединений таблицы самой с собой (self-join).

В предыдущих версиях вызов статистических функций для проверки гипотез со случайными распределениями на основе гамма-функции (критерий хи-квадрат, Стьюдента, Фишера) с отрицательными аргументами, близкими к нулю, приводил к длительным вычислениям или бесконечному циклу. В новой версии Clickhouse вызов этих статистических функций с нулевыми или отрицательными аргументами приведет к исключению.

В новой версии улучшена работа функции arrayWithConstant(length, elem), которая создает массив длины length с элементами elem. Ранее она была очень медленной, если требовалось сгенерировать очень большие массивы. В новой версии размер массива ограничен 1 ГБ, поэтому функция работает быстро.

Также исправлена ошибка с динамическим типом данных (Dynamic), который позволяет хранить значения любого типа, не зная их всех заранее. При создании столбца с динамическим типом данных можно объявить, сколько различных типов данных может храниться как отдельные подстолбцы внутри столбца с типом Dynamic в одном блоке данных, который хранится отдельно, например, в одной части данных для таблицы с движком MergeTree. Ранее при превышении этого предела, по умолчанию равного 32, все значения с новыми типами приводились к типу String. В ClickHouse 24.8 LTS при достижении этого предела новые типы не приводятся к строке, а сохраняются в специальной структуре данных в двоичном формате с двоично-кодированным типом данных. Теперь любой тип, когда-либо вставленный в Dynamic-столбец, может быть прочитан из него как подстолбец с сохранением исходного типа данных.

Значимые улучшения и новые фичи

Для самого популярного табличного движка MergeTree добавлен новый параметр deduplicate_merge_projection_mode. Он позволяет управлять проекциями во время слияний и оптимизацией дубликатов запросов. В зависимости от значения этого параметра, Clickhouse может выдать исключение, если проекция не полностью поддерживается движком семейства MergeTree, удалить проекцию во время слияния, если она не может быть объединена последовательно и перестроить проекцию с нуля, что является довольно тяжеловесной операцией.

Введен новый адаптивный метод расчета размера задачи чтения для параллельных реплик. Адаптивность означает, что он зависит от размеров столбцов чтения. Знать размеры столбцов нужно для определения размера задачи в случаях MergeTreeReadPool и MergeTreePrefetchedReadPool для удаленного чтения.

Еще одним значимым изменением стало добавление нового табличного движка TimeSeries для обработки протоколов Prometheus. Также добавлен новый экспериментальный механизм хранения Kafka для хранения смещений в Keeper вместо того, чтобы полагаться на их фиксацию в Kafka. Это делает фиксацию в таблицах ClickHouse атомарной с учетом потребления данных из топика.

Введено разделение в стиле Hive для разных движков хранения (File, URL, S3, AzureBlobStorage, HDFS). Разделение в стиле Hive организует данные в разделенные подкаталоги, что делает его эффективным для запросов и управления большими наборами данных. Пока это разделение создает только виртуальные столбцы с соответствующим именем и данными, а в будущем для ускорения производительности будет представлена ​​соответствующая фильтрация данных.

Теперь JSON является полноценным типом данных в Clickhouse. Например, следующий SQL-запрос

CREATE TABLE test (json JSON(a.b UInt32, SKIP a.e)) ENGINE = Memory;
INSERT INTO test VALUES ('{"a" : {"b" : 42}, "c" : [1, 2, 3]}'), ('{"f" : "Hello, World!"}'), ('{"a" : {"b" : 43, "e" : 10}, "c" : [4, 5, 6]}');

создает таблицу test с одним столбцом json, который имеет тип данных JSON. В типе данных JSON указано, что поле a.b должно быть типа UInt32 (беззнаковое 32-битное целое число), а поле a.e должно быть пропущено при хранении данных (оно указывается с помощью ключевого слова SKIP). Таблица будет храниться в оперативной памяти, поскольку используется движок Memory.

Движок Memory означает, что таблица будет храниться в оперативной памяти, что обеспечивает высокую скорость доступа к данным, но данные будут утрачены при завершении работы сервера. Тип JSON поддерживает чтение каждого пути как отдельного подстолбца. Если тип запрошенного пути не был указан в объявлении типа JSON, подстолбец пути всегда будет иметь тип Dynamic. Тип JSON поддерживает чтение вложенных объектов как подстолбцов с типом JSON, используя синтаксис json.^some.path, например:

SELECT json.^a.b, json.^d.e.f FROM test;

Пути JSON, содержащие массив объектов, анализируются как тип Array(JSON) и вставляются в Dynamic-столбец для этого пути. Чтобы прочитать массив объектов, можно извлечь его из Dynamic-столбца как подстолбец.

Добавлен новый параметр сервера disable_insertion_and_mutation. Если он включен, сервер будет отклонять все вставки и мутации, включая асинхронные INSERT. Этот параметр можно использовать для создания реплик только для чтения.

Для повышения эффективности запросов добавлен механизм тегирования для кэша запросов. Напомним, ClickHouse поддерживает кэширование запросов, используя разные типы кэшей, в зависимости от табличных движков. Новый механизм тегирования позволяет использовать разный кэш для разных запросов, разделив их по различным пространствам имен. Теперь одни и те же запросы с разными тегами будут кэшироваться по-разному, например запросы

SELECT 1 SETTINGS use_query_cache = 1, query_cache_tag = 'abc'

и

SELECT 1 SETTINGS use_query_cache = 1, query_cache_tag = 'def'

создают разные записи кэша запросов.

А для эффективного управления таблицами удалить все отсоединенные от таблицы разделы можно с помощью одного запроса

ALTER TABLE ... DROP DETACHED PARTITION ALL

Освойте использование ClickHouse для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://github.com/ClickHouse/ClickHouse/blob/master/CHANGELOG.md
  2. https://presentations.clickhouse.com/release_24.8/#7
Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.
Поиск по сайту