clickhouse ttl

Краткое введение

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

Введение

ClickHouse поддерживает TTL как встроенную механику для таблиц на основе MergeTree и их вариаций. TTL - это конфигурация, которая описывает, какие данные должны исчезнуть или быть переведены в другой объем хранения через заданный интервал времени. Важная концептуальная мысль: TTL не просто удаляет данные мгновенно; он инициирует перерасчёт и перераспределение данных в фоновом процессе Merge-операций, что влияет на производительность и планирование ресурсов. При грамотной настройке TTL позволяет обеспечить единый стандарт хранения данных во всей экосистеме аналитики: от «горячих» свежих данных до «холодных» архивов.

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

Ключевые понятия

TTL (Time To Live) - время жизни данных в конкретных сегментах таблицы.
MergeTree и его вариации - движок, на котором реализуется TTL.
TO VOLUME / TO DISK - механизмы переноса данных в другой уровень хранения.
DELETE - действие удаления данных по TTL.
ALTER TABLE ... MODIFY TTL - способ изменения TTL на уже существующей таблице.
PARTITION / ROW-уровень - TTL может зависеть от дата-колонки или иного признака, позволяющего планировать удаление на уровне части данных.
Storage policy (политика хранения) и Volume - способы описания многоуровневого хранения: hot, warm, cold.

Теоретические основы и терминология

TTL в ClickHouse строится вокруг концепции автоматизированной жизнедеятельности данных. В теории TTL можно рассматривать как контракт между бизнес-логикой и инфраструктурой: «данные образуют жизненный цикл». TTL не требует внешних инструментов, однако в реальных сценариях его сочетание с partitioning, репликацией и подмножествами хранения существенно влияет на задержки удаления и консистентность.

Основные правила работы TTL:

TTL выражение вычисляется на этапе фоновой компоновки и мержа (background merges). Это означает, что удаление не происходит мгновенно, а осуществляется параллельно с прочими операциями над таблицей.
Данные, которые попадают под TTL, физически удаляются или перераспределяются в указанную цель (DISK/VOLUME) в зависимости от конфигурации.
TTL может работать как на уровне столбцов, так и на уровне строк, но наиболее распространен сценарий удаления по значению датчика времени (Date/DateTime).

Типовые TTL-выражения:

TTL EventDate + INTERVAL 3 MONTHS DELETE;
TTL EventDate + INTERVAL 30 DAY DELETE TO VOLUME 'cold';
TTL EventDate + INTERVAL 6 MONTHS TO DISK 'backup';

Важно: TTL зависит от типа данных и корректной работы умолчаний сервера. В реальных системах часто TTL строится вокруг ключевых полей времени (EventDate, CreatedAt) и согласуется с политикой хранения.

Три ключевых аспекта для понимания TTL:

Временной горизонт и бизнес-правила: как долго данные должны храниться в горячем слое, когда переходить в холодный и когда удалять.
Поведение при репликации: TTL применим к каждому реплике, но требуется согласованность политик и контроль над дубликатами/потоками.
Взаимодействие с хранением: выбор между удалением, переносом в другой диск и переносом в другой volume влияет на время выполнения операций и стоимость.

Таблица 1. Основные режимы TTL

Режим TTL	Описание	Пример	Влияние на хранение
DELETE	Удаление данных, подпадающих под TTL	TTL eventDate + INTERVAL 3 MONTHS DELETE	Уменьшение объема, удаление по времени
TO VOLUME	Перенос данных в указанный Volume	TTL eventDate + INTERVAL 6 MONTHS TO VOLUME 'cold'	Перемещение в холодное хранение, сохранение данных
TO DISK	Перемещение на другой диск	TTL eventDate + INTERVAL 12 MONTHS TO DISK 'backup'	Архивирование, регрессия к менее дорогому хранению

Методологии и подходы

Инкапсуляция политики TTL в архитектуре данных: TTL должен быть частью дизайна схемы, а не «последним припасом» для экономии места.
Разделение по доменам: TTL для логов может отличаться от TTL для финальных агрегатов. В частности, в telemetry/логах TTL может быть коротким (несколько дней), тогда как фактологические таблицы бизнес-событий - месяцы.
Гибкость хранения: TTL с TO VOLUME позволяет создавать явные слои hot/warm/cold. В ClickHouse это достигается через storage policies и конфигурацию volumes.

Архитектура и технологическая реализация

Архитектурная карта

Data sources → MergeTree таблицы → TTL-политики → Storage policy (hot/warm/cold) → Механизмы восстановления при необходимости → Мониторинг TTL.
TTL часто применяется к таблицам типа MergeTree и их вариациям (ReplicatedMergeTree, Distributed и т. п.). TTL корректно работает и там, где настройки синхронности и консистентности должны быть соблюдены.

Архитектурные паттерны TTL

