Data engineering
Parquet: тест с выбором ответа
Суть Синтез всего юнита Parquet в формате с выбором ответа — колоночная раскладка, статистики футера и pushdown, encoding против compression, размер row group и ловушка small files.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь юнит. Каждый — это решение, которое ты принимаешь, проектируя таблицу в озере данных: не определение для пересказа, а компромисс, который надо взвесить против реального запроса и реальной цены.
Цель
Убедись, что умеешь связать колоночную раскладку, статистики футера, encoding против compression, размер row group и продакшен-ловушки — синтез, к которому вёл урок.
Викторина
Completed
Таблица events из 40 колонок запрашивается как SELECT user_id, country WHERE day = '2024-02-01'. Два независимых механизма Parquet делают это гораздо дешевле, чем CSV. Какие?
Heads-up В Parquet нет внешнего индекса значение-в-смещение. Пропуск идёт от min/max/null-count статистик в собственном футере файла по каждой row group плюс опциональные page indexes — это грубый отсев по диапазону, а не точный seek.
Heads-up Выигрыш в том, что читается меньше, а не в скорости распаковки. Column pruning и row-group skipping означают, что большинство байтов вообще не читается и не распаковывается; более быстрый кодек вторичен.
Heads-up Parquet не сортирует данные глобально за тебя; кластеризацию ты устраиваешь при записи. Pruning — это отсев row group и pages по диапазону через статистики, а не бинарный поиск.
Викторина
Completed
В таблице есть статистики по day на каждую row group, но WHERE day = '2024-02-01' всё равно сканирует почти все row groups. Какая причина наиболее вероятна?
Heads-up Parquet держит min/max для упорядоченных типов, включая даты и строки; pruning для них работает. Проблема здесь — перекрытие диапазонов из-за разбросанных значений, а не тип колонки.
Heads-up Pushdown по диапазону из min/max футера работает без Bloom filter. Bloom filter помогает равенству на колонках высокой кардинальности; он не предпосылка для отсева по диапазону дат.
Heads-up Статистики живут в футере независимо от кодека сжатия. Выбор кодека влияет на размер и скорость чтения, но никогда на то, существуют ли статистики и могут ли они отсеивать.
Викторина
Completed
Коллега говорит: 'Parquet сжимает данные, значит encoding и compression — это одно и то же.' Какая точная поправка?
Heads-up Encoding и compression различны. Dictionary/RLE/delta encoding переструктурирует значения по типу до того, как байтовый кодек вообще запустится, и сам по себе даёт значительную часть выигрыша по размеру.
Heads-up Encoding независим от выбора кодека. Snappy-файл всё равно использует dictionary/RLE/bit-packing на своих pages; кодек накладывается поверх того encoding, что был применён.
Heads-up Оба lossless, но это разные механизмы с разными ручками и разными режимами отказа — dictionary blowup это проблема encoding, а CPU-цена кодека это проблема compression. Смешение скрывает реальные решения по тюнингу.
Викторина
Completed
Ты включаешь dictionary encoding на колонке случайных UUID. Какой вероятный исход и почему?
Heads-up Dictionary encoding окупается только когда значения повторяются. С почти уникальными UUID словарь становится таким же большим, как сама колонка, переполняет бюджет, и Parquet его бросает.
Heads-up Повреждения нет — Parquet просто откатывается на plain encoding для этой колонки. Цена это потраченный CPU и, возможно, больший файл, но никогда не корректность.
Heads-up На данных высокой кардинальности это не бесплатно: ты платишь за построение словаря, который ничего не уменьшает, а затем его выбрасываешь, что может дать файл больше, чем дал бы plain encoding.
Викторина
Completed
Kafka-консьюмер сбрасывает крошечный Parquet-файл в S3 каждые 10 секунд. Дашборды над таблицей стали мучительно медленными. Какое решение даёт наибольший рычаг?
Heads-up zstd это реальный выигрыш по размеру за крошечную плату на чтении, но он ничего не делает с количеством файлов. Узкое место — листинг и чтение миллионов футеров при планировании, а не байты на файл: верная идея, не та проблема.
Heads-up Сброс раз в 10 секунд имеет лишь пару КБ для записи, так что он не заполнит row group в 1 ГБ — ты по-прежнему получаешь много крошечных файлов, теперь с крошечными row groups. Размер row group важен для больших батч-записей, а не для высокочастотного стримингового писателя.
Heads-up Убрав футер, ты убираешь column pruning и predicate pushdown, так что каждый запрос полностью сканирует и парсит — гораздо хуже. И у тебя всё равно останутся миллионы мелких файлов для листинга. Это меняет вопрос тюнинга на фундаментальный.
Викторина
Completed
Сырые Parquet-файлы в директории дают тебе колоночное хранение и pushdown. Что добавляют сверху Iceberg, Delta Lake и Hudi и почему это важно?
Heads-up Они не заменяют Parquet — они держат данные в Parquet и добавляют слой таблицы сверху. Хранение остаётся колоночным Parquet; формат добавляет транзакции, снапшоты и метаданные для планирования.
Heads-up Сжатие по-прежнему работа Parquet (snappy/zstd/gzip). Table formats добавляют корректность и планирование — манифест текущего набора файлов, ACID, time travel — а не новый кодек.
Heads-up Это гораздо больше, чем именование: манифест отслеживает, какие именно файлы принадлежат таблице прямо сейчас, с их статистиками, что даёт ACID-коммиты, time travel и отсев на уровне файла, недоступный простому листингу директории.
Итог
Сквозная линия юнита — один цикл проектирования: колоночная раскладка даёт column pruning, min/max в футере дают пропуск row group и pages (predicate pushdown) — но только когда данные кластеризованы по колонкам фильтра. Encoding и compression — отдельные наложенные выигрыши, и dictionary encoding бьёт по рукам на колонках высокой кардинальности. Повторяющиеся продакшен-ловушки — это small-files problem (лечится compaction, а не кодеком получше) и размер row group. А поскольку у сырого Parquet нет транзакций, table formats — Iceberg, Delta Lake, Hudi — оборачивают его слоем манифеста ради ACID, time travel, безопасной schema evolution и pruning на уровне манифеста.