Icebergテーブルフォーマット、良いアイデア ― 誤って定義された仕様 ― Part 2 of 2

アイスバーグ仕様の問題点

• アイスバーグ仕様の深刻な問題: アイスバーグ仕様は、大規模データレイクのメタデータ問題を解決するための本気の試みではない。
• 歴史的な教訓: 第1部では、過去の教訓を学ぶために歴史を振り返り、データベースが解決すべき「空間管理問題」を紹介した。
  • 問題の要素:
    1. 空間の断片化
    2. きめ細かな同時実行制御
    3. 複数オブジェクトに対する原子性
    4. 行とファイルの間のインピーダンスミスマッチ
    5. メタデータへの低レイテンシかつ高スループットなアクセス
• オープンフォーマットの重要性: あらゆるスタックでオープンフォーマットを使うことには100%賛成であり、特に表形式データでParquetを共通の保存フォーマットとして使うことに大きな期待を寄せている。
• Parquetファイルとデータベーステーブルの違い: Parquetファイルが集まっているからといって、それがデータベーステーブルになるわけではない。データベーステーブルは単なる行の集合以上のものだ。

メタデータ問題の要約

• 空間管理問題: データベースが解決すべき複数の問題をあらためて強調した。
• メタデータの必要性: 複数のParquetファイルをデータベーステーブルのように見せるには、次のようなメタデータが必要になる:
  1. テーブルを構成するすべてのファイル位置の一覧
  2. 各ファイルに関する大まかなメタデータ
  3. ファイルを追加または削除できるトランザクション制御メカニズム
  4. テーブルスキーマを進化させる方法
• ファイル位置の探索: Parquetファイル群を単一テーブルとして扱うには、ファイルを見つける仕組みが必要だ。
• メタデータの重要性: 各ファイルには、関心のある行をすばやく見つけるための追加メタデータが必要だ。

Parquetファイルとデータベーステーブル

• Parquetファイルの定義: Parquetは、自己記述的で表形式のデータフォーマットを提供する。
• データベーステーブルの定義: データベーステーブルは単なる行の集合ではなく、さまざまなメタデータとトランザクション制御を必要とする。
• Parquetファイルをテーブルのように使うための条件:
  1. ファイル位置の一覧
  2. 各ファイルのメタデータ
  3. ファイルの追加・削除のためのトランザクション制御メカニズム
  4. テーブルスキーマを進化させる方法
• ファイルとテーブルの違い: Parquetファイルが同じ列レイアウトを持っているからといって、データベーステーブルのように見えるわけではない。

マニフェストファイルとリスト

• データ追加の流れ: アイスバーグクライアントがテーブルにデータを追加するには、次の手順を踏む必要がある:
  1. 1つ以上のParquetファイルを特定の場所（例: S3）に書き込む。
  2. 手順1で書き込んだファイルを指すマニフェストファイルを書く。
  3. 新しいマニフェストリストを書く。
• マニフェストファイルの形式: マニフェストファイルとリストはAVRO形式で、圧縮されており自己記述的である。
• マニフェストファイルの内容: マニフェストファイルには、Parquetファイルへのポインタと各列に関するメタデータが含まれる。
• メタデータサイズの問題: このような形でメタデータを保存すると必要以上に大きくなり、ファイル間で共通する文字列値を認識して圧縮することもできない。

クライアント負担の増大

• クライアントの責任: アイスバーグ仕様全体を通じて、クライアントは単純な変更のために膨大な記録管理を行わなければならない。
• メタデータの正確性の問題: クライアントが一部を誤って書く可能性があるため、新しいスナップショットのコミットでは厳密な検証が必要であり、マニフェストデータが正しく書かれていることを確認しなければならない。
• セキュリティ問題: クライアントがすべてのマニフェストファイルを指すマニフェストリストを書かなければならないため、すべてのS3ファイル位置が漏えいする。
• データセキュリティの重要性: データの価値が高い以上、仕様がセキュリティを最優先で扱っていない理由は疑問視されるべきだ。

行セキュリティの欠陥

• 行セキュリティの必要性: 米国のような比較的規制の緩い国であっても、機微データを保護するためには行レベルセキュリティが必要だ。
• EUのGDPR: 欧州ではGDPRのような法律により、データアクセスに対してさらに慎重である必要がある。
• クライアントのデータアクセス問題: クライアントはテーブルにデータを追加できる一方で、既存データへのアクセスを制限することはできない。
• セキュリティ問題の深刻さ: 仕様がセキュリティを優先していない理由は、データレイク情報の価値に対する疑問を投げかける。

メタデータファイルの役割

• メタデータファイルの作成: クライアントはParquetファイルを書いた後、そのマニフェストファイルを作成し、既存のマニフェストリストを読み、新しいマニフェストリストを生成してからデータをコミットしなければならない。
• コミット処理: コミットはメタデータファイル（<prefix>.metadata.json）を書き込むことで行われる。
• JSON形式の選択: メタデータファイルがJSON形式である理由は不明で、「委員会による設計」のような印象を与える。
• メタデータの反復性: メタデータファイルはすべてのスナップショットを列挙しており、情報の重複によって領域が無駄になる。

