データ・フロー・プール
データ・フロー・プールは、多くのデータ・フロー・バッチ、ストリーミング、セッション・ワークロードで、同じテナント内の様々なユーザーが同時に使用できます。
プールは、同じテナント内の複数のユーザー間でSparkベースのバッチ、ストリーミングおよびセッション・ワークロードを効率的に管理するための強力で柔軟なメカニズムを提供します。時間に敏感な本番環境と動的な開発シナリオの両方をサポートするように設計されたプールは、事前に初期化されたコンピュート・インフラストラクチャを維持することで、アプリケーションの起動時間を短縮します。
これにより、エンタープライズ・グレードのワークロードを分離できるため、専用のリソース・セグメンテーションを通じて、重要な本番ジョブが開発アクティビティの影響を受けないことが保証されます。認可されたユーザーまたは特定の環境にプールの使用を制限するファイングレインIAMポリシーにより、コスト制御が合理化されます。同時に、インテリジェント・キューイング・メカニズムにより、リソース使用率を最適化しながら、大量のジョブ送信が可能になります。
プールは、定義された時間枠内に自動的に開始するようにスケジュールでき、最終的に使用量のタイムアウト後に停止し、コンピュート可用性をビジネス・プロセスと連携させ、アイドル・コストを最小限に抑えることができます。また、組込みの自動化により、実行中のアプリケーションを中断することなく、シームレスにセキュリティ・パッチ適用を処理できるため、プールは、セキュアでスケーラブル、かつコスト効率の高いSparkワークロード実行に最適な選択肢となります。
プールは、次のような様々なユース・ケースに対して幅広い機能を提供します。
- 時間を重視する大規模な本番ワークロード。多くのエグゼキュータでは、起動時間を数秒で短縮する必要があります。
- 重要な本番ワークロードは、リソースを異なるプールに分割できるため、動的開発ワークロードの影響を受けません。
- データ・フロー実行を特定のプールに送信できるIAMポリシーを使用して、開発のコストおよび使用量を制御します。
- 多数のデータ・フロー実行は、起動時間を短縮して処理する必要があります。
- キューイング・データ・フローは、リソースおよびコスト管理を効率的に使用するためにプールで実行されます。
- ワークロードは、スケジュール上のプールの自動起動を必要とする特定の時間ウィンドウでのみ実行され、アイドル時に自動停止されます。
- プール内の実行またはリソースに影響を与えずに、セキュリティの自動パッチ適用を行います。
データ・フローのもう1つのユース・ケースは、特別な構成でノードを事前割当て(または予約)する機能です。これらは、特定のサイズ(またはCPUとメモリーの関係)のリソースであり、リージョンをサポートするデータ・センターではまれです。このような特別な構成を必要とするジョブには通常、大量のデータ量とレコードサイズが含まれますが、ジョブ実行により多くのノードを割り当てることによって簡単に分散することはできません。
これらのシナリオでは、リージョン内のデータ・センターを問い合せて、これらのリソースの可用性を評価することが実用的です。Oracleサンプルは、様々な商業コンテキストでそのような容量を調べるための簡単なアプローチを提供します。
プールを使用するための実行およびアプリケーションの構成
データ・フローのアプリケーションおよび実行でプールを使用します。
プールを使用したアプリケーションの開発
アプリケーションの開発中に、アプリケーションに追加するDELETED
以外の任意の状態のプールを選択できます。アプリケーションに追加されたデータ・フロー・プールで構成されているドライバおよびエグゼキュータ・シェイプのみを選択します。
プールを使用したアプリケーションの実行
データ・フロー実行の送信中に、アプリケーションを追加するDELETED
以外の任意の状態のプールを選択します。実行に追加されたデータ・フロー・プールで構成されているドライバおよびエグゼキュータ・シェイプのみを選択します。
プール付きキューイング・データ・フロー
プール・コンピュート・リソースが他の実行で使用されている場合、プール・キューにさらに実行を送信できます。デフォルトでは、実行はプール内のリソースが使用可能になるまで待機するために20分間キューに入れられます。「データ・フローの実行」または「アプリケーションの拡張」オプションでSpark構成spark.dataflow.acquireQuotaTimeout
を設定することで、キューの待機時間を構成できます。この構成の値は、1h | 30m | 45minのように書式設定できます。
データ・フロー実行が、プール内のアクティブな実行によって保持されているリソースが使用可能になるのをキューで待機している間、コールド・スタートアップが発生します。
実行からのデータ・フロー・プールの開始
停止されたデータ・フロー・プールまたは受け入れられたデータ・フロー・プールは、プールを使用して実行を発行することによって開始することもできます。
プールがアクティブになるまで待機します。実行タイムアウトを回避するために、プールのキューイング機能を使用することをお薦めします。実行を取り消して停止しても、プールは停止されません。
実行またはアプリケーションでのプールIDのオーバーライド
-
アプリケーションおよび実行にプールを追加する場合は、実行に追加されたプールが使用されます。
-
アプリケーションに追加するが、実行には追加しないプールをアプリケーションに追加する場合、「実行」を発行すると、アプリケーションに追加されたプールが使用されます。
-
実行でプールを追加する場合で、アプリケーションには追加しない場合、実行に追加されたプールの送信時に使用されます。
-
これにより、同じアプリケーションの異なる実行でioの多くのプールを使用できます。
制限
- テナント・レベルのデータ・フロー制限およびコンパートメント割当ては、プールの作成中または起動中に引き続き適用可能です。
- プール内のすべての構成の合計で最大1000ノード。
- 作成および使用できるプールの数に制限はありません。管理者は、ユーザー、ユーザー・グループまたはコンパートメントを制限するコンパートメント割当てポリシーを記述して、プールに構成されているノードのシェイプおよび数を制御できます。