オブジェクト テーブルの概要

このドキュメントでは、オブジェクト テーブルについて説明します。オブジェクト テーブルは、Cloud Storage 内にある非構造化データ オブジェクトの読み取り専用テーブルです。

オブジェクト テーブルによって、Cloud Storage 内の非構造化データを分析できます。リモート関数で分析を行う、または BigQuery ML を使用して推論を実行して、これらのオペレーションの結果を BigQuery の残りの構造化データと結合できます。

BigLake テーブルと同様に、オブジェクト テーブルでもアクセス委任が使用されます。これにより、オブジェクト テーブルへのアクセスと Cloud Storage オブジェクトへのアクセスが切り離されます。Cloud Storage への接続にはサービス アカウントに関連付けられた外部接続が使用されるため、オブジェクト テーブルへのアクセス権をユーザーに付与するだけで済みます。これにより、行レベルのセキュリティを強化し、ユーザーがアクセスできるオブジェクトを管理できます。

オブジェクト テーブル スキーマ

オブジェクト テーブルは、指定された Cloud Storage バケット内の非構造化データ オブジェクトのメタデータ インデックスを提供します。テーブルの各行はオブジェクトに対応し、テーブルの列は Cloud Storage によって生成されたオブジェクト メタデータ(カスタム メタデータを含む)に対応しています。

また、オブジェクト テーブルには、ファイル コンテンツを RAW バイトで表す data 疑似列も含まれます。これは、オブジェクト テーブルの作成時に自動的に入力されます。この疑似列は、画像データの推論時に ML.DECODE_IMAGE 関数で使用されます。data 疑似列はクエリに含めることはできず、オブジェクト テーブル スキーマの一部としては表示されません。

次の表に、オブジェクト テーブルで使用される固定スキーマを示します。

