Nimble Architecture

Parquet проектировался в 2013 году для аналитических workload’ов: десятки колонок, SQL-запросы, Hadoop MapReduce. Внутри Meta масштабы другие: AI/ML training таблицы с 10 000+ колонок (features, embeddings, метрики), где Parquet’s Thrift-based metadata становится узким горлом, а фиксированный набор кодировок ограничивает эффективность для новых типов данных.

Nimble — это C++ формат хранения, разработанный Meta (facebookincubator/nimble) как ответ на эти ограничения. Открыт в 2024 году (до этого — внутренний проект «Alpha»). Тесно интегрирован с Velox — execution engine Meta, используемым в Presto, Spark и внутренних ML pipeline’ах.

Мотивация: широкие таблицы Meta

Meta обрабатывает таблицы, структура которых радикально отличается от типичных OLAP-датасетов:

Конкретные проблемы Parquet для таблиц Meta:

1. Metadata bottleneck. Parquet использует Apache Thrift для сериализации метаданных. Thrift требует полного парсинга всего сообщения — нельзя прочитать metadata для одной колонки из 10 000 без десериализации всего блока. При 10K+ колонок это 50-200ms на row group только на metadata.

2. Фиксированные кодировки. Parquet поддерживает ~6 кодировок (PLAIN, DICTIONARY, RLE, DELTA_BINARY_PACKED, BYTE_STREAM_SPLIT, DELTA_LENGTH_BYTE_ARRAY). Добавление новой кодировки требует обновления спецификации, всех реализаций (Java, C++, Rust), совместимости. Meta хочет добавлять кодировки быстро.

3. Непредсказуемое потребление памяти. Parquet декодирует данные потоково (stream) — объём памяти зависит от размера page и паттерна кодирования. Для scheduler’а ML-pipeline, который должен разместить N декодеров на GPU/CPU cores, непредсказуемость — проблема.

Структура файла Nimble

Nimble организует данные в stripes (аналог row groups в Parquet), но с принципиально другой организацией внутри:

Footer размещён в конце файла — это позволяет writer’у записывать данные последовательно и финализировать метаданные одним write. Reader сначала читает footer (seek to end → read size → read footer), затем навигирует к нужным stripes.

Stripes, Streams и Blocks

Внутри каждого stripe данные организованы в streams. Каждая колонка представлена одним или несколькими streams (для nested типов — дополнительные streams для definition/repetition levels):

Ключевое отличие от Parquet: блочная организация вместо страничной. В Parquet данные в page — это stream (произвольной длины), декодирование которого может потребовать непредсказуемый объём памяти. В Nimble block — это атомарная единица с известным размером decoded output.

FlatBuffers vs Thrift: доступ к метаданным

Выбор формата метаданных — одно из ключевых архитектурных решений Nimble:

Block Encoding vs Stream Encoding

Главное архитектурное решение Nimble — блочное кодирование вместо потокового. Это напрямую влияет на предсказуемость потребления памяти:

Предсказуемость памяти — не теоретическое преимущество. В инфраструктуре Meta, где тысячи ML-training jobs конкурируют за GPU/CPU ресурсы, scheduler должен точно знать memory requirements каждого task. Block encoding делает decoding планируемым — как CPU instruction с известным latency.

Encoding Pipeline

Nimble использует рекурсивный, композируемый encoding pipeline. В отличие от Parquet, где кодировка выбирается на уровне page и применяется целиком, Nimble составляет цепочки кодировок:

Рекурсивность означает, что каждый уровень может создавать sub-streams, которые проходят следующие уровни. Пример: Nullable(Dictionary(Delta(ZSTD(data)))) — nullable колонка с dictionary encoding, где indices закодированы delta + сжаты ZSTD.

Интеграция с Velox

Nimble не существует как standalone библиотека — он тесно интегрирован с Velox, execution engine Meta:

Tight coupling с Velox даёт преимущество в performance (нет conversion layer), но создаёт серьёзное ограничение: без Velox нельзя читать Nimble файлы. Нет standalone decoder, нет Python bindings, нет Java/Rust реализации.

Сравнение с Parquet: структура метаданных

Stripe Layout: потоки данных

Каждый stripe содержит параллельные streams для каждой колонки. Для nested типов (struct, list, map) создаётся иерархия streams:

Иерархия streams зеркалирует иерархию типов — в отличие от Parquet’s Dremel encoding, где nested types «размазываются» в плоские колонки с repetition/definition levels. Подход Nimble более прямолинейный: каждый уровень вложенности = отдельный stream. Это упрощает декодирование и делает его параллелизуемым.

Параллельное декодирование

Блочная архитектура Nimble обеспечивает предсказуемый параллелизм:

Сравнение с форматами курса

Итоги

Nimble — это целенаправленный ответ на конкретные проблемы Meta:

1. FlatBuffers metadata решает bottleneck Thrift при 10K+ колонках: O(1) random access вместо O(N) десериализации.

2. Block encoding обеспечивает предсказуемое потребление памяти: decoded size известен до начала декодирования. Scheduler точно планирует параллельное декодирование на N cores.

3. Рекурсивный encoding pipeline позволяет комбинировать кодировки произвольной глубины без изменения спецификации.

4. Tight coupling с Velox даёт performance (нет conversion layer), но ограничивает экосистему.

В следующем уроке мы разберём философию дизайна Nimble — подход «библиотека как спецификация», почему Meta осознанно отказывается от multi-implementation модели Parquet, и какие уроки из фрагментации Parquet-экосистемы привели к такому решению.