Open Table Formatとは｜データを「特定システムの持ち物」から解き放て（1/2）

データを「システムの縛り」から解放する

企業は、かつてないほど多くのデータを持つようになりました。販売データ、顧客データ、ログデータ、業務システムの履歴、IoTから生まれる時系列データ。これらはクラウドストレージやデータウェアハウスに蓄積され、経営判断や業務改善、AI活用の材料になることが期待されています。

しかし実際には、「データはあるのに使いにくい」という状況がよく起こります。

BIで見たい。
機械学習で使いたい。
部門ごとに分析したい。
リアルタイム処理にも使いたい。

しかし、そのたびにデータをコピーしたり、別形式に変換したり、特定のツールに合わせて持ち替えたりする必要があります。ここに、現代のデータ基盤が抱える大きな問題があります。問題は、単にデータ量が増えたことではありません。むしろ、データが「どのシステムで処理されるか」に強く縛られていることです。

Open Table Formatは、この縛りを緩めるための考え方です。（人月の神話的にいうと「銀の弾丸」ですね。）

まず分けて考える：Storage、Metadata、Compute

Open Table Formatを理解するには、最初にデータ基盤の役割を分けて考える必要があります。

大きく見ると、現代のデータ基盤には三つの役割があります。

一つ目は、Storageです。
これはデータを保存する場所です。たとえばAmazon S3、Azure Data Lake Storage、Google Cloud Storageなどが該当します。Storageは、いわば倉庫です。ファイルを置いておくことはできますが、自分でSQLを実行したり、集計したり、分析したりするわけではありません。

二つ目は、Metadataです。
これは、Storage上に置かれた大量のファイルを「テーブル」として管理する仕組みです。代表例として、Apache Iceberg、Delta Lake、Apache Hudiがあります。これらは、ファイルそのものではなく、「どのファイルがどのテーブルに属しているか」「現在有効なデータはどれか」「スキーマはどうなっているか」「過去の状態に戻れるか」といった情報を管理します。
たとえるなら、Metadataは倉庫管理台帳です。これまでのCSVやJSONが「書類の入った箱」だとしましょう。倉庫にそういうデータの箱が大量に置かれていても、「どの箱に何が入っているのか」がわからなければ実際の業務では使えません。（片っ端からすべての箱をひとつひとつ開けて中身を確認するなんて、想像するだけでゾッとしますよね。）
良質な管理台帳があることで、倉庫の中身を秩序立てて扱えるようになります。

三つ目は、Computeです。
これは、実際にデータを処理する主体、つまり計算エンジンです。Spark、Snowflake、Trino、Flink、BigQueryなどが該当します。Computeは、データを読み、条件を適用し、JOINし、集計し、結果を返します。
倉庫業務で言えば、現場で実際に作業する人であり、運搬するためのフォークリフトなどの機械です。

つまり、端的に言えば、S3は倉庫、Icebergは倉庫管理台帳、Sparkは作業員と重機なのです。
この役割分担を押さえると、Open Table Formatが目指す世界観の全体像が見えてきます。

この3層構造を「Lakehouse（レイクハウス）」と呼びます。Storageの池に貯められたMetadata付きのデータ群を、いろんなDBエンジンがアクセスする様子をイメージしていただくと良いでしょう。

計算エンジン（Compute）とは「実際に動く主体」である

ここで、Computeについて少し掘り下げておきましょう。たとえば、次のようなSQLを書いたとします。

このSQLは、書かれただけでは何も起こりません。
「誰か」がデータを読み、国ごとに分け、売上を合計し、結果を返す必要があります。

その「誰か」が計算エンジンです。

Sparkであれば、データを複数のWorkerに分散し、それぞれで部分的に集計し、最後に結果を統合します。Snowflakeであれば、Warehouseと呼ばれる計算クラスターが裏側で処理を行います。

ここで重要なのは、データを保存することと、データを処理することは別の能力だという点です。

昔のデータベースは、この二つが一体化していました。Oracleや従来型のDWHでは、保存、管理、計算が一つの大きなシステムの中に閉じていました。

しかしクラウド時代には、この前提が変わりました。データは安価なStorageに置き、必要なときだけCompute（計算エンジン）を動かす。つまり、保存と計算を分離する考え方が主流になりました。

これは技術的な変化であると同時に、経済合理性の変化でもあります。常に巨大な計算機を持ち続けるのではなく、必要なときに必要なだけ借りる。固定費を変動費に近づける。このクラウド的な発想が、データ基盤にも入ってきたわけです。

Open Table Formatは何を解決するのか

StorageとComputeを分離すると、一つの問題が生まれます。

データはStorageにある。
Computeは、Storageにアクセスしに行く。
しかし、果たして、そのデータを様々なComputeから安全に、正しく、効率よくアクセスし、読み取ることができるのか？という問題です。

単にParquetファイルをS3に置くだけでは、十分ではありません。ファイルが増えれば、どれが現在有効なデータなのか、どのスキーマで読むべきなのか、更新や削除をどう扱うのか、何かあった際に過去の状態に戻せるのか、といった問題が出てきます。

そこで必要になるのが、Open Table Formatです。

Open Table Formatは、多様なファイルの集合体を、複数の計算エンジンが「テーブル」として扱うことを可能にします。Sparkからも読める。Trinoからも読める。Snowflakeからも読める。将来的にはAI基盤や別の処理エンジンからも扱えるようになります。

つまり、データを特定のシステムの内部形式に閉じ込めず、より開かれた形で管理するための仕組みなのです。ここでの本質は、「保存形式」の話だけではありません。企業の保有するさまざまなデータを、どの処理エンジンからも使える共有資源として設計し直すことです。

後半へ続く