Data engineering
Parquet: тест на припоминание
Припоминание бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть модельный ответ — именно усилие припоминания закрепляет решения по раскладке.
Восстанови ключевые механизмы юнита — колоночную раскладку, pushdown через футер, разделение encoding/compression, размер row group, schema evolution и то, что добавляют table formats — не заглядывая в урок.
- 01Объясни от начала до конца, почему фильтрованный запрос с проекцией на Parquet читает гораздо меньше, чем тот же запрос на CSV.
- 02Опиши физическую вложенность внутри Parquet-файла, от файла вниз до закодированных значений.
- 03Чем отличаются encoding и compression в Parquet и почему держать их в голове раздельно?
- 04Что такое small-files problem, почему она калечит планирование запросов и как помогают table formats?
- 05Как выбирать размер row group и что идёт не так на каждом краю?
- 06Почему schema evolution это ловушка с сырым Parquet и как table formats делают её безопасной?
Если ты смог восстановить каждый ответ по памяти — ты держишь хребет юнита: Parquet колоночный и самоописывающий, так что pruning и pushdown читают только то, что нужно запросу — но лишь когда данные кластеризованы по колонкам фильтра. Файл вложен файл — row group — column chunk — page, и каждая page сначала кодируется (структурный, типозависимый слой), затем сжимается (байтовый кодек) — два отдельных выигрыша с отдельными режимами отказа. Размер row group — реальная ручка с плохими краями в обе стороны, small-files problem лечится compaction, а поскольку у сырого Parquet нет транзакций и стабильной идентичности схемы, table formats оборачивают его манифестом ради ACID, безопасной schema evolution, time travel и отсева на уровне файла.