Яндекс открыл YaFF для Protobuf: чтение данных в 3,8 раза быстрее FlatBuffers

До сих пор единственной распространённой альтернативой для тех, кому Protobuf тормозил, был FlatBuffers. Но у него своя схема, свои правила и несовместимый формат, а значит, миграция требовала переписывания конвертеров вручную. YaFF закрывает именно этот разрыв: формат работает поверх стандартных .proto-файлов и не требует отказа от Protobuf, а значит, внедрять его можно модуль за модулем. О выпуске Яндекс сообщил на GitHub, текущая версия 0.1.0, библиотека написана на C++.

Что именно сделали?

Сериализация (превращение структуры данных в поток байтов для хранения или передачи) в Protobuf устроена так: сервис получает сообщение, разбирает его, создаёт объект в памяти, и только потом может читать поля. На один разбор уходят доли микросекунды, но когда таких операций миллиарды в сутки, процессоры тратят ощутимую долю времени только на парсинг.

Формат с нулевым копированием (zero-copy) работает иначе: данные лежат в буфере ровно так, как их будут читать, поэтому этап разбора пропускается. Поле читается прямо из буфера, как если бы вы открыли нужную страницу книги, а не переписывали её в тетрадь.

YaFF предлагает четыре варианта раскладки данных в памяти:

• Fixed (фиксированная): данные упакованы плотно, без заголовков, схема заморожена. Максимальная скорость, но нельзя менять набор полей.
• Flat (плоская): добавляет двухбайтовый заголовок и позволяет эволюцию схемы, то есть добавление новых полей без поломки старого кода.
• Sparse (разреженная): адресует поля через мета-таблицу, подходит для схем, где заполнена лишь часть полей.
• Dynamic (динамическая, по умолчанию): автоматически выбирает Flat или Sparse в зависимости от того, позволяет ли текущая схема плоскую раскладку.

Главная идея: .proto-файл остаётся единственным источником правды. YaFF меняет только физическое расположение данных в памяти, а программный интерфейс остаётся похожим на стандартный Protobuf.

Что показали бенчмарки?

Яндекс опубликовал воспроизводимый набор тестов на базе google/benchmark. Замеры выполнены на процессоре AMD EPYC 7713, компилятор Clang 20.1.8, сборка Release. Ключевые результаты на иерархическом сценарии чтения:

• Flat Layout YaFF: 9,79 нс на операцию чтения.
• FlatBuffers: 37,30 нс, то есть в 3,8 раза медленнее.
• Стандартный Protobuf: 219,35 нс, в 22 раза медленнее.
• Сырая структура C++ без всяких форматов: 8,14 нс. YaFF отстаёт от неё всего в 1,2 раза.

Яндекс отдельно оговаривает: абсолютные числа зависят от процессора и памяти, но соотношение между форматами должно сохраняться на другом оборудовании.

Кроме скорости, YaFF решает техническую проблему компиляторной оптимизации. И FlatBuffers, и YaFF читают поля, интерпретируя сырую память как нужный тип. Компилятор LLVM при этом не может доказать, что повторные обращения к одному полю безопасно кэшировать, и перечитывает цепочку доступа заново. YaFF добавляет в сгенерированный код аннотации, которые помогают компилятору переиспользовать результат, если между чтениями память не менялась.

В продакшене Яндекс использует YaFF в рекламной рекомендательной системе. По данным компании, это даёт 10-20% экономии процессорного времени.

Что это значит для вас?

Для тех, кто работает с контентом и ИИ в России, эта новость интересна с нескольких сторон.

Разработчикам на C++, которые используют Protobuf в высоконагруженных сервисах, YaFF даёт способ ускорить чтение данных без полной миграции. Достаточно подключить формат в одном критичном участке кода, а на границах оставить двустороннюю конвертацию в Protobuf. Подключение идёт через CMake или Conan.

Тем, кто работает с Protobuf Golang или другими языками, пока не повезло: YaFF существует только для C++. Но сам подход (альтернативный формат хранения поверх .proto-схем) может появиться и для других экосистем, если сообщество подхватит проект.

Авторам Дзена и маркетологам новость показывает, как российские компании решают инженерные задачи, которые напрямую влияют на скорость и стоимость рекомендаций. Рекламная система Яндекса обслуживает показы на Дзене, в Поиске и Директе, а экономия 10-20% процессоров на этом масштабе означает либо экономию на серверах, либо ресурс для более сложных моделей ранжирования.

По данным GitHub-репозитория YaFF (Яндекс).