ボーダーレス Lakehouse とそれに関連するリソースのエラー（メタデータ テーブル クエリ、metadata.json ファイルサイズの制限、マルチリージョン カタログ構成の問題など）を診断して解決できます。これらの問題に対処すると、レイクハウス ワークロード全体でテーブル オペレーションとクエリ実行を復元できます。
メタデータ テーブルをクエリできない
この問題は、BigQuery の Lakehouse ランタイム カタログでサポートされている Apache Iceberg テーブルのメタデータ テーブル（.snapshots や .files など）を 5 つの部分からなる名前識別子を使用してクエリすると発生します。
この問題を解決するには、Apache Spark を使用してこれらのテーブルにクエリを実行します。
metadata.json ファイルサイズの上限
Apache Iceberg metadata.json のファイルサイズは 1 MB に制限されています。この上限は、テーブル スナップショット、スキーマ、パーティション仕様を追跡するメタデータ ファイルに適用されます。メタデータ ファイルがこのサイズを超えると、Apache Iceberg REST カタログ エンドポイントを介してテーブル オペレーションを実行するときにエラーが発生することがあります。
この問題を解決するには、Google アカウント チームに連絡して上限の引き上げをリクエストしてください。
マルチリージョン カタログのクエリ時に NOT_FOUND エラーが発生する
この問題は、プライマリ ロケーションを指定せずにマルチリージョン Cloud Storage バケットを使用して Lakehouse ランタイム カタログにカタログを作成し、BigQuery 仮想リージョン（US や EU など）を指定してカタログをクエリしようとしたときに発生します。
マルチリージョン バケットを使用してカタログを作成すると、そのメタデータは、対応する BigQuery 仮想リージョンではなく、マルチリージョンの地理的範囲内の特定のリージョン ロケーションに保存されます。メタデータが存在しない仮想リージョンでクエリを強制的に実行すると、クエリは NOT_FOUND エラーで失敗します。
この問題を解決するには、カタログの作成時にプライマリ ロケーション（US や EU など）を指定します。詳細については、米国と EU のマルチリージョンのプライマリ リージョンを指定するをご覧ください。
ストレージ最適化ジョブが INFORMATION_SCHEMA.JOBS に表示されない
この問題は、Apache Iceberg テーブルでテーブル管理を有効にして、データ ミューテーション（挿入や DML ステートメントなど）を実行しても、INFORMATION_SCHEMA.JOBS ビューにストレージ最適化ジョブ（CALL BQ.OPTIMIZE_STORAGE など）が表示されない場合に発生します。これらのジョブのクエリの詳細については、Iceberg ストレージ最適化ジョブを取得するをご覧ください。
この動作は、ストレージの最適化がスキップされた場合に想定されます。テーブル管理では、データ変更後にテーブル レイアウトを評価し、データファイルの圧縮または再構築が必要な場合にのみ最適化ジョブを実行します。バックグラウンド テーブル管理ジョブはプロジェクトで実行され、コンピューティング リソースを消費するため、テーブル レイアウトがすでに最適化されている場合、BigQuery はデータを書き換えません。次の条件では、最適化はスキップされます。
- ファイルはすでに最適化されている: 既存のデータファイルは、すでにターゲット ファイルサイズに近いか、それを超えています（圧縮されていない平均サイズが 256 MB の 50% 以上）。
- しきい値が満たされていない: テーブルに十分な数の小さなファイルが蓄積されていないか、圧縮に必要なサイズしきい値（テーブルの合計サイズが 1 GB を超えるなど）を満たしていません。
ストレージ最適化がスキップされると、バックグラウンド ジョブは実行されず、INFORMATION_SCHEMA.JOBS にエントリは記録されません。
クエリのパフォーマンスが要件を満たし、ファイルのサイズがすでに適切である場合は、対応は必要ありません。ストレージの最適化は、将来の書き込みによって十分なファイル フラグメンテーションが発生すると自動的に実行されます。
テスト環境でストレージ最適化ジョブをモニタリングするには、1 GB を超えるテーブルに複数の小さなバッチのデータを挿入して、ファイルの断片化をシミュレートします。