メタデータのキャッシュ保存

このドキュメントでは、BigLake とオブジェクト テーブルとともにメタデータのキャッシュ保存を使用して、クエリのパフォーマンスを向上させる方法について説明します。

BigLake とオブジェクト テーブルは、Cloud Storage や Amazon Simple Storage Service（Amazon S3）などの外部データソースのファイルに関するメタデータのキャッシュ保存をサポートしています。メタデータには、ファイル名、パーティショニング情報、ファイルの物理的なメタデータ（行数など）が含まれます。テーブルでメタデータのキャッシュ保存を有効にするかどうかを選択できます。多数のファイルと Hive パーティション フィルタを使用したクエリは、メタデータのキャッシュから最大限のメリットを得られます。

メタデータのキャッシュ保存を有効にしていない場合、テーブルのクエリはオブジェクト メタデータを取得するために外部データソースを読み取る必要があるため、クエリの待ち時間が増加します。外部データソースから数百万のファイルを一覧表示するには、数分かかることがあります。メタデータのキャッシュ保存を有効にすると、クエリで外部データソースのファイルを一覧表示することを回避し、パーティションとファイルのプルーニングを高速化できます。

この機能を制御するプロパティが 2 つあります。

  • 最大の未更新。キャッシュされたメタデータをクエリで使用するタイミングを制御します。
  • メタデータ キャッシュ モード。メタデータの収集方法を制御します。

メタデータのキャッシュ保存を有効にする場合は、テーブルに対するオペレーションで許容されるメタデータ未更新の最大間隔を指定します。たとえば、1 時間の間隔を指定すると、テーブルに対するオペレーションでは、キャッシュされたメタデータが過去 1 時間以内に更新されている場合、そのメタデータが使用されます。キャッシュに保存されているメタデータがそれより古い場合、オペレーションは代わりに Cloud Storage からメタデータを取得します。未更新の間隔は 30 分～7 日の間で指定できます。

キャッシュを自動または手動で更新することを選択できます。

  • 自動更新の場合、キャッシュはシステムが定義した間隔（通常は 30～60 分）で更新されます。外部データソース内のファイルがランダムな間隔で追加、削除、変更される場合は、キャッシュの自動更新が適しています。更新のタイミングを制御する必要がある場合（たとえば、抽出、変換、読み込みジョブの最後に更新をトリガーするなど）は、手動更新を使用します。

  • 手動で更新する場合は、BQ.REFRESH_EXTERNAL_METADATA_CACHE システム プロシージャを実行して、決定したスケジュールでメタデータのキャッシュを更新します。パイプラインの出力など、既知の間隔で z 内のファイルが追加、削除、変更される場合、キャッシュを手動で更新することをおすすめします。

    複数の手動更新を同時に発行しても、成功するのは 1 つだけです。

メタデータ キャッシュは、更新しない場合、7 日後に期限切れになります。

未更新間隔とメタデータ キャッシュ モードの値は、設定する前に、どのように相互作用するかを検討する必要があります。以下の例を考えてみましょう。

  • テーブルのメタデータ キャッシュを手動で更新していて、未更新間隔を 2 日に設定した場合、キャッシュされたメタデータを使用するテーブルのオペレーションを行うには 2 日以内の間隔で、BQ.REFRESH_EXTERNAL_METADATA_CACHE システム プロシージャを実行する必要があります。
  • テーブルのメタデータ キャッシュを自動的に更新していて、未更新間隔を 30 分に設定した場合、メタデータ キャッシュのリフレッシュが通常の 30～60 分より長くかかると、テーブルに対する操作の一部が Cloud Storage から読み込まれる可能性があります。

メタデータ更新ジョブに関する情報を探すには、次の例に示すように INFORMATION_SCHEMA.JOBS ビューをクエリします。

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

メタデータのキャッシュ保存の設定

