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

このドキュメントでは、オブジェクトテーブルについて説明します。オブジェクトテーブルは、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 のハッシュと ETag をご覧ください。
`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 モデル	TensorFlow、TensorFlow Lite、ONNX モデルを BigQuery ML にインポートして、BigQuery でローカル推論を実行します。	サポートされている制限に収まるオープンソースモデルまたはカスタムモデルを使用しています。	チュートリアル: 特徴ベクトルモデルを使用してオブジェクトテーブルで推論を実行する
Cloud Functions	Cloud 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-SignedHeaders=abcd |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-SignedHeaders=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 を使用して推論を行う場合、オブジェクトテーブルはいくつかのサイズと型の要件を満たす画像ファイルしか対象にできません。詳細については、制限事項をご覧ください。

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

キャッシュに保存されたメタデータを使用すると、オブジェクトテーブルに対する推論やその他のタイプの分析のパフォーマンスを向上できます。特に、オブジェクトテーブルが大量のオブジェクトを参照している場合に有効です。

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;

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

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

制限事項

オブジェクトテーブルは、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` 予約内のスロットを代わりに使用します。

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

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

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

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

ユースケース

利点

署名付き URL

アクセス制御

セキュリティ モデル

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

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