パイプラインには、多くのフローを含む多くのデータセットを含め、それらを最新の状態に保つことができます。 パイプラインは、更新プログラムとクラスターを自動的に管理して効率的に更新します。 ただし、多数のフローを管理するとオーバーヘッドが発生し、場合によっては、処理中に予想よりも大きな初期化や管理オーバーヘッドが発生する可能性があります。
5 分以上の初期化時間など、トリガーされたパイプラインで初期化を待機する遅延が発生している場合は、データセットで同じソース データが使用されている場合でも、処理を複数のパイプラインに分割することを検討してください。
注
トリガーされたパイプラインは、トリガーされるたびに初期化手順を実行します。 継続的パイプラインは、初期化手順が停止して再起動されたときにのみ実行されます。 このセクションは、トリガーされたパイプラインの初期化を最適化する場合に最も役立ちます。
パイプラインの分割を検討する場合
パフォーマンス上の理由から、パイプラインの分割が有利になる場合がいくつかあります。
-
INITIALIZINGフェーズとSETTING_UP_TABLESフェーズは、必要以上に時間がかかり、パイプライン全体の時間に影響します。 これが 5 分を超える場合、多くの場合、パイプラインを分割することで改善されます。 - クラスターを管理するドライバーは、1 つのパイプライン内で多数の (30 から 40 を超える) ストリーミング テーブルを実行するときにボトルネックになる可能性があります。 ドライバーが応答しない場合は、ストリーミング クエリの期間が長くなり、更新プログラムの合計時間に影響します。
- 複数のストリーミング テーブル フローを持つトリガーされたパイプラインでは、並列化可能なすべてのストリーム更新を並列で実行できない場合があります。
パフォーマンスの問題の詳細
このセクションでは、1 つのパイプラインに多数のテーブルとフローがあることから発生する可能性があるパフォーマンスの問題について説明します。
INITIALIZING フェーズと SETTING_UP_TABLES フェーズにおけるボトルネック
パイプラインの複雑さに応じて、実行の初期フェーズがパフォーマンスのボトルネックになる可能性があります。
初期化フェーズ
このフェーズでは、依存関係グラフを構築し、テーブルの更新の順序を決定するためのプランを含む論理プランが作成されます。
SETTING_UP_TABLES フェーズ
このフェーズでは、前のフェーズで作成されたプランに基づいて、次のプロセスが実行されます。
- パイプラインで定義されているすべてのテーブルのスキーマの検証と解決。
- 依存関係グラフを構築し、テーブルの実行順序を決定します。
- 各データセットがパイプラインでアクティブであるか、以前の更新以降に新しいデータセットであるかどうかを確認します。
- 最初の更新でストリーミング テーブルを作成し、具体化されたビューの場合は、パイプラインの更新ごとに必要な一時ビューまたはバックアップ テーブルを作成します。
INITIALIZINGとテーブルの設定に時間がかかる理由
多くのデータセットに対して多数のフローを含む大規模なパイプラインには、いくつかの理由で時間がかかる場合があります。
- 多数のフローと複雑な依存関係を持つパイプラインの場合、これらのフェーズは、実行する作業量のために時間がかかる場合があります。
-
Auto CDC変換を含む複雑な変換は、定義された変換に基づいてテーブルを具体化するために必要な操作のため、パフォーマンスのボトルネックを引き起こす可能性があります。 - また、多数のフローが更新プログラムに含まれていない場合でも、低速になる可能性があるシナリオもあります。 たとえば、700 を超えるフローを含むパイプラインを考えてみましょう。その中で、構成に基づいてトリガーごとに更新されるフローは 50 未満です。この例では、各実行で 700 個のテーブルすべてに対していくつかの手順を実行し、データフレームを取得してから、実行するテーブルを選択する必要があります。
ドライバーにおけるボトルネック
ドライバーは、実行中の更新プログラムを管理します。 各フローを処理するクラスター内のインスタンスを決定するには、すべてのテーブルに対していくつかのロジックを実行する必要があります。 1 つのパイプライン内で複数の (30 から 40 を超える) ストリーミング テーブルを実行すると、ドライバーがクラスター全体の作業を処理する際に CPU リソースのボトルネックになる可能性があります。
ドライバーはメモリの問題に直面する場合もあります。 これは、並列フローの数が 30 以上の場合に発生する可能性があります。 ドライバーのメモリの問題を引き起こす可能性がありますが、並列で実行されているタスクの複雑さに依存するフローやデータセットは、特定の数ではありません。
ストリーミング フローは並列で実行できますが、これにはドライバーがすべてのストリームのメモリと CPU を同時に使用する必要があります。 トリガーされたパイプラインでは、メモリと CPU の制約を回避するために、ドライバーがストリームのサブセットを一度に並列で処理する場合があります。
いずれの場合も、パイプラインを分割して、それぞれに最適なフローセットが存在するようにすることで、初期化と処理時間を短縮できます。
パイプラインの分割によるトレードオフ
すべてのフローが同じパイプライン内にある場合、Lakeflow Spark 宣言パイプラインによって依存関係が管理されます。 複数のパイプラインがある場合は、パイプライン間の依存関係を管理する必要があります。
依存 関係 (1 つではなく) 複数のアップストリーム パイプラインに依存するダウンストリーム パイプラインがある場合があります。 たとえば、
pipeline_A、pipeline_B、pipeline_Cの 3 つのパイプラインがあり、pipeline_Cがpipeline_Aとpipeline_Bの両方に依存している場合、pipeline_Cとpipeline_Aの両方がそれぞれの更新を完了した後にのみpipeline_Bを更新します。 これに対処する 1 つの方法は、依存関係を適切にモデル化したジョブで各パイプラインをタスクにすることで依存関係を調整するため、pipeline_Cpipeline_Aとpipeline_Bの両方が完了した後にのみ更新されます。並行 処理 パイプライン内のフローが異なる場合があり、完了までに非常に異なる時間がかかる場合があります(たとえば、15 秒以内に
flow_A更新が行われ、flow_Bに数分かかる場合など)。 パイプラインを分割する前にクエリ時間を確認し、短いクエリをまとめてグループ化すると便利です。
パイプラインの分割を計画する
開始する前に、パイプラインの分割を視覚化できます。 25 個のテーブルを処理するソース パイプラインのグラフを次に示します。 1 つのルート データソースが 8 つのセグメントに分割され、それぞれに 2 つのビューがあります。
パイプラインを分割した後、2 つのパイプラインがあります。 1 つは単一のルート データソースと、4 つのセグメントと関連付けられたビューを処理します。 2 番目のパイプラインは、他の 4 つのセグメントとそれに関連付けられたビューを処理します。 2 番目のパイプラインは、ルート データソースを更新するために最初のパイプラインに依存します。
完全な更新なしでパイプラインを分割する
パイプラインの分割を計画したら、必要な新しいパイプラインを作成し、パイプライン間でテーブルを移動してパイプラインの負荷分散を行います。 完全な更新を行わずにテーブルを移動できます。
詳細については、「 パイプライン間でのテーブルの移動」を参照してください。
この方法にはいくつかの制限があります。
- パイプラインは Unity カタログに含まれている必要があります。
- ソース パイプラインと移行先パイプラインは、同じワークスペース内に存在する必要があります。 ワークスペース間の移動はサポートされていません。
- 移動先パイプラインは、移動前に (失敗した場合でも) 1 回作成して実行する必要があります。
- 既定の発行モードを使用するパイプラインから、従来の発行モードを使用するパイプラインにテーブルを移動することはできません。 詳細については、 LIVE スキーマ (レガシ) を参照してください。