Apache Iceberg テーブル

BigQuery で管理される Apache Iceberg テーブル（以前の BigQuery 内の Apache Iceberg 用 BigLake テーブル）は、 Cloud de Confiance by S3NSでオープン形式のレイクハウスを構築するための基盤になります。マネージド Iceberg テーブルは、標準の BigQuery テーブルと同じフルマネージド エクスペリエンスを提供しますが、お客様所有のストレージ バケットにデータを保存します。マネージド Iceberg テーブルは、オープン Spark テーブル形式をサポートしているため、データの単一コピーでオープンソースとサードパーティのコンピューティング エンジンとの相互運用性が向上します。

マネージド Iceberg テーブルは、次の機能をサポートしています。

• テーブル ミューテーション: GoogleSQL データ操作言語（DML）を使用します。
• 統合されたバッチ処理と高スループット ストリーミング: Spark、Dataflow、その他のエンジンなどのコネクタを介して BigQuery Storage Write API を使用します。
• Apache Iceberg V2 スナップショットのエクスポートと自動更新。Spark などのオープンソースとサードパーティのクエリエンジンを使用して直接クエリにアクセスするための各テーブル ミューテーション。
• スキーマの進化: ニーズに合わせて列の追加、削除、名前の変更が可能です。この機能を使用すると、既存の列のデータ型の変更や、列モードの変更ができます。詳細については、型変換規則をご覧ください。
• ストレージの自動最適化: 適応型ファイルサイズ設定、自動クラスタリング、ガベージ コレクション、メタデータの最適化などが含まれます。
• BigQuery での過去のデータアクセス用のタイムトラベル。
• 列レベルのセキュリティとデータ マスキング。
• マルチステートメント トランザクション（プレビュー）。
• テーブルのパーティショニング（プレビュー）。
• Dataform ワークフローでのテーブル作成。

アーキテクチャ

マネージド Iceberg テーブルを使用すると、独自のクラウド バケットに存在するテーブルで、BigQuery リソース管理の利便性を享受できます。これらのテーブルでは、管理するバケットからデータを移動することなく、BigQuery とオープンソースのコンピューティング エンジンを使用できます。マネージド Iceberg テーブルの使用を開始する前に、Cloud Storage バケットを構成する必要があります。

マネージド Iceberg テーブルは、すべての Spark データの統合ランタイム カタログとして Lakehouse ランタイム カタログを使用します。Lakehouse ランタイム カタログは、複数のエンジンからのメタデータを管理するための信頼できる唯一の情報源を提供し、エンジンの相互運用を可能にします。

Apache Iceberg テーブルを使用すると、バケットに次のような影響があります。

• BigQuery は、書き込みリクエストやバックグラウンドのストレージ最適化（DML ステートメントやストリーミングなど）に応じて、バケットに新しいデータファイルを作成します。
• バケット内のデータファイルに対して自動圧縮とクラスタリングが実行されます。タイムトラベル ウィンドウの有効期限が切れると、データファイルはガベージ コレクションされます。ただし、テーブルが削除されても、関連付けられたデータファイルはガベージ コレクションされません。詳細については、ストレージの最適化をご覧ください。

Spark テーブルの作成は、BigQuery テーブルの作成と似ています。データをオープン形式で Cloud Storage に保存するため、次の操作を行う必要があります。

• WITH CONNECTION を使用して Cloud リソース接続を指定し、BigQuery が Cloud Storage にアクセスするための接続認証情報を構成します。
• file_format = PARQUET ステートメントを使用して、データ ストレージのファイル形式を PARQUET として指定します。
• table_format = ICEBERG ステートメントを使用して、オープンソースのメタデータ テーブル形式を ICEBERG として指定します。

ベスト プラクティス

BigQuery の外部でバケットのファイルを直接変更または追加すると、データ損失や回復不能エラーが発生する可能性があります。次の表に、考えられるシナリオを示します。

