Learning Platform
Глоссарий Troubleshooting
Урок 17.02 · 35 мин
Продвинутый
NimbleLibrary as SpecParquet FragmentationWide SchemaParallel DecodingOpenZLMetaVeloxSpecificationImplementation Model

Nimble — философия дизайна

В предыдущем уроке мы разобрали техническую архитектуру Nimble: stripes, blocks, FlatBuffers, encoding pipeline. Но самое интересное в Nimble — не структура файла, а философия проекта. Nimble осознанно отвергает модель, по которой работают все остальные форматы хранения: отдельная спецификация + множество независимых реализаций.

Девиз проекта: «More than a specification, Nimble is a product» — «Nimble — не спецификация, а продукт». Это радикальный выбор, и он вытекает из конкретного опыта Meta с Parquet.

Проблема Parquet: фрагментация реализаций

Parquet — один из самых успешных open-source форматов. Но успех multi-implementation модели имеет цену:

Экосистема реализаций Parquet

Parquet Specification

Apache Parquet Specification: документ, описывающий формат файла. Определяет структуру (row groups, pages, footer), типы данных, кодировки, compression. Спецификация — источник истины, но интерпретация зависит от реализации.

parquet-java

parquet-java (Apache): оригинальная реализация. Поддерживает все features. Используется в Spark, Hive, Impala. Некоторые features (column encryption) — только здесь.
ОсобенностиПолная поддержка спецификации + расширения: column encryption (AES-GCM), modular encryption. Bloom filter implementation отличается от parquet-cpp. Некоторые edge cases в nested types — java-specific поведение.

parquet-cpp (Arrow)

parquet-cpp (Apache Arrow): C++ реализация через Arrow. Используется в PyArrow, DuckDB, Polars. Высокая производительность, но не все features parquet-java.
ОсобенностиArrow-native: читает напрямую в Arrow arrays. Нет column encryption (не реализовано). Bloom filter implementation — другая от Java. Statistics encoding: minor differences в edge cases.

parquet-rs (Rust)

parquet-rs (Apache Arrow): Rust реализация. Используется в DataFusion, Ballista, delta-rs. Быстро развивается, но отстаёт по feature coverage от Java.
ОсобенностиБыстрейший reader для single-node. Асинхронный I/O (tokio). Нет column encryption. Page index support — partial. Некоторые кодировки (BYTE_STREAM_SPLIT) появились позже, чем в Java.

Проблемы multi-implementation модели:

Проблемы фрагментации Parquet
Feature GapsНе все реализации поддерживают все features. Файл, записанный parquet-java с column encryption, нечитаем в parquet-cpp или parquet-rs. Bloom filter формат различается. Page index support — не везде.
Behavior DifferencesОдни и те же данные могут давать разные statistics в разных реализациях. Edge cases в nested types (especially map with null keys). Sort order для binary types — неоднозначен в спецификации.
Evolution FrictionДобавить новую кодировку = обновить спецификацию + согласовать с 3+ реализациями + подождать releases + обеспечить backward compatibility. Цикл: 12-24 месяца. Meta хочет добавлять кодировки за недели.
NOTE

Это не критика Parquet — multi-implementation модель обеспечила Parquet статус универсального стандарта. Файлы, записанные в Java Spark, читаются Python PyArrow и Rust DataFusion. Но для Meta, где скорость добавления новых кодировок критичнее универсальности, эта модель — bottleneck.

«Библиотека как спецификация»

Nimble переворачивает модель: реализация IS спецификация. Нет отдельного документа, описывающего формат — есть C++ библиотека, которая определяет, как файлы записываются и читаются:

Модели спецификации форматов

Parquet Model

Модель Parquet: спецификация как отдельный документ. Реализации интерпретируют спецификацию независимо. Спецификация — арбитр, но не всегда однозначна.
Spec-FirstШаг 1: написать спецификацию (Thrift IDL + prose). Шаг 2: реализации интерпретируют spec. Шаг 3: corner cases → разные интерпретации → compatibility issues. Шаг 4: обновить spec для уточнения → новый цикл.

Nimble Model

Модель Nimble: библиотека = спецификация. Нет отдельного документа. Если хочешь узнать, как работает формат — читай код. Нет ambiguity, нет divergent interpretations.
Library-FirstШаг 1: написать библиотеку. Шаг 2: библиотека — единственный reader/writer. Шаг 3: нет разных интерпретаций — один код, один результат. Шаг 4: добавить фичу = один PR.

Преимущества library-first подхода:

  1. Нет ambiguity. Вопрос «как работает encoding X?» — ответ в коде. Нет расхождений между спецификацией и реализацией.

  2. Быстрая эволюция. Новая кодировка = один PR в один репозиторий. Нет согласования с другими реализациями, нет compatibility matrix.

  3. Консистентность. Файл, записанный Nimble, гарантированно читается Nimble. Нет сюрпризов «этот файл записан Java-реализацией, у которой другой bloom filter формат».

