Чем ClickHouse Keeper отличается от Apache Zookeeper

Что не так с Apache Zookeeper и почему разработчики ClickHouse решили заменить его на встроенный сервис синхронизации метаданных на базе RAFT-протокола с линеаризацией записи и чтения. Как работает ClickHouse Keeper и где его настроить.

Что не так с Apache Zookeeper

Многие распределенные системы, которые состоят из нескольких узлов, для обеспечения консенсуса между ними, т.е. координации и синхронизации распределенных операций, используют Apache Zookeeper. ZooKeeper — одна из первых известных систем координации с открытым исходным кодом. Она реализована на Java и имеет довольно простую и мощную модель данных. Алгоритм координации ZooKeeper, ZooKeeper Atomic Broadcast (ZAB), не предоставляет гарантий линеаризуемости для чтения, поскольку каждый узел ZooKeeper обслуживает чтение локально. ZooKeeper стал очень популярен благодаря простому протоколу координации и наличии собственной реализации клиента.

Например, до внедрения режима KRaft с версии 2.8 именно Zookeeper был необходим для работы кластера Kafka. ClickHouse тоже изначально использовал именно этот сервис синхронизации метаданных. Впрочем, ZooKeeper объявлен устаревшим в Kafka 3.5 и будет удален вообще в выпуске 4.0, о чем мы писали здесь. Разработчики ClickHouse тоже с 2021 создают альтернативу Zookeeper, назвав ее ClickHouse Keeper.

Замена ZooKeeper на ClickHouse Keeper обусловлена следующими причинами:

разнородность техстека – ZooKeeper написан на Java, а ClickHouse на C++. Хотя многие сложные системы разработаны с использованием более одного языка программирования, их интеграция между собой может вызвать сложности. Java и C++ изначально имеют разные профили производительности: C++ обычно работает быстрее, что критично для высоконагруженных систем, таких как ClickHouse. Кроме того, среда JVM требует регулярной настройки и мониторинга, например, для управления сборкой мусора, что добавляет дополнительный уровень сложности в эксплуатации систем. Наконец, эксплуатация компонентов, написанных на разных языках, может затруднить обновление и поддержку, поскольку нужно учитывать совместимость и синхронизацию версий различных библиотек и системных пакетов.
Недостаточная производительность. Хотя ZooKeeper хорошо справляется с координацией небольших кластеров, при высоких нагрузках скорость его работы снижается. Но масштабировать его в больших кластерах сложно, поскольку увеличение числа узлов требует балансировки нагрузки и распределения данных.
Недостаточная надежность. В ZooKeeper возможно переполнение ZXID (ZooKeeper Transaction ID), когда номер транзакции достигает максимального значения слишком быстро. ZXID представляет собой 64-битное число, в котором 32 бита используются для обозначения номера эпохи, а оставшиеся 32 бита — для номера транзакции в рамках этой эпохи. Когда номер транзакции достигает своего максимального значения, он обнуляется и начинается новая эпоха. Это случается в системах с очень высокой нагрузкой, где совершается огромное количество операций. В результате может возникнуть ситуация, когда текущая эпоха не изменяется, а номера транзакций начинают повторяться, что может привести к непредсказуемому поведению системы и нарушению её целостности. Избежать этого можно, разделив данные и распределив нагрузку между несколькими кластерами ZooKeeper, а также с помощью планового и регулярного обновления эпохи. Однако, такие меры дополнительно повышают сложность эксплуатации сервиса синхронизации метаданных. Кроме того, контрольные суммы являются опциональными, что увеличивает риск повреждения данных. А проблемы с надежностью при переподключении клиентов могут привести к ситуациям, когда клиентские приложения не могут быстро восстановить соединение после его потери, что снижает доступность и согласованность данных в распределённой системе.
Ресурсоемкость. Логи и снимки состояния ZooKeeper не сжимаются, занимая много места на диске.
Сложность управления. Чтобы обеспечить высокую доступность и надежность, надо тщательно настраивать конфигурацию ZooKeeper, включая точный расчет количества серверов в кластере и их размещение. Необходимо постоянно отслеживать состояние узлов ZooKeeper, их производительность и доступность, чтобы своевременно реагировать на сбои и предотвращать потерю данных.

Поэтому в феврале 2021 года началась разработка встроенной альтернативы ZooKeeper — ClickHouse Keeper с полностью совместимым клиентским протоколом и той же моделью данных.

Построение хранилища данных на базе Clickhouse

