ClickHouse 22.9: настраиваем холодный уровень хранения на MinIO

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

Зачем вообще tiered storage

У одного из клиентов - аналитический кластер ClickHouse, который собирает события из нескольких источников. Данные нужны в двух режимах: горячие (последние 90 дней) запрашиваются постоянно, аналитики работают с ними в Grafana и собственных дашбордах. Данные старше 90 дней запрашиваются редко - раз в неделю или реже, обычно для ретроспективных отчётов.

Хранить всё на быстрых NVMe дорого и смысла нет. Логичное решение - горячие данные на локальных дисках сервера, холодные на чём-то дешевле. В нашем случае - на MinIO, который у клиента уже стоит и используется для бэкапов и артефактов CI/CD.

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

Как выглядит конфигурация

Идея в ClickHouse такая: описываешь несколько дисков (диск = место хранения, может быть локальный путь или S3-endpoint), из дисков собираешь volume-ы, из volume-ов - storage policy, и уже policy назначаешь таблице. Движение данных между уровнями управляется через TTL и правилами policy.

Конфигурация дисков в storage_configuration:

<storage_configuration>
  <disks>
    <local_nvme>
      <path>/var/lib/clickhouse/data/</path>
    </local_nvme>
    <minio_cold>
      <type>s3</type>
      <endpoint>http://minio.internal:9000/clickhouse-cold/</endpoint>
      <access_key_id>...</access_key_id>
      <secret_access_key>...</secret_access_key>
      <send_metadata>true</send_metadata>
    </minio_cold>
  </disks>
  <policies>
    <tiered>
      <volumes>
        <hot>
          <disk>local_nvme</disk>
          <max_data_part_size_bytes>10737418240</max_data_part_size_bytes>
        </hot>
        <cold>
          <disk>minio_cold</disk>
          <prefer_not_to_merge>false</prefer_not_to_merge>
        </cold>
      </volumes>
      <move_factor>0.1</move_factor>
    </tiered>
  </policies>
</storage_configuration>

Дальше - TTL на таблице:

ALTER TABLE events
    MODIFY TTL
        event_date + INTERVAL 90 DAY TO VOLUME 'cold';

Это говорит ClickHouse: парты старше 90 дней переносить на volume cold, то есть в MinIO. Данные не удаляются - просто переезжают.

Что получилось

Настроили на тестовой копии кластера, залили исторические данные, подождали пока TTL-мержер отработает. Парты старше 90 дней начали переезжать в MinIO - можно видеть в system.parts через колонку disk_name.

Переезд происходит при мерже. Это важный момент: TTL-перемещение в ClickHouse привязано к операциям мержа частей. Свежий парт не прыгает в cold сразу по истечении 90 дней - нужно дождаться, пока фоновый мержер до него доберётся. В нашем случае при умеренном объёме данных задержка небольшая, но если партов много и они маленькие - мержер может отстать. В 22.9 поведение здесь стало предсказуемее: раньше были случаи когда мержер по TTL не запускался вовремя без ручного OPTIMIZE, теперь это чинят на уровне логики планировщика.

Запросы к холодным данным работают, но медленнее. Что ожидаемо - MinIO за сетью, не NVMe рядом. По нашим замерам запросы к данным на cold volume медленнее раз в пять-семь по сравнению с горячими данными. Для редких ретроспективных отчётов это приемлемо: аналитик нажал кнопку и ждёт несколько минут вместо секунд, но это раз в неделю. Для регулярных дашбордов такое не подойдёт.

send_metadata: true - обязательно. Без этого флага в случае потери метаданных ClickHouse-а восстановить данные из S3 сложно. С флагом metadata хранится прямо в S3 рядом с данными, что сильно упрощает потенциальное восстановление.

Про проекции

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

До конца не разобрались: проекции на холодных данных ведут себя корректно, но влияние на скорость запросов к MinIO-данным нужно мерить отдельно. Пока оставили эксперименты с проекциями на горячем слое.

Где сейчас

На тест клиент дал добро, смотрим на поведение в течение нескольких недель. Объём данных, который уедет в cold при переходе в продакшн, приличный - несколько терабайт. Хочется убедиться, что перенос проходит стабильно и MinIO под такой объём не преподносит сюрпризов.

По первым результатам идея работает: горячий слой на NVMe остаётся компактным, запросы к нему быстрые, холодные данные доступны пусть и медленно. Стоимость хранения должна снизиться ощутимо - MinIO у клиента на обычных SATA SSD, что на порядок дешевле NVMe на тот же объём.

Если вам нужна аналитическая инфраструктура с управляемым хранением - обсудим архитектуру под ваши данные и бюджет.