🧱 Parquet под капотом: почему «размер файла имеет значение»
Мы шли сверху вниз: разделили compute и storage → положили сверху Iceberg → разобрали каталоги. Остался последний этаж — сами файлы. Под каждым Iceberg лежит обычный Parquet, и именно здесь производительность или выигрывается, или проваливается.
🦖 Как было: строчный формат
CSV, Avro, любая OLTP-таблица хранят данные построчно. Чтобы посчитать SUM по одной колонке, движок физически читает строки целиком — все 200 полей. Для аналитики это катастрофа I/O: платишь за 200 колонок, используешь 3.
🟢 Как стало: колонки вместо строк
• Читаешь только нужные колонки (projection pushdown) — остальные с диска не поднимаются вообще.
• В колонке лежат однородные данные → сжатие в разы. Пять повторяющихся статусов в строке не сожмёшь, а в колонке они схлопываются в словарь.
🔬 Как устроен файл
файл → row groups (горизонтальные срезы, обычно ~128 МБ) → column chunks → pages.
В футере — схема и статистика по каждому chunk: min, max, число NULL.
И вот главное. Запрос WHERE created_at = ‘2026-07-20’: движок читает футер, видит по min/max, что в этом row group нужных дат нет, и пропускает его целиком — не читая ни байта данных. Это predicate pushdown.

🛠 Что это значит для DE
🔴 Мелкие файлы убивают. Миллион файлов по 10 КБ = миллион HTTP-запросов к S3, и платишь ты не за объём, а за latency каждого (привет посту про compute vs storage). Компакть в 128–512 МБ.
🔴 Несортированные данные = бесполезная статистика. Если ключ фильтрации размазан по всем row groups, min/max в каждом — «от января до декабря», и пропустить нельзя ничего. Сортируй перед записью по колонке, по которой реально фильтруешь: диапазоны станут узкими, и pruning начнёт резать.
🟡 Следи за размером row group и шириной схемы: слишком широкие и глубоко вложенные схемы бьют по памяти на запись, слишком мелкие row groups раздувают метаданные.
🟡 Партиционируй с умом (hidden partitioning в Iceberg), но не плоди тысячи мелких партиций — вернёшься ровно к проблеме №1.
🔮 А Parquet не устарел?
Формату больше десяти лет, и под ИИ-нагрузки он тесноват — точечный доступ к одной записи, фичестор на тысячи колонок, эмбеддинги.
На этом выросли Lance (быстрый random access и вектора),
Vortex (инкубируется в Linux Foundation) и
Nimble от Meta.
Но в 2026-ом: Parquet под управлением Iceberg остаётся источником правды для BI и всей классической аналитики, а новые форматы живут рядом, под ML. Переезжать всем пока не за чем.
🔗 Замыкаем цепочку
сеть (compute/storage) + колоночный формат (Parquet) + указатель каталога (Iceberg + REST) = весь Cloud-Native стек, который мы собирали четыре поста подряд.
Дальше — вверх, к движкам и стримингу.
Как боретесь с мелкими файлами — автокомпакция каталога (S3 Tables/Iceberg), OPTIMIZE, свой джоб? И сортируете ли данные перед записью? 👇

#data_engineering #parquet #lakehouse #storage #dj_architecture #DataJungle