BigLake テーブルの概要

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

• Cloud Storage BigLake テーブルを作成してから、クエリを実行します。
• Amazon S3 BigLake テーブルを作成してから、クエリを実行します。
• Azure Blob Storage BigLake テーブルを作成してから、クエリを実行します。

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

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

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

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

• Amazon S3（BigQuery Omni を使用）
• Blob Storage（BigQuery Omni を使用）
• Cloud Storage

一時テーブルのサポート

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

複数のソースファイル

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

クロスクラウド結合

クロスクラウド結合を使用すると、Google Cloud と BigQuery Omni の両方のリージョンにまたがるクエリを実行できます。GoogleSQL JOIN オペレーションを使用すると、AWS、Azure、一般公開データセット、その他の Google Cloud サービスなど、さまざまなストレージ ソリューションのデータを分析できます。クロスクラウド結合により、クエリを実行する前にソース間でデータをコピーする必要がなくなります。

BigLake テーブルは、SELECT ステートメント内の任意の場所を標準の BigQuery テーブルのように参照できます。これには、データの取得にサブクエリを使用するデータ操作言語（DML）とデータ定義言語（DDL）ステートメントも含まれます。同じクエリで、異なるクラウドの複数の BigLake テーブルと BigQuery テーブルを使用できます。すべての BigQuery テーブルが同じリージョンのものである必要があります。

クロスクラウド結合に必要な権限

クロスクラウド結合の実施に必要な権限を取得するには、結合を実施するプロジェクトの BigQuery データ編集者（roles/bigquery.dataEditor）IAM ロールの付与を管理者に依頼します。ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

この事前定義ロールには、クロスクラウド結合の実施に必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

クロスクラウド結合を実施するには、次の権限が必要です。

• bigquery.datasets.create
• bigquery.tables.create

これらの権限は、カスタムロールや他の事前定義ロールを使用して取得することもできます。

クロスクラウド結合では、__bigquery_xregion_sink_ 接頭辞が付いたデータセットと、そのデータセット内の一時テーブルが作成されます。クロスクラウド結合によって作成されたリソースに対するアクセス権のみを付与するには、Table リソースタイプと Dataset リソースタイプに resource.name.startsWith 条件を使用します。

BigQuery における IAM ロールと権限の詳細については、IAM の概要をご覧ください。

クロスクラウド結合の費用

クロスクラウド結合オペレーションを行うと、BigQuery はクエリを解析してローカル部分とリモート部分に分割します。ローカル部分は、BigQuery リージョンの標準クエリとして扱われます。リモート部分は、BigQuery Omni リージョン内の参照される BigLake テーブルの CREATE TABLE AS SELECT（CTAS）オペレーションに変換されます。これにより、BigQuery リージョンに一時テーブルが作成されます。BigQuery は、この一時テーブルを使用してクロスクラウド結合を実施し、8 時間後にテーブルを自動的に削除します。

参照される BigLake テーブル内のデータにはデータ転送費用が発生します。ただし、BigQuery では、テーブル全体ではなく、クエリで参照される BigLake テーブルの列と行のみを転送することで、これらのコストを削減できます。転送費用をさらに削減するため、可能な限り絞り込んだ列フィルタを指定することをおすすめします。CTAS ジョブはジョブ履歴に表示され、転送されたバイト数などの情報が表示されます。転送が成功すると、メインのクエリジョブが失敗しても料金が発生します。詳しくは、BigQuery Omni の料金をご覧ください。

次のクエリを例に考えます。

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

この例では、従業員テーブル（レベルフィルタを使用）とアクティブな従業員テーブルからの 2 つの転送があります。結合は、転送の発生後に BigQuery リージョンで行われます。1 つの転送が失敗し、もう 1 つの転送が成功しても、成功した転送に対してデータ転送料金が適用されます。

クロスクラウド結合の制限事項