Горячие данные + холодное хранение:
- Живой анализ на горячем диске/volume, удаление устаревших данных из горячего слоя и перенос более старых данных в холодный диск.
- Пример: TTL EventDate + INTERVAL 3 MONTHS TO VOLUME 'cold'.
Архивирование без удаления:
- Перемещение в диск/облачное хранилище вместо удаления - подход для соответствия регуляциям, когда удаление данных запрещено.
- Пример: TTL logDate + INTERVAL 1 YEAR TO DISK 'archive'.
Гибридные сценарии для мультирегиональных решений:
- TTL в разных регионах может отличаться по длительности, применяемым действиям и целям хранения.

Технологическая реализация

Доказательство концепции: реализация TTL в DDL:


CREATE TABLE events_hits
(
    EventDate Date,
    UserID UInt64,
    Country String,
    Event String,
    Value Float64
) ENGINE = MergeTree()
## ORDER BY (EventDate, UserID)
TTL EventDate + INTERVAL 3 MONTHS DELETE;

Изменение TTL на существующей таблице:


ALTER TABLE events_hits MODIFY TTL EventDate + INTERVAL 4 MONTHS DELETE;

TTL с перенесением в холодное хранилище:


ALTER TABLE events_hits MODIFY TTL EventDate + INTERVAL 6 MONTHS TO VOLUME 'cold';

TTL с архивированием в диск:


ALTER TABLE events_hits MODIFY TTL EventDate + INTERVAL 12 MONTHS TO DISK 'archive';

Пример использования storage_policy и volumes в конфигурациях (через настройку сервера и конфигурационные файлы):


## В конфигурации storage_policy

  
    default
    
      
        hot
        local
      
      
        cold
        ssd_archive

Привязка TTL к политике хранения через явное указание TO VOLUME/TO DISK (в документации можно найти точные имени volumes, которые существуют в вашем окружении).

Инструменты и практические детали

Мониторинг TTL: полезно отслеживать прогресc TTL через метрики MergeTree и TTL-процессов. Включение детального логирования TTL поможет отследить, какие части данных попали под TTL и как быстро они обрабатываются.
Взаимодействие TTL иMaterialized View: TTL работает на уровне таблицы, но агрегаты MV могут потребовать переконфигурации или пересчёта после удаления данных.
Репликация и TTL: TTL в replicated-таблицах применяется ко всем репликам. Важно обеспечить консистентность политики TTL между репликами, чтобы не возникало рассинхронов в удалении или перемещении данных.

Организационные и процессные аспекты

Определение политики хранения внутри организации: кто отвечает за создание и корректировку TTL, как согласовываются TTL между аналитическим и операционным подразделениями.
Градиент данных: отделение доменов данных (например, логи, транзакции, метрики) и для каждого домена назначение своей TTL-политики.
Регуляторные требования: регулятивная дисциплина иногда требует сохранения данных дольше, чем бизнес-логика предполагает. TTL-политики должны соответствовать этим требованиям и предусматривать исключения (например, архивирование вместо удаления).
Документация и аудит: хранение версий TTL-политик и протоколов изменения; аудит изменений TTL.

Технические детали реализации (алгоритмы, схемы, протоколы, интеграции)

Алгоритм работы TTL в ClickHouse можно рассматривать как последовательность шагов:

Определение TTL-условия на уровне таблицы (DDL или ALTER TABLE).
Фильтрация данных по TTL в рамках фонового процесса MergeTree. Это означает, что данные, удовлетворяющие TTL-условию, планируются на удаление или перенос в целевой volume/disk.
Выполнение действий над данными: удаление или перенос/архивирование.
Обновление статистик и метрик по TTL, которые позволяют операторам оценивать производительность и размер хранимой информации.
Взаимодействие TTL с репликациями и с распределённой архитектурой: консистентное и синхронное применение TTL в разных нодах.

Схема процессов TTL (описательная):

Время наступает: TTL условие истинно.
Нода/узел помечает секцию данных как под TTL.
Фоновая задача Merge выполняет переработку и удаление или перенос частей данных.
Обновляются метаданные таблицы и статистика использования памяти и дискового пространства.

Протокол взаимодействия с хранилищем:

TTL с TO VOLUME/TO DISK требует наличия корректно сконфигурированной storage policy на уровне сервера. Это включает имена volumes и disks внутри конфигурации storage.
При переносе между дисками/толпами слоев данные должны сохранять целостность и сохранение структурной целостности таблиц (доступ к индексам, блокам и ключам ORDER BY).

Интеграции:

ETL-процессы, которые подгружают данные в горячий слой, должны учитывать TTL: если данные часто удаляются, возможно стоит переработать план загрузки и архитектуру партии данных.
Мониторинг должна учитывать TTL: задержки в удалении, количество удаляемых строк, частоты запусков Merger и влияние на IO.

Риски, ограничения и типовые ошибки

Неправильная настройка TTL может привести к непреднамеренной потере данных и нарушению регуляторных требований. Важно проверить, какие данные подпадают под TTL и как долго они должны храниться.
TTL обратно совместим с репликациями, но возможны временные несоответствия между репликами в случае миграций и сбоев узлов. Необходимо тестировать TTL-политики в репликационных настройках до перехода в прод.
Продвинутая настройка TTL с TO VOLUME может усложнить архитектуру и увеличить сложность восстановления данных после катастрофы, если улика не соблюдается. Необходимо иметь plan B: резервная копия, архивы, и тесты восстановления.
Влияние TTL на производительность: TTL запускается в фоне через Merge-процессы. При большом объёме данных и частых TTL-перемещениях может возрасти нагрузка на диски и сеть.
Время задержки удаления: TTL не гарантирует мгновенное удаление; время реакции зависит от загрузки сервера и частоты Merger.
Неправильная настройка временных зон и типов времени (Date vs DateTime) может привести к несоответствию TTL и реальных временных границ.

