TTL и срок хранения аналитики
В «Событиях» появились исходные доставки, логические события и подготовленные агрегаты. Теперь зададим время хранения. TTL в ClickHouse выражает правило истечения для данных, однако его действие связано с обработкой частей и не означает моментальное исчезновение каждой строки точно в заданную секунду.
Результат урока — техническая схема сроков и ограничения её применения. Учебные команды не выполнялись, данные не удалялись. Пример девяноста дней служит разбору механизма; он не является юридически установленным или рекомендованным для любого сайта сроком пользовательской аналитики.
Срок следует назначению слоя
Исходные доставки помогают объяснять повторы и задержки. После разбора качества их можно хранить меньше, чем обезличенный агрегат по дням. Логические события нужны воронкам и когортам, но позволяют связывать действия одного anon_id. Поэтому срок этого слоя должен учитывать и полезность, и объём связанной истории.
Агрегат без индивидуального идентификатора может храниться по другой политике. Однако одно отсутствие столбца посетителя не доказывает отсутствие риска раскрытия для очень маленьких групп. При внешней публикации dashboard потребуется оценить минимальный размер группы и набор доступных фильтров. Технический TTL не решает вопрос доступности отчёта.
Таблица сроков является продуктовым договором. Для учебного проекта запишем разные примеры, не называя их универсальной нормой.
| Слой | Пример срока | Основание для отдельного решения |
|---|---|---|
| Доставки | 30 дней по получению | Разбор повторов и работы сборщика |
| Логические события | 90 дней по действию | Ограниченное окно индивидуальной аналитики |
| Дневной агрегат | 12 месяцев | Сравнение периодов без полной истории браузера |
После выбора срока нужны методы проверки и удаления, особенно если продукт обещает конкретную дату исчезновения данных. Нельзя подписать такое обещание только на основании одной строки DDL.
Выражение времени жизни
В таблице TTL может ссылаться на временное поле. Для логических событий зададим девяносто дней от occurred_at, для доставок тридцать от received_at. Это разные отсчёты, согласованные с назначением слоёв.
ALTER TABLE events_lab.events
MODIFY TTL occurred_at + INTERVAL 90 DAY DELETE;
ALTER TABLE events_lab.deliveries
MODIFY TTL received_at + INTERVAL 30 DAY DELETE;ALTER изменяет правило таблицы. Для существующих данных обработка и применение требуют учёта текущих частей и настроек среды. Руководство TTL объясняет, что удаление происходит в ходе фоновой работы и зависит от соответствующих настроек. Здесь не запускаем принудительную материализацию или объединение ради иллюстрации.
Отсчёт по действию означает, что очень поздно доставленная старая строка может почти сразу оказаться за пределом срока. Отсчёт по получению даёт сборщику время разобрать её качество. Это допустимо, если разные сроки слоёв заранее описаны. Если запретить поздние события старше девяноста дней, такой предел нужно применить и в контракте приёмника.
TTL не исправляет отчёт сам
Представление доставок увеличило дневной счётчик при вставке. Когда TTL удалит источник, ранее записанный агрегат не уменьшится автоматически. Это может соответствовать выбранной политике долгого хранения суммы, но может противоречить обещанию удалить влияние определённого посетителя. Решение зависит от смысла агрегата и требований продукта.
В нашем снимке логических событий тоже останутся ранее посчитанные строки, пока снимок не перестроен или не имеет собственного срока. Следовательно, каждому слою нужен свой TTL либо управляемое удаление. Политика только исходной таблицы не описывает всё аналитическое хранилище.
Добавление TTL дневного агрегата требует подходящего типа даты и преобразования к времени. При разных зонах нужно сохранить один календарь. Не применяйте срок по случайному времени создания снимка, если договор говорит о дне события: новый пересчёт мог бы продлить срок старого периода без намерения владельца.
Удержание после удаления истории
Девятый урок вычислял первую наблюдаемую дату как минимум просмотров. После удаления ранних событий тот же браузер может получить новое начало и попасть в другую когорту. Отчёт станет математически согласованным с оставшимся набором, но перестанет соответствовать прежнему определению первого появления.
Для устойчивых когорт можно хранить отдельно первый наблюдаемый день с собственной политикой или сохранять уже рассчитанные агрегаты. Однако такая отдельная запись тоже содержит связь с идентификатором, поэтому её срок нельзя забыть. Более длинное хранение одного вспомогательного поля способно фактически продлить идентификацию, которую вы намеревались ограничить.
Если продукт выбирает отчёт «первая активность внутри последних девяноста дней», название должно это говорить. Тогда изменение начала после удаления является частью метрики. Нельзя оставлять прежнее название «первый визит» и объяснять расхождение только техническим TTL.
Удаление отдельного субъекта
TTL удаляет по времени, а запрос удалить данные конкретного пользователя — другая операция. Для анонимной модели нужно определить, как связать запрос с идентификатором и какой доказуемый объём можно удалить. Если владелец не хранит связь с аккаунтом, он не должен обещать невидимое объединение всех устройств.
Прямые удаления и мутации имеют эксплуатационную стоимость, а копии в выгрузках и резервных слоях требуют отдельной политики. В этой серии не выполняются команды удаления настоящих пользовательских данных. Договор передачи перечисляет слои и место каждого копирования, чтобы будущий владелец мог оценить полный путь данных.
Исходный журнал, экспорт CSV и файл dashboard тоже являются копиями. Удаление строки в ClickHouse не стирает уже скачанный файл. Поэтому автоматическая выгрузка должна иметь назначение, доступ и срок, а публикация отчёта — правила допустимых агрегатов.
Как подтвердить выполнение срока
Будущая проверка должна сравнить возраст строк и фактическую политику таблицы, оценить время фонового применения и убедиться, что связанные слои имеют согласованные сроки. Отдельно требуется проверить позднюю доставку, повторное заполнение и пересчёт когорты. Один успешный ALTER не подтверждает весь жизненный цикл.
Для архива серии сроки записаны как примеры и статус остаётся not_run. Следующий урок экспортирует агрегированный отчёт и завершит договор передачи. Он сохранит определения периода, события, идентификатора и времени среза, чтобы dashboard не выглядел более окончательным, чем доступные данные.