フィールド名 モード 説明
uri STRING NULLABLE uri: オブジェクトの Uniform Resource Identifier(URI)(gs://bucket_name/[folder_name/]object_name 形式)。
generation INTEGER NULLABLE このオブジェクトの世代。これはオブジェクトのバージョンを識別します。
content_type STRING NULLABLE オブジェクト データの Content-Type。オブジェクトの種類を表します。Content-Type なしで格納されたオブジェクトは、application/octet-stream として提供されます。
size INTEGER NULLABLE データの Content-Length(バイト単位)。
md5_hash STRING NULLABLE データの MD5 ハッシュbase64 でエンコードされます。MD5 ハッシュの使用の詳細については、Cloud Storage オブジェクトのメタデータをご覧ください。
updated TIMESTAMP NULLABLE オブジェクトのメタデータが最後に変更された時刻。
metadata RECORD REPEATED オブジェクトのカスタム メタデータ。メタデータの各部分は、metadata フィールドの子 (metadata.)name フィールドと (metadata.)value フィールドで Key-Value ペアとして表されます。
(metadata.)name STRING NULLABLE 個々のメタデータ エントリをキーにします。
(metadata.)value STRING NULLABLE 個々のメタデータ エントリの値。

オブジェクト テーブルの行は次のようになります。

------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  |
-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              |
-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              |
-----------------------------------------------------------------------------------------------------------------------------------------------

ユースケース

オブジェクト テーブル内のメタデータは、他の BigQuery テーブルと同様にクエリできます。ただし、オブジェクト テーブルの主なユースケースは、分析のために非構造化データにアクセスできるようにすることです。BigQuery ML を使用して、TensorFlow、TensorFlow Lite、PyTorch モデルで画像オブジェクト テーブルの推論を実行できます。リモート関数を使用して、希望するほとんどの方法で非構造化データを分析することもできます。たとえば、Cloud Vision を使用して画像を分析できるリモート関数を作成したり、Apache Tika を使用して PDF ドキュメントからメタデータを抽出できる関数を作成したりできます。

次の表に、オブジェクト テーブルのデータに対して ML を実行するために使用できる統合ポイントを示します。

インテグレーション 説明 ユースケース チュートリアル
インポートされた BigQuery ML モデル TensorFlowTensorFlow LiteONNX モデルを BigQuery ML にインポートして、BigQuery でローカル推論を実行します。 サポートされている制限に収まるオープンソース モデルまたはカスタムモデルを使用しています。 チュートリアル: 特徴ベクトルモデルを使用してオブジェクト テーブルで推論を実行する
Cloud Run 関数 Cloud Run functions を使用して、サービスまたはホストされているモデルを呼び出します。これは最も一般的な統合です。 Compute Engine、Google Kubernetes Engine、またはその他のお客様所有のインフラストラクチャでモデルを自己ホストしている。
ML.ANNOTATE_IMAGE 関数 Cloud Vision API を使用して画像にアノテーションを付けます。 Vision API の事前トレーニング済みモデルを使用して、画像にアノテーションを付けます。 ML.ANNOTATE_IMAGE 関数を使用して画像にアノテーションを付ける
ML.PROCESS_DOCUMENT 関数 Document AI API を使用してドキュメントの分析情報を抽出します。 Document AI の事前トレーニング済みまたはカスタムのドキュメント プロセッサを使用します。 ML.PROCESS_DOCUMENT 関数を使用してドキュメントを処理する
ML.TRANSCRIBE 関数 Speech-to-Text API を使用して音声ファイルを文字変換します。 Speech-to-Text の事前トレーニング済みまたはカスタムの音声認識機能を使用します。 ML.TRANSCRIBE 関数を使用して音声ファイルを文字変換する

分析結果を他の構造化データと結合する場合は、分析結果からビューやテーブルを作成できます。たとえば、次のステートメントは推論結果に基づいてテーブルを作成します。

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

テーブルが作成されたら、次に示すように、標準またはカスタムのメタデータ フィールドに基づいて、他のテーブルと結合できます。

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

検索インデックスを作成して、分析結果の検索を強化することもできます。たとえば、次のステートメントは PDF ファイルから抽出したデータの検索インデックスを作成します。

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

このインデックスを使用して、結果から必要なものを見つけることができます。

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

利点

BigQuery で非構造化データをネイティブに分析すると、次の利点があります。

  • モデル要件に合わせた画像サイズの調整などの前処理手順を自動化できるため、手作業が削減されます。
  • シンプルで使い慣れた SQL インターフェースを使用して非構造化データを操作できます。
  • 新しい形式のコンピューティングをプロビジョニングするのではなく、既存の BigQuery スロットを利用することで、費用を削減できます。

署名付き URL

オブジェクトによって表されるデータにアクセスするには、署名付き URL を生成します。署名付き URL を使用してオブジェクト データを直接表示できます。また、署名付き URL をリモート関数に渡して、オブジェクト テーブルデータを処理できるようにすることもできます。

署名付き URL を生成するには、次の例のように EXTERNAL_OBJECT_TRANSFORM 関数を使用します。

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE `mydataset.myobjecttable`, ['SIGNED_URL']);

これにより、次のような結果が返されます。

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
--------------------------------------------------------------------------------------------------

オブジェクト テーブルから生成された署名付き URL を使用すると、その URL を所有しているユーザーまたはプロシージャは、対応するオブジェクトを読み取ることができます。生成された署名付き URL は 6 時間後に期限切れになります。詳細については、Cloud Storage の署名付き URL をご覧ください。

アクセス制御

オブジェクト テーブルは BigLake の上に構築されているため、サービス アカウントに基づく外部接続を使用して Cloud Storage データにアクセスします。これにより、アクセス権の委任によって、テーブルへのアクセス権が、基礎となるオブジェクト ストアへのアクセス権から切り離されます。サービス アカウントに、オブジェクトのデータとメタデータにアクセスし、テーブルに表示する権限を付与します。ユーザーにはテーブルに対してのみ権限を付与できます。このテーブルでは、Identity and Access Management(IAM)と行レベルのセキュリティを使用してデータアクセスを管理できます。

オブジェクト テーブルは、アクセスの委任を使用するほかのテーブルとは異なります。オブジェクト テーブルの行へのアクセス権があると、元のファイル コンテンツへのアクセス権が付与されます。ユーザーはオブジェクトに直接アクセスすることはできませんが、ファイルの内容を確認できる署名付き URL を生成できます。たとえば、ユーザーが flower.jpg 画像ファイルを表すオブジェクト テーブルの行にアクセスできる場合、署名付き URL を生成してファイルを表示でき、それがデイジーの画像だと確認できます。

オブジェクト テーブルに行レベルのアクセス ポリシーを設定すると、ユーザーまたはグループの、選択した行のオブジェクト メタデータと、それらの行で表されるオブジェクトに対するアクセスが制限されます。たとえば、次のステートメントでは、ユーザー Alice に、2022 年 6 月 25 日より前に作成されたオブジェクトを表す行のみに対するアクセス権を付与します。

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

