Learning Platform
Глоссарий Troubleshooting
Урок 17.04 · 40 мин
Продвинутый
F3WebAssemblyWasmWasmtimeExtensibilityEncoding DeploymentSandboxPerformance OverheadFleet UpgradeSelf-Describing

F3 — Wasm-декодеры

В предыдущем уроке мы разобрали структуру F3: IOUnits, EncUnits, FlatBuffer metadata. Но главная инновация F3 — embedded WebAssembly decoders. Каждый F3 файл содержит скомпилированный Wasm-код, способный декодировать собственные данные. Это самый радикальный подход к extensibility среди всех форматов в курсе.

Проблема: как обновить кодировки на 10 000 серверов

Представьте: исследователь в CMU разрабатывает новую кодировку для float64, которая сжимает на 30% лучше ALP. Как её внедрить?

Проблема deployment новых кодировок

Новая кодировка: super-alp-float64

Новая кодировка: super-alp-float64. Сжимает float64 на 30% лучше, чем ALP. Реализация: 500 строк Rust/C++ кода. Хотим использовать в production.
Parquet PathШаг 1: PR в Apache Parquet spec (review 3-6 мес). Шаг 2: реализовать в parquet-java (review + release 2-3 мес). Шаг 3: реализовать в parquet-cpp/Arrow (2-3 мес). Шаг 4: реализовать в parquet-rs (2-3 мес). Шаг 5: roll out новые версии на 10K серверов (1-3 мес). Итого: 12-18 месяцев.
F3 PathШаг 1: реализовать decoder в Rust (дни). Шаг 2: скомпилировать в Wasm (минуты). Шаг 3: writer начинает embed Wasm в новые файлы (немедленно). Шаг 4: любой reader с Wasmtime декодирует — без обновлений. Итого: дни.
NOTE

Это не гипотетическая проблема. Parquet encoding evolution: DELTA_BINARY_PACKED (2014) → BYTE_STREAM_SPLIT (2020) → DELTA_BYTE_ARRAY improvements (2022). Каждое добавление = multi-year process. Между тем, research на encoding’ах движется быстрее: ALP (2023), FastLanes (2023), FSST (2020), BtrBlocks (2023) — все появились быстрее, чем Parquet может их adopt.

Как работает Wasm в F3

WebAssembly (Wasm) — компактный бинарный формат для portable выполнения кода. Разработан для браузеров, но активно используется server-side (Wasmtime, Wasmer, WasmEdge):

Wasm Decode Pipeline в F3

Writer: Rust encoding → Compile to Wasm

Writer: реализует encoding на Rust/C/C++. Компилирует в Wasm target (wasm32-wasi или wasm32-unknown-unknown). Размер: исходный Rust код ~500 строк → Wasm binary ~5-50KB (tiny по сравнению с данными файла).
Embed в файлWriter встраивает compiled Wasm binary в footer файла (Wasm Decoder Registry). Каждый уникальный encoding = один Wasm module в registry. EncUnit descriptor ссылается на module ID.

Self-Describing F3 File

File на storage: содержит данные (EncUnits с encoded payloads) + metadata (FlatBuffers) + Wasm decoders (в footer). Файл полностью самодостаточен — любой reader с Wasm runtime может его прочитать.
Reader: load + executeReader открывает файл → загружает Wasm modules из footer в Wasmtime → pre-compile (AOT compilation, ~10ms per module). Для каждого EncUnit: lookup decoder ID → call decode(payload) в Wasm sandbox → получить decoded values.

Decoded Column Data

Decoded data: стандартный columnar output. Reader не знал encoding заранее — Wasm decoder «научил» его декодировать. Любой future encoding: тот же pipeline.

Performance: Wasm overhead

Ключевой вопрос: какова цена universality? F3 SIGMOD paper измеряет overhead:

Wasm Overhead vs Native Decoding
Startup Cost (one-time)Wasm module compilation: AOT (Ahead-of-Time) compilation в Wasmtime. Один раз при открытии файла. ~5-15ms per module. Для файла с 3-5 encodings: ~30-75ms total startup. Amortized по всем EncUnits в файле.
Per-EncUnit DecodeWasm decode call overhead: function call через Wasm boundary (~100ns), memory copy in/out of Wasm sandbox (~1-5μs per MB), SIMD: Wasm SIMD128 supported но не автоматический. Total overhead per EncUnit: 10-30% vs native C/Rust.
Net EffectWasm overhead: 10-30% slower decoding. НО: F3 storage layout improvements (tunable IOUnit, decoupled dict, column skip) offset 10-50% of I/O cost. Net: F3 competitive with native-decoded Parquet despite Wasm overhead. Paper conclusion: overhead acceptable.
TIP

Wasm module size: 2-50KB. Для context: один Parquet data page = ~64KB. Overhead embedding Wasm decoders в файл = negligible. Файл 1GB с 5 encodings: 100KB Wasm / 1GB data = 0.01% overhead.

Sandbox Security

Wasm execution в sandbox — важное свойство. Reader выполняет чужой код (decoder из файла), но Wasm гарантирует изоляцию:

Wasm Sandbox Model

Native Plugin (C/C++ .so)

Native plugin model (C/C++ shared library): полный доступ к памяти процесса, файловой системе, сети. Malicious decoder может: прочитать secrets, модифицировать данные, exfiltrate data. Unsafe.
RisksFull memory access: может прочитать любой адрес процесса. File system: может читать/писать файлы. Network: может открыть сокеты. Arbitrary code execution: полный контроль.

Wasm Decoder (sandboxed)

Wasm sandbox (Wasmtime): decoder работает в изолированном linear memory. Нет доступа к host memory, файловой системе, сети. Может только: читать input buffer, писать output buffer. Вызвать decode() — и всё.
GuaranteesMemory: только свой linear memory (max 4GB, обычно ~1MB). No host access: не видит процесс host. No I/O: нет файлов, нет сети. No side effects: чистая функция input → output. Deterministic execution.
WARNING

Sandbox не защищает от всего. Wasm decoder может: (1) consume excessive CPU (infinite loop — нужен timeout), (2) allocate excessive memory (нужен memory limit в Wasmtime config), (3) return incorrect results (нет way to verify correctness без known-good decoder). F3 — research prototype, production security model требует дополнительных гарантий.

Три подхода к расширяемости

F3 представляет один из трёх подходов к решению проблемы encoding extensibility. Сравним:

Спектр расширяемости форматов

Nimble: One Library

Nimble: одна библиотека. Добавить кодировку = PR в один репозиторий. Нет coordination overhead. Но: reader ДОЛЖЕН быть обновлён. Если reader старый — не читает новую кодировку.
МеханизмНовая кодировка → PR в nimble repo → merge → все Velox-based системы получают при следующем rebuild. Fast iteration, но requires rebuild/redeploy. Scope: Velox ecosystem only.
Trade-offPro: простейшая модель, нет compatibility issues. Con: reader update required, ecosystem = one library. Философия: 'доверяем одной команде, оптимизируем iteration speed'.

Vortex: Pluggable Encodings

Vortex: pluggable encodings через Rust traits. Третьи стороны могут реализовать trait → register encoding → Vortex reader вызывает через vtable dispatch. Self-describing layouts для forward compat.
МеханизмРеализовать EncodingTrait в Rust → зарегистрировать → reader загружает encoding plugin. FlatBuffer описывает layout → known encoding: native decode; unknown: Wasm fallback (planned). Балансирует between extensibility и performance.
Trade-offPro: extensible, native performance для known encodings. Con: unknown encodings require fallback mechanism, Rust ecosystem only (no Java/Python plugins). Философия: 'extensible within Rust ecosystem'.

F3: Embedded Wasm

F3: embedded Wasm decoders. Каждый файл содержит decoder'ы. Reader с Wasmtime runtime декодирует любой файл. Нет зависимости от конкретной библиотеки. Максимальная portability.
МеханизмРеализовать encoding → compile to Wasm → embed в файл. Reader: load Wasm → execute в sandbox → decoded data. Нет library updates, нет fleet rollout. Файл = self-contained system.
Trade-offPro: maximum portability, zero deployment friction. Con: 10-30% Wasm overhead, security risks (executing untrusted code), debugging complexity. Философия: 'файл — автономная единица, не зависит от ecosystem'.

Deployment Model Comparison

Визуализация процесса deploy новой кодировки в трёх моделях:

Deployment Pipeline: новая кодировка

Encoding Lifecycle в F3

Как новая кодировка проходит полный lifecycle от разработки до использования:

Encoding Lifecycle в F3
  1. Research: новый encoding
Phase 1: Research. Исследователь разрабатывает новый encoding алгоритм. Пишет decoder на Rust. Тестирует на benchmark данных. Публикует paper (опционально).
  1. Compile: Rust → Wasm
Phase 2: Compile to Wasm. Rust decoder → cargo build --target wasm32-wasi → Wasm binary. Размер: 2-50KB. Тестирование: decode(encode(data)) == data.
  1. Writer: embed decoder
