博士

ロボ子、大変なのじゃ！Hugging Face Hubが、XetストレージレイヤーとApache ArrowのParquet CDCっていうのを使って、Parquetファイルのアップロードとダウンロードをめっちゃ速くしたらしいぞ！

ロボ子

Parquet CDC、ですか。それは具体的にどのような技術なのでしょうか、博士？

博士

Parquet CDCは、簡単に言うと、Parquetファイルを細かく分割して、変更された部分だけをアップロード・ダウンロードする技術なのじゃ。PyArrowとPandasで使えるらしいぞ。

ロボ子

なるほど。Hugging Faceは現在21PBものデータセットをホストしていて、Parquetファイルがそのうち4PB以上を占めているとのことですから、ストレージの最適化は非常に重要ですね。

博士

そう！Parquetはちょっと変えるだけでも全体が大きく変わっちゃうから、普通のやり方だと無駄が多かったのじゃ。でも、CDCなら変更されたデータチャンクだけを扱えるから、データ転送とストレージのコストを大幅に削減できるってわけ！

ロボ子

`use_content_defined_chunking=True`という引数を渡すだけで有効になるのは簡単で良いですね。Hugging Face URIをpyarrow関数で使用して、直接Hubにファイルを読み書きできるのも便利そうです。

博士

そうそう！Hugging Face URIを使うと、hf://スキームで直接アクセスできるのじゃ。まるで魔法みたいじゃろ？

ロボ子

記事によると、テーブルのコピーの再アップロード、列の追加・削除、データ型の変更、行の追加・挿入・削除、行グループサイズの変更、ファイル分割など、様々なケースでパフォーマンスをテストしているようですね。

博士

特に、新しい列を追加するときにデータセット全体を転送しなくて済むのが大きいぞ！変更された列とメタデータだけアップロードすれば良いから、めっちゃ効率的なのじゃ！

ロボ子

データの挿入や削除によるデータページの違いを最小限に抑えられるのも重要ですね。Xetストレージレイヤーはリポジトリ間で重複排除が機能するとのことですから、データ共有とコラボレーションも効率化されそうです。

博士

その通り！それに、異なるファイルレベルの分割でも、データ全体のアップロードサイズをほぼ同じに保てるらしいぞ。これはすごい発見じゃ！

ロボ子

Parquet CDCはデータページレベルで適用されるため、重複排除のパフォーマンスはフィルタの選択性やデータセット全体の変更の分布に依存するとのことですね。この点は注意が必要そうです。

博士

ふむ、つまり、変更が一部に集中していると効果が出にくいってことじゃな。でも、全体的に見れば、従来のクラウドストレージよりもデータ転送時間とコストを大幅に削減できるのは間違いないぞ！

ロボ子

はい、博士。Parquet CDCを備えたXetストレージレイヤーは、データエンジニアリングの未来を大きく変える可能性を秘めていると言えそうですね。

博士

まさにそうじゃ！…ところでロボ子、Parquet CDCって、まるで私の秘密兵器みたいじゃない？

ロボ子

博士の秘密兵器は、いつもドジを踏むところまでがセットですけどね。

博士

むむ、それは禁句なのじゃ！