📦 AnyBlox: A Framework for Self-Decoding Datasets
#tum #arrow #parquet #wasm #avx

🥼 Article https://www.vldb.org/pvldb/vol18/p4017-gienieczko.pdf
Статья получила премию VlDB'25 Best Paper Award, но я не согласен 😧

В статье описан формат хранения для аналитических задач, который должен решить часть проблем совместимости между разными системами.

🪨 Context
Сейчас стандартом для аналитических задач стали несколько комбинаций форматов:
1. Iceberg (+Parquet) для долговременного хранения и использования в разных системах
2. Apache Arrow для быстрой аналитической обрабтки в памяти или передачи между разными системами
3. Свои бинарные форматы: clickhouse, duckdb, bigquery, и т.п.

Apache Iceberg начал становиться стандартом, но с ним есть проблема.
Для каждого ЯП -- своя реализация, поддерживающая разный набор фичей и разную производительность.

Parquet, страдает тем же самым, каждая система пишет его по-своему.
Каждая БД рано или поздно хочет написать свой Reader / Writer, потому что можно более тесно встроить и значительно ускорить работу.

Из-за этого возникает проблема MxN (где у нас M-систем/БД и N-форматов), количество реализаций и форматов растет, а поддерживать их сложнее.

Свои бинарные форматы всегда работают и поддерживаются лучше, но они всегда vendor-lock на конкретной системе.

🧂The Idea
В статье автор предлагает следующее решение проблемы:
* Рядом с самими данными можно подкладывать программу, которая знает как распаковать эти данные в память.
* В качестве такой механизма для исполнения -- WebAssembly (WASM), ограниченная VM, которая может исполнить произвольный код без системных вызовов.
* База данных должна поддержать WASM Engine, который скомпилирует это программу под свой архитектуру и исполнит ее
* Это программа читает данные и маппит их на Apache Arrow формат, который уже поддерживается многими БД
* PROFIT!

🈲 My opinion
WASM предоставляет песочницу, но она нужна если исполнять там произвольный код.
Если формат стандартизирован, то эта песочница не нужна, нужно тестировать input/output формата, гонять fuzzing testing и схема будет проще и надежней.

Основная проблема с реализациями в том, что некоторые ЯП вроде Java (Scala, Kotlin, ...) и Go, не любят использовать внешние C-libs, потому что взаимодействие своего runtime с любой внешней сишной либой вызывает много проблем.
НО WASM никак не решает эти проблемы, все остается на том же месте.
Здорово иметь возможность запустить произвольный код, но скорее всего разработчики продолжат писать свои parquet reader/writer во всех ЯП (C, C++, Rust, Go, Java).

WASM накладывает ограничения на прямую работу с памятью и автор предлагает использовать mmap, и транслировать их в WASM для zero-copy работы.
Это решает проблему с копированием данных между runtime, но полностью будет игнорировать механизм работы BufferManager в самой БД.
БД сама должна иметь свой буффер и mmap это плохая идея https://db.cs.cmu.edu/mmap-cidr2022/

Apache Arrow как в общий формат это лучший из текущих вариантов для этой задачи, но и у него есть ограничения по типам данных и методам обработки.
Нужно ли дальше БД конвертировать в свой формат? Появится ли там data copy? Если все БД будут использовать Arrow, то их производительность будет ограничена этим форматом.
⚡Это просто не выгодно бизнесу, как формат для импортирования данных -- да, для полноценной работы -- нет

WASM поддерживает векторные инструкции, но до 128 bits (bye-bye AVX256/AVX512), а писать код с ними сложнее чем на C/C++.
Из-за этого вариант с WASM всегда будет хуже C-library или своим парсером.

ИМХО, это проблему лучше решить через Change-Data-Capture.
Например как Data Transfer / Airbyte компонента, которая умеет подписываться на Iceberg и конвертировать его сразу в Arrow или свой бинарный формат.
Думаю это более надежный и быстрый вариант.

Автор в статье показывает, что WASM работает медленее нативных форматов с векторизацией, но быстрее parquet. Ну доля правды в этом и есть, именно поэтому и лучше и переписать parquet lib, потому что там еще есть места для ускорений.