Разделение данных по ключу (обычно по дате), чтобы запрос читал минимум файлов.
Ключевые тезисы
- Партиция по дате события, а не по дате загрузки — иначе поздние данные ломают историю.
- Слишком мелкие партиции создают проблему «маленьких файлов» и замедляют чтение.
- Для ML критично уметь получить срез данных «как он выглядел на дату T».
Подробный разбор
2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.
1Выбор ключа партиционирования
Дата события против даты загрузки.
Партиционировать почти всегда следует по дате события. Тогда поздно пришедшие данные попадут в свою историческую партицию, и пересчёт признаков «на момент времени» останется корректным.
- Партиция по дате загрузки удобна инженеру и вредна аналитику: история «плывёт».
- Слишком детальное партиционирование (по часу и по клиенту) порождает миллионы мелких файлов.
- Ориентир по размеру одного файла: сотни мегабайт, не килобайты.
2Проблема маленьких файлов
Классическая беда озёр данных.
Каждый файл — это отдельный запрос к объектному хранилищу и отдельная задача в движке. Десятки тысяч файлов по 200 КБ читаются на порядок дольше, чем сотня файлов по 200 МБ с тем же объёмом данных.
Лечение: регулярная компактация (OPTIMIZE в Delta, compaction в Iceberg) и запись с явным контролем числа выходных файлов (repartition / coalesce).
Связанные темы
Платформа данных
Warehouse, Lake, Lakehouse80%
Хранилище, озеро, lakehouse · Инженерия данныхТри способа хранить аналитические данные: строгая схема, сырые файлы или гибрид с транзакциями поверх объектного хранилища.
File Formats80%
Форматы хранения · Инженерия данныхКолоночные форматы против строковых: почему Parquet почти всегда лучше CSV для аналитики.
Analytical SQL80%
Аналитический SQL · Инженерия данныхОконные функции, агрегации и CTE — основной инструмент подготовки признаков на больших данных.
ETL vs ELT80%
ETL и ELT · Инженерия данныхПреобразовывать данные до загрузки или уже внутри хранилища — и почему индустрия сместилась ко второму.
Batch and Streaming80%
Батч и стриминг · Инженерия данныхОбработка по расписанию против непрерывной обработки событий. Разные задержки, разные гарантии, разная стоимость.
Orchestration80%
Оркестрация пайплайнов · Инженерия данныхПланировщик, который знает зависимости между задачами, повторяет упавшие и не даёт запускать одно и то же дважды.
Spark80%
Spark · Инженерия данныхРаспределённая обработка больших объёмов данных: тот случай, когда данные не помещаются на одну машину.
Kafka80%
Kafka · Инженерия данныхРаспределённый журнал событий: основа потоковой архитектуры и источник данных для онлайн-признаков.
ML Pipelines80%
ML-пайплайны · MLOpsОформление обучения как воспроизводимой последовательности шагов вместо разрозненных ноутбуков.
Data Versioning80%
Версионирование данных · MLOpsДанные меняются чаще кода — без их версий эксперимент не воспроизвести.