Цена:

  1. Vendor lock-in. Без Velox нет Nimble. Нет Python, Java, Rust readers.

  2. Нет ecosystem. Нет DuckDB connector, нет PyArrow reader, нет Polars support. Только Velox-based системы.

  3. Bus factor. Одна команда, одна организация. Если Meta перестанет поддерживать — формат мёртв.

Оптимизация для широких схем

Nimble архитектурно оптимизирован для таблиц с тысячами колонок. Это проявляется на нескольких уровнях:

Wide Schema: Parquet vs Nimble при 10K колонок
Query: 4 columns из 10 000Запрос: SELECT col_42, col_7891, col_3 FROM wide_table WHERE col_100 > threshold. Таблица: 10 000 колонок, 1B строк. Нужно прочитать 4 колонки из 10 000.
ParquetШаг 1: прочитать footer → Thrift metadata для всех 10K колонок → полная десериализация: 50-200ms. Шаг 2: найти offset'ы 4 колонок в row group metadata → ещё одна Thrift десериализация per row group. Шаг 3: seek + read 4 column chunks.
NimbleШаг 1: прочитать footer → FlatBuffers. Шаг 2: random access к metadata col_42, col_7891, col_3, col_100 — 4 offset lookups. Не десериализуем остальные 9996 колонок. Шаг 3: seek + read 4 streams.

Параллельное декодирование: scheduling без данных

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

Scheduling Pipeline: Nimble Block Decoding

Stripe Footer (FlatBuffers)

Stripe footer: FlatBuffers metadata с полной информацией о каждом block в каждом stream. Включает: offset, encoded size, decoded size, encoding type, value count. Достаточно для полного планирования.
Phase 1: Planning (no data loaded)Scheduler анализирует metadata: для каждого запрошенного stream — список blocks с известными decoded sizes. Строит execution plan: какой block на каком core, сколько памяти выделить. Нулевой I/O для data на этом этапе.
Phase 2: I/O (batched reads)Batched I/O: scheduler знает exact offset и size каждого block. Собирает I/O requests для всех нужных blocks → один batched read (или несколько coalesced reads). Минимальное количество I/O операций.
Phase 3: Decode (parallel, bounded memory)Параллельное декодирование: каждый core декодирует назначенные blocks в pre-allocated буферы. Нет динамических аллокаций — всё выделено в Phase 1. Нет OOM surprises — peak memory = planned memory.

Decoded Columns (Velox Vectors)

Decoded column data: готовые Velox Vectors для execution engine. Весь pipeline: plan → I/O → decode — с гарантией отсутствия OOM и минимальным memory waste.
TIP

Сравните с Vortex из Модуля 15: Vortex тоже использует FlatBuffers metadata и cascading encodings, но не гарантирует known decoded size на уровне каждого chunk. Nimble’s block encoding — более строгий контракт: каждый block = предсказуемый memory footprint.

OpenZL: format-aware compression

Meta разрабатывает OpenZL — compression framework, который работает совместно с Nimble. Идея: compression engine, который «знает» о формате данных:

OpenZL: Format-Aware Compression

Generic Compression

Традиционная compression: ZSTD/LZ4 работают с raw bytes. Не знают, что данные — это колоночные values. Ищут byte patterns, повторы, entropy. Эффективно, но generic.
ZSTD / LZ4Вход: поток байт. Алгоритм: LZ77 (sliding window) + Huffman/FSE. Не использует знание о типе данных. Compression ratio: хорошее для text, mediocre для float64 arrays.

Format-Aware (OpenZL)

OpenZL: знает структуру Nimble — types, encoding pipeline, block boundaries. Может применять type-specific compression: integer delta + varint, float XOR + ZSTD, string dictionary + FSST.
OpenZLВход: typed column data + encoding metadata. Алгоритм: выбирает compression strategy на основе типа данных и encoding pipeline. Float → XOR encoding → ZSTD. Integer → Delta → Varint → LZ4. String → Dictionary → FSST.

Сравнение implementation моделей

Implementation Models: от Multi-Impl до Embedded Decoders
NOTE

F3 (урок 03 и 04) представляет противоположный полюс: каждый файл содержит собственный decoder. Nimble: «один decoder для всех файлов». F3: «каждый файл — свой decoder». Оба решают проблему расширяемости, но из противоположных философских позиций.

Kernel Scheduling: параллелизм без загрузки данных

Детальнее о механизме, который отличает Nimble от всех форматов в курсе — возможность полностью спланировать decode pipeline из одних метаданных:

Kernel Scheduling: Nimble vs Parquet

Parquet Scheduler

