ClickHouse 24.3 LTS: параллельные реплики наконец стабильны - обновляем аналитический кластер

ClickHouse 24.3 вышел как LTS - и мы ждали этого релиза с конкретной целью. После октябрьского апгрейда на 23.9 у нас на кластере работали параллельные реплики, и в целом работали хорошо, но мы держали их включёнными только для тяжёлых аналитических запросов через явный SET в сессии. Для широкого включения на уровне конфигурации - с любыми запросами, любыми пользователями - 23.9 ещё чувствовался как «почти». 24.3 объявили как версию, где Parallel Replicas выходят из экспериментального статуса для серьёзного использования. Это и есть основной повод для обновления.

Что изменилось в Parallel Replicas

С 22.3, когда функция появилась с флагом allow_experimental_parallel_reading_from_replicas, мы следили за её эволюцией в каждом LTS. В 23.9 переработали алгоритм динамического распределения гранул - стало лучше, особенно на длинных временных диапазонах. В 24.3 команда идёт дальше.

Ключевые изменения, которые видны из changelog и которые нас интересовали:

• Улучшен эвристический контроль над тем, когда параллельные реплики вообще стоит использовать. В 23.9 была проблема: для небольших запросов накладные расходы на координацию съедали прирост, но отключить это автоматически было нельзя. В 24.3 планировщик умеет лучше оценивать объём работы и сам решает, подключать ли дополнительные реплики.
• parallel_replicas_custom_key окончательно не нужен на кластерах с однородными партами. Мы убрали его ещё на 23.9, но теперь это официальная рекомендация, а не эксперимент с нашей стороны.
• Улучшена работа с FINAL - запросы с FINAL для дедупликации теперь корректно распределяются между репликами без риска получить неправильный результат из-за того, что разные реплики видят разные версии строк.

Планировщик ресурсов

Второе заметное нововведение - переработанный Resource Scheduler. В ClickHouse давно можно выставлять приоритеты запросов через workload-настройки, но до 24.3 это работало довольно грубо. Новый планировщик вводит иерархию workload'ов с честным разделением ресурсов - CPU и дискового I/O - между ними.

На нашем клиентском кластере смешанная нагрузка: интерактивные дашборды (ответ нужен за секунды), фоновые ETL-агрегации (могут ждать) и разовые аналитические запросы от аналитиков (где-то посередине). До этого приоритеты выставляли через max_threads и priority на уровне пользователя - работало, но топорно: ETL мог занять все I/O и подвесить интерактивные запросы на несколько секунд. Новый планировщик позволяет описать workload-иерархию в конфиге и задать веса. Пока только разворачиваем на тестовом кластере - на этой версии мы только перешли, и трогать планировщик сразу в продакшне не торопимся.

JSON как нативный тип

Отдельная история - JSON. В 24.3 появляется поддержка JSON как нативного типа данных колонки, а не через String с visitParam*-функциями или через вариант с Tuple. Это экспериментально и за флагом allow_experimental_json_type, но сам факт показателен: в практике почти каждый OLAP-проект имеет какую-то долю полу-структурированных данных, и хранить их в String с распарсиванием на лету - не лучший вариант с точки зрения производительности.

Мы пробовали JSON-тип на отдельной таблице с event-данными, где схема нестабильная и ключи постоянно добавляются. Выборки по конкретным полям внутри JSON ускорились относительно String-подхода. Насколько именно - зависит от глубины вложенности и числа полей, которые реально читаешь. Пока держим это в эксперименте: статус «experimental» - не просто слово, и класть туда продакшн-данные в апреле не планируем.

Обновление: как прошло

Кластер тот же, что в октябре: три узла, ReplicatedMergeTree, ClickHouse 23.9.x. Обновляли по одному узлу с проверкой репликационного лага после каждого перезапуска.

# По одному узлу, с проверкой после каждого
apt-get install -y clickhouse-server=24.3.2.23 clickhouse-client=24.3.2.23
systemctl restart clickhouse-server

# Проверяем что кластер видит обновлённый узел и реплики синхронизованы
SELECT host_name, version()
FROM clusterAllReplicas('default_cluster', system.one)
ORDER BY host_name;

Никаких сюрпризов - оба LTS, схема таблиц не менялась. Единственное, на что обратили внимание: в 24.3 изменились дефолтные значения нескольких параметров, связанных с параллельными репликами. Стоит пройтись по конфигу и убедиться, что явные значения, которые вы выставляли раньше, не конфликтуют с новыми дефолтами.

Параллельные реплики в широком использовании: первые наблюдения

Включили параллельные реплики на уровне профиля пользователя - то есть без явного SET в каждой сессии:

<profiles>
    <default>
        <allow_experimental_parallel_reading_from_replicas>1</allow_experimental_parallel_reading_from_replicas>
        <max_parallel_replicas>3</max_parallel_replicas>
    </default>
</profiles>

Первые несколько дней мониторили system.query_log на предмет запросов, где параллельные реплики включились, но не принесли пользы. Такие нашлись - короткие lookups за последние часы данных, где координатор добавлял латентность. Для них через use_hedged_requests и профиль с явным отключением параллелизма сделали исключение.

В целом картина позитивная: тяжёлые запросы стали стабильно быстрее, и это теперь происходит автоматически для всех пользователей, без ручного включения в каждом запросе. Это и есть то, чего мы ждали.

Где сейчас

Кластер на 24.3 работает несколько дней. Новый планировщик ресурсов изучаем на тестовом стенде - если понравится, перенесём конфиг в продакшн на следующем DWH-сопровождении этого клиента. JSON-тип отложили до выхода из экспериментального статуса.

24.3 - хороший момент для обновления аналитических кластеров. Если вы держитесь на 23.3 или 22.3 LTS и смотрели на параллельные реплики с осторожностью - сейчас разумный момент пересмотреть эту осторожность.