この機能の動作を制御するプロパティが 2 つあります。

  • 最大の未更新は、キャッシュされたメタデータをクエリで使用するタイミングを指定します。
  • メタデータ キャッシュ モードは、メタデータの収集方法を指定します。

メタデータのキャッシュ保存を有効にする場合は、テーブルに対するオペレーションで許容されるメタデータ未更新の最大間隔を指定します。たとえば、1 時間の間隔を指定すると、テーブルに対するオペレーションでは、キャッシュされたメタデータが過去 1 時間以内に更新されている場合、そのメタデータが使用されます。キャッシュに保存されているメタデータがそれより古い場合、オペレーションは代わりに Cloud Storage からメタデータを取得します。未更新の間隔は 30 分～7 日の間で指定できます。

キャッシュを自動または手動で更新することを選択できます。

  • 自動更新の場合、キャッシュはシステムが定義した間隔（通常は 30～60 分）で更新されます。Cloud Storage 内のファイルがランダムな間隔で追加、削除、変更される場合、キャッシュを自動的に更新することをおすすめします。更新のタイミングを制御する必要がある場合（たとえば、抽出、変換、読み込みジョブの最後に更新をトリガーするなど）は、手動更新を使用します。
  • 手動で更新する場合は、BQ.REFRESH_EXTERNAL_METADATA_CACHE システム プロシージャを実行して、決定したスケジュールでメタデータのキャッシュを更新します。Cloud Storage 内のファイルが既知の間隔（パイプラインの出力など）で追加、削除、変更される場合は、キャッシュを手動で更新することをおすすめします。

手動と自動のキャッシュ更新はどちらも、INTERACTIVE クエリの優先度で実行されます。

自動更新を使用する場合は、予約を作成してから、メタデータ キャッシュ更新ジョブを実行するプロジェクトの BACKGROUND ジョブタイプの割り当てを作成することをおすすめします。これにより、更新ジョブとユーザーのクエリによるリソースの奪い合いを防ぎ、利用可能なリソースが十分でない場合に失敗する可能性を防ぐことができます。

未更新間隔とメタデータ キャッシュ モードの値は、設定する前に、どのように相互作用するかを検討する必要があります。以下の例を考えてみましょう。

  • テーブルのメタデータ キャッシュが手動更新を必要とするように設定されており、未更新期間が 2 日に設定されている場合、テーブルに対する操作でキャッシュされたメタデータを使用する場合は、2 日以内ごとに BQ.REFRESH_EXTERNAL_METADATA_CACHE システム手続きを実行する必要があります。
  • テーブルのメタデータ キャッシュが自動的に更新されるように設定されており、未更新間隔が 30 分に設定されている場合、メタデータ キャッシュの更新が通常の時間枠（30 分から 60 分）において長めの間隔で実行されると、テーブルに対する操作の一部が Cloud Storage から読み込まれる可能性があります。

BigLake テーブルでメタデータのキャッシュ保存の設定を使用する方法については、パーティション分割されていないデータに対して BigLake テーブルを作成するをご覧ください。オブジェクト テーブルでメタデータのキャッシュ保存の設定を使用する方法については、オブジェクト テーブルを作成するをご覧ください。

メタデータ キャッシュ更新ジョブに関する情報を取得する

メタデータ更新ジョブに関する情報を探すには、次の例に示すように INFORMATION_SCHEMA.JOBS ビューをクエリします。

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

キャッシュに保存されたメタデータで顧客管理の暗号鍵を使用する

キャッシュに保存されたメタデータは、キャッシュに保存されたメタデータが関連付けられているテーブルに使用される顧客管理の暗号鍵（CMEK）によって保護されます。これは、テーブルに直接適用される CMEK である場合もあれば、テーブルがデータセットまたはプロジェクトから継承する CMEK である場合もあります。

プロジェクトまたはデータセットにデフォルトの CMEK が設定されているか、プロジェクトまたはデータセットの既存の CMEK が変更される場合、既存のテーブルやキャッシュに保存されたメタデータに影響はありません。新しい鍵をテーブルとキャッシュに保存されたメタデータの両方に適用するには、テーブルのキーを変更する必要があります。