Cloud Storage バケットの構成に関するベスト プラクティス

Cloud Storage バケットの構成と BigQuery との接続は、マネージド Iceberg テーブルのパフォーマンス、費用、データの整合性、セキュリティ、ガバナンスに直接影響します。この構成に役立つベスト プラクティスは次のとおりです。

• バケットがマネージド Iceberg テーブル専用であることを明確に示す名前を選択します。

• BigQuery データセットと同じリージョンに配置されている単一リージョン Cloud Storage バケットを選択します。この調整により、データ転送料金を回避できるため、パフォーマンスが向上し、費用が削減されます。

• デフォルトでは、Cloud Storage はデータを Standard ストレージ クラスに保存します。このクラスは十分なパフォーマンスを提供します。データ ストレージ費用を最適化するには、Autoclass を有効にして、ストレージ クラスの移行を自動的に管理します。Autoclass は Standard Storage クラスから始まり、アクセスされないオブジェクトをよりコールドなクラスに移動して、ストレージ費用を削減します。オブジェクトが再度読み取られると、Standard クラスに戻ります。

• 均一なバケットレベルのアクセスと公開アクセスの防止を有効にします。

• 必要なロールが適切なユーザーとサービス アカウントに割り当てられていることを確認します。

• Cloud Storage バケット内の Spark データの誤った削除や破損を防ぐには、組織内のほとんどのユーザーの書き込み権限と削除権限を制限します。これを行うには、指定したユーザーを除くすべてのユーザーに対して PUT リクエストと DELETE リクエストを拒否する条件で、バケット権限ポリシーを設定します。

• 機密データをさらに保護するために、Google 管理または顧客管理の暗号鍵を適用します。

• 運用の透明性、トラブルシューティング、データアクセスのモニタリングのために、監査ロギングを有効にします。

• 誤って削除された場合に備えて、デフォルトの削除（復元可能）ポリシー（7 日間の保持）を維持します。ただし、Spark データが削除された場合は、オブジェクトを手動で復元するのではなく、サポートにお問い合わせください。BigQuery の外部で追加または変更されたオブジェクトは、BigQuery メタデータで追跡されません。

• 適応型ファイルサイズ設定、自動クラスタリング、ガベージ コレクションは自動的に有効になり、ファイル パフォーマンスと費用の最適化に役立ちます。

• マネージド Iceberg テーブルではサポートされていないため、次の Cloud Storage 機能は使用しないでください。

  • 階層型名前空間
  • オブジェクト アクセス制御リスト（ACL）
  • 顧客指定の暗号鍵
  • オブジェクトのバージョニング
  • オブジェクト ロック
  • バケットロック
  • BigQuery API または bq CLI を使用して削除済み（復元可能）オブジェクトを復元する

これらのベスト プラクティスを実装するには、次のコマンドを使用してバケットを作成します。

gcloud storage buckets create gs://BUCKET_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --enable-autoclass \
    --public-access-prevention \
    --uniform-bucket-level-access

次のように置き換えます。

• BUCKET_NAME: 新しいバケットの名前
• PROJECT_ID: オブジェクトの ID
• LOCATION: 新しいバケットのロケーション

Spark テーブルのワークフロー

次のセクションでは、マネージド テーブルの作成、読み込み、管理、クエリの方法について説明します。

始める前に

マネージド Iceberg テーブルを作成して使用する前に、ストレージ バケットへの Cloud リソース接続が設定されていることを確認してください。次の必要なロール セクションで指定されているように、接続にはストレージ バケットへの書き込み権限が必要です。接続に必要なロールと権限の詳細については、接続を管理するをご覧ください。

必要なロール

プロジェクト内のテーブルを BigQuery が管理できるようにするために必要な権限を取得するには、次の IAM ロールの付与を管理者に依頼してください。

• マネージド Iceberg テーブルを作成するには:
  • プロジェクトに対する BigQuery データオーナー（roles/bigquery.dataOwner）
  • プロジェクトに対する BigQuery Connection 管理者（roles/bigquery.connectionAdmin）