コミット処理の複雑さ

• 原子性の問題: 新しいメタデータファイルを最新ファイルにし、以前のメタデータファイルと原子的に置き換えなければならない。
• コミット手順の複雑さ: 新しいメタデータバージョンV+1をコミットするには、次の手順が必要になる:
  1. 現在のメタデータを基に新しいテーブルメタデータファイルを生成する。
  2. 新しいテーブルメタデータを一意のファイルに書き込む。
  3. メタストアに要求し、テーブルのメタデータポインタをVからV+1へ置き換える。
• スワップ失敗時の処理: スワップに失敗した場合、別のライターがすでにV+1を生成したことを意味するため、クライアントは再び手順1に戻らなければならない。
• 競合状態の問題: クライアント同士が競合すると、先行クライアントが書いたメタデータファイルを読み直し、マニフェストリストとメタデータファイルを再生成しなければならない。

楽観的同時実行制御の問題

• 同時実行の現実: リソース競合が想定されないなら、どの種類の同時実行制御を使っても大差はない。
• 競合が予想される場合: 2つのクライアントが同じ値を変更しようとするなら、ロック機構を使うべきだ。
• 楽観的同時実行制御の限界: アイスバーグでは、2つの同時書き込みは常に衝突するようになっており、これは仕様の設計のしかたによるものだ。
• 最悪のロック意味論: メタデータに対して最悪レベルのロック意味論を採用しており、単にデータを追加したいだけならクライアント間の調整は不要なはずだ。

メタデータスワップの限界

• メタデータの中央集権化: テーブルのメタデータを単一ファイルに集中させることで、あらゆる書き込みに対する単一の競合点を生み出している。
• リトライ時のクライアント負担: クライアントが失敗した場合、先行クライアントが書いたデータを読み、マニフェストリストとメタデータファイルを再生成しなければならない。
• メタデータスワップの速度: メタデータスワップを実行するサービスはリトライ込みで処理しなければならず、これは性能低下を招く。
• 制限されたコミット数: 単純な同時実行実装のため、コミット数は制限され、メタデータファイルの原子的置換にかかる時間に縛られる。

データベースの必要性

• メタデータファイル位置の探索: アイスバーグテーブルのスナップショットは、metadata.jsonファイルによって完全に記述される。
• アイデアの矛盾: アイスバーグはファイルだけでメタデータ形式を定義しようとしているが、結局はデータベースが必要になる。
• データベースの利点: 現代のデータベースは数十万件の書き込みを処理でき、分散的にスケールできる。
• ファイルシステムとデータベースの比較: メタデータをファイルに保存するより、データベースに保存するほうが効率的だ。

断片化とメタデータ肥大化

• metadata.jsonファイルの増大: metadata.jsonファイルは最新スナップショットを指し、各メタデータファイルは以前のスナップショットへの逆ポインタを含む。
• メタデータの継続的増加: メタデータは継続的に増加し、データレイクの性能に悪影響を及ぼす。
• 定期的なメタデータ整理の必要性: データレイクに継続してデータを追加する場合、メタデータを整理しなければならない。
• HTTPリクエストのコスト: メタデータファイルを削除する過程でHTTPリクエストが発生し、コストにつながる可能性がある。

データ読み取りとクエリ計画

• マニフェストファイルの役割: マニフェストファイルにはParquetファイルに関するメタデータが含まれている。
• クエリ計画の複雑さ: クエリを実行するには、マニフェストリストとマニフェストファイルを順番に読まなければならない。
• コストの問題: S3での読み取りコストが発生し、クエリ実行速度に影響する。
• メタデータ断片化の問題: メタデータが断片化するとクエリ計画は複雑になり、データアクセスが難しくなる。

キャッシュとクエリ計画の難しさ

• マニフェストのキャッシュ: マニフェストをキャッシュすることはできるが、メタデータサイズが大きくなるため非効率だ。
• キャッシュの有効性維持: キャッシュが最新かどうかを確認し続ける必要があり、追加のコストと複雑さを招く。
• クライアントの負担: すべてのクライアントがメタデータをキャッシュしなければならず、結果として数百万件のHTTPリクエストが発生する。
• 複雑さの増大: データレイクの利用は複雑になり、それを解決するための追加ソリューションが必要になる。

アイデアの結論

• アイデアへの批判: アイスバーグ仕様は、データレイクメタデータに関する真剣な仕様ではなく、多くの問題を抱えている。
• 問題の要約: アイスバーグはO(n)の作業でメタデータを追加し、テーブル横断コミットを扱えず、メタデータ肥大化の問題も解決できていない。
• スケーリングの限界: アイスバーグはスケーリングに適しておらず、過剰な複雑さをクライアント側へ押し付けている。
• 業界への問い: なぜIT業界でこのような問題が起きるのか、という問いを投げかけている。