ハクソク

世界を動かす技術を、日本語で。

パルクエの二つのバージョン

2025年8月21日原文(jeronimo.dev)

概要

  • DuckDB の開発者によるParquetフォーマット進化の障壁に関する議論
  • Parquet Version 2の仕様とエコシステム全体への影響
  • バージョン2のパフォーマンス検証結果
  • エコシステムでの互換性問題と導入判断の難しさ
  • 進化の課題と将来展望

Parquetフォーマット進化の障壁

  • DuckDB 開発者による記事「Query Engines: Gatekeepers of the Parquet File Format」での指摘
    • ParquetファイルをSQLテーブルとして扱う Query Engine が最新仕様へ未対応
    • エコシステム全体の進化が停滞する要因
  • この問題は Query Engine だけでなく、周辺ツール全体に波及
    • Carpetリリース直後、ParquetフォーマットVersion 2の存在に気付く
    • Java ParquetライブラリはVersion 2をデフォルトで有効化しない仕様
  • 仕様が確定済みでも、エコシステム全体で実装状況が不十分
    • Pandas（Python）でVersion 2ファイルの読み込み不可問題を経験
    • 互換性のため即座にロールバック対応

Parquet Version 2の仕様と実装状況

  • 仕様は確定済みだが、実装・対応状況はエコシステムでバラバラ
    • どこまで対応すれば「Version 2互換」と言えるか未合意
    • Pull Requestやメーリングリストで4年以上議論が継続
  • 仕様内で独立して進化できる2つの概念
    • 列データの エンコーディング方式 （RLE_DICTIONARY、DELTA_BYTE_ARRAY等）
    • エンコード済みデータの ファイル内配置構造 （Data Page V2）
  • エンコーディング改善は列単位の非互換、ページ構造変更はファイル全体の非互換に直結
  • 新しい論理型（例：VARIANT）は特定バージョンに依存せず追加可能
    • 例：DATEはint64、Big DecimalやStringはBYTE_ARRAYで表現
  • 機械学習分野ではParquetやORCの限界も顕在化
    • FacebookのNimble、LanceDBのLV2など新フォーマットの登場
    • ただし、これらはニッチ用途と位置付け、Parquetがデータエンジニアリング分野で主流継続予想

Parquet Version 2のパフォーマンス検証

  • ファイル書き込み時にバージョン指定はプロパティ設定のみで簡単

    • 例：CarpetWriterでWriterVersion.PARQUET_2_0を指定

  • イタリア政府データセット・New Yorkタクシーデータセットを用いた比較

    • ファイルサイズ比較

      | フォーマット | Version 1 | Version 2 | 改善率 | |---|---|---|---| | CSV | 1761MB | 1761MB | - | | UNCOMPRESSED | 564MB | 355MB | 37% | | SNAPPY | 220MB | 198MB | 10% | | GZIP | 146MB | 138MB | 5% | | ZSTD | 148MB | 144MB | 2% | | LZ4_RAW | 209MB | 192MB | 8% | | LZO | 215MB | 195MB | 9% |

      • Version 2の新エンコーディングにより、圧縮前で大きな効果
      • 追加圧縮の効果は相対的に小さくなる傾向

    • 書き込み速度比較

      | フォーマット | Version 1 | Version 2 | 改善率 | |---|---|---|---| | UNCOMPRESSED | 25.0s | 23.6s | 6% | | SNAPPY | 25.2s | 23.5s | 7% | | GZIP | 39.3s | 35.8s | 9% | | ZSTD | 27.3s | 25.7s | 6% | | LZ4_RAW | 24.9s | 23.8s | 4% | | LZO | 26.0s | 24.6s | 5% |

      • 特に数値型が多いデータセットで書き込み速度が大幅改善
      • GZIP圧縮時の改善が顕著

    • 読み込み速度比較

      | フォーマット | Version 1 | Version 2 | 改善率 | |---|---|---|---| | UNCOMPRESSED | 11.4s | 11.3s | 1% | | SNAPPY | 12.5s | 11.5s | 8% | | GZIP | 13.6s | 12.8s | 6% | | ZSTD | 13.1s | 12.2s | 7% | | LZ4_RAW | 12.8s | 11.3s | 12% | | LZO | 13.1s | 12.1s | 7% |

      • 読み込み速度も全体的に改善
      • 特に10進数型が多いデータセットで効果大

互換性問題と導入判断

  • Parquetの進化を批判する意図ではなく、 オープンフォーマット進化の難しさ を記録
  • Parquetの利便性・恩恵は小さな不便を大きく上回る
  • 最新仕様によるファイルサイズ・処理速度の改善はあるが、劇的ではない
  • エコシステムでVersion 2の採用が進んでいない現状
    • サードパーティ連携時の互換性問題を考慮し、導入の判断が必要
  • 全工程を自前で管理できる場合は、 最新仕様採用も選択肢

進化の課題と将来展望

  • オープンフォーマット進化には 合意形成の難しさ、 実装状況の不均一性 という構造的課題
  • エコシステム全体での 対応状況の見極め が重要
  • 新しい用途や分野での限界が見えてきた場合、 新フォーマットの検討 も必要
  • しかし、Parquetは今後もデータエンジニアリング分野で 中心的役割 を果たす見通し

Hackerたちの意見

私はオープンソースソフトウェアの長年の支持者でありユーザーとして言いますが、こういう問題があるからこそ、政府や企業は今でもOracleやSQL Serverを使い続けているんです。著者は変更を元に戻せましたが、ある業界では、計画外のデータの利用不可が発生すると、その企業でのキャリアが終わることもあります。ベンダーから「問題ない」と確認するCYAメールがないとね。そのCYAメールと責任を追及できる相手がいるからこそ、Oracleは劣ったソフトウェアソリューションを提供する企業と7桁や8桁のライセンス契約を結ぶんです。Linuxは、リーナスのリーダーシップのおかげで、このリスク問題を解決し、商業用UNIXオペレーティングシステムを完全に置き換えることができたようです。スタックの上下で、他の多くのプロジェクトも同じ成功を収められることを願っています。

└

コメントの最初の方で「こういう問題」と言ってたから、4年間のコアについての議論のことかと思ったよ。

└

それに、CERNがまた独自のファイルフォーマットを使ってるのはなんでだろう、2025年にね。https://cds.cern.ch/record/2923186

└

人々がOracleを使い続けるのは、たくさんのコードがあって移行がコスト高すぎるからなんだ。Oracleもソフトウェアの問題には免疫がないよ。実際、今年はクラウドのバグのあるアップグレードのせいで、2つの週末を失ったんだ。生産クラスタが失敗状態になっちゃってさ。

└

丁寧に反対しますが、政府や企業がOracleやSQL Serverを使い続けるのは、ほぼシスフィスのようなものです。実際に可能ですが（私たちもやっています）、それには止まることなく取り組むチームが必要です。本当に大変な作業です。

└

ごめんなさい、この記事を誤解していると思います。著者が変更を元に戻すと言っているのは、データベースのことではなく、彼のライブラリのバージョンのことを指しています。もし誰かが彼の新しいバージョンを使ったら、問題があったとしたら、Pandasがそのフォーマットをサポートしていないからコードが動かなかっただけだと思います。この記事は、新しいParquetフォーマットのバージョンが広く採用されていないことについてで、今Parquetコミュニティは異なる方向に引っ張られている状態にあります。これは、密接に結びつく必要のない2つの異なる焦点から生じているのです。この記事で議論されている問題がソフトウェアの信頼性にどう関係するのか、私には理解できません。

└

著者は変更を元に戻すことができたけど、いくつかの業界では、計画外の企業全体のデータ利用不可イベントは、その会社でのキャリアの終わりを意味するんだ。もし（大規模な）ソフトウェアのアップデートが障害を引き起こしたら、ソフトウェアを責めるべきじゃなくて、不十分なテストと検証を責めるべきだよ。大企業（俺もいくつか働いたことがあるけど）は、新しい技術を採用するのが遅いのは、非常に慎重で、すべてが適切にテストされてから導入したいからなんだ。それが、彼らが今でもOracleやSQL Server（そしてHP-UXやIBMi）を使っている理由でもある。これらの製品は動いていて、何世代もの社員が使ってきたからね。彼らがフェンスの向こう側に移ることを考えるには、かなりのメリットが必要だよ。

そうそう、2010年代にPythonコードでParquetを効果的に使うために何年も待たなきゃいけなかったんだ。主に2つ（PyarrowとFastparquet）があって、互いに互換性がなかったし、Sparkとも互換性がなかったからね。Parquetのサポートは、ブラウザにおけるJavaScriptのサポートに似てる。期待するすべてのプラットフォームで互換性があるときだけ、より高度な機能を使えるんだよね。

icebergとdelta lakeがv2をサポートしない限り、導入は本当に難しいよ。私はParquetをたくさん使ってるけど、v2.0があることすら知らなかった。

└

なんでv2.0を採用しないんだろう？

https://www.jeronimo.dev/the-two-versions-of-parquet/#perfor... この見出しの最初の段落は、私が圧縮アルゴリズムに関する前の投稿で考慮していなかったマークダウンエラーだね。

データがすでに特定の列でソートされているかどうかのメタデータを技術的にサポートしていると知ったとき、かなり混乱しました。私の目には、いくつかの簡単な最適化ができるように見えました。でも、最後に確認したとき、実際にはほとんど何も使われていないようで、一部のライブラリはこのフィールドすら読まないみたいです。

Hacker Newsで議論の続きを見る