• マネージド Iceberg テーブルをクエリするには:
  • プロジェクトに対する BigQuery データ閲覧者（roles/bigquery.dataViewer）
  • プロジェクトに対する BigQuery ユーザー（roles/bigquery.user）
• Cloud Storage でのデータの読み取りと書き込みを接続サービス アカウントで行えるように、次のロールを付与します。
  • バケットに対するストレージ オブジェクト ユーザー（roles/storage.objectUser）
  • バケットに対する Storage レガシー バケット読み取り（roles/storage.legacyBucketReader）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、プロジェクト内のテーブルの BigQuery による管理を許可するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

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

マネージド Iceberg テーブルを作成する

Spark テーブルを作成するには、次のいずれかの方法を選択します。

CREATE TABLE [PROJECT_ID.]DATASET_ID.TABLE_NAME (
COLUMN DATA_TYPE[, ...]
)
CLUSTER BY CLUSTER_COLUMN_LIST
WITH CONNECTION {CONNECTION_NAME | DEFAULT}
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'STORAGE_URI');

bq --project_id=PROJECT_ID mk \
    --table \
    --file_format=PARQUET \
    --table_format=ICEBERG \
    --connection_id=CONNECTION_NAME \
    --storage_uri=STORAGE_URI \
    --schema=COLUMN_NAME:DATA_TYPE[, ...] \
    --clustering_fields=CLUSTER_COLUMN_LIST \
    DATASET_ID.MANAGED_TABLE_NAME

{
"tableReference": {
  "tableId": "TABLE_NAME"
},
"biglakeConfiguration": {
  "connectionId": "CONNECTION_NAME",
  "fileFormat": "PARQUET",
  "tableFormat": "ICEBERG",
  "storageUri": "STORAGE_URI"
},
"schema": {
  "fields": [
    {
      "name": "COLUMN_NAME",
      "type": "DATA_TYPE"
    }
    [, ...]
  ]
}
}

マネージド Iceberg テーブルにデータをインポートする

次のセクションでは、さまざまなテーブル形式からマネージド Iceberg テーブルにデータをインポートする方法について説明します。

フラット ファイルからのデータの標準読み込み

マネージド Iceberg テーブルは、BigQuery 読み込みジョブを使用して外部ファイルをマネージド Iceberg テーブルに読み込みます。既存の Spark テーブルがある場合は、bq load CLI ガイドまたは LOAD SQL ガイドに沿って外部データを読み込みます。データの読み込み後、新しい Parquet ファイルが STORAGE_URI/data フォルダに書き込まれます。

既存の Spark テーブルがない場合に前述の手順を行うと、代わりに BigQuery テーブルが作成されます。

マネージド テーブルへのバッチ読み込みの、ツール固有の例については、以下をご覧ください。

LOAD DATA INTO MANAGED_TABLE_NAME
FROM FILES (
uris=['STORAGE_URI'],
format='FILE_FORMAT');

bq load \
  --source_format=FILE_FORMAT \
  MANAGED_TABLE \
  STORAGE_URI

Apache Hive パーティション分割ファイルからの標準読み込み

標準の BigQuery 読み込みジョブを使用して、Apache Hive パーティション分割ファイルをマネージド Iceberg テーブルに読み込むことができます。詳細については、外部パーティション分割データの読み込みをご覧ください。

Pub/Sub からストリーミング データを読み込む

Pub/Sub BigQuery サブスクリプションを使用して、ストリーミング データをマネージド Iceberg テーブルに読み込むことができます。

マネージド Iceberg テーブルからデータをエクスポートする

次のセクションでは、マネージド Iceberg テーブルからさまざまなテーブル形式にデータをエクスポートする方法について説明します。

データをフラット形式にエクスポートする