Phase 3: Writer embeds. F3 writer получает Wasm module. При записи файла: encode данные → embed Wasm decoder в footer → EncUnit descriptors ссылаются на module ID. Файл готов.
  1. File → data lake
Phase 4: Distribution. Файл попадает в data lake (S3, HDFS). Тысячи readers в кластере. Ни один reader не знает о новом encoding. Но каждый reader имеет Wasmtime runtime.
  1. Reader: load Wasm → decode
Phase 5: Any reader decodes. Reader открывает файл → загружает Wasm из footer → AOT compile → decode. Нет library update, нет coordination, нет fleet rollout. Reader 'учится' декодировать при открытии файла.
  1. Optional: add native decoder
Phase 6: Native optimization (optional). Если encoding доказал эффективность — можно добавить native decoder в reader library. Wasm остаётся как fallback для old readers. Gradual optimization.

Phase 6 — опциональная оптимизация: если encoding стал популярным, reader library может добавить native decoder. Тогда: known encoding → native decode (100% speed), unknown → Wasm decode (70-90% speed). Gradual optimization без breaking change.

Wasm vs Native: детальное сравнение

Wasm Decode vs Native Decode: детали
NOTE

10-30% overhead — результат из SIGMOD 2025 paper. Для context: разница между ZSTD level 1 и level 3 compression = ~30% decode speed. Wasm overhead сопоставим с выбором compression level — не catastrophic, но заметен для hot decode paths.

Спектр расширяемости: от Parquet до F3

Все форматы курса можно расположить на спектре «extensibility vs performance vs ecosystem»:

Спектр расширяемости форматов
ParquetМинимальная extensibility: 6 фиксированных encodings. Максимальная ecosystem: Java, C++, Rust, Python. Максимальная совместимость. Добавить encoding = 12-18 месяцев.
NimbleСредняя extensibility: новые encodings быстро (PR), но reader update required. Минимальная ecosystem (Velox only). Максимальная consistency (one codebase).
VortexВысокая extensibility: pluggable Rust traits, Wasm fallback (planned). Средняя ecosystem (DuckDB, Iceberg, Arrow). Native performance для known encodings.
F3Максимальная extensibility: embedded Wasm, мгновенный deploy, zero fleet updates. Universal portability (any Wasm runtime). 10-30% overhead. Research prototype.
ТрендОбщий тренд: от fixed encodings (Parquet) к self-describing файлам (F3). Каждое поколение двигается вправо по спектру. Вопрос: где оптимальная точка для production?

Практические импликации

Хотя F3 — research prototype, идеи embedded decoders уже влияют на production форматы:

Влияние F3 на ecosystem
VortexVortex уже планирует Wasm fallback для unknown encodings. Идея из F3: если reader не знает encoding → загрузить embedded Wasm decoder. Это гибрид: native для known, Wasm для unknown.
Lance v2Lance v2 protobuf 'any' messages — шаг в направлении self-describing файлов. Unknown encoding type → skip (graceful degradation). Не Wasm, но похожая идея: forward compatibility через metadata.
Future ParquetDiscussions в Parquet community о Parquet 3.0: custom encodings, extensible metadata. F3 paper цитируется. Вероятно: не embedded Wasm, но pluggable encoding descriptors.

Итоги

Embedded Wasm decoders — самый амбициозный подход к extensibility среди форматов нового поколения:

  1. Мгновенный deploy. Новая кодировка = compile to Wasm → embed в файлы. Нет fleet upgrades, нет coordination. Writer-driven evolution.

  2. Universal portability. Любой reader с Wasm runtime (Wasmtime, Wasmer, WasmEdge, browser) декодирует любой F3 файл. Нет language lock-in.

  3. Sandbox security. Wasm decoders работают в изолированной памяти. Нет доступа к host, файловой системе, сети. Safe execution of untrusted code.

  4. Acceptable overhead. 10-30% vs native — сопоставимо с выбором compression level. Storage layout improvements offset часть overhead.

  5. Research prototype. F3 — proof of concept, не production format. Но идеи уже влияют на Vortex (Wasm fallback) и discussions о Parquet 3.0.

В следующем уроке — сравнение всех форматов нового поколения: Lance vs Vortex vs Nimble vs F3 vs Parquet. Какой формат для какого use case, и ответ на вопрос «заменят ли они Parquet?».

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

Результат: 0 из 0
Аналитический
Вопрос 1 из 4. Исследователь разработал новую кодировку super-alp-float64 (30% лучше ALP). Сравните deployment pipeline в Parquet vs F3.

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

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

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