パイプラインを構成する

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

Databricks では、サーバーレスを使用して新しいパイプラインを開発することをお勧めします。 サーバーレス パイプラインの構成手順については、「 サーバーレス パイプラインの構成」を参照してください。

このページの構成手順では、Unity カタログを使用します。 従来の Hive メタストアを使用してパイプラインを構成する手順については、「従来の Hive メタストアで Lakeflow パイプラインを使用する」を参照してください。

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

注

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

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

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

パイプラインの設定

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

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

ほとんどの設定には適切な既定値がありますが、運用環境で実行する前に 2 つの設定に注意が必要です。

  • ターゲット カタログとスキーマ: パイプラインの外部でデータを使用できるようにするには、ターゲット カタログとスキーマを宣言します。 データは、既定で Unity カタログに発行されます。 「ターゲット カタログとスキーマのを設定する」を参照してください。
  • データ アクセス: 実行に使用されるコンピューティングには、データ ソースと、指定されている場合はストレージの場所に対して構成されたアクセス許可が必要です。

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

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

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

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

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

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

  4. パイプラインを作成する任意のオプションを選択します。

    • SQL のサンプル コードから始めて、SQL のサンプル コード を含む新しいパイプラインとフォルダー構造を作成します。
    • Python のサンプル コードから始めて、Python のサンプル コード を含む新しいパイプラインとフォルダー構造を作成します。
    • 1 つの変換から始めて 、新しい空白のコード ファイルを使用して、新しいパイプラインとフォルダー構造を作成します。
    • 既存の資産を追加 して、ワークスペース内の既存のコード ファイルに関連付けることができるパイプラインを作成します。
    • ソース管理プロジェクトを作成 して、新しい宣言型オートメーション バンドル プロジェクトを含むパイプラインを作成するか、既存のバンドルにパイプラインを追加します。

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

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

    ETL パイプラインは、次の既定の設定で作成されます。

    この構成は、開発やテストを含む多くのユース ケースに推奨され、スケジュールに従って実行する運用ワークロードに適しています。 パイプラインのスケジュール設定の詳細については、「ジョブ用パイプライン タスク」をご覧ください。

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

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

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

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

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

コンピューティング構成オプション

Databricks では、常に拡張自動スケーリングを使用することをお勧めします。 その他のコンピューティング構成については、既定値のままで多くのパイプラインに適しています。

サーバーレス パイプラインでは、コンピューティング構成オプションは削除されます。 サーバーレス パイプラインの構成手順については、「 サーバーレス パイプラインの構成」を参照してください。

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

  • クラスター タグを使用すると、パイプラインに関連するコストを監視できます。 コンピューティング タグの構成を参照してください。
  • パイプラインの実行に使用する仮想マシンの種類を指定するには、[インスタンスの種類]を構成します。 「パイプラインを実行するインスタンスの種類を選択する」を参照してください。
    • パイプラインで構成されたワークロード用に最適化されたワーカーの種類を選択します。
    • 必要に応じて、ワーカーの種類とは異なるドライバーの種類を選択できます。 これは、ワーカーの種類が大きく、ドライバーのコンピューティング使用率が低いパイプラインのコストを削減したり、大規模なドライバーの種類を選択して、多数の小規模なワーカーを使用するワークロードでメモリ不足の問題を回避したりする場合に役立ちます。

実行ユーザーを設定する

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

必要なアクセス許可

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

  • パイプラインに対するCAN_MANAGE権限
  • サービス プリンシパルの CAN_USE ロール (サービス プリンシパルに対して実行ユーザーを設定する場合)

実行ユーザーまたはサービス プリンシパルの場合:

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

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

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

    • パイプライン ソース コードに含まれるすべてのノートブックの読み取り可能アクセス許可
    • パイプラインでワークスペース ファイルが使用されている場合は、ワークスペース ファイルに対するアクセス許可を読み取ることができます

  • Unity カタログのアクセス許可 (Unity カタログを使用するパイプラインの場合):

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

  • 従来の Hive メタストアのアクセス許可 (Hive メタストアを使用するパイプラインの場合):

    • 対象のデータベースおよびテーブルの SELECT および MODIFY アクセス許可

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

    • ストレージ ソース位置からの読み取りアクセス権
    • 対象ストレージへの書き込み許可

実行ユーザーを設定する方法

run-as ユーザーは、パイプライン監視ページまたはパイプライン エディターのパイプライン設定を使用して設定できます。 パイプライン監視ページからユーザーを変更するには:

  1. [ ジョブ] と [パイプライン ] をクリックしてパイプラインの一覧を開き、編集するパイプラインの名前を選択します。
  2. pipline 監視ページで、[ 設定] をクリックします。
  3. [パイプライン設定] サイドバーで、Pencil icon.Pencil icon.[実行ユーザー] の横にある [編集] をクリックします。
  4. 編集ウィジェットで、次のいずれかのオプションを選択します。
    • 独自のユーザー アカウント
    • CAN_USE アクセス許可を持つサービス プリンシパル
  5. 変更を適用するには、保存をクリックします。

実行ユーザーを正常に更新した場合:

  • パイプライン ID は、今後のすべての実行に新しいユーザーまたはサービス プリンシパルを使用するように変更されます
  • Unity カタログ パイプラインでは、パイプラインによって発行されたテーブルの所有者が、新しい実行 ID と一致するように更新されます
  • 今後のパイプライン更新では、新しい実行 ID のアクセス許可と資格情報が使用されます
  • 設定の変更と同様に、新しい ID は次のパイプライン更新に適用されます。継続的パイプラインは新しい ID で自動的に再起動しますが、トリガーされたパイプラインは次の実行で適用されます。 run-as 設定の変更により、進行中の更新が中断される可能性があります。 構成の変更を有効にする方法を参照してください。

注

"run-as の更新が失敗した場合は、失敗の理由を説明するエラーメッセージが表示されます。" 一般的な問題には、サービス プリンシパルに対するアクセス許可の不足が含まれます。

その他の構成に関する考慮事項

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

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

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

  • Triggered がデフォルトです。 パイプラインは更新開始時に利用可能なすべてのテーブルを更新し、その後停止するため、計算は更新期間中のみ実行されます。 トリガー済みのパイプラインは、必要に応じて、またはスケジュールに従って実行できます。 ジョブ用パイプライン タスクを参照してください。
  • Continuous は、ソースに届く新しいデータを処理することでテーブルを新鮮に保ちます。 これにより、新規データと更新された結果の間の遅延が短縮されますが、常に稼働するクラスターのコストを代償として実現します。 低遅延要件が証明された場合にのみ連続モードを選択してください。

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

構成の変更を有効にする方法

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

継続的ジョブの代わりに、パイプラインに組み込まれているPipeline mode設定を使用する場合:

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

製品エディションを選択する

パイプライン要件に最適な機能を備えた製品エディションを選択します。 次の製品エディションを利用できます。

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

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

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

アクティブ（非終了）の更新は常に表示されます。 更新プログラムが保持期間より古い場合、Azure Databricksはリストの応答から除外しますが、基になるイベント ログに保持します。

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

ソース コードを構成する

Lakeflow Pipelines エディターの資産ブラウザーを使用して、パイプラインを定義するソース コードを構成できます。 パイプライン ソース コードは、ワークスペース ファイルに格納されている SQL または Python スクリプトで定義されます。 パイプラインを作成または編集するときに、1 つ以上のファイルを追加できます。 既定では、パイプラインのソース コードは、パイプラインのルート フォルダーの transformations フォルダーにあります。

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

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

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

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

Azure Databricks ワークスペースに格納されている Python モジュールを使用する

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

  • Last updated on