BigLake テーブルの概要

このドキュメントでは、BigLake の概要について説明します。データベース テーブルと Identity and Access Management(IAM)をよく理解していることを前提としています。サポート対象のデータストアに保存されているデータに対してクエリを実行するには、まず BigLake テーブルを作成してから、GoogleSQL 構文を使用してクエリを実行する必要があります。

外部テーブルを BigLake にアップグレードすることもできます。詳細については、外部テーブルを BigLake にアップグレードするをご覧ください。

BigLake テーブルでは、アクセス権の委任を使用して外部データストアの構造化データをクエリできます。アクセス権の委任により、BigLake テーブルへのアクセス権と基盤となるデータストアへのアクセス権が分離されます。データストアへの接続には、サービス アカウントに関連付けられた外部接続が使用されます。サービス アカウントがデータストアからデータを取得する操作を行うため、必要な操作はユーザーに BigLake テーブルへのアクセス権を付与することのみです。これにより、行レベル列レベルのセキュリティなど、テーブルレベルでの詳細なセキュリティを適用できます。Cloud Storage に基づく BigLake テーブルの場合は、動的データ マスキングも使用できます。Amazon S3 または Blob Storage のデータを含む BigLake テーブルを使用したマルチクラウド分析ソリューションの詳細については、BigQuery Omni をご覧ください。

サポートされているデータストア

BigLake テーブルは、次のデータストアで使用できます。

一時テーブルのサポート

Cloud Storage に基づく BigLake テーブルは、一時的と永続的のどちらも可能です。Amazon S3 または Blob Storage に基づく BigLake テーブルは、永続的である必要があります。

複数のソースファイル

データソースが同じスキーマを持つ場合は、複数の外部データソースに基づいて BigLake テーブルを作成できます。

結合

Cloud Storage に基づく BigLake テーブルは、ロケーションに関する考慮事項に従って、他の BigQuery テーブル結合できます。Amazon S3 または Blob Storage に基づく BigLake テーブルは、同じロケーションにある他の BigLake テーブルとのみ結合できます。

コネクタ

BigQuery コネクタを使用すると、他のデータ処理ツールから Cloud Storage にある BigLake テーブルのデータにアクセスできます。たとえば、Apache SparkApache HiveTensorFlowTrino、または Presto から BigLake テーブルのデータにアクセスできます。BigQuery Storage API は、BigLake テーブルへのすべてのデータアクセス(コネクタを介したアクセスを含む)に行レベルと列レベルのガバナンス ポリシーを適用します。

たとえば、次の図は、BigQuery Storage API により、ユーザーが Apache Spark などのオープンソース クエリエンジンを使用して承認済みデータにアクセスする方法を示しています。

BigLake アーキテクチャ

オブジェクト ストア上の BigLake テーブル

データレイク管理者である場合は、BigLake を使用すると、ファイルではなくテーブルにアクセス制御を設定して、データレイク内のデータへのユーザー アクセスを詳細に設定できます。

このように BigLake テーブルではアクセス制御が簡素化されるため、BigLake テーブルを使用して外部オブジェクト ストアへの接続を構築して維持することをおすすめします。

ガバナンスが要件でない場合や、アドホックのデータ検出と操作には、外部テーブルを使用できます。

制限事項

  • BigLake テーブルには、外部テーブルの制限がすべて適用されます。
  • オブジェクト ストア上の BigLake テーブルには、BigQuery テーブルと同じ制限が適用されます。詳細については、割り当てをご覧ください。
  • BigLake は、Dataproc 個人用クラスタ認証で範囲が限定された認証情報をサポートしていません。回避策として、個人クラスタ認証でクラスタを使用するには、--access-boundary=<(echo -n "{}") フラグを使用して空の認証情報アクセス境界を使用して認証情報を挿入する必要があります。たとえば、次のコマンドは、mycluster という名前のクラスタに対して、myproject という名前のプロジェクトで認証情報の伝播セッションを有効にします。

    gcloud dataproc clusters enable-personal-auth-session \
        --region=us \
        --project=myproject \
        --access-boundary=<(echo -n "{}") \
        mycluster
    

  • BigLake テーブルは読み取り専用です。DML ステートメントやその他のメソッドを使用して BigLake テーブルを変更することはできません。

  • BigLake テーブルは、次の形式をサポートしています。

    • Avro
    • CSV
    • Iceberg
    • JSON
    • ORC
    • Parquet
  • Apache Iceberg BigLake テーブルではキャッシュに保存されたメタデータを使用できません。マニフェスト ファイルで Iceberg がキャプチャしたメタデータはすでに BigQuery で使用されています。

  • AWS や Azure などの他のクラウド環境では、BigQuery Storage API を使用できません。

  • キャッシュに保存されたメタデータを使用する場合は、次の制限が適用されます。

    • Parquet、JSON、CSV 形式を使用する BigLake テーブルでは、キャッシュに保存されたメタデータのみを使用できます。
    • Amazon S3 でファイルを作成、更新、または削除した場合、ファイルをクエリしても、メタデータ キャッシュが次に更新されるまで更新されたデータが返されません。これによって予期しない結果が生じる可能性があります。たとえば、ファイルを削除して新しいファイルを書き込むと、キャッシュに保存されたメタデータが最後に更新された日時によっては、クエリ結果で古いファイルと新しいファイルの両方が除外される場合があります。
    • Amazon S3 または Blob Storage のデータを参照する BigLake テーブルでは、キャッシュに保存されたメタデータでの顧客管理の暗号鍵(CMEK)の使用はサポートされていません。