• クロスクラウド結合は、BigQuery の無料枠と BigQuery サンドボックスでサポートされていません。
• クエリに JOIN ステートメントが含まれている場合、集計が BigQuery Omni リージョンにプッシュダウンされないことがあります。
• 各一時テーブルは 1 つのクロスクラウド クエリでのみ使用され、同じクエリが複数回繰り返されても再利用されません。
• 各転送の転送サイズの上限は 60 GB です。特に、BigLake テーブルにフィルタを適用して結果を読み込む場合、サイズは 60 GB 以下でなければなりません。必要に応じて、割り当て上限の引き上げをリクエストできます。スキャンされるバイト数に上限はありません。
• クロスクラウド結合クエリでは、クエリのレートに対して内部割り当てが使用されます。クエリのレートが割り当てを超えると、All our servers are busy processing data transferred between regions エラーが発生することがあります。ほとんどの場合、クエリの再試行で問題を解決できます。クエリの処理率を高めるには、サポートに連絡して、内部割り当ての増加をリクエストしてください。
• クロスクラウド結合は、対応する BigQuery Omni リージョンがあるコロケーションされた BigQuery リージョン、およびマルチリージョン US と EU でのみサポートされます。US または EU マルチリージョンで実施されるクロスクラウド結合は、それぞれ米国または EU の BigQuery Omni リージョン内のデータにのみアクセスできます。
• クロスクラウド結合クエリが BigQuery Omni リージョンの 10 個以上のデータセットを参照していると、エラー Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region> で失敗することがあります。この問題を回避するには、10 個を超えるデータセットを参照するクロスクラウド結合を実行する際に、ロケーションを明示的に指定することをおすすめします。BigQuery リージョンを明示的に指定し、クエリに BigLake テーブルのみが含まれている場合、クエリはクロスクラウド クエリとして実行され、データ転送費用が発生します。
• クロスクラウド結合を使用して _FILE_NAME 疑似列に対してクエリを実行することはできません。
• WHERE 句で BigLake テーブルの列を参照する場合、NUMERIC、BIGNUMERIC、BYTES、TIME、INTERVAL リテラルは使用できません。
• クロスクラウド結合ジョブでは、他のクラウドから処理されて転送されたバイト数は報告されません。この情報は、クロスクラウド クエリ実行の一部として作成された子 CTAS ジョブで取得できます。
• BigQuery Omni テーブルまたはビューを参照する承認済みビューと承認済みルーティンは、BigQuery Omni リージョンでのみサポートされます。
• クロスクラウド クエリが STRUCT 列または JSON 列を参照している場合、リモート サブクエリにプッシュダウンは適用されません。パフォーマンスを最適化するには、BigQuery Omni リージョンで、STRUCT 列と JSON 列をフィルタし、必要なフィールドのみを個々の列として返すビューを作成することをご検討ください。
• クロスクラウド結合ではタイムトラベル クエリはサポートされていません。

クロスクラウド結合の例

次のクエリは、BigQuery リージョンの orders テーブルと BigQuery Omni リージョンの lineitem テーブルを結合します。

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

このクエリはローカル部分とリモート部分に分かれています。次のクエリは、BigQuery Omni リージョンに送信され、最初に実行されます。その結果、BigQuery リージョンに一時テーブルが作成されます。この子 CTAS ジョブとそのメタデータは、ジョブ履歴で確認できます。

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

一時テーブルが作成されると、JOIN オペレーションが完了し、次のクエリが実行されます。

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

別の例として、次のクロスクラウド結合について考えてみましょう。

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
  SELECT c_mktsegment, c_name
  FROM aws_dataset.customer
  WHERE c_mktsegment = 'FURNITURE'
  LIMIT 10;

このクエリでは、LIMIT 句は BigQuery Omni リージョンに push されません。FURNITURE マーケット セグメントのすべての顧客は、まず BigQuery リージョンに転送され、その後 10 の上限が適用されます。

コネクタ

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

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

BigQuery でサポートされているコネクタの詳細については、BigQuery コネクタをご覧ください。

オブジェクト ストア上の 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
  

  注意: 空の認証情報アクセス境界を使用すると、Dataproc クラスタから盗まれた認証情報による攻撃に対する保護のレイヤが 1 つ解除されます。盗まれた認証情報により、範囲が限定されず、エラーの影響範囲が大きくなります。

  代わりに、個人用クラスタ認証を無効にして、Dataproc 仮想マシン（VM）サービス アカウントをユーザー グループのプロキシとして使用することもできます。

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

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

  • Avro
  • CSV
  • Delta Lake
  • Iceberg
  • JSON
  • ORC
  • Parquet

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

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

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

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

セキュリティ モデル

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

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

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

注意: データ アナリストに次の権限を付与しないでください。

• Cloud Storage から直接オブジェクトを読み取ることができる権限（Storage オブジェクト閲覧者 IAM ロールを参照）。この権限により、データ アナリストは、データ ウェアハウス管理者が設定したアクセス制御を回避できます。

• テーブルを接続にバインドできる権限（BigQuery Connection 管理者など）。

  そうしないと、データ アナリストは、アクセス制御が存在しない新しいオブジェクトを作成して、データ ウェアハウス管理者が設定した制御を回避できてしまいます。

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

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

• Amazon S3 BigLake テーブル
• Cloud Storage BigLake テーブル

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

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

この機能を制御するプロパティが 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;

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

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

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

キャッシュが有効なテーブルのマテリアライズド ビュー

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

インテグレーション

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 予約内のスロットを代わりに使用します。

また、Cloud Storage、Amazon S3、Azure Blob Storage のストレージとデータアクセスに対しても、各プロダクトの料金ガイドラインに従って課金されます。

次のステップ

• 外部テーブルを BigLake テーブルにアップグレードする方法を確認する。
• Cloud Storage BigLake テーブルを作成する方法を学習する。
• Amazon S3 BigLake テーブルを作成する方法を学習する。
• Blob Storage BigLake テーブルを作成する方法を学習する。
• Dataplex でデータ品質タスクを作成する方法を確認する。