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

パイプラインの構成

ワークスペース UI で、ソースコード、ターゲットカタログとスキーマ、コンピュート、パイプラインモードなど、パイプラインの基本設定を構成します。

このページでの構成手順では、Unity Catalogを使用します。レガシーHive metastoreでパイプラインを構成する手順については、レガシーHive metastoreでLakeFlow Pipelinesを使用するを参照してください。

このページでは、パイプラインの現在のデフォルトの公開モードの機能について説明します。2025 年 2 月 5 日より前に作成されたパイプラインでは、従来の公開モードとLIVE仮想スキーマが使用される可能性があります。LIVE スキーマ (レガシー)を参照してください。

注記

UI には、JSON で設定を表示および編集するオプションがあります。ほとんどの設定は、UI または JSON 仕様を使用して構成できます。一部の詳細オプションは、JSON 構成でのみ使用できます。

JSON 構成ファイルは、パイプラインを新しい環境にデプロイする場合や、CLI またはREST APIを使用する場合にも役立ちます。

パイプラインJSON構成設定の完全なリファレンスについては、 「パイプライン構成」を参照してください。

パイプライン設定​

パイプライン設定は2つのカテゴリに分類されます。

  • ソース コード ：パイプライン構文を使用してデータセットを宣言するファイルのコレクション。「ソースコードの設定」を参照してください。
  • インフラストラクチャ：コンピュート、更新の処理方法、テーブルの保存場所を制御する設定。

ほとんどの設定では妥当なデフォルト値が用意されていますが、本番運用する前に2点注意が必要です。

  • ターゲットカタログとスキーマ ：パイプラインの外部でデータを利用できるようにするには、ターゲットカタログとスキーマを宣言する必要があります。データはUnity Catalogにデフォルトで公開されます。ターゲット カタログとスキーマを設定するを参照してください。
  • データアクセス ：実行に使用されるコンピュートには、データソースと、指定されている場合はストレージの場所に、アクセス許可が構成されている必要があります。

新しいパイプラインを構成する​

新しいパイプラインを構成するには、次の手順を実行します。

  1. サイドバーの上部にあるプラスアイコン。 新規 を選択し、パイプラインアイコン。 ETL パイプライン 。

  2. 上部に、パイプラインに一意の名前を付けます。

  3. 名前の下に、選択されたデフォルトのカタログとスキーマが表示されます。これらを変更して、パイプラインに異なるデフォルトを設定します。

    デフォルトのカタログとデフォルトのスキーマは、コード内でカタログまたはスキーマを使用してデータセットを修飾していない場合に、データセットの読み取りまたは書き込みが行われる場所です。詳細については、 Databricksのデータベース オブジェクト」を参照してください。

  4. パイプラインを作成するには、希望するオプションを選択します。

    • SQL のサンプル コードから開始して、 SQL のサンプル コードを含む新しいパイプラインとフォルダー構造を作成します。
    • Python のサンプル コードから始めて、 Python のサンプル コードを含む新しいパイプラインとフォルダー構造を作成します。
    • 単一の変換から始めて、 新しい空のコード ファイルを使用して、新しいパイプラインとフォルダー構造を作成します。
    • 既存のアセットを追加して 、ワークスペース内の既存のコード ファイルに関連付けることができるパイプラインを作成します。
    • 新しい宣言型自動化バンドルプロジェクトを使用してパイプラインを作成するか、既存のバンドルにパイプラインを追加するには 、ソース管理されたプロジェクトを作成します 。

    ETL パイプラインには、SQL と Python の両方のソース コード ファイルを含めることができます。新しいパイプラインを作成し、サンプル コードの言語を選択すると、その言語はデフォルトでパイプラインに含まれるサンプル コードのみに適用されます。

  5. 選択すると、新しく作成されたパイプラインにリダイレクトされます。

    ETL パイプラインは、次のデフォルト設定で作成されます。

    この構成は、開発やテストなどの多くのユースケースに推奨されており、スケジュールに従って実行する必要がある本番運用ワークロードに適しています。 パイプラインのスケジュール設定の詳細については、 「ジョブのパイプライン タスク」を参照してください。

    これらの設定はパイプライン ツールバーから調整できます。

あるいは、ワークスペース ブラウザから ETL パイプラインを作成することもできます。

  1. 左側のペインで 「ワークスペース」 をクリックします。
  2. Git フォルダーを含む任意のフォルダーを選択します。
  3. 右上隅の [作成] をクリックし、 [ETL パイプライン] をクリックします。

[ジョブとパイプライン] ページからETLパイプラインを作成することもできます。

  1. ワークスペースで、サイドバーの ワークフロー アイコン。 ジョブ & パイプライン をクリックします。
  2. [新規] の下で、 [ETL パイプライン] をクリックします。

コンピュート構成オプション​

Databricksでは常に 強化 オートスケール を使用することをお勧めします。 他のコンピュート構成のデフォルト値は、多くのパイプラインで適切に機能します。

コンピュート構成をカスタマイズするには、次の設定を使用します。

  • ワークスペース管理者は、 クラスターポリシー を構成できます。 コンピュート ポリシー 管理者は、ユーザーが使用できるコンピュート オプションを制御できます。 コンピュートポリシーの選択を参照してください。

  • オプションで、 クラスターモード を 固定サイズ または レガシー オートスケール で実行するように構成できます。オートスケールを使用したLakeFlow Pipelines クラスター利用率の最適化を参照してください。

  • オートスケールが有効になっているワークロードの場合、 最小ワーカー と 最大ワーカー を設定して、スケーリング動作の制限を設定します。 「パイプライン用のクラシック コンピュートの構成」を参照してください。

  • オプションでPhotonアクセラレーションをオフにすることができます。 Photonとはを参照してください。

  • クラスタータグを 使用すると、パイプラインに関連するコストを監視できます。 「コンピュート タグの構成」を参照してください。

  • インスタンスタイプ を設定して、パイプラインの実行に使用する仮想マシンのタイプを指定します。パイプラインを実行するためのインスタンスタイプを選択するを参照してください。

    • パイプラインで構成されたワークロードに最適化された ワーカー タイプ を選択します。
    • オプションで、ワーカー タイプとは異なる ドライバー タイプ を選択することもできます。 これは、大規模なワーカー タイプと低いドライバー コンピュート使用率を使用するパイプラインのコストを削減したり、多数の小規模なワーカーを含むワークロードでのメモリ不足の問題を回避するためにより大きなドライバー タイプを選択したりする場合に役立ちます。

実行ユーザーを設定する​

実行ユーザーを使用すると、パイプラインが実行に使用するIDと、パイプラインが作成または更新するテーブルの所有権を変更できます。これは、パイプラインを作成した元のユーザーが非アクティブ化された場合（たとえば、会社を辞めた場合）に役立ちます。このような場合、パイプラインが機能しなくなり、パブリッシュされたテーブルが他のユーザーがアクセスできなくなる可能性があります。パイプラインをサービスプリンシパルなどの別の ID として実行するように更新し、パブリッシュされたテーブルの所有権を再割り当てすることによって、アクセスを復元し、パイプラインが引き続き機能するようにすることができます。サービスプリンシパルとして実行されるパイプラインは、個々のユーザーに縛られず、自動化されたワークロードに対してより安全で、安定し、信頼性が高まるため、ベストプラクティスと見なされます。

必要な権限​

変更を行うユーザーの場合:

  • パイプラインに対する CAN_MANAGE 権限
  • サービスプリンシパルの CAN_USE ロール (実行-as をサービスプリンシパルに設定する場合)
  • グループへのメンバーシップ、またはグループに対する Assume 権限（run-as をグループに設定する場合）。「グループをラン-as IDとして設定する」を参照してください。

実行者ユーザー、Service Principal、またはグループの場合:

  • ワークスペース アクセス:

    • ワークスペース内で操作するためのワークスペースアクセス 権限
    • パイプラインで使用するクラスターポリシーの権限 を使用できます
    • ワークスペースでのコンピュート作成許可

  • ソースコードアクセス:

    • パイプラインのソースコードに含まれるすべてのノートブックの 読み取り権限を持つ
    • パイプラインがワークスペースファイルを使用する場合、そのファイルに対する 読み取り権限を持つ

  • Unity Catalog権限 ( Unity Catalogを使用するパイプラインの場合):

    • USE CATALOG 対象カタログ
    • USE SCHEMA ターゲットスキーマのCREATE TABLE
    • MODIFY パイプラインが更新する既存のテーブルに対する権限
    • CREATE SCHEMA パイプラインが新しいスキーマを作成する場合の権限

  • レガシーHive metastoreアクセス許可 ( Hive metastoreを使用するパイプラインの場合):

    • SELECT およびターゲットデータベースとテーブルに対するMODIFY権限

  • 追加のクラウド ストレージ アクセス (該当する場合):

    • ソースストレージの場所から読み取る権限
    • ターゲットストレージの場所への書き込み権限

実行ユーザーの設定方法​

run-asユーザーは、パイプライン モニタリング ページまたはパイプライン エディターのパイプライン設定を通じて設定できます。 パイプラインモニタリングページからユーザーを変更するには:

  1. [ジョブとパイプライン] をクリックしてパイプラインのリストを開き、編集するパイプラインの名前を選択します。

  2. パイプラインモニタリングページで、 設定 をクリックします。

  3. パイプライン設定 サイドバーで、 鉛筆アイコン。 [実行者として] の横にある[編集] をクリックします。

  4. 編集ウィジェットで、次のいずれかのオプションを選択します。

    • あなた自身のユーザーアカウント
    • CAN_USE 権限を持つサービスプリンシパル
    • メンバーである、または Assume 権限を持っているアカウントグループ。「ラン実行者 ID をグループに設定する」を参照してください。

  5. 変更を適用するには、 「保存」 をクリックします。

実行ユーザーを正常に更新すると、次のようになります。

  • 今後のすべてのランにおいて、パイプライン ID が新しいユーザー、Service Principal、またはグループを使用するように変更されます。
  • Unity Catalogパイプラインでは、パイプラインによって公開されたテーブルの所有者が、新しい実行-as ID に一致するように更新されます。
  • 今後のパイプラインの更新では、新しい実行-as ID の権限と認証情報が使用されます。
  • 他の設定変更と同様に、新しいIDは次回のパイプライン更新に適用されます。継続的なパイプラインは新しいIDで自動的に再起動し、トリガーされたパイプラインは次回の実行時に適用されます。実行者変更は、アクティブな更新を中断する可能性があります。構成変更が有効になる仕組みを参照してください。
注記

実行-as の更新が失敗した場合、失敗の理由を説明するエラー メッセージが表示されます。 一般的な問題には、サービスプリンシパルに対する権限が不十分であることが含まれます。

グループをラン実行 ID に設定する​

パイプラインの 「ラン対象」 ID にアカウントグループを設定することは、ユーザーまたは Service Principal を設定する場合と同様に機能します。パイプラインの更新はグループの権限で実行され、Unity Catalog パイプラインでは、パイプラインが発行するテーブルはグループによって所有されます。自動化されたパイプラインを1人のユーザーのアカウントに結び付けるのではなく、チームに所有させたい場合はグループを使用します。これにより、チームのメンバーシップが変更されてもパイプラインが機能し続けます。

Databricksでは、ロールはグループとして実装されているため、 Run as がグループに設定されているパイプラインは、そのロールとして実行されます。役割ベースのアクセス制御（RBAC）を参照してください。

Run as にグループを設定しても、パイプラインの所有者は変わりません。所有権とラン実行者 ID は別の設定です。所有者を変更するには、パイプラインの所有者の変更を参照してください。

実行者 (ラン as) にグループを設定するには、次のいずれかを行う必要があります:

グループは、ワークスペースに割り当てられているアカウントグループである必要があります。ワークスペースローカルグループをランIDとして使用することはできません。また、大規模な組み込みグループである admins、users、および account users も使用できません。

必要な権限に記載されているように、パイプラインに必要なすべての権限をグループに付与します。更新はグループとして実行されるため、パイプラインのソースコードとデータへのアクセスを自分自身に付与するだけでは十分ではありません。

ワークスペース UI で ラン者 をグループに設定するには、ラン者ユーザーの設定方法の手順に従い、編集ウィジェットでグループを検索します。グループは、ユーザーやService Principalとともに表示されます。変更を確認するには、 パイプライン設定 のサイドバーを再度開き、 ランとして にグループが表示されていることを確認します。

REST API を使用してグループを実行者 (run-as) ID として設定するには、run_as.group_name にグループ名を設定します。グループとして実行されるパイプラインを作成するには、次をランします:

JSON
{
  "name": "sales-etl",
  "run_as": {
    "group_name": "Test Group"
  }
}

完全なリクエストについては、パイプラインの作成を参照してください。既存のパイプライン定義を更新する場合は、代わりに updated_run_as.group_name を設定してください。

Declarative Automation Bundles バンドルでグループをラン実行者 ID として設定するには、パイプラインリソースの run_as マッピングで group_name を設定します。

YAML
resources:
  pipelines:
    sales_etl:
      name: sales-etl
      run_as:
        group_name: Test Group

SET OWNER TO SQLステートメントでは、マテリアライズドビューまたはストリーミングテーブルの所有者としてグループを設定することはできません。ワークスペースUIを使用します。「ALTERステートメントをパイプラインデータセットで使用する」を参照してください。

ジョブは同じランとしてグループの構成をサポートしています。「ランをグループとして設定する」を参照してください。

その他の構成上の考慮事項​

パイプラインでは次の構成オプションも使用できます。

パイプラインモードを設定してください​

パイプラインモード 設定は、パイプラインがデータを処理する方法を制御します:

  • Trigger がdefaultです。パイプラインは、更新開始時に利用可能なデータですべてのテーブルを更新した後に停止するため、コンピュートは更新期間中のみ実行されます。Triggerされたパイプラインをオンデマンドまたはスケジュールでランします。ジョブのパイプラインタスクを参照してください。
  • 連続 実行は、ソースに新しいデータが到着するたびに処理を行うことで、テーブルを最新の状態に保ちます。これにより、新しいデータから更新された結果までの遅延が短縮されますが、常時稼働中のクラスターが必要となります。低レイテンシの要件が明確な場合にのみ、連続モードを選択してください。

モードを設定するには、パイプラインを作成または編集する際のパイプライン 設定内のパイプラインモード オプションを使ってください。2つのモードの完全な比較と選択のガイダンスについては、「 トリガー付きモード」と「連続パイプラインモード」を参照してください。

構成変更が有効になる方法​

パイプラインの設定を編集して保存すると、その変更は次回のパイプライン更新時に適用されます。継続的なジョブがパイプラインをオーケストレーションする場合、更新された設定を有効にするためにジョブを再起動する必要はありません。ジョブは次回の更新時にそれらを適用します。実行モードを決定するのはジョブのスケジュールであり、パイプラインの パイプライン モード 設定ではありません。継続的なジョブによる継続的なパイプラインのランを参照してください。

継続的なジョブの代わりにパイプラインの組み込みの パイプライン モード 設定を使用する場合：

  • 継続的なパイプラインは、更新された構成で自動的に再開されます。これはアクティブな更新を中断する可能性があります。
  • タイプを Triggerから連続に変更すると、更新された設定で新しい更新が自動的に起動します。逆に、タイプを連続からTriggerに変更すると、アクティブな更新がキャンセルされます。

製品エディションを選択してください​

パイプラインの要件に最適な機能を備えた製品エディションを選択してください。利用可能な製品エディションは次のとおりです。

  • Core ストリーミング取り込みワークロードを実行します。パイプラインがチェンジデータキャプチャ (CDC) やエクスペクテーションなどの高度な機能を必要としない場合は、Coreエディションを選択します。
  • Pro ストリーミング取り込みと CDC ワークロードを実行します。Pro製品エディションは、 Coreのすべての機能をサポートするほか、ソース データの変更に基づいてテーブルを更新する必要があるワークロードもサポートします。
  • Advanced ストリーミング取り込みワークロード、CDC ワークロード、およびエクスペクテーションが必要なワークロードを実行します。Advanced 製品エディションは、Core エディションと Pro エディションの機能をサポートし、エクスペクテーションに対するデータ品質制約が含まれています。

パイプラインを作成または編集する際に、製品エディションを選択できます。パイプラインごとに異なるエディションを選択できます。エディション別のより包括的な機能の内訳を含め、詳細については、Databricks上のApache Spark™宣言型パイプライン製品ページをご覧ください。

パイプラインは、パイプライン UI と Pipelines API で過去 60 日間の更新を保持します。

アクティブな（非終了状態の）更新は常に表示されます。更新が保持期間を超過している場合、Databricksはそれをリスト応答から除外しますが、基になるイベントログには保持されます。

注: パイプラインに、期待値など、選択した製品エディションでサポートされていない機能が含まれている場合は、エラーの理由を説明するエラー メッセージが表示されます。その後、パイプラインを編集して適切なエディションを選択できます。

ソースコードを構成する​

Lakeflow Pipelines Editor のアセットブラウザを使用して、パイプラインを定義するソースコードを設定できます。 パイプラインのソース コードは、ワークスペース ファイルに保存されている SQL または Python スクリプトで定義されます。パイプラインを作成または編集するときに、1 つ以上のファイルを追加できます。デフォルトでは、パイプラインのソース コードは、パイプラインのルート フォルダー内のtransformationsフォルダーにあります。

パイプラインはデータセットの依存関係を自動的に分析して処理グラフを構築するため、ソースコードアセットを任意の順序で追加できます。

Lakeflow Pipelinesエディターの使用の詳細については、 「 Lakeflow Pipelinesエディターを使用したETLパイプラインの開発とデバッグ」を参照してください。

Python を使用するパイプラインの外部依存関係を管理する​

パイプラインの外部依存関係 ( Pythonパッケージやライブラリなど) を使用したパイプラインのサポート。 依存関係の使用に関するオプションと推奨事項については、 「パイプラインの Python 依存関係の管理」を参照してください。

Databricksワークスペースに保存されているPythonモジュールを使用する​

パイプラインのソース コード ファイルに Python コードを実装するだけでなく、Databricks Git フォルダーまたはワークスペース ファイルを使用して、コードを Python モジュールとして保存することもできます。コードをPythonモジュールとして保存することは、同じパイプライン内の複数のパイプラインまたはノートブックで使用したい共通の機能がある場合に特に便利です。 パイプラインで Python モジュールを使用する方法については、 「Git フォルダーまたはワークスペース ファイルから Python モジュールをインポートする」を参照してください。

このページの見出し