ストレージとファイル形式

業務 DB の多くは行指向で、1行のすべての列をまとめて保存します。1件の注文を読んだり書いたりするのに向いています。分析では「1億行の中の金額と日付の列だけ」を読むことが多いので、列ごとにまとめて保存する列指向のほうが、読む量がずっと少なくて済みます。Parquet は列指向のファイル形式の定番で、データレイクやレイクハウスの標準になっています。

Parquet の中身（行グループ・エンコーディング）

Parquet が速いのは、列指向であることに加えて、ファイルの中に読み飛ばすための情報を持っているからです。

Parquet はファイルをいくつかの行グループに分け、その中で列ごとにまとめます。列の中では値を小さく表す工夫（エンコーディング）をします。種類の少ない列（都道府県など）は辞書エンコーディングで値を番号に置き換え、同じ値の連続はランレングス（「東京が 500 回」）で表します。その上に Snappy や Zstandard などの圧縮をかけます。さらに行グループごとに列の最小値・最大値を持っているので、WHERE order_date = … の条件に合わない行グループを読まずに飛ばせます。

ファイル形式は「誰が、どう読むか」で選びます。取り込みの途中と、分析で読む置き場所で形式を変えるのが普通です。

よくある形は、届いたままの形（JSON・CSV）を生の置き場所に保存し、整えたものを Parquet で書くことです。生のファイルを残しておけば、変換を直したときにやり直せます。CSV を取り込むときは、文字コード・区切り文字・引用符・ヘッダーの有無・日付の書き方を最初に決めておきます。

ストリームや細かいバッチで書き続けると、小さなファイルが大量にたまります。クエリのエンジンはファイルを1つずつ開いて中の情報を読むので、データの量が同じでもファイルの数が多いほど遅くなり、オブジェクトストレージへのリクエストの料金も増えます。

Parquet の公式ドキュメントは行グループを 512MB〜1GB と大きめにすることを勧めています。実務では、1ファイル数百 MB〜1GB 程度を目安に、定期的にまとめ直すことが多いです（コンパクション）。また、よく絞り込む列で並べてから書くと、最小値・最大値による読み飛ばしがよく効きます。

• 書く側で、出力のパーティション数（Spark の repartition・coalesce）を調整して、ファイルを作りすぎない。
• Iceberg・Delta Lake などのテーブル形式には、ファイルをまとめ直す機能がある。夜間などに定期的に流す。
• パーティションを細かく切りすぎない（日付×ユーザーなど）。1つのパーティションのデータが少ないほど、ファイルは小さくなる。

データレイクでは、dt=2026-11-02/ のようにフォルダの名前に列の値を入れて置く形（Hive 形式）がよく使われます。クエリのエンジンは条件に合うフォルダだけを読むので、DWH のパーティションと同じように読む量を減らせます。

テーブル形式の Iceberg では、列の値から区切りを自動で計算する仕組み（隠れたパーティション）があり、利用者がフォルダの形を意識せずに済みます。

分析用のデータの置き場所には大きく3つの考え方があります。

テーブル形式（Iceberg・Delta Lake）の仕組み

最近は DWH の側も Iceberg などの外部テーブルを読めるようになり、境目は小さくなっています。選ぶときは「誰がどのエンジンで読むか」「更新や削除がどのくらいあるか」「運用に人を割けるか」で決めます。

テーブル形式（Apache Iceberg・Delta Lake・Apache Hudi）は、Parquet ファイルの集まりを「1つのテーブル」として扱うための仕組みです。どのファイルがテーブルの今の中身かをメタデータで管理するので、次のことができるようになります。

• 書き込みの途中で読んでも、半端な状態が見えない（ACID のトランザクション）
• UPDATE・DELETE・MERGE（個人情報の削除依頼にも対応できる）
• 過去の時点のテーブルを読む（タイムトラベル）・間違えたら戻す
• 列の追加などスキーマの変更、Spark・Trino・DWH など複数のエンジンからの読み書き

メタデータが増え続けるので、古いスナップショットの削除や小さなファイルのまとめ直しを定期的に流す運用が要ります。古いスナップショットを消すと、その時点へのタイムトラベルはできなくなります。