この行レベルのアクセス ポリシーを設定すると、Alice は次の結果になります。

  • SELECT * FROM my_dataset.my_object_table; クエリを実行すると、2022 年 6 月 25 日より前の updated 値を持つ行のみが返されます。
  • my_dataset.my_object_table で推論を実行すると、2022 年 6 月 25 日より前の updated 値を持つオブジェクトの予測のみが返されます。
  • my_dataset.my_object_table の署名付き URL を生成すると、2022 年 6 月 25 日より前に updated 値を持つオブジェクトの URL のみが作成されます。

カスタム メタデータを使用して、オブジェクト テーブルの行へのアクセスを制限することもできます。たとえば、次のステートメントは、オブジェクトに個人情報が含まれていないとタグ付けされている行のみにアクセスするように、users グループを制限します。

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

セキュリティ モデル

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

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

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

サポートされているオブジェクト ファイル

任意のタイプとサイズの非構造化データファイルのオブジェクト テーブルを作成できます。また、リモート関数を作成して、あらゆるタイプの非構造化データを処理できます。ただし、BigQuery ML を使用して推論を行う場合、オブジェクト テーブルはいくつかのサイズと型の要件を満たす画像ファイルしか対象にできません。詳細については、制限事項をご覧ください。

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

キャッシュに保存されたメタデータを使用すると、オブジェクト テーブルに対する推論やその他のタイプの分析のパフォーマンスを向上できます。メタデータ キャッシュは、オブジェクト テーブルが大量のオブジェクトを参照している場合に特に有効です。メタデータには、ファイル名、パーティショニング情報、ファイルの物理的なメタデータ(行数など)が含まれます。テーブルでメタデータのキャッシュ保存を有効にするかどうかを選択できます。多数のファイルと Hive パーティション フィルタを使用したクエリは、メタデータのキャッシュから最大限のメリットを得られます。

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

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

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

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

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

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

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

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

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

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

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

  • テーブルのメタデータ キャッシュを手動で更新していて、未更新間隔を 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;

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

メタデータのキャッシュ オプションの設定の詳細については、オブジェクト テーブルを作成するをご覧ください。

制限事項

  • オブジェクト テーブルは、Cloud Storage 内の非構造化データ オブジェクトにマッピングされるため、読み取り専用です。オブジェクト テーブルやオブジェクト テーブルのデータは変更できません。
  • レガシー SQL や、AWS や Microsoft Azure などの他のクラウド環境では、オブジェクト テーブルはサポートされていません。
  • BigQuery ML を使用して推論を実行する場合は、使用するモデルとオブジェクト テーブルが制限事項で説明されている要件を満たしている必要があります。
  • オブジェクト テーブルを含むクエリで、10 GB を超えるオブジェクト メタデータにアクセスすることはできません。たとえば、クエリがオブジェクト テーブルのメタデータ列と署名付き URL を介してオブジェクト データの組み合わせから 100 TB にアクセスする場合、その 100 TB のうちメタデータ列から取得できるのは 10 GB のみです。
  • オブジェクト テーブルには、他のすべての BigQuery 外部テーブルと同じ制限事項が適用されます。詳細については、割り当てをご覧ください。
  • オブジェクト テーブルに対するクエリには、他のすべての BigQuery クエリと同じ制限が適用されます。詳細については、割り当てをご覧ください。
  • オブジェクト テーブルの非構造化データを処理するリモート関数には、他のすべてのリモート関数と同じ制限が適用されます。
  • オブジェクト テーブル内のオブジェクトに対して生成された署名付き URL は、クエリ実行時間の上限である 6 時間後に期限切れになります。
  • BigQuery ML による推論は、オンデマンド料金または Standard エディションではサポートされていません。
  • 次の関数は、オンデマンド料金または Standard エディションではサポートされていません。

費用

費用は、オブジェクト テーブルの次の要素に関連して発生します。

スロット予約がある場合、外部テーブルのクエリに対しては課金されません。代わりに、スロットがこれらのクエリで消費されます。

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


オンデマンド料金

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

クエリ

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

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

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

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

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

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

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

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

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

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

Analytics Hub でのオブジェクト テーブルの使用

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

次のステップ