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

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

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

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

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

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

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

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

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

------------------------------------------------------------------------------------------------------------------------------------------------
|  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 ドキュメントからメタデータを抽出できる関数を作成したりできます。

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

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

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 エディションではサポートされていません。

  • ML.CONVERT_COLOR_SPACE
  • ML.CONVERT_IMAGE_TYPE
  • ML.RESIZE_IMAGE

費用

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

• テーブルに対するクエリの実行
• メタデータ キャッシュの更新。

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

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

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

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

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

次のステップ

• オブジェクト テーブルを作成する方法を学習する。
• 画像オブジェクト テーブルで推論を実行する方法を確認する。
• リモート関数を使用してオブジェクト テーブルを分析する方法を学習する。