BigQuery で作成された CMEK は、BigLake テーブルとオブジェクト テーブルで使用される Cloud Storage ファイルには適用されません。エンドツーエンドの CMEK 暗号化を取得するには、これらのファイル向けに Cloud Storage で CMEK を構成します。

クエリジョブごとのメタデータ キャッシュ使用状況に関する情報を取得する

クエリジョブのメタデータ キャッシュ使用量に関する情報を取得するには、対象ジョブの jobs.get メソッドを呼び出し、Job リソースの JobStatistics2 セクションで MetadataCacheStatistics フィールドを確認します。このフィールドには、クエリで使用されたメタデータ キャッシュが有効なテーブル、メタデータ キャッシュがクエリで使用されたかどうか、使用されていない場合はその理由が表示されます。

テーブルの統計情報

Parquet ファイルに基づく BigLake テーブルでは、メタデータ キャッシュが更新されたときにテーブルの統計情報が収集されます。テーブルの統計情報の収集は、自動更新と手動更新の両方で行われ、統計情報はメタデータ キャッシュと同じ期間保持されます。

収集されるテーブル統計情報には、行数、物理的なファイルサイズ、非圧縮時のファイルサイズ、列のカーディナリティなどのファイル情報が含まれます。Parquet ベースの BigLake テーブルでクエリを実行すると、これらの統計情報がクエリ オプティマイザーに提供されるため、より適切なクエリ プランニングが可能になり、一部のタイプのクエリでパフォーマンスが向上する可能性があります。たとえば、一般的なクエリ最適化では制約が動的に反映され、クエリ オプティマイザーが、小さなディメンション テーブルから結合した大きなファクト テーブルの述語を動的に推測します。この最適化では、正規化されたテーブル スキーマを使用してクエリを高速化できますが、正確なテーブル統計情報が必要とされます。メタデータのキャッシュ保存によって収集されたテーブル統計情報によって、BigQuery と Apache Spark の両方でクエリプランのさらに優れた最適化が可能になります。

制限事項

メタデータ キャッシュには、次の制限が適用されます。

  • 複数の手動更新を同時に発行しても、成功するのは 1 つだけです。
  • メタデータ キャッシュは、更新しない場合、7 日後に期限切れになります。
  • テーブルのソース URI を更新しても、メタデータ キャッシュは自動的には更新されません。それ以降のクエリでは、古いキャッシュのデータが返されます。これを回避するには、メタデータ キャッシュを手動で更新します。テーブルのメタデータ キャッシュが自動で更新されるように設定されている場合は、テーブルの更新モードを手動に変更し、手動で更新してから、テーブルの更新モードを再度自動に戻す必要があります。

  • メタデータ キャッシュを手動で更新していて、ターゲット データセットと Cloud Storage バケットがリージョンのロケーションにある場合、BQ.REFRESH_EXTERNAL_METADATA_CACHE プロシージャ コールを実行するときに、この場所を明示的に指定する必要があります。これは次のいずれかの方法で行うことができます。

    コンソール

    1. [BigQuery] ページに移動します。

      [BigQuery] に移動

    2. エディタでタブを選択します。

    3. [ 展開] をクリックして、[クエリの設定] をクリックします。

    4. [詳細オプション] セクションで、[自動ロケーション選択] チェックボックスをオフにして、ターゲット リージョンを指定します。

    5. [保存] をクリックします。

    6. その [エディタ] タブで、BQ.REFRESH_EXTERNAL_METADATA_CACHE プロシージャ呼び出しを含むクエリを実行します。

    bq

    BQ.REFRESH_EXTERNAL_METADATA_CACHE プロシージャ コールを含むクエリを bq query を使って実行する場合は、必ず --location フラグを指定してください。

次のステップ