ヤンデックスがプロトコルバッファ用ゼロコピーワイヤーフォーマット「YaFF」をオープンソース化
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MarkTechPost
ヤンデックスは、プロトコルバッファの物理メモリレイアウトを変更するゼロコピー形式「YaFF」を Apache 2.0 ライセンスで公開した。同社ベンチマークではホットデータ読み込み速度が FlatBuffers の約 3.8 倍に達し、広告推薦システムでも 10〜20% の性能向上を確認している。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
TLDR
YaFF は、Protobuf 向けの Yandex オープンソース・ゼロコピーワイヤーフォーマットです。Apache 2.0 ライセンスで、現在は C++ で実装され、バージョンは v0.1.0 です。
.proto ファイルが真のソースのままであり、物理的なメモリアウトプットのレイアウトのみが変更されます。
Yandex のベンチマークでは、フラットレイアウトによるホットデータの読み込み速度は FlatBuffers より約 3.8 倍速く、生 C++ 構造体との差は 1.2 倍以内です。
4 つのレイアウト(固定、フラット、スパース、ダイナミック)があり、それぞれが読み取り速度とスキーマの柔軟性の間でトレードオフを行います。デフォルトはダイナミックです。
YaFF は Yandex の広告推薦システムで稼働しており、本番環境スケールでは CPU 使用量を 10〜20% 削減した実績があります。
導入は段階的に行われます:ホットパスの 1 つに YaFF を投入し、エッジ部で双方向 Protobuf 変換を行います。
Yandex は Apache 2.0 の下で YaFF(Yet another Flat Format)をオープンソース化しました。これは高性能な C++ シリアライゼーションライブラリです。YaFF は Protobuf エコシステム向けのゼロコピーワイヤーフォーマットを提供します。.proto ファイルは唯一の真のソースとして維持され、フォーマットの変更はデータがメモリ上にどのように配置されるかという点に限定されます。この技術はサーバーサイドランタイムに焦点を当てています。
YaFF とは何か
YaFF は Protobuf の代替品ではありません。それは Protobuf メッセージ向けの代替ワイヤーフォーマットです。同じ.proto スキーマから、プロトタイプのような C++ API が生成されます。読み取りには解析ステップが不要なため、フィールドはバッファから直接取得できます。パフォーマンスに敏感でないコードでは、依然としてワイヤーフォーマットを Protobuf メッセージへパースして戻すことも可能です。この双方向変換こそが、モジュールごとの段階的導入を現実的なものとしています。YaFF はホットパスの 1 つに導入し、残りの部分は引き続き Protobuf を使用します。
それが解決する課題
Protobuf の解析は、高負荷のバックエンドでは CPU の使用率を二桁パーセントまで消費することがあります。大規模なスケールでは、これは数千もの物理コアに相当します。一般的なゼロコピーオプションとして Google 製の FlatBuffers が挙げられますが、FlatBuffers は Protobuf のドロップイン代替ではなく、別個のスキーマと変換レイヤーの維持を必要とします。意味論的に Protobuf と互換性がないため、移行にはスキーマの重複、異なるスキーマ進化ルール、そして手書きによるフィールドコンバータが必要となります。多くのチームは、このコストに見合わないという結論に至ります。YaFF はこのギャップを埋めることを目指し、Protobuf の意味論を維持したままゼロコピー読み取りを実現します。
レイアウトの仕組みについて
レイアウトは、メッセージがバッファ内にどのように保存されるかを決定するものです。これは物理的な表現のみを変更し、スキーマや生成されたインターフェースには変更を加えません。YaFF では 4 つのレイアウトが提供されています。「Fixed」はヘッダーを持たない単純なパッキング済み構造体で、スキーマは固定されます。「Flat」は 2 バイトのヘッダーを追加し、スキーマ進化をサポートします。「Sparse」はメタテーブルを通じてフィールドにアクセスするため、疎なスキーマに適しています。「Dynamic」がデフォルトであり、実行時に Flat または Sparse を選択します。スキーマが許容する場合は Flat を使用し、進化によってフラットなアライメントが崩れた場合に Sparse に切り替えます。
レイアウト 読み取りアクセス メッセージごとのオーバーヘッド スキーマ進化 最適な用途
Fixed 1 回の読み取り、0 回の分岐 0 バイト 固定 小規模なインラインプリミティブ
Flat 2 回の読み取り、1 回の分岐 2 バイト 制限あり(型保存) 密なデータ、ホットデータ
Sparse 4 回の読み取り、2 回の分岐 6 バイト 制限なし 疎なスキーマ、自由な進化
動的(デフォルト)/ランタイム時のフラットまたはスパース / 2 または 6 バイト / 制限なし / 一般的なアプリケーションロジック
ベンチマーク
ヤンデックスは、google/benchmark を使用してビルドされた再現可能なベンチマークスイートをリリースビルドとして提供しています。以下の数値は、AMD EPYC 7713 プロセッサと Clang 20.1.8 コンパイラ環境における、読み取りあたりの中央値ナノ秒数を示しています。数値が小さいほど高速です。ホットな階層ケースにおいて、フラットレイアウトの読み込み時間は 9.79 ナノ秒です。FlatBuffers は 37.30 ナノ秒を要し、Protobuf(プロトコルバッファ)は 219.35 ナノ秒かかります。一方、生 C++ 構造体のベースラインは 8.14 ナノ秒です。つまり、フラットレイアウトはここでは FlatBuffers より約 3.8 倍、Protobuf より約 22 倍高速であり、生構造体との差も 1.2 倍以内に収まっています。
フォーマット 読み込み時間(ナノ秒) 生構造体に対する遅延率
生 C++ 構造体 8.14 1.0×
YaFF フラットレイアウト 9.79 1.2×
YaFF スパースレイアウト 21.23 2.6×
FlatBuffers 37.30 4.6×
Protobuf(プロトコルバッファ) 219.35 26.9×
読み取りあたりの中央値ナノ秒数、階層化/ホット/チェーンキャッシングなし。出典:https://yaff.tech/docs/en/benchmarks/access
注:絶対値はホスト CPU とメモリに依存しますが、フォーマット間の比率はハードウェアを跨いで概ね維持されると予想されます。
コンパイラエイリアシングの詳細
FlatBuffers と YaFF はどちらも、生メモリをターゲット型として再解釈することでフィールドを読み取ります。この型パニングにより、TBAA(Type-Based Alias Analysis)には十分な情報が不足し、LLVM のエイリアス解析は保守的な MayAlias 判定に依存せざるを得なくなります。その結果、コンパイラは繰り返しアクセスが再利用可能であることを証明できず、root.intermediate().leaf().a() を二度呼び出すたびにツリーを再走査することになります。YaFF は生成されたコードに注釈を追加し、再利用が安全なタイミングをコンパイラに伝えます。関連するメモリが読み取り間に修正されていない限り、YaFF の生成コードによる注釈は、コンパイラがアクセスチェーンの再利用を支援できることがよくあります。読み取り間にメモリの書き込みが行われない限り、YaFF は独自にアクセスチェーンをキャッシュします。
適用領域:ユースケース
YaFF は、プロデューサーとコンシューマーの両方を制御できるシステムを対象としています。推薦や広告配信バックエンドが最も明確な適用例です。Yandex によると、YaFF は同社の広告推薦システムで動作しており、本番環境スケールでは CPU 使用量を 10〜20% 削減できると報告されています。メモリモップドインデックスは二つ目の適用領域です。ホストは数十ギガバイトのローカルデータを保持できます。これらの mmap 可能なインデックスは、サービス再起動時に再解析することなく存続します。検索インデックス、特徴量ストア、フィードサービスはいずれも、この読み取り集中型のプロファイルを持っています。計画されているカラムナーレイアウトは、大規模な繰り返しフィールドを持つ分析および機械学習パイプラインを対象としています。YaFF は FlatBuffers よりもコンパクトになる可能性があり、キャッシュ動作の向上に寄与します。
コード概観
読み取りパスは、パースステップを除き Protobuf と同様です。
Copy CodeCopiedUse a different Browser
#include "feed.pb.h" // protoc によって生成
#include "feed.yaff.h" // yaff_generate() によって生成
// 1. 既存の Protobuf メッセージを YaFF バッファにシリアライズする。
feed::FeedResponse proto = LoadFeedResponse();
const auto buffer = yaff::Serialize(proto);
// 2. バッファから直接フィールドを読み取る。パース処理は不要。
const auto& response = yaff::ReadMessage(buffer.Data());
for (const auto& item : response.items()) {
std::string_view title = item.title();
std::string_view author = item.author().name(); // 著者が未設定の場合は空文字
}
// 3. コンシューマーがパース済みメッセージを必要とする場合は、Protobuf に変換する。
feed::FeedResponse restored;
response.ParseTo(restored);
YaFF は CMake (find_package) または Conan を通じて追加します。コード生成では protobuf_generate() の後に yaff_generate() が実行されます。生成された YaFF タイプは protoyaff:: ネームスペースに存在します。ほとんどのプロジェクトでは yaff::core と yaff::proto だけをリンクすれば十分です。
リソース:
GitHub リポジトリとドキュメントをご覧ください。
原文を表示
TLDR
YaFF is Yandex’s open-source zero-copy wire format for Protobuf — Apache 2.0, currently C++, v0.1.0.
The .proto file stays the source of truth; only the physical memory layout changes.
On Yandex’s benchmarks, the Flat Layout reads hot data ~3.8× faster than FlatBuffers, within 1.2× of a raw C++ struct.
Four layouts — Fixed, Flat, Sparse, Dynamic — trade read speed for schema flexibility; Dynamic is the default.
YaFF runs in its advertising recommendation system, where it reports 10–20% CPU savings at production scale.
Adoption is incremental: drop it into one hot path, with two-way Protobuf conversion at the edges.
Yandex has open-sourced YaFF (Yet another Flat Format) under Apache 2.0. It is a high-performance C++ serialization library. YaFF provides a zero-copy wire format for the Protobuf ecosystem. Your .proto file stays the single source of truth. The format only changes how data sits in memory. It concentrates on server-side runtimes.
What is YaFF
YaFF is not a replacement for Protobuf. It is an alternative wire format for Protobuf messages. The same .proto schema generates a proto-like C++ API. Reads need no parsing step, so fields come straight from the buffer. Less performance-sensitive code can still parse the wire format back into Protobuf messages. That two-way conversion is what makes module-by-module adoption realistic. You introduce YaFF in one hot path and leave the rest on Protobuf.
The Problem it Targets
Protobuf parsing can consume double-digit percentages of CPU in high-load backends. At scale, that maps to thousands of physical cores. The common zero-copy option is FlatBuffers, also from Google. But FlatBuffers is not a Protobuf drop-in and requires maintaining a separate schema and conversion layer. semantically incompatible with Protobuf. Migrating means duplicated schemas, different schema-evolution rules , and hand-written field converters. Many teams conclude the cost is not worth it. YaFF aims at that gap: zero-copy reads with Protobuf semantics preserved.
How the Layouts Work
A layout decides how a message is stored in the buffer. It changes only the physical representation, leaving the schema and generated interfaces unchanged. YaFF ships four layouts. Fixed is a plain packed struct with no header and a frozen schema. Flat adds a two-byte header and supports schema evolution. Sparse addresses fields through a meta table, fitting sparse schemas. Dynamic is the default and selects Flat or Sparse at runtime. It uses Flat while the schema permits, then switches to Sparse when evolution breaks flat alignment.
LayoutRead accessPer-message overheadSchema evolutionBest for
Fixed1 read, 0 branches0 bytesFrozenSmall inlined primitives
Flat2 reads, 1 branch2 bytesRestricted (type preservation)Dense, hot data
Sparse4 reads, 2 branches6 bytesUnrestrictedSparse schemas, free evolution
Dynamic (default)Flat or Sparse at runtime2 or 6 bytesUnrestrictedGeneral application logic
Benchmark
Yandex ships a reproducible benchmark suite, built with google/benchmark in a Release build. The numbers below are median nanoseconds per read on an AMD EPYC 7713 with Clang 20.1.8. Lower is faster. In the hot hierarchical case, the Flat Layout reads in 9.79 ns. FlatBuffers needs 37.30 ns, and Protobuf needs 219.35 ns. The raw C++ struct baseline is 8.14 ns. So the Flat Layout reads about 3.8× faster than FlatBuffers here, and about 22× faster than Protobuf. It stays within 1.2× of the raw struct.
FormatRead time (ns)Slowdown vs raw struct
Raw C++ struct8.141.0×
YaFF Flat Layout9.791.2×
YaFF Sparse Layout21.232.6×
FlatBuffers37.304.6×
Protobuf219.3526.9×
Median ns per read, hierarchical / hot / no chain caching. Source: https://yaff.tech/docs/en/benchmarks/access
Note: The absolute numbers depend on the host CPU and memory. The ratios between formats are expected to hold across hardware.
The Compiler Aliasing Detail
FlatBuffers and YaFF both read fields by reinterpreting raw memory as the target type. That type-punning leaves TBAA without strong enough facts. So LLVM’s alias analysis falls back to a conservative MayAlias verdict. The compiler then cannot prove that repeated accesses are safe to reuse. Writing root.intermediate().leaf().a() twice re-walks the tree each time. YaFF adds annotations in its generated code that tell the compiler when reuse is safe. YaFF’s generated-code annotations can often help the compiler reuse the access chain, as long as the relevant memory is not modified between reads. As long as nothing writes to memory between reads, YaFF caches the access chain on its own.
Where It Fits: Use Cases
YaFF targets systems where you control both producer and consumer. Recommendation and ad-serving backends are the clearest fit. According to Yandex, YaFF runs in its advertising recommendation system, where it reports 10–20% CPU savings at production scale. Memory-mapped indexes are a second fit. A host can hold tens of gigabytes of local data. Those mmap-able indexes survive service restarts without re-parsing. Search indexes, feature stores, and feed services share that read-heavy profile. The planned Columnar Layout targets analytics and ML pipelines with large repeated fields. YaFF can also be more compact than FlatBuffers, which helps cache behavior.
A Look at the Code
The read path mirrors Protobuf, minus the parse step.
Copy CodeCopiedUse a different Browser
#include "feed.pb.h" // generated by protoc
#include "feed.yaff.h" // generated by yaff_generate()
// 1. Serialize an existing Protobuf message into a YaFF buffer.
feed::FeedResponse proto = LoadFeedResponse();
const auto buffer = yaff::Serialize<protoyaff::feed::FeedResponse>(proto);
// 2. Read fields directly from the buffer. There is no parsing step.
const auto& response = yaff::ReadMessage<protoyaff::feed::FeedResponse>(buffer.Data());
for (const auto& item : response.items()) {
std::string_view title = item.title();
std::string_view author = item.author().name(); // empty if author is unset
}
// 3. Convert back to Protobuf when a consumer needs the parsed message.
feed::FeedResponse restored;
response.ParseTo(restored);
You add YaFF through CMake (find_package) or Conan. Code generation runs protobuf_generate() then yaff_generate(). Generated YaFF types live in the protoyaff::<package> namespace. Most projects only link yaff::core and yaff::proto.
Resources:
Check out the GitHub repository and Documentation.
The post Yandex Open-Sources YaFF: A Zero-Copy Wire Format for Protobuf With Near-Struct Read Speed appeared first on MarkTechPost.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み