Hugging Face Hub における Parquet 重複排除の改善

Hugging Face はストレージアーキテクチャを最適化し、Parquet ファイルの重複排除効率を向上させ、ユーザーが大規模データセットを更新する際に必要なストレージオーバーヘッドを削減しています。この取り組みは重要で、Parquet ファイルは Hugging Face Hub にホストされている約 11PB のデータセットのうち 2.2PB 以上を占めています。

Parquet 重複排除の課題

ストレージコストを最小化するため、Hugging Face はバイトレベルの Content-Defined Chunking（CDC）を使用してデータの重複排除を行っています。CDC は多くのファイルタイプにおける挿入や削除に効果的ですが、Parquet ファイルの特有のレイアウトにより、増分更新時の効率的な重複排除に課題が生じます。

Parquet テーブルは行グループ（row groups）で構成され、各行グループ内の各列は圧縮されて保存されます。この構造により、データの変更が結果のファイルバイト数に不均衡な影響を与え、以前のバージョンと比較してどれだけのファイルが重複排除できるかに影響します。

データ操作が重複排除に与える影響

Hugging Face は FineWeb データセットからの 2GB の Parquet ファイル（1,092,000 行）を使用して、さまざまな操作が重複排除率に与える影響を分析する実験を行いました。

データの追加

10,000 行の新しい行を追加すると、重複排除効率が高くなります。追加はファイルの末尾にのみ影響するため、新しいバージョンは 99.1% が重複排除され、追加ストレージはわずか 20MB です。

データの変更

単一行（例：10,000 行目）を変更すると、重複排除が大幅に低下します。新しいファイルはわずか 89% が重複排除され、追加ストレージは 230MB 必要です。これは Parquet ファイル形式が列ヘッダーに絶対ファイルオフセットを含んでいるため（特に ColumnChunk と ColumnMetaData 構造体）、変更があるとすべての列ヘッダーが書き換えられることが原因です。

データの削除

ファイルの途中から行を削除すると、残りのファイルが完全に新しいブロックで構成されることが多く、ファイルの後半部分の重複排除が失われます。これは主に列圧縮が強力であることが原因です。圧縮をオフにすれば重複排除は改善されますが、ファイルサイズが倍増し、ストレージ効率と重複排除能力の間でトレードオフが生じます。

提案された解決策：コンテンツ定義行グループ

削除や挿入時に圧縮と重複排除効率の両方を維持するため、Hugging Face はバイトレベルだけでなく行レベルでの Content-Defined Chunking の使用を提案しています。

固定行数（例：1,000 行ごと）で行グループを分割する代わりに、提供された「Key」列のハッシュに基づいて行グループを分割します。キー列のハッシュを目標行数で割った余りがゼロになるたびに（最小・最大サイズの制約あり）行グループが分割されます。

実験結果は、この手法により行が削除された場合でも、圧縮された Parquet ファイル全体で効率的な重複排除が可能であることを示しています。影響を受けた行グループと列ヘッダーのみが書き換えられます。

Parquet ストレージの将来の最適化

Hugging Face は Parquet の重複排除可能性を向上させるための主な 2 つの道筋を特定しています。

相対オフセット：ファイル構造データ内の絶対オフセットを相対オフセットに置き換えて、Parquet 構造を位置に依存しないものにします。ただし、これはファイル形式への複雑な変更と見なされています。
コンテンツ定義行グループ：行グループに対するコンテンツ定義チャンクのサポートを実装します。Parquet 形式は均一サイズの行グループを必須としないため、既存の形式への影響を最小限に抑えて Parquet フォーマットライターを更新することで実装可能です。

さらに、Hugging Face はアップロード前に Parquet ファイルを書き換えて絶対ファイルオフセットを除去し、ダウンロード時に復元するオプションの可能性も検討しています。