Код курса

CLICH

Ближайшая дата курса

17 февраля, 2025

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

Как работает ClickHouse Keeper

В ClickHouse Keeper моментальные снимки и логи занимают гораздо меньше места на диске благодаря лучшему сжатию, нет ограничений на размер пакета и данных узла по умолчанию, как и проблем с переполнением ZXID. Реализуя протокол RAFT, ClickHouse Keeper предоставляет дополнительные гарантии согласованности: помимо линеаризуемых записей и строгого порядка операций внутри одного сеанса, через настройку quorum_reads доступны линеаризуемые чтения. Наконец, ClickHouse Keeper более эффективен в потреблении ресурсов и использует меньше памяти для того же объема данных, чем ZooKeeper.

ClickHouse Keeper совместим с ZooKeeper: любой стандартный клиент ZooKeeper может использоваться для взаимодействия с ClickHouse Keeper. Как и ZooKeeper, ClickHouse Keeper поддерживает ACL-списки контроля доступа, тот же набор разрешений и идентичные встроенные схемы: world, auth и digest, которая использует пару username:password, кодируя пароль в Base64.

Однако, снимки и логи имеют несовместимый с ZooKeeper формат. Поэтому для преобразования данных ZooKeeper в снимки ClickHouse Keeper придется использовать специальный инструмент clickhouse-keeper-converter. Межсерверный протокол ClickHouse Keeper также несовместим с ZooKeeper, поэтому использовать оба сервиса в одном кластере ClickHouse нельзя.

ClickHouse Keeper может использоваться как самостоятельная замена ZooKeeper или как внутренняя часть сервера ClickHouse. Для этого надо настроить конфигурацию в xml-файлах на каждом узле сервера ClickHouse. В файле keeper.xml указать tcp-порт, на котором будет работать ClickHouse Keeper, уникальный идентификатор сервера в кластере ClickHouse Keeper, а также пути для хранения логов и моментальных снимков. В этом же файле задаются настройки координации: тайм-аут для операций и сессий, уровень логирования, интервал ротации логов и конфигурация для протокола консенсуса Raft. Для взаимодействия с ZooKeeper надо указать локальный хост и порт, а также путь в ZooKeeper, где хранятся задания распределенных DDL-запросов.

Еще на каждом сервере ClickHouse надо настроить файл macros.xml, указав макросы для конфигурации и настройки кластера: имя кластера и реплики, а также номер шарда. Эти файлы конфигурации позволяют ClickHouse взаимодействовать с распределёнными системами и управлять кластером. Макросы упрощают обращение к различным элементам инфраструктуры через унифицированные имена.

Наконец, на каждом сервере ClickHouse надо настроить файл clusters.xml, указав в нем все удалённые серверы кластера, доступные из текущей конфигурации, включая их логическую группу и шард (часть данных), где могут находиться одна или несколько реплик. Каждая реплика шарда работает на определенном узле кластера, т.е. хосте с заданным портом.

Таким образом, все, что требует согласованности между несколькими серверами ClickHouse в самоуправляемых кластерах без разделения ресурсов, может полагаться на ClickHouse Keeper:

автоматическая дедупликация вставок для реплицированных таблиц семейства движков MergeTree основана на хэш-суммах блоков, хранящихся в Keeper;
консенсус для имен частей (на основе последовательных номеров блоков) и для назначения их слияний и мутаций определенным узлам кластера;
согласованное хранилище пар «ключ-значение» с линеаризуемыми записями и последовательно согласованными чтениями;
Sink-коннектор ClickHouse Kafka Connect использует этот табличный движок как надежное хранилище состояний для реализации гарантий доставки exactly once$
мониторинг используемых файлов в таблице S3Queue, которая обеспечивает интеграцию с экосистемой Amazon S3 и позволяет выполнять потоковый импорт данных, предоставляя возможности этого объектного хранилища.
хранение метаданных для replicated-движка;
координация резервных копий с предложением ON CLUSTER;
хранение пользовательских функций и информации о контроле доступа.

Кроме того, ClickHouse Keeper используется как общее централизованное хранилище для всех метаданных в Cloud-версии этой колоночной базы данных.

Бенчмаркинговые тест, проведенные разработчиками ClickHouse Keeper, показывают выигрыш в скорости и производительности, по сравнению с Zookeeper. Однако, на практике, обе альтернативы до сих пор используются в производстве, и говорить о полной замене Zookeeper еще рано.