Spark テーブルをフラット形式にエクスポートするには、EXPORT DATA ステートメントを使用してエクスポート先の形式を選択します。詳細については、データのエクスポートをご覧ください。

Spark テーブルのメタデータ スナップショットを作成する

Spark テーブルのメタデータ スナップショットを作成する手順は次のとおりです。

1. EXPORT TABLE METADATA SQL ステートメントを使用して、メタデータを Spark V2 形式にエクスポートします。

2. 省略可: Spark メタデータ スナップショットの更新をスケジュールします。設定された時間間隔で Spark メタデータ スナップショットを更新するには、スケジュールされたクエリを使用します。

3. 省略可: プロジェクトのメタデータの自動更新を有効にして、テーブル ミューテーションごとに Spark テーブルのメタデータ スナップショットを自動的に更新します。メタデータの自動更新を有効にするには、bigquery-tables-for-apache-iceberg-help@google.com にお問い合わせください。更新オペレーションごとに EXPORT METADATA 費用が適用されます。

次の例では、DDL ステートメント EXPORT TABLE METADATA FROM mydataset.test を使用して、My Scheduled Snapshot Refresh Query という名前のスケジュールされたクエリを作成します。DDL ステートメントは 24 時間ごとに実行されます。

bq query \
    --use_legacy_sql=false \
    --display_name='My Scheduled Snapshot Refresh Query' \
    --schedule='every 24 hours' \
    'EXPORT TABLE METADATA FROM mydataset.test'

Spark テーブルのメタデータ スナップショットを表示する

Spark テーブルのメタデータ スナップショットを更新すると、Spark テーブルが最初に作成された Cloud Storage URI でスナップショットを確認できます。/data フォルダには Parquet ファイルのデータシャードが含まれ、/metadata フォルダには Spark テーブルのメタデータ スナップショットが含まれます。

SELECT
  table_name,
  REGEXP_EXTRACT(ddl, r"storage_uri\s*=\s*\"([^\"]+)\"") AS storage_uri
FROM
  `mydataset`.INFORMATION_SCHEMA.TABLES;

mydataset と table_name は、実際のデータセットとテーブルのプレースホルダです。

Spark でマネージド Iceberg テーブルを読み取る

次のサンプルでは、Spark で Spark SQL を使用するように環境をセットアップしてから、クエリを実行して、指定された Spark テーブルからデータを取得します。

spark-sql \
  --packages org.apache.iceberg:iceberg-spark-runtime-ICEBERG_VERSION_NUMBER \
  --conf spark.sql.catalog.CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog \
  --conf spark.sql.catalog.CATALOG_NAME.type=hadoop \
  --conf spark.sql.catalog.CATALOG_NAME.warehouse='BUCKET_PATH' \

# Query the table
SELECT * FROM CATALOG_NAME.FOLDER_NAME;

次のように置き換えます。

• ICEBERG_VERSION_NUMBER: Spark ランタイムの現在のバージョン。Spark のリリースから最新バージョンをダウンロードしてください。
• CATALOG_NAME: Spark テーブルを参照するカタログ。
• BUCKET_PATH: テーブル ファイルを含むバケットへのパス。例: gs://mybucket/
• FOLDER_NAME: テーブル ファイルを含むフォルダ。例: myfolder

マネージド Iceberg テーブルを変更する

Spark テーブルを変更するには、テーブル スキーマの変更の手順に沿って操作します。

マルチステートメント トランザクションを使用する

マネージド Iceberg テーブルのマルチステートメント トランザクションを利用するには、登録フォームに必要事項を記入してお申し込みください。

パーティショニングを使用する

Apache Iceberg テーブルのパーティショニングを利用するには、登録フォームに必要事項を記入してお申し込みください。

テーブルを分割するには、テーブルの分割に使用するパーティション列を指定します。マネージド Iceberg テーブルでは、次の列型がサポートされています。

• DATE
• DATETIME
• TIMESTAMP

DATE、DATETIME、または TIMESTAMP 列でテーブルをパーティショニングすることを、時間単位列パーティショニングと呼びます。パーティションの粒度を時間単位、日単位、月単位、年単位のいずれにするかを選択します。

マネージド Iceberg テーブルは、クラスタリングとクラスタ化テーブルとパーティション分割テーブルの結合もサポートしています。

パーティショニングの制限事項

• BigQuery パーティション分割テーブルの制限事項がすべて適用されます。
• DATE、DATETIME、TIMESTAMP 以外のパーティショニング列の型はサポートされていません。
• パーティションの有効期限はサポートされていません。
• パーティションの進化はサポートされていません。

パーティション分割された Spark テーブルを作成する

パーティション分割された Spark テーブルを作成するには、標準の Spark テーブルを作成する手順に沿って、環境に応じて次のいずれかを含めます。

• PARTITION BY 句
• --time_partitioning_field フラグと --time_partitioning_type フラグ
• timePartitioning プロパティ

パーティション分割されたマネージド Iceberg テーブルを変更してクエリを実行する

パーティション分割されたマネージド Iceberg テーブルの BigQuery データ操作言語（DML）ステートメントとクエリは、標準の Spark テーブルと同じです。BigQuery は、Spark の非表示パーティショニングと同様に、ジョブを適切なパーティションに自動的にスコープします。また、テーブルに追加する新しいデータは自動的にパーティション分割されます。

パーティション分割されたマネージド Iceberg テーブルに対して、標準のマネージド Iceberg テーブルと同じように他のエンジンでクエリを実行することもできます。最適なエクスペリエンスを実現するため、メタデータ スナップショットを有効にすることをおすすめします。

セキュリティを強化するため、マネージド Iceberg テーブルのパーティショニング情報はデータパスから切り離され、メタデータ レイヤによって完全に管理されます。

料金

Spark テーブルの料金は、ストレージ、ストレージ最適化、クエリとジョブで構成されます。

ストレージ

マネージド Iceberg テーブルは、すべてのデータを Cloud Storage に保存します。保存されたすべてのデータ（過去のテーブルデータを含む）に対して課金されます。Cloud Storage のデータ処理と転送料金も適用される場合があります。BigQuery または BigQuery Storage API を介して処理されるオペレーションについては、一部の Cloud Storage オペレーション料金が免除される場合があります。BigQuery 固有のストレージ料金はありません。詳細については、Cloud Storage の料金をご覧ください。

ストレージ最適化

マネージド Iceberg テーブルは、クエリのパフォーマンスを最適化し、ストレージ費用を削減するために、圧縮、クラスタリング、ガベージ コレクション、BigQuery メタデータの生成/更新などのテーブルの自動管理を行います。テーブル管理のコンピューティング リソースの使用量は、秒単位で、Data Compute Unit（DCU）で課金されます。詳細については、Apache Iceberg テーブルの料金をご覧ください。

Storage Write API を介してストリーミング中に実行されるデータ エクスポート オペレーションは、Storage Write API の料金に含まれており、バックグラウンド メンテナンスとしては課金されません。詳細については、データの取り込みの料金をご覧ください。

これらのバックグラウンド オペレーションのログとコンピューティング使用状況を表示するには、INFORMATION_SCHEMA.JOBS ビューをクエリします。クエリの例については、以下をご覧ください。

• ストレージ最適化ジョブ
• EXPORT TABLE METADATA ジョブ

クエリとジョブ

BigQuery テーブルと同様に、BigQuery オンデマンド料金を使用する場合はクエリと読み取りバイト数（TiB 単位）、BigQuery 容量コンピューティングの料金を使用する場合はスロットの使用量（スロット時間単位）に基づいて課金されます。

BigQuery の料金は、BigQuery Storage Read API と Storage Write API にも適用されます。

読み込みオペレーションとエクスポート オペレーション（EXPORT METADATA など）は、Enterprise エディションの従量課金制スロットを使用します。BigQuery テーブルでは異なり、これらのオペレーションに対して料金が発生しません。Enterprise または Enterprise Plus のスロットによる PIPELINE 予約が使用できる場合、読み込みオペレーションとエクスポート オペレーションには、これらの予約スロットが優先的に使用されます。

制限事項

マネージド Iceberg テーブルには次の制限があります。

• マネージド Iceberg テーブルは、名前変更オペレーションや ALTER TABLE RENAME TO ステートメントをサポートしていません。
  • マネージド Iceberg テーブルは、テーブルのコピーや CREATE TABLE COPY ステートメントをサポートしていません。
    • マネージド Iceberg テーブルは、テーブル クローンや CREATE TABLE CLONE ステートメントをサポートしていません。
      • マネージド Iceberg テーブルは、テーブル スナップショットや CREATE SNAPSHOT TABLE ステートメントをサポートしていません。
        • マネージド Iceberg テーブルは、次のテーブル スキーマをサポートしていません。
• 空のスキーマ
  • BIGNUMERIC、INTERVAL、JSON、RANGE、GEOGRAPHY のデータ型のスキーマ。
  • フィールドの照合順序を含むスキーマ。
    • デフォルト値の式を含むスキーマ。
• マネージド Iceberg テーブルは、次のスキーマ進化のケースをサポートしていません。
  • NUMERIC から FLOAT への型強制変換
  • INT から FLOAT への型強制変換
  • SQL DDL ステートメントを使用した、新しいネストされたフィールドの既存の RECORD 列への追加
• マネージド Iceberg テーブルでは、コンソールまたは API でクエリが実行されると、ストレージ サイズが 0 バイトと表示されます。
• マネージド Iceberg テーブルはマテリアライズド ビューをサポートしていません。
• マネージド Iceberg テーブルは承認済みビューをサポートしていませんが、列レベルのアクセス制御はサポートしています。
• マネージド Iceberg テーブルは、変更データ キャプチャ（CDC）の更新をサポートしていません。
• マネージド Iceberg テーブルは、マネージド障害復旧をサポートしていません
• マネージド Iceberg テーブルは、行レベルのセキュリティをサポートしていません。
• マネージド Iceberg テーブルは、フェイルセーフ期間をサポートしていません。
• マネージド Iceberg テーブルは抽出ジョブをサポートしていません。
• INFORMATION_SCHEMA.TABLE_STORAGE ビューには、Spark テーブルは含まれません。
• マネージド Iceberg テーブルは、クエリ結果の宛先としてサポートされていません。代わりに、CREATE TABLE ステートメントを使用し、AS query_statement 引数を指定して、クエリ結果の宛先としてテーブルを作成できます。
• CREATE OR REPLACE は、標準テーブルの Apache Iceberg テーブルへの置き換え、またはマネージド Iceberg テーブルの標準テーブルへの置き換えをサポートしていません。
• バッチ読み込みと LOAD DATA ステートメントは、既存のマネージド Iceberg テーブルへのデータの追加のみをサポートします。
• バッチ読み込みと LOAD DATA ステートメントは、スキーマの更新をサポートしていません。
• TRUNCATE TABLE はマネージド Iceberg テーブルをサポートしていません。これに代わる方法が 2 つあります。
  • CREATE OR REPLACE TABLE（同じテーブル作成オプションを使用）。
  • WHERE 句 true での DELETE FROM テーブル
• APPENDS テーブル値関数（TVF）は、マネージド Iceberg テーブルをサポートしていません。
• Spark メタデータには、過去 90 分以内に Storage Write API によって BigQuery にストリーミングされたデータは含まれない場合があります。
• tabledata.list を使用したレコードベースのページ分割アクセスは、Apache Iceberg テーブルをサポートしていません。
• Spark テーブルごとに 1 つの同時変更 DML ステートメント（UPDATE、DELETE、MERGE）のみが実行されます。追加の変更 DML ステートメントはキューに入ります。