セキュリティ モデル

通常、次の組織ロールは BigLake テーブルの管理と使用に関連しています。

  • データレイク管理者。これらの管理者は通常、Cloud Storage のバケットとオブジェクトの Identity and Access Management(IAM)ポリシーを管理します。
  • データ ウェアハウス管理者。これらの管理者は通常、テーブルを作成、削除、更新します。
  • データ アナリスト。アナリストは通常、データを読み取り、クエリを実行します。

データレイク管理者は、接続を作成してデータ ウェアハウス管理者と共有する責任があります。次に、データ ウェアハウス管理者は、テーブルを作成し、適切なアクセス制御を設定して、データ アナリストとテーブルを共有します。

パフォーマンス向上のためのメタデータ キャッシュ

キャッシュに保存されたメタデータを使用すると、BigLake テーブルに対するクエリ パフォーマンスを向上できます。これは、多数のファイルを扱う場合、またはデータが Hive パーティション分割される場合に特に便利です。

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;

BigLake メタデータ キャッシュ対応テーブルのマテリアライズド ビューを使用すると、Cloud Storage に保存されている構造化データをクエリする際のパフォーマンスと効率性を向上できます。これらのマテリアライズド ビューは、BigQuery マネージド ストレージ テーブルに対するマテリアライズド ビューと同様に、自動更新スマート チューニングの便益を含めて、機能します。

Parquet ファイルに基づく BigLake テーブルの場合、メタデータ キャッシュの更新中にテーブル統計情報が収集され、クエリプランの改善に使用されます。

詳細については、メタデータのキャッシュ保存をご覧ください。

キャッシュ保存に関するオプションの設定の詳細については、BigLake テーブルを作成するまたは BigLake テーブルを更新するをご覧ください。

インテグレーション

BigLake テーブルには、以下のサービスを含め、他にも多数の BigQuery 機能と gcloud CLI サービスからアクセスできます。

Analytics Hub

BigLake テーブルは Analytics Hub と互換性があります。BigLake テーブルを含むデータセットは、Analytics Hub のリスティングとして公開できます。Analytics Hub のサブスクライバーは、これらのリスティングに登録できます。これは、リンクされたデータセットと呼ばれる読み取り専用データセットをプロビジョニングします。サブスクライバーは、すべての BigLake テーブルを含む、リンクされたデータセット内のすべてのテーブルに対してクエリを実行できます。詳細については、リスティングに登録するをご覧ください。

BigQuery ML

BigQuery ML を使用すると、Cloud Storage の BigLake でモデルをトレーニングして実行できます。

Sensitive Data Protection

Sensitive Data Protection は、BigLake テーブルをスキャンして機密データを特定し、分類します。センシティブ データが検出された場合は、Sensitive Data Protection の匿名化変換によりデータをマスキング、削除、難読化できます。

費用

費用は、BigLake テーブルの次の要素に関連しています。

次の表に、料金モデルがこれらの費用の適用方法に与える影響を示します。


オンデマンド料金

Standard、Enterprise、Enterprise Plus のエディション

クエリ

ユーザークエリで処理されたバイト数が課金されます。

QUERY ジョブタイプの予約割り当てスロットは、クエリ時間中に消費されます。

メタデータ キャッシュを手動で更新する。

キャッシュの更新には、処理されたバイト数に対する料金が請求されます

QUERY ジョブタイプの予約割り当てスロットは、キャッシュの更新中に消費されます。

メタデータ キャッシュの自動更新。

キャッシュの更新には、処理されたバイト数に対する料金が請求されます

BACKGROUND ジョブタイプの予約割り当てスロットは、キャッシュの更新中に消費されます。

メタデータ キャッシュの更新に使用できる BACKGROUND 予約が存在せず、Enterprise または Enterprise Plus のエディションをご利用の場合、BigQuery は自動的に QUERY 予約内のスロットを代わりに使用します。

次のステップ