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

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

オブジェクト テーブルと一部のタイプの BigLake テーブルでは、外部データストア（Cloud Storage など）のファイルに関するメタデータ情報をキャッシュに保存できます。メタデータのキャッシュ保存は、次のタイプの BigLake テーブルでサポートされています。

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

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

テーブルの作成時に、BigLake テーブルまたはオブジェクト テーブルでメタデータのキャッシュ保存を有効にできます。オブジェクト テーブルの作成の詳細については、Cloud Storage オブジェクト テーブルを作成するをご覧ください。BigLake テーブルの作成の詳細については、次のいずれかをご覧ください。

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

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

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

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

キャッシュを自動更新するか、手動更新するかを選択できます。

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

  • 手動で更新する場合は、BQ.REFRESH_EXTERNAL_METADATA_CACHE システム プロシージャを実行して、要件を満たすスケジュールでメタデータのキャッシュを更新します。BigLake テーブルの場合、テーブルデータ ディレクトリのサブディレクトリを指定することで、メタデータを選択的に更新できます。これにより、不要なメタデータ処理を回避できます。 パイプラインの出力など、既知の間隔でデータストア内のファイルが追加、削除、変更される場合、キャッシュを手動で更新することをおすすめします。

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

メタデータ キャッシュは、更新されなければ 7 日後に期限切れになります。

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

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

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

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

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

メタデータ更新ジョブに関する情報を確認するには、次の例に示すように 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;

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

キャッシュに保存されたメタデータは、キャッシュに保存されたメタデータが関連付けられているテーブルに使用される顧客管理の暗号鍵（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 フラグを指定してください。

次のステップ