Data tiering на собеседовании Data Engineer

Зачем нужен tiering

Стоимость хранения растёт вместе с объёмом данных, но обращаются к данным неравномерно. Свежие данные читают часто — это горячий (hot) слой. Старые данные трогают редко — это холодный (cold) слой. Data tiering — это подход, при котором вы сопоставляете паттерн доступа к данным со стоимостью хранилища: часто читаемое держите на быстром и дорогом носителе, редко читаемое — на медленном и дешёвом.

На собесе Data Engineer тему поднимают в контексте оптимизации затрат и retention. Типичные вопросы: «как удешевить хранение при росте объёма», «куда девать логи и события старше года», «как настроить автоматический переезд данных между слоями». Важно показать, что вы думаете не только про скорость, но и про деньги, и понимаете trade-off: чем дешевле хранение, тем дороже и медленнее доступ.

Горячий слой (hot tier)

• Носитель: SSD, NVMe, in-memory кэши.
• Задержка: миллисекунды.
• Стоимость: самая высокая за ГБ.

Сюда кладут свежие и часто читаемые данные: последние 30 дней событий, активные дашборды, оперативную аналитику. Здесь важна скорость ответа, а объём относительно небольшой, поэтому высокая цена за ГБ оправдана. Примеры хранилищ: PostgreSQL, горячие таблицы ClickHouse на быстрых дисках, кэш Redis, S3 Standard для объектов.

Тёплый слой (warm tier)

• Носитель: HDD, S3 Standard-IA (Infrequent Access).
• Задержка: секунды.
• Стоимость: средняя.

Слой для данных, к которым обращаются заметно реже: возраст примерно от одного до двенадцати месяцев, отчётность на конец месяца, разбор инцидентов задним числом. Здесь хранение уже дешевле горячего, но у классов вроде S3 Standard-IA есть нюансы — минимальный срок хранения (обычно 30 дней) и плата за извлечение за ГБ. То есть тёплый слой выгоден, только если вы действительно читаете данные редко.

Холодный слой (cold tier)

• Носитель: S3 Glacier / Glacier Deep Archive, ленты, архивы.
• Задержка: извлечение от минут до часов.
• Стоимость: минимальная, на 80–90% дешевле горячего.

Сюда уходит то, что почти не читают, но обязаны хранить: данные старше года, обязательная выгрузка под compliance (финансовые, регуляторные требования), резервные копии для disaster recovery. Ключевой момент — за низкую цену хранения вы платите высокой ценой и задержкой извлечения. Поэтому в холодный слой кладут данные, которые почти наверняка не понадобятся для регулярных запросов; если данные нужно доставать часто, экономия на хранении съедается платой за retrieval.

Политики жизненного цикла

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

S3 lifecycle — правила перехода между классами хранения по возрасту объекта:

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [
      {"Days": 30, "StorageClass": "STANDARD_IA"},
      {"Days": 90, "StorageClass": "GLACIER"},
      {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
    ]
  }]
}

ClickHouse TTL — переносит части таблицы между томами хранилища (быстрый диск → медленный) и в конце удаляет по возрасту:

ALTER TABLE events MODIFY TTL
  event_date + INTERVAL 30 DAY TO VOLUME 'warm',   -- через 30 дней на тёплый том
  event_date + INTERVAL 90 DAY TO VOLUME 'cold',   -- через 90 дней на холодный
  event_date + INTERVAL 365 DAY DELETE;            -- через год удалить

Здесь VOLUME 'warm' и 'cold' — это тома в storage policy ClickHouse, привязанные к разным дискам. TTL перемещает партиции между ними в фоне.

Iceberg и другие lakehouse-форматы дают tiering на уровне партиций: компакция мелких файлов, архивация старых снапшотов и партиций, вынос холодных партиций на дешёвое хранилище без перезаписи всей таблицы.

Частые ошибки

• Тирить только по возрасту, игнорируя паттерн доступа. Иногда старые данные всё ещё горячие (популярный отчёт, часто открываемая историческая витрина). Правильный критерий — частота обращений, а не только дата.
• Забыть про стоимость и задержку извлечения из холодного слоя. Glacier дёшев для хранения, но извлечение стоит денег и занимает минуты-часы. Класть туда данные, которые придётся регулярно читать, — антипаттерн.
• Не учитывать минимальный срок хранения. У S3 Standard-IA и Glacier есть минимальная длительность хранения; ранний перенос или удаление всё равно тарифицируются за полный срок, и «экономия» оборачивается переплатой.
• Удалять данные, которые обязаны храниться. Финансовые и регуляторные требования часто предписывают хранить данные несколько лет. TTL с DELETE без оглядки на compliance — прямой путь к нарушению. Такие данные отправляют в холодный слой, а не удаляют.
• Строить tiering без мониторинга затрат. Без наблюдения за реальными расходами и паттернами доступа политики быстро расходятся с жизнью, и вы либо переплачиваете за горячее, либо тормозите на извлечении из холодного.

Связанные темы

• S3 и object storage для DE
• Партиционирование таблиц для DE
• ClickHouse MergeTree для DE
• Lakehouse Iceberg Delta для DE
• Подготовка к собесу Data Engineer

FAQ

Чем отличаются hot, warm и cold слои?

Горячий слой — быстрые носители (SSD, in-memory), миллисекундные задержки, самая высокая цена за ГБ, для свежих и часто читаемых данных. Тёплый — HDD или S3 Standard-IA, задержки в секунды, средняя цена, для данных, к которым обращаются редко. Холодный — Glacier, ленты, архивы, извлечение минуты-часы, минимальная цена хранения, для архивов и compliance.

По какому критерию решать, что переносить в холодный слой?

По частоте доступа, а не только по возрасту. Если данные почти не читают и они нужны в основном для соответствия требованиям или disaster recovery — им место в холодном слое. Если старые данные всё ещё регулярно запрашивают, они должны оставаться горячими или тёплыми.

Как автоматизировать переезд между слоями?

Политиками жизненного цикла. В S3 — lifecycle-правила с переходами по возрасту объекта между классами хранения. В ClickHouse — TTL с TO VOLUME для переноса частей таблицы между томами и DELETE для удаления. В lakehouse-форматах вроде Iceberg — компакция и архивация на уровне партиций.

В чём подвох холодного хранилища вроде Glacier?

Низкая цена хранения компенсируется высокой ценой и задержкой извлечения: достать данные стоит денег и занимает минуты-часы, а у ряда классов есть минимальный срок хранения. Поэтому в Glacier кладут то, что почти наверняка не понадобится для регулярных запросов, а не всё подряд «чтобы сэкономить».

Как tiering связан с retention и compliance?

Compliance часто требует хранить данные несколько лет, но не требует держать их быстрыми. Это идеальный кандидат для холодного слоя: дёшево лежит, доступно при необходимости, не удаляется раньше срока. Политики жизненного цикла настраивают так, чтобы удаление срабатывало только после истечения обязательного срока хранения.

Это официальная информация?

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

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.