Типовые ошибки:

Забыл указать правильный формат интервала (DAY vs MONTHS) или пропустил часть TTL-выражения.
Неправильное использование TO VOLUME без корректной политики хранения, что ведёт к переносу в неправильный слой.
Неправильный выбор ключа ORDER BY для TTL-сценариев, приводящий к неэффективности удаления.

Заключение

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

Практические примеры и кейсы

Open-source примеры:

Базовый пример TTL на таблице MergeTree со временем жизни по полю EventDate и удалением:


CREATE TABLE events
(
    EventDate Date,
    UserID UInt64,
    Event String,
    Value Float64
) ENGINE = MergeTree()
## ORDER BY (EventDate, UserID)
TTL EventDate + INTERVAL 3 MONTHS DELETE;

Пример TTL с переносом в холодное хранение:


ALTER TABLE events MODIFY TTL EventDate + INTERVAL 6 MONTHS TO VOLUME 'cold';

Пример TTL с архивированием на другой диск:


ALTER TABLE events MODIFY TTL EventDate + INTERVAL 12 MONTHS TO DISK 'archive';

Российские и локальные решения:
- Яндекс.Облако предлагает управляемый ClickHouse, который поддерживает TTL в рамках облачных сервисов с настройками storage_policy и volumes. Такой подход упрощает реализацию бизнес-правил хранения и обеспечивает консистентность TTL в рамках управляемых сервисов.
- Ряд крупных российских организаций развертывает ClickHouse в локальных кластерах с использованием собственных storage policies и TTL-политик для логов, телеметрии и бизнес-событий. Эти кейсы демонстрируют переход к многоуровневому хранению и автоматическому удалению данных по времени.
Архитектура горячего/холодного хранения:
- Пример архитектуры с hot/warm/cold через TTL:
```
TTL EventDate + INTERVAL 3 MONTHS DELETE TO VOLUME 'cold';
```
В случае архивирования в публичное облако, можно перенести данные в диск/хранилище типа S3 через то же TTL-правило и политику хранения.

FAQ (Вопросы и ответы)

Что такое clickhouse ttl и зачем он нужен?

clickhouse ttl - это механизм управления жизненным циклом данных в ClickHouse, который позволяет автоматически удалять или перемещать старые данные по времени. Он необходим для соответствия регуляциям, сокращения затрат на хранение и поддержания высокой скорости аналитики за счёт своевременного удаления устаревших данных.

Как задать TTL на таблице MergeTree?

TTL задаётся либо в CREATE TABLE, либо через ALTER TABLE MODIFY TTL. Примеры:


CREATE TABLE t (...) ENGINE = MergeTree() ORDER BY (... ) TTL EventDate + INTERVAL 3 MONTHS DELETE;
ALTER TABLE t MODIFY TTL EventDate + INTERVAL 3 MONTHS DELETE;

Какие действия можно выполнять с TTL?

DELETE (удаление), TO VOLUME (перемещение в другой Volume), TO DISK (перемещение на другой диск). Вопрос выбора зависит от политики хранения и требований к архивированию.

Как TTL влияет на производительность?

TTL выполняется в фоновом режиме через механизм Merge. При больших объёмах данных и частых TTL-перемещениях может возрасти нагрузка на диск и сеть. Рекомендуется тестировать TTL в стенде и постепенно повышать нагрузку в прод.

Как TTL работает с реплицируемыми таблицами?

TTL применяется к каждой реплике. Важно синхронизировать TTL-политики между репликами, чтобы не возникло расхождений в удаляемых данных. В продакшене следует тестировать TTL на ReplicaSet.

Как мониторить TTL?

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

Что происходит, если TTL не выполнился во время сбоев узла?

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

Когда лучше использовать TO VOLUME по TTL?

TO VOLUME целесообразно использовать для движимой многоуровневой архитектуры хранения, когда cold-данные должны быть доступны для аналитики редкой частоты или архивной доступности, но не в режиме реального времени.

Можно ли комбинировать TTL с Materialized View?

TTL влияет на данные таблиц, а MV - на результат их агрегации. При изменении TTL желательно проверить MV-материалы и обновления, чтобы агрегаты отражали текущее состояние удалённых данных.

Какие риски связаны с TTL в рамках регуляторных требований?

Основные риски - потеря данных и несоответствие требованиям: TTL-политики должны быть документированы, протестированы и согласованы с юридическим отделом. Архивирование через TO DISK или TO VOLUME может быть предпочтительным для сохранения данных под регулятивные требования.

← Предыдущая статья

ClickHouse distributed

Следующая статья →

clickhouse github