Parquet scheduler: знает offset'ы pages из column metadata. Но decoded size pages — unknown. Dictionary page может быть 1KB или 1GB. RLE page decoded size зависит от run lengths.
ОграниченияProblem 1: decoded size page = unknown → нельзя pre-allocate. Problem 2: dictionary page загрузка → memory spike (dictionary в память + decoded values). Problem 3: nested types → interdependent pages (definition levels).

Nimble Scheduler

Nimble scheduler: stripe footer содержит для каждого block: encoded_size, decoded_size, value_count, encoding_type. Полная информация для планирования до загрузки данных.
ВозможностиDecoded size: exact per block → exact total. Pre-allocate: одна аллокация точного размера. Scheduling: distribute blocks по cores → known time per block (proportional to decoded_size). No surprises.

Для ML-training pipelines в Meta, где тысячи decode tasks конкурируют за N GPU/CPU cores, deterministic scheduling — необходимость, не оптимизация. Nimble’s block headers — это контракт: «для декодирования этого block нужно X байт памяти и ~Y микросекунд CPU».

Текущие ограничения

Философия «одна библиотека» — осознанный trade-off. Текущие ограничения:

Ограничения Nimble (март 2026)
ЯзыкТолько C++. Требует Velox build system: folly, glog, gtest, abseil, fmt. Нет standalone cmake — интеграция через Velox CMake. Компиляция: 30+ минут с зависимостями.
БиндингиНет Python bindings (нельзя pip install). Нет Java bindings (нельзя использовать в Spark напрямую, только через Gluten/Velox plugin). Нет Rust bindings.
EcosystemНет DuckDB connector. Нет Polars reader. Нет Arrow C Data Interface export. Файлы можно читать только через Velox-based приложения (Presto, Spark+Gluten).
AdoptionOpen-sourced 2024 (formerly 'Alpha'). GitHub: facebookincubator/nimble. Ранняя стадия: limited documentation, no tutorials, no ecosystem integrations. Используется внутри Meta, но внешнего adoption почти нет.
WARNING

Nimble — не формат для production use за пределами Meta. Это скорее архитектурный эксперимент, демонстрирующий подход «библиотека как спецификация». Ценность для инженера — понимание trade-offs между universal ecosystem (Parquet) и fast-evolving single-source (Nimble).

Уроки для дизайна форматов

Опыт Nimble формулирует несколько принципов, актуальных для всех форматов нового поколения:

Дизайн-принципы Nimble
Принцип 1Metadata format определяет scalability. Thrift/Protobuf = O(N) десериализация. FlatBuffers = O(1) random access. При 10K+ колонках разница в 2 порядка. Все форматы нового поколения (Vortex, F3, Nimble) выбрали FlatBuffers.
Принцип 2Предсказуемость памяти > raw throughput для scheduling. Block encoding с known decoded size позволяет deterministic scheduling. Потоковое декодирование быстрее в single-thread, но unpredictable для parallel workloads.
Принцип 3Extensibility vs ecosystem — фундаментальный trade-off. Parquet: максимальная ecosystem, медленная extensibility. Nimble: мгновенная extensibility, minimal ecosystem. Vortex/F3: попытки найти баланс (pluggable encodings / embedded decoders).
Принцип 4Tight coupling с execution engine — мощный performance tool, но ecosystem risk. Nimble + Velox: нет conversion overhead. Но без Velox — Nimble мёртв. Contrast: Lance + Arrow: loose coupling, universal interop.

Итоги

Nimble — это не «ещё один формат хранения», а философский statement о дизайне форматов данных:

  1. «Библиотека как спецификация» устраняет фрагментацию реализаций. Один codebase = zero ambiguity, instant evolution. Цена — экосистема ограничена одним языком и одним execution engine.

  2. Wide schema optimization — ответ на конкретную проблему Meta (10K+ колонок). FlatBuffers metadata + stream-per-column = O(1) доступ к любой колонке.

  3. Deterministic scheduling — block encoding с known decoded sizes позволяет планировать parallel decode без загрузки данных. Для ML-training infra Meta это критично.

  4. OpenZL — format-aware compression, работающая совместно с encoding pipeline. Использует знание о типах данных для лучшего compression ratio.

В следующем уроке мы перейдём к F3 — Future-proof File Format от CMU. Если Nimble — это «одна библиотека для всех файлов», то F3 — «каждый файл содержит свой собственный decoder». Два полярных подхода к проблеме расширяемости форматов.

Проверьте понимание

Результат: 0 из 0
Прикладной
Вопрос 1 из 4. Parquet поддерживает column encryption в parquet-java, но не в parquet-cpp (Arrow) и не в parquet-rs. Как модель «библиотека как спецификация» (Nimble) решает такие feature gaps?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок
Вернуться к курсу
Прогресс модуля
0 из 5