Apache ORC（Optimized Row Columnar）は2013年にHortonworksがHive用に開発した列指向ファイル形式で、当時主流だったRCFileとTrevniを置き換えるべく設計された。Parquetと並ぶHadoop系の二大列指向フォーマットとして知られ、Hive・Presto・Trino・Sparkで幅広くサポートされる。圧縮率と統計情報の充実度ではParquet以上とも評されており、Facebook（Meta）のデータウェアハウスでも長年中心的に利用されてきた。
この記事の目次
- Stripe構造とインデックスの工夫
- ACIDトランザクションとの統合
- Parquetとの比較で見える個性
- ORC利用時の落とし穴
- まとめ
Stripe構造とインデックスの工夫
ORCファイルはStripe（既定64MB）と呼ばれる単位でデータを格納し、各StripeはIndex Data・Row Data・Stripe Footerの3区画に分かれる。Index Dataには各カラムの最小値・最大値・合計値・行数といった統計が10000行単位（Row Group）で記録され、フィルタ条件にマッチしないRow Groupはスキップ可能だ。これによりWHERE句が効くクエリではディスクI/Oを劇的に削減できる。
Stripeの上にはFile Footerとファイル全体のPostscriptがあり、Postscriptには圧縮アルゴリズム・Footer長などのメタが入る。ParquetがFooterに統計を集中させるのに対し、ORCはStripeレベル・Row Groupレベル・ファイルレベルの3階層で統計を持つため、より細かい単位でPredicate Pushdownが効くのが特徴である。Bloom Filterもオプションで埋め込め、等価検索に強い。
ACIDトランザクションとの統合
ORCはHive 0.14以降、ACIDトランザクションテーブルの物理形式として採用された。通常のBase Fileに加え、INSERT/UPDATE/DELETEで生成されるDelta FileをCompactorと呼ばれるバックグラウンドプロセスが定期的にマージする仕組みで、MapReduce／Tez／LLAP上でトランザクショナルなデータレイクを実現する。この設計はその後のIceberg・Hudi・Delta Lakeに大きな影響を与えた。
ACIDテーブルではrowid（originalTransaction、bucket、rowId）が暗黙列として付与され、Streaming Ingest APIを通じてKafkaやFlumeから秒単位の追記が可能となる。ただしACIDモードはHive専用機能寄りで、Presto/Trino側からは長らく読み取り限定の扱いだった経緯がある。2020年代に入りIceberg/Hudiが台頭してからは、ORCはACIDより純粋な高速列指向ファイルとして再評価される傾向にある。
Parquetとの比較で見える個性
ParquetとORCは設計思想が近いため機能比較が活発に行われてきた。ベンチマーク傾向として、ORCはZlib／Zstd圧縮との相性が良く、ストレージサイズはParquet比で1〜2割小さくなる事例が多い。一方でParquetは多言語SDK（PyArrow、parquet-cpp）の充実度やIceberg・Delta Lakeなど近年のテーブルフォーマットでの採用優位があり、エコシステムの広がりではParquetが先行する。
実務では「Hive中心のオンプレ基盤 → ORC」「クラウドレイクハウス → Parquet」と棲み分けることが多い。Trinoは両方読めるが、IcebergやDelta Lakeを採用する場合はParquetに統一するのが運用上シンプルだ。なお、ORC側もApache Iceberg対応が進んでおり、選択肢としては依然有力で、特にFacebook由来のクエリエンジンPrestoではORC最適化が深く行われている。
ORC利用時の落とし穴
ORCを使う上での典型的な落とし穴は、Bloom Filter・Stripe Sizeなどのチューニングパラメータを既定値のまま放置してしまうことだ。例えば等価検索が頻出するカラムには明示的にBloom Filterを指定し、Stripe Sizeはディスクシーク特性に合わせて128MBに拡大するなど、ワークロード依存の調整で性能が大きく変わる。これを怠るとParquetより遅くなることすらある。
また、Hiveのバージョン差で互換性の落とし穴がある。Hive 2系で書いたORCをHive 3系でACIDテーブル扱いで読むと暗黙列の解釈で齟齬が出るケースがある。本番移行時には必ずHCFS（Hadoop互換ファイルシステム）レベルでの読み取りテストを行い、Spark等の外部エンジンからも読めることを確認しておきたい。文字コードはUTF-8が前提で、Shift_JIS混在データの直接取り込みは事故になりやすい。
まとめ
Apache ORCはHiveエコシステムで磨かれた高密度な列指向フォーマットで、細粒度の統計とACID対応が他にない強みとなっている。近年はParquetがエコシステム広がりで優勢だが、圧縮率や既存Hive資産との親和性では依然第一級の選択肢であり、Trinoなど主要エンジンから安心して利用できる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント