Модуль «ClickHouse»

Модуль ClickHouse выполняет роль высокопроизводительного аналитического хранилища всех событий, поступающих в Систему Логикор.

Структура ClickHouse

Модуль ClickHouse, как правило, состоит из нескольких сервисов СУБД ClickHouse и нескольких сервисов координации ClickHouse-Keeper.

В Логикор предустановлены базовые настройки этих сервисов. При необходимости их можно изменить в соответствии с требованиями конкретной установки.

В продуктивной среде сервисы размещаются на независимых узлах.

ClickHouse-Keeper

ClickHouse-Keeper обеспечивает координацию работы сервисов СУБД ClickHouse, входящих в единый кластер, в том числе при репликации данных.

В продуктивной среде рекомендуется использовать нечетное количество узлов с ClickHouse-Keeper, но не менее трех.

ClickHouse

ClickHouse представляет собой СУБД с открытым исходным кодом, предназначенную для хранения и анализа данных в высоконагруженных системах.

В продуктивной среде каждый сервис устанавливается на независимом узле. Несколько таких узлов могут быть объединены в единый кластер, координацию работы которого обеспечивает ClickHouse-Keeper.

Для горизонтального масштабирования используется шардирование, при котором общий набор данных разделяется на части, называемые шардами. Они размещаются на разных узлах кластера и позволяют распределить между ними объем хранения и нагрузку на обработку. Каждый шард хранит свою часть данных, а вместе они образуют единый набор в рамках всего кластера. Таким образом, для хранения и обработки используются ресурсы нескольких узлов, а не одного.

Для обеспечения отказоустойчивости применяется репликация, при которой данные одного шарда хранятся на нескольких узлах. Количество реплик может различаться для каждого шарда. При записи в одну из реплик данные копируются в остальные реплики того же шарда. Этот процесс выполняется сервисами ClickHouse при координации со стороны ClickHouse-Keeper. Репликация асинхронная, поэтому новые записи могут появляться на других репликах с задержкой.

В Системе Логикор количество необходимых независимых шардов определяется нагрузкой на запись в базу данных, выраженной в EPS (количество событий в секунду). Количество реплик выбирается в соответствии с потребностями и требованиями конкретной установки.

Схема таблиц

В Системе Логикор в основном используются следующие типы таблиц:

• Distributed Table - распределенная таблица для чтения данных со всего кластера logger_cluster;
• Replicated Table - реплицированная таблица для записи и хранения данных.

Имя таблицы	Тип таблицы	Описание
messagesTable	ReplicatedMergeTree	Основная реплицируемая таблица для хранения событий в Системе Логикор. Состав данных на каждом узле зависит от настроек кластера
messages	Distributed	Распределенная таблица для чтения событий со всех шардов кластера. Запросы к событиям необходимо выполнять через эту таблицу
tagsTable	ReplicatedMergeTree	Основная таблица для хранения списка используемых тегов
tags	Distributed	Распределенная таблица для чтения информации о тегах со всего кластера баз данных
mv_tagsTable	MATERIALIZED VIEW	Материализованное представление для сохранения используемых тегов из таблицы messagesTable в таблицу tagsTable

Запись и чтение данных

Запись событий в Системе Логикор осуществляется в реплицированную таблицу messagesTable, которая хранит данные независимо на каждой реплике каждого шарда кластера.

Чтение данных осуществляется из распределенной таблицы messages, которая непосредственно не хранит данные, но отвечает за сбор данных со всех шардов кластера.

При чтении данных из распределенной таблицы messages с помощью сервиса ClickHouse-Keeper система определяет доступные реплики внутри каждого шарда и распределяет нагрузку на чтение по всем узлам кластера, что позволяет увеличивать производительность чтения и поиска событий.

Запись данных

Сервис Saturn выполняет асинхронную запись событий в ClickHouse. Сервер в течение настраиваемого интервала объединяет поступающие данные в блок, после чего записывает его целиком.

Запись выполняется от имени пользователя logger, обладающего правами на запись.

В момент записи узел назначения выбирается произвольно в два этапа: сначала выбирается шард, затем реплика внутри него.

Если запись невозможна, например из-за недоступности узла, Система использует механизм повторных попыток (retry-логику). Она пытается выполнить запись на следующем узле того же шарда. Если он также недоступен, выполняется переход к другому произвольному шарду. В рамках этого механизма могут быть перебраны все доступные узлы до успешного завершения записи событий.

Такой подход обеспечивает равномерное распределение данных по всем шардам кластера.

Чтение данных

Чтение данных выполняют различные сервисы, в том числе Mars и Earth.

Запросы выполняются от имени пользователя logger_reader, обладающего правами только на чтение. Для него можно настроить максимальный объем потребляемой оперативной памяти (RAM), максимальное количество используемых потоков для ограничения нагрузки на CPU и другие параметры запросов ClickHouse. Настройки и лимиты пользователя logger_reader могут задаваться на уровне конкретного приложения либо в его профиле для всей СУБД.

Для чтения используется распределенная таблица messages, которая обеспечивает доступ к данным всех шардов кластера logger_cluster. Эта таблица существует на каждом узле ClickHouse, поэтому запрос к ней направляется на произвольный узел кластера.

При чтении данных сервисы Системы Логикор формируют SQL-запросы, которые выполняются на стороне базы данных ClickHouse. При этом запросы соответствуют настройкам Системы в рамках ролевой модели.

Хранение данных

Все данные в ClickHouse разделяются на логические части, называемые партициями. Партиционирование настраивается для каждой таблицы отдельно. В Системе Логикор используется ежедневное партиционирование: события одного дня относятся к одной партиции, а разных дней — к разным.

Каждая партиция состоит из партов, которые представляют собой физические части данных таблицы. Условно один парт можно представить как отдельный каталог на диске, содержащий часть записей. Например, он может хранить миллион или несколько миллионов записей таблицы.

При записи событий в messagesTable создаются новые парты. Для управления их количеством ClickHouse объединяет небольшие части в более крупные. Этот процесс называется слиянием партов (merge) и регулируется параметрами конфигурации.

Кроме объединения, доступны сжатие, перенос между дисками, удаление и другие операции с партами.

В результате ClickHouse позволяет гибко настраивать хранение данных и сокращать занимаемый ими объем за счет сжатия.

Пример

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

При создании парты сжимаются по алгоритму LZ4 и размещаются на доступном для ClickHouse диске hot disk. Если этот диск недоступен для записи, например переполнен или превышен лимит его заполнения, данные могут быть записаны на следующий доступный диск cold disk, если такой имеется.

Время для каждого парта условно отсчитывается от наибольшей даты события в нем.

Через 2 дня после события, относительно даты партиционирования, данные повторно сжимаются алгоритмом ZSTD(3) для более компактного хранения. Данные остаются на том же диске, где были размещены ранее. В данном примере это hot disk.

Через 7 дней после события, относительно даты партиционирования, данные перемещаются на целевой диск cold disk для долгосрочного хранения. Если они уже находятся на целевом диске, повторная запись не выполняется. Перенос возможен только при наличии свободного места.

Через 60 дней данные автоматически удаляются из Системы, что позволяет выполнять ротацию данных на дисках.