メインコンテンツまでスキップ
に最終更新

Zerobus Ingest の機能

このページでは、 Lakeflow Connectにおける Zerobus Ingest の概要について説明します。各機能から、その完全なドキュメントにリンクしています。

常時稼働Endpoint​

Zerobus Ingestは、サポートされているリージョン内のワークスペースに対してdefaultで有効になっているServerless Endpointです。起動、プロビジョニング、またはスケールするものは何もありません。ターゲットテーブルと許可されたIDがあれば、データのプッシュを開始でき、容量は自動的にスケーリングされます。起動方法については、 Zerobus Ingestの使用を参照してください。

認証方法​

すべてのZerobusクライアントは、有効期間の短いDatabricks OAuthトークンで認証します。SDKを使用すると、SDKがトークンを取得して更新します。REST APIなどの他のインターフェースでは、トークンを自分で取得し、リクエストに含めます。セットアップステップとコードについては、認証の構成を参照してください。

Service Principalによる OAuth (default)​

Databricks Service PrincipalのクライアントIDとシークレットで認証します。これはdefaultの方法です。Databricks管理のシークレットを保持できるワークロードに適しています。

外部IDプロバイダーによるフェデレーション​

Databricksシークレットの代わりに、Microsoft Entra IDなどの独自の ID プロバイダーのトークンで認証します。ID プロバイダー トークンは、RFC 8693 トークン交換を使用してZerobusスコープのDatabricksトークンと交換されるため、長期間有効なDatabricksシークレットはクライアントに保存されません。

フェデレーションでは、2 つのIDモデルがサポートされています。

  • アカウントレベルのフェデレーション : Databricks Service Principalはありません。IDプロバイダーからのIDは自動ID管理を通じてDatabricksアカウントに同期され、クライアントはそのIDとして認証されます。これには、プロバイダーを信頼できる発行者として登録するアカウント フェデレーション ポリシーが必要です。
  • Workload ID フェデレーション : クライアント ID を持ち、シークレットを持たない Databricks Service Principal と、フェデレーション ポリシーを使用します。

これらのページではMicrosoft Entra IDを例として使用していますが、同じフェデレーションフローは、他のOpenID Connect（OIDC）互換のIDプロバイダーでも機能します。

認証方法の比較​

手法

Databricks Service Principal

Databricksクライアントシークレット

使用する場合

OAuth Service Principal

はい

はい

クライアントは、Databricks管理のシークレットを保持できます。

アカウントレベルのフェデレーション

No

No

IDはプロバイダー内でのみ管理され、Databricks Service Principalまたはシークレットは使用されません。

Workload IDフェデレーション

はい、シークレットなし

No

シークレットを保存せずにDatabricks Service Principal IDが必要です。

手法

Databricks Service Principal

Databricksクライアントシークレット

使用する場合

OAuth Service Principal

はい

はい

クライアントは、Databricks管理のシークレットを保持できます。

アカウントレベルのフェデレーション

No

No

IDはプロバイダー内でのみ管理され、Databricks Service Principalまたはシークレットは使用されません。

Workload IDフェデレーション

はい、シークレットなし

No

シークレットを保存せずにDatabricks Service Principal IDが必要です。

注記

SDKでの自動トークン交換は、Python SDK 1.10.0以降およびRust SDK 2.11.0以降で利用できます。セットアップのステップとコードについては、「認証の構成」を参照してください。

Delta テーブル機能​

Zerobus Ingest は標準の Unity Catalog マネージド Delta テーブルに書き込むため、取り込まれたデータは Delta テーブルの機能と連携します。ターゲットテーブルが満たすべき要件については、「テーブルの要件」を参照してください。

  • パーティション分割されたテーブル : サポートされていますが、パーティションのファンアウト制限が適用されます。Databricks では、カーディナリティの高いキーに対してリキッドクラスタリングを推奨しています。パーティション分割されたテーブルを参照してください。
  • リキッドクラスタリングテーブル ：パーティションのファンアウト制限なしでクエリーパフォーマンス向けにデータを整理する推奨Layoutです。テーブルにリキッドクラスタリングを使用するを参照してください。
  • バリアントデータ : 半構造化データをVARIANTカラムに取り込みます。サポートされているデータ型を参照してください。

永続的なfallbackロケーション​

Zerobus Ingest がデータを耐久性のある状態にした後、テーブルへの公開が行われる前にテーブルの破壊的な変更が発生した場合、Zerobus Ingest はデータを破棄するのではなく、テーブルのストレージ・ロケーション内の fallback ディレクトリに Parquet ファイルとして書き込みます。スキーマを修正した後にこのデータを検索して再処理するには、耐久性のある fallback ロケーションからのデータ復旧を参照してください。

使用状況のモニタリング​

システムテーブルを使用して、Zerobus Ingest の使用状況と利用料金を監視します。Zerobus Ingest システムテーブル リファレンスを参照してください。また、利用料金については、コスト配下の課金システムテーブルを参照してください。

このページの見出し