情報スキーマを使用してトラブルシューティングを行う

BigQuery 管理者またはデータ アナリストとして、エンタープライズ ワークロードを管理するには、パフォーマンスのボトルネック、クエリの失敗、容量制限、ストレージの増加を診断するための信頼性の高いスケーラブルな方法が必要です。BigQuery 情報スキーマ ビューは、標準の GoogleSQL クエリでアクセスできるほぼリアルタイムの履歴メタデータを提供するオブザーバビリティの基盤として機能します。

このドキュメントでは、情報スキーマを使用した BigQuery のトラブルシューティングの基本原則の概要、管理トラブルシューティング ツールボックスの構造化された概要を示し、BigQuery ライブラリの特定のビューに移動します。

タスク別の情報スキーマのトラブルシューティング

次の表に、タスクと診断のユースケースごとに分類された有用な情報スキーマ ビューの概要を示します。

タスク ユースケース 情報スキーマビュー
クエリのパフォーマンスとエラー
  • スロットを最も消費する高コストのクエリを特定します。
  • ジョブエラーの理由と障害パターンを集計します。
  • ステージごとの実行時間とスピルされたバイト数を分析します。
ワークロードの容量と競合
  • スロットの競合、スロットリング、キュー時間を検出します。
  • インメモリ シャッフル メモリの飽和状態をモニタリングします。
  • 予約のベースライン スロットと自動スケーリング スロットの使用状況を監査します。
  • プロジェクトとフォルダの予約割り当てを確認します。
ストレージ費用とデータ アーキテクチャ
  • 物理ストレージまたは論理ストレージが過剰に使用されているテーブルを特定します。
  • タイムトラベル ストレージとフェイルセーフ ストレージの肥大化を検出します。
  • パーティションのスキューとパーティションの上限に近づいているテーブルを診断します。
  • タイムトラベル期間内の期限切れまたは削除されたテーブルを検出します。
アクセス制御とガバナンス
  • テーブルとデータセットに対する明示的な Identity and Access Management（IAM）ロール付与を監査します。
  • ユーザーとサービス アカウントのアクセス拒否エラーのトラブルシューティングを行います。
  • プロジェクト間のデータセットの共有と分析の使用状況を追跡します。
データの取り込みパイプライン
  • Storage Write API の取り込みスループットとエラーをモニタリングします。
  • ストリーミング挿入のレイテンシとレート上限を診断します。
  • ストリームの種類とエラーコードで失敗したストリームを特定します。
機械学習とベクトル検索
  • モデルのトレーニング時間とリソース消費量を追跡します。
  • ベクトル インデックスのビルド ステータスとカバレッジ率を監査します。
  • ストアド プロシージャと Python UDF のビルドのトラブルシューティングを行います。
ワークロード最適化の分析情報
  • 自動パーティショニングとクラスタリングの推奨事項を確認します。
  • マテリアライズド ビューの候補テーブルを特定します。

情報スキーマを使用したトラブルシューティングの原則

BigQuery でワークロードまたは環境の問題を診断する場合は、次の基本原則を適用します。

  • リージョン、データセット、プロジェクトでスコープを設定します。BigQuery ワークロード管理とコンピューティング リソースは、リージョン境界内で実行されます。次の点を考慮してください。

    • 常に正しいリージョン修飾子（region-REGION.INFORMATION_SCHEMA.JOBS_BY_PROJECT など）またはデータセット修飾子を指定します。

    • 単一ユーザーの問題、プロジェクト固有のワークロード、テナント全体の問題のいずれを調査しているかに基づいて、適切な階層レベル（BY_PROJECT、BY_USER、BY_FOLDER、BY_ORGANIZATION）を選択します。

  • コンピューティング需要と容量を関連付けます。クエリのパフォーマンスが低下する原因は、非効率的な SQL だけでなく、スロットの競合であることもよくあります。同じ時間枠でジョブ リソース リクエスト（period_estimated_runnable_units）と割り当てられた予約スロット（period_slot_ms）を比較して、クエリ チューニングの機会と容量不足が原因で発生した問題を区別します。

  • テレメトリーの粒度と保持境界を考慮します。情報スキーマ ビューは、それぞれ異なる更新間隔とデータ保持期間で動作します。JOBS ビューのジョブ メタデータは 180 日間使用できますが、JOBS_TIMELINE ビューと RESERVATIONS_TIMELINE ビューの高解像度タイムライン指標は、より短い期間（通常は 14 ～ 30 日間）保持されます。長期的な監査と傾向分析を行う場合は、テレメトリーをパーティション分割テーブルにエクスポートする必要があります。

  • マルチステートメント クエリでの指標の歪みを回避します。複数ステートメント スクリプト（DECLARE、IF、WHILE を含む手続き型 SQL）は、statement_type = 'SCRIPT' を含む親ジョブと、各ステートメントの個々の子ジョブを生成します。total_slot_ms や total_bytes_billed などの指標を集計する場合は、statement_type = 'SCRIPT' を除外して重複カウントを防ぎます。

  • パーティション分割列でフィルタします。クエリの実行時間を最小限に抑え、オンデマンド分析で不要なスキャン費用を回避するには、creation_time、job_start_time、period_start などのパーティション列に制限付きの時間フィルタを常に含めます。

次のステップ

  • 情報スキーマの構文と使用可能なビューのリストの詳細については、INFORMATION_SCHEMA の概要をご覧ください。
  • ジョブの詳細を表示する方法、アクティブなジョブを一覧表示する方法、実行中のジョブをキャンセルする方法については、ジョブを管理するをご覧ください。