9 вопросов по теме «Data Engineering: Хранение и форматы» на собеседовании

Короткий ответ: В строковом формате значения одной записи лежат рядом, в колоночном — рядом лежат все значения одной колонки. Для аналитических запросов (агрегаты по нескольким колонкам из десятков) колоночный формат читает только нужные колонки, лучше сжимается и поддерживает предикатный пушдаун — отсюда меньше I/O и ниже стоимость.

Подробно:

1. Проекция колонок (projection pushdown) — запросу нужны 3 колонки из 50, и колоночный движок читает с диска только эти три. Строковый формат вынужден прочитать строку целиком.
2. Сжатие — в колонке лежат однотипные значения (один тип, похожие данные), поэтому dictionary-, run-length- и delta-кодирование дают степень сжатия в разы выше, чем на разнородной строке.
3. Предикатный пушдаун (predicate pushdown) — по хранимым min/max статистикам блока фильтр WHERE date = ... пропускает целые блоки, не читая их.
4. Строковый формат выигрывает при точечных операциях: прочитать/записать запись целиком (OLTP, стриминг по одной записи).

Строковый (row):   [id=1,name=A,ts=..][id=2,name=B,ts=..][id=3,...]
                    └── запись 1 ──┘└── запись 2 ──┘

Колоночный (columnar):
  id:   [1, 2, 3, ...]        ← читаем только нужные
  name: [A, B, C, ...]           колонки, каждая
  ts:   [.., .., .., ...]        сжата отдельно

⚠️ Частая ошибка: считать колоночный формат universally лучшим. Для построчной записи и чтения записи целиком (стриминг, транзакционные апдейты) строковый формат (Avro) эффективнее.

Короткий ответ: Parquet — колоночный формат, где файл разбит на горизонтальные row groups, внутри каждого данные хранятся по колонкам (column chunks), а колонка — из страниц (pages). В футере лежат схема и статистики (min/max, счётчики null) по каждому column chunk, за счёт которых движок пропускает лишние данные.

Подробно:

1. Row group — горизонтальный срез (обычно 128–512 МБ), единица параллелизма: разные воркеры читают разные row groups.
2. Column chunk — данные одной колонки внутри row group; читаются только колонки из проекции.
3. Pages — колонка бьётся на страницы (~1 МБ) со своими статистиками и кодированием (dictionary, RLE, bit-packing) поверх сжатия (Snappy/Zstd).
4. Footer — метаданные в конце файла: схема, смещения, min/max по chunk. Читается первым, поэтому фильтр отсекает row groups до чтения данных.

Parquet file
┌──────────────────────────────────────────┐
│ Row Group 0                                │
│   col A chunk [page|page|...] (min/max)    │
│   col B chunk [page|page|...] (min/max)    │
│ Row Group 1                                │
│   col A chunk ...   col B chunk ...         │
├──────────────────────────────────────────┤
│ Footer: schema + row-group/column stats    │
└──────────────────────────────────────────┘

⚠️ Частая ошибка: ждать пушдауна, а на деле генерировать тысячи мелких файлов по паре row groups — статистики почти не отсекают данные, и накладные расходы на открытие файлов съедают выигрыш.

Короткий ответ: Parquet и ORC — колоночные форматы для аналитики (сжатие, пушдаун). Avro — строковый бинарный формат для стриминга и обмена сообщениями с сильной эволюцией схемы. CSV/JSON — текстовые форматы для обмена и отладки, но не для аналитики на объёме.

Подробно:

1. Аналитика по колонкам — Parquet или ORC: читаешь мало колонок из многих, статистики отсекают блоки.
2. Стриминг и обмен сообщениями — Avro: пишешь запись целиком, схема эволюционирует без переписывания данных.
3. Текстовые CSV/JSON — удобны и переносимы, но нет типов, статистик и эффективного сжатия — для больших таблиц дорого.

⚠️ Частая ошибка: держать аналитический слой в CSV или «сыром» JSON. На объёме это кратно больше I/O и денег, чем тот же датасет в Parquet.

Короткий ответ: Табличный формат — это слой метаданных над файлами Parquet/ORC в объектном хранилище, который превращает набор файлов в таблицу с ACID-транзакциями, атомарными коммитами, time travel, эволюцией схемы и партиций. Iceberg, Delta и Hudi решают одно и то же, различаясь деталями движка и экосистемы.

Подробно:

1. ACID и атомарные коммиты — читатели видят либо старую, либо новую версию таблицы, без «полусырых» файлов на середине записи.
2. Time travel — снапшоты по версии/времени: можно прочитать таблицу «как было» и откатиться.
3. Эволюция схемы и партиций — добавить/переименовать колонку и даже сменить схему партиционирования без переписывания данных.
4. Hidden partitioning (Iceberg) — партиция выводится из значения (например, из timestamp), пользователю не нужно вручную фильтровать по колонке-партиции.

-- time travel в Iceberg: читаем таблицу на конкретный снапшот
SELECT * FROM orders
FOR SYSTEM_VERSION AS OF 3821550127947089009;

⚠️ Частая ошибка: думать, что «положил Parquet в S3 — уже есть таблица». Без табличного формата нет ни атомарности при конкурентной записи, ни time travel, ни безопасной эволюции схемы.

Короткий ответ: Партиционирование — раскладка данных по директориям вида col=value, чтобы запрос по фильтру читал только нужные партиции (partition pruning). Выбирайте колонку с умеренной кардинальностью, по которой реально фильтруете; избегайте слишком мелких партиций и переизбытка партиций.

Подробно:

1. Партиция = префикс пути — движок видит year=2026/month=06 и пропускает остальные партиции без чтения данных.
2. Выбор ключа — брать колонку из частых WHERE (дата, регион) с умеренной кардинальностью; высококардинальные ключи (user_id) плодят миллионы партиций.
3. Размер файла — целитесь в файлы 128 МБ–1 ГБ; много крошечных файлов = проблема мелких файлов и медленный листинг в S3.
4. Не переусердствовать — тысячи партиций по паре файлов дают дорогой листинг метаданных и почти не ускоряют чтение.

s3://lake/events/
  year=2026/
    month=06/
      day=30/
        part-0001.parquet   (≈256 МБ)
        part-0002.parquet   (≈256 МБ)
    month=07/
      day=01/
        part-0001.parquet

⚠️ Частая ошибка: партиционировать по высококардинальной колонке (например, по user_id) — получаются тысячи директорий с крошечными файлами, и листинг метаданных становится дороже самого запроса.

Короткий ответ: Кодек — это компромисс между скоростью и степенью сжатия. Snappy — быстрый, но слабее жмёт; Gzip жмёт сильнее, но медленный и не splittable в сыром виде; Zstd даёт лучший баланс с настраиваемым уровнем. Для аналитики важна разбиваемость, чтобы читать файл параллельно.

Подробно:

1. Скорость vs степень — Snappy оптимизирует CPU (частое чтение), Gzip — размер (архив/выгрузка), Zstd покрывает диапазон уровнем сжатия.
2. Splittable-разбиваемость — можно ли читать разные части файла параллельно. Сырой Gzip неразбиваем: один воркер тянет весь файл, теряя параллелизм.
3. Спасение внутри Parquet — в Parquet/ORC сжатие идёт по страницам/чанкам, поэтому даже Gzip внутри Parquet читается параллельно по row groups.
4. Практика — Snappy как дефолт для «горячих» данных, Zstd когда важнее хранение при приемлемом CPU.

⚠️ Частая ошибка: класть большой .csv.gz как единый несплитируемый файл — весь гигабайт читает один воркер, и параллелизм кластера простаивает. Дробите на файлы или используйте Parquet.

Короткий ответ: Эволюция схемы — изменение структуры данных без переписывания уже записанных файлов и без поломки старых читателей/писателей. Безопасность зависит от совместимости: добавление колонки со значением по умолчанию обычно безопасно, удаление и переименование — рискованны. Avro решает это через разрешение схем (schema resolution), табличные форматы — через отслеживание колонок по стабильным id.

Подробно:

1. Добавление колонки — безопасно при наличии default: старые файлы читаются, отсутствующее значение подставляется дефолтом.
2. Удаление колонки — безопасно для читателей нового кода, но старый читатель, требующий поле, сломается — нужна обратная совместимость.
3. Переименование — самое опасное «в лоб»: по имени это удаление + добавление. Avro решает через алиасы, Iceberg — через стабильные column id, а не имена.
4. Совместимость — backward (новая схема читает старые данные), forward (старая схема читает новые данные), full — обе сразу; в Kafka её стережёт Schema Registry.

⚠️ Частая ошибка: переименовать колонку в «сыром» Parquet-датасете по имени — старые файлы под старым именем перестают читаться как новая колонка, и данные молча пропадают из выборок.

Короткий ответ: Объектное хранилище — это плоское key-value хранилище объектов по HTTP, а не файловая система: нет настоящих директорий, нет дешёвого переименования, оплата идёт за хранение и за запросы. В отличие от HDFS/POSIX оно отделяет хранение от вычислений и масштабируется практически безгранично, но переименование папки — это копирование всех объектов.

Подробно:

1. Плоское пространство ключей — «директории» это лишь префиксы в имени объекта; листинг идёт по префиксу, а не обходом дерева.
2. Нет атомарного rename — переименование/перемещение = copy + delete по каждому объекту, поэтому коммит через переименование папки (как в HDFS) дорог; отсюда committers и табличные форматы.
3. Консистентность — современный S3 read-after-write строго консистентен, но исторически была eventual consistency; закладывайтесь на возможные задержки в старых системах.
4. Модель стоимости — платите за GB хранения, за GB трафика и за количество запросов (GET/PUT/LIST) — отсюда штраф за миллионы мелких файлов.

⚠️ Частая ошибка: относиться к S3 как к POSIX-ФС и делать много LIST/rename на миллионах ключей — счёт за запросы и латентность листинга неожиданно становятся узким местом пайплайна.

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

Подробно:

1. Откуда берётся — частые микро-батчи и стриминг, слишком мелкие партиции, много воркеров, каждый пишет свой крошечный файл.
2. Почему больно — на каждый файл: запрос к S3, чтение метаданных, отдельный split/таск планировщика; тысячи файлов = тысячи открытий и медленный листинг.
3. Компакция (compaction) — фоновая задача читает мелкие файлы и переписывает их в крупные (целимся в 128 МБ–1 ГБ); в Iceberg/Delta есть встроенные операции (OPTIMIZE, rewrite_data_files).
4. Профилактика — писать реже и крупнее, дозагрузка батчей, разумная гранулярность партиций, не плодить лишние партиции.

До компакции:  [f1][f2][f3][f4][f5]...[f999]   ← 999 файлов × ~1 МБ
                     tiny files problem
                          │  compaction
                          ▼
После:         [ big-0001.parquet ][ big-0002.parquet ]  ← 2 файла × ~256 МБ

⚠️ Частая ошибка: гнать стриминг напрямую в озеро микро-батчами по секунде без последующей компакции — таблица за сутки обрастает сотнями тысяч файлов, и любой аналитический запрос по ней замедляется в разы.