TwitterとClouderaのParquetはデータを列単位で保存し、ビッグデータのデフォルトとなった

Hadoop上の分析はレコードを行単位で読み取るため、給与1つだけを必要とするクエリでも従業員ごとのレコード全体を取得してしまい、異種混在のレコードは圧縮効率が悪かった。Twitter自身のデータセットは7階層の深さにネストし、80以上のリーフノードを持っていた。

TwitterとClouderaは、Hadoop向けのオープンソースの列指向ストレージ形式であるParquetを構築した。行ではなく列を書き込む。つまり、すべての名前、次にすべての年齢、次にすべての給与という順である。その大きな功績は、GoogleのDremelのレコード分割アルゴリズムと共有のエンコーディング仕様を用いて、ネストしたデータを列に分割したことだった。

列は1つの型を保持するため、汎用的な圧縮と型固有の圧縮の両方が改善し、クエリエンジンは不要な列の読み込みをスキップする。自動辞書エンコーディングに加え、ビットパッキングとランレングスエンコーディングが残りを縮小する。Parquetはユーザーを特定のシリアライゼーションライブラリに縛らないため、多くのエンジンが採用した。

Parquet 1.0は、Twitter、Cloudera、Criteo、Berkeley AMPLab、Stripeにまたがる貢献者によって2013年7月にローンチされ、すでにTwitterの本番環境で稼働していた。

列単位で保存することで、分析は不要なものをスキップする

同種の列値は混在した行よりもはるかに効率よく圧縮されるため、ファイルは大幅に小さくなる。

クエリは必要な列だけを読み込むため、I/Oとコストが急減する。

Dremelによるネストデータの分割により、複雑なスキーマでも列に収まる。

フレームワーク非依存であるため、あらゆるエンジンが書き換えなしに採用できた。

ボトルネックが読み取りと圧縮にある場合、ロジックではなく物理レイアウトを変える。同種の値をまとめて保存することで、高コストなI/Oが縮小し、ファイルも無償で小さくなる。

Parquet 1.0は2013年7月に出荷され、HadoopとSparkのエコシステム全体で、そしてデータレイク、レイクハウス、クラウドウェアハウスの中で、デフォルトの列指向形式となった。現在では最も広くサポートされるオープンストレージ形式の1つであり、分析がワイドテーブルの高速で安価なスキャンを必要とするあらゆる場所で使われている。