CSV・JSONL・Parquet・ORC・Arrow・Avroは何が違う？

6形式をざっくり比較

たとえば売上データを考えます。人が表計算ソフトで少量を確認するならCSVが扱いやすいかもしれません。ログとして1件ずつ追記するならJSONLが自然です。一方、1000万行・100列のデータから売上金額と日付だけを何度も集計するなら、必要な列を効率よく読めるParquetやORCが向いてきます。

CSV — 一番単純な「表のテキスト」

CSVは、通常はカンマで列を区切り、改行でレコードを区切るテキスト形式です。多くの表計算ソフトやデータ処理ツールで開け、人がテキストエディタで中身を確認できるのが大きな強みです。小さな表を受け渡したり、一度きりのエクスポートをしたりする用途では今でも非常に便利です。

一方、CSVそのものには「この列は整数」「これは日付」「これは配列」といった共通の型・スキーマを埋め込む仕組みが基本的にありません。区切り文字、文字コード、引用符、日付表現なども実装や運用による差が出やすく、複雑なネストデータには向きません。単純であることが長所であり、その単純さが限界でもあります。

JSONL — JSONを1件ずつ並べる

JSONL（JSON Lines / NDJSON）は、1行ごとに独立したJSON値を置く形式です。JSONなので文字列だけでなく数値、真偽値、null、配列、オブジェクトをそのまま表せます。CSVより複雑な1レコードを表現しやすく、それでも1行ずつ読み進められます。

そのためログ、イベント、機械学習用データなど、レコードを順番に追加・処理したい用途と相性があります。ファイル全体を巨大な1つのJSON配列にしなくても、1行ずつ解析できます。ただしJSONL自体は、通常「全行がこのスキーマに従う」というファイル全体のスキーマを持ちません。同じフィールドに異なる型が混ざることもあり、必要なら利用側で検証します。

ParquetとORC — 似ているが、ファイル内部と得意な環境が少し違う

ParquetとORCは、どちらも大量の構造化データを列単位で保存し、必要な列だけを読みやすくする分析向けファイル形式です。圧縮やエンコード、列ごとの統計情報を使って、全部を読み込まずに必要なデータへ近づくという考え方も共通しています。まずは「かなり似た目的の形式」と考えて問題ありません。

違いが出やすいのは、ファイル内部の区切り方と、どのデータ基盤で使われてきたかです。ParquetはRow Groupの中に列ごとのColumn Chunk、その中にPageを持つ構造です。ORCはStripeという大きな単位の中に、列データと行グループ用のインデックス、Stripe Footerをまとめます。ざっくり言えば、Parquetは「Row Groupの中を列に分ける」、ORCは「Stripeの中に列データと索引をまとめる」と覚えると違いをつかみやすいです。ORCはHive / Hadoopの高速化を背景に作られ、ファイル・Stripe・Row Groupの各段階で統計やインデックスを使って不要な範囲を飛ばせる構造を用意しています。

一方でParquetは、特定の1つの処理系に寄せるより、さまざまな分析ツールや言語から使える列指向の共通形式として広く実装されています。だから「Parquetの方が新しい」「ORCの方が高性能」と単純に決めるのではなく、既存の基盤と対応ツールを見るのが実用的です。

Arrow — 保存容量より「処理中のデータをそのまま渡す」ことが中心

ArrowはParquetやORCと少し立ち位置が違います。Apache Arrowの中心は、表形式データをメモリ上でどう並べるかを言語に依存せず共通化する列指向フォーマットです。CPUが連続したデータを効率よく処理しやすくし、異なるライブラリや言語の間でデータを移すときの変換コストを減らすことを狙っています。

Arrow IPCにはFileとStreamがあり、ArrowのSchema、Record Batch、Dictionaryなどを保存・転送できます。そのため`.arrow`や`.ipc`というファイルを見ることはありますが、Parquetのように「できるだけ小さく長期保存する」ことが設計の中心ではありません。Parquetから読み出したデータを処理するとき、メモリ上ではArrow形式を使う、といった組み合わせもあります。

Avro — スキーマを前提にレコードを扱う

Avroは、スキーマに従ってレコードをバイナリとしてシリアライズする仕組みです。ファイルとして保存するときによく使われるAvro Object Container Fileでは、ファイル内のメタデータにwriter schemaが保存され、レコードはブロック単位で格納されます。ブロックを圧縮することもでき、ファイルを受け取った側はコンテナ内のwriter schemaから「どんなフィールドと型で書かれたデータか」を確認できます。

JSONLもレコードを1件ずつ扱いやすい形式ですが、JSONLはテキストで人が読みやすく、ファイル全体のスキーマを必須にしません。Avroは人が直接読む形式ではない代わりに、スキーマを前提に機械同士でレコードをやり取りする用途へ寄せています。なおAvroにはObject Container File以外のエンコード方法もあり、すべてのAvroデータが「完全なスキーマをデータ自身に持つ」わけではありません。

ParquetとORC、結局どう選ぶ？ Arrowは別の層

すでに利用している基盤があるなら、その基盤で標準的に使われている方を選ぶのが最初の判断です。複数の言語や分析ツールへ渡すことを重視するなら、幅広い実装があるParquetは候補にしやすいです。HiveやORCを中心にした既存基盤があるなら、ORCを使い続ける方が自然です。片方へ変換するだけで必ず速くなったり、小さくなったりするわけではありません。

圧縮率やクエリ速度を本当に比較したい場合は、同じ実データを同じ程度の圧縮設定で書き出し、実際に使うエンジンとクエリで測るのが確実です。データの並び方、列の種類、絞り込み条件、Writerの設定によって結果が変わるためです。

Arrowはその2つと競う保存形式というより、読み出したデータをメモリ上で処理したり、処理系の間で渡したりする共通層として見ると理解しやすくなります。Apache Arrow自身も、Parquetは保存効率を重視する形式、Arrowは計算で直接扱いやすいインメモリ形式という違いを説明しています。

結局どれを選ぶ？ 目的から逆算する

人が表計算ソフトで開くならCSV、レコードを1件ずつ追加・処理したいならJSONL、大量の分析データを保存するならParquetやORC、処理中の表データをシステム間で効率よく受け渡すならArrow、スキーマを前提にレコードを保存・交換するならAvro、というのが大まかな出発点です。

ただし実際のシステムでは、1つだけに統一する必要はありません。入口ではJSONL、保存はParquet、分析エンジンの内部ではArrow、別システムへのイベント連携ではAvro、と役割ごとに形式を使い分けることがあります。形式の数が多いのは重複しているからというより、同じデータでも置かれる場所と使われ方が違うためです。

注意点

• CSVとJSONLは通常テキストのままなので、巨大ファイルでは読みやすさと処理効率が両立しないことがあります。必要ならgzipなど外側の圧縮と組み合わせる運用もあります。
• ParquetとORCのファイルサイズはデータ内容、圧縮方式、エンコード、書き出し設定で変わります。形式名だけで圧縮率を断定できません。
• Arrowは「Parquetより速い保存形式」と考えるより、処理中のデータを効率よく扱うためのメモリ形式とIPCだと考える方が誤解が少なくなります。
• AvroではSchema Evolutionの仕組みがありますが、実際の互換性はwriter schema / reader schemaや運用ルールに依存します。単にAvroにすれば変更が自動的に安全になるわけではありません。
• どの形式でも、閲覧ツールで開けることと編集・再保存できることは別です。確認用途なら、元ファイルを書き換えない読み取り専用Viewerも選択肢になります。