次の方法で共有


Microsoft Fabric の Apache Spark コンピューティングとは?

適用対象:✅ Microsoft Fabric でのデータ エンジニアリングとデータ サイエンス

Microsoft Fabric のデータ エンジニアリングとデータ サイエンのエクスペリエンスは、フル マネージドの Apache Spark コンピューティング プラットフォームで動作します。 このプラットフォームは、並外れた速度と効率を提供するように設計されています。 スターター プールを使うと、Apache Spark セッションの短時間での初期化 (通常 5 から 10 秒以内) が期待でき、手動セットアップは必要ありません。 また、特定のデータ エンジニアリングとデータ サイエンスの要件に従って、Apache Spark プールを柔軟にカスタマイズすることもできます。 このプラットフォームにより、最適化され、調整された分析エクスペリエンスが可能になります。

スターター プールとカスタムの Spark プールがある Spark コンピューティング プラットフォームを示す画像。

スターター プール

スターター プールは、Microsoft Fabric プラットフォームで Spark を数秒以内に使用するための高速で簡単な方法です。 Spark セッションは、Spark によってノードが設定されるのを待機せず、すぐに使用できます。このため、データを使用してより多くの作業を行い、より迅速に分析情報を得ることができます。

スターター プール構成を示す表の画像。

スターター プールには、要求に対して常に有効で準備ができている Apache Spark クラスターがあります。 これは、Spark ジョブのニーズに基づいて動的にスケールアップする中間ノードを使用します。

スターター プールのおおまかな設計を示す図。

スターター プールには既定の設定もあります。これにより、セッションの開始時に低速にならずに、ライブラリをすばやくインストールできます。 ただし、ワークスペースまたは容量の設定から追加のカスタム Apache Spark プロパティまたはライブラリを使う必要がある場合は、Spark によるノードの取得にかかる時間が長くなります。 課金と容量消費については、ノートブックまたは Apache Spark ジョブ定義の実行を始めると、容量消費に対して課金されます。 クラスターがプール内でアイドル状態になっている間は課金されません。

スターター プールのおおまかな課金段階を示す図。

たとえば、ノートブック ジョブをスターター プールに送信する場合は、ノートブック セッションがアクティブな期間に対してのみ課金されます。 課金される時間には、アイドル時間や、Spark コンテキストでセッションを個人設定するためにかかった時間は含まれません。

Spark プール

Spark プールは、データ分析タスクに必要なリソースの種類を Spark に伝える方法です。 Spark プールに名前を付け、ノード (作業を行うマシン) の数とサイズを選択できます。 作業量に応じてノードの数を調整する方法を Spark に指示することもできます。 Spark プールの作成は無料です。課金されるのは、プールで Spark ジョブを実行し、Spark によってノードが設定されたときのみです。

セッションの有効期限が切れた後に Spark プールを 2 分間使用しない場合、Spark プールの割り当ては解除されます。 この既定のセッション有効期限は 20 分に設定されていて、必要に応じて変更できます。 ワークスペース管理者の場合は、ワークスペースのカスタム Spark プールを作成し、それを他のユーザーの既定のオプションにすることもできます。 これにより、ノートブックまたは Spark ジョブを実行するたびに新しい Spark プールを設定することを回避できるため、時間を節約できます。 Spark は Azure からノードを取得する必要があるため、カスタム Spark プールの起動には約 3 分かかります。

ノードの最小数を 1 に設定することで、単一ノードの Spark プールを作成することもでき、ドライバーと Executor は、復元可能な HA に付属する、小規模なワークロードに適した単一ノードで実行されます。

カスタム Spark プールに含めることができるノードのサイズと数は、Microsoft Fabric の容量によって異なります。 容量は、Azure で使用できるコンピューティング能力の量の尺度です。 1 つの考え方として、2個の Apache Spark 仮想コア (Spark のコンピューティング能力の単位) が 1 容量ユニットに等しいということがあります。 たとえば、Fabric の容量 SKU F64 には 64 容量ユニットがあり、これは 384 個の Spark 仮想コア (64 * 2 * 3X バースト倍率) に相当します。 Spark 仮想コアの合計数が 384 を超えない限り、これらの Spark 仮想コアを使用して、カスタム Spark プール用にさまざまなサイズのノードを作成できます。

Spark プールは、スターター プールと同様に課金されます。ノートブックまたは Spark ジョブ定義を実行するためにアクティブな Spark セッションを作成しない限り、作成したカスタム Spark プールについて支払うことはありません。 ジョブの実行期間中にのみ課金されます。 クラスターの作成やジョブ完了後の割り当て解除などのステージに対しては課金されません。

カスタム プールのおおまかな課金段階を示す図。

たとえば、ノートブック ジョブをカスタム Spark プールに送信する場合は、セッションがアクティブな期間に対してのみ課金されます。 Spark セッションが停止するか期限切れになると、そのノートブック セッションの課金は停止します。 クラウドからのクラスター インスタンスの取得にかかった時間、または Spark コンテキストの初期化にかかった時間には課金されません。

前の例に基づいて、F64 で使用できるカスタム プール構成:

Fabric の容量 SKU 容量ユニット Spark 仮想コア ノード サイズ ノードの最大数
F64 64 384 Small 96
F64 64 384 Medium 48
F64 64 384 Large 24
F64 64 384 X-Large 12
F64 64 384 極大 6

Note

カスタム プールを作成するには、ワークスペースの管理者アクセス許可が必要です。 また、Microsoft Fabric 容量管理者がワークスペース管理者に対して、カスタム Spark プールのサイズを変更できるアクセス許可を付与する必要があります。 詳細については、Fabric でのカスタム Spark プールの概要に関する記事を参照してください

Nodes

Apache Spark プール インスタンスは、1 つのヘッド ノードとワーカー ノードで構成され、1 つの Spark インスタンスに最低 1 つのノードから開始できます。 ヘッド ノードは、Livy、Yarn Resource Manager、Zookeeper、Apache Spark ドライバーなどの追加の管理サービスを実行します。 すべてのノードは、Node Agent や Yarn Node Manager などのサービスを実行します。 すべてのワーカー ノードは、Apache Spark Executor サービスを実行します。

ノードのサイズ

Spark プールは、小規模コンピューティング ノード (4 つの仮想コアと 32 GB のメモリ) から、超大規模コンピューティング ノード (ノードあたり 64 の仮想コアと 512 GB のメモリ) まで、さまざまなノード サイズで定義できます。 ノードのサイズはプールの作成後に変更できますが、アクティブなセッションの再起動が必要になる場合があります。

[サイズ] 仮想コア メモリ
Small 4 32 GB
Medium 8 64 GB
Large 16 128 GB
X-Large 32 256 GB
極大 64 512 GB

Note

ノード サイズ X-Large および XX-Large は、非試用版 Fabric SKU でのみ許可されます。

Autoscale

Apache Spark プール用の自動スケーリングでは、アクティビティの量に基づいてコンピューティング リソースを自動的にスケールアップおよびスケールダウンすることができます。 自動スケーリング機能を有効にするときに、スケーリングするノードの最小数と最大数を設定します。 自動スケーリング機能を無効にしても、設定されているノード数は固定されたままになります。 この設定はプールの作成後に変更できますが、インスタンスの再起動が必要になる場合があります。

Note

デフォルトでは、spark.yarn.executor.decommission.enabled は true に設定されており、使用率の低いノードの自動シャットダウンを有効にしてコンピューティング効率を最適化します。 あまり積極的なスケールダウンが推奨されていない場合は、この構成を false に設定できます。

動的割り当て

動的割り当てを使用すると、タスクが現在の Executor が負担できる負荷を超えた場合に、Apache Spark アプリケーションがより多くの Executor を要求できます。 また、ジョブが完了したとき、および Spark アプリケーションがアイドル状態に移行している場合は、Executor を解放します。 Executor の構成は、Spark ジョブ実行プロセスのさまざまなステージで大きく異なるため、エンタープライズ ユーザーが調整するのが難しいことがよくあります。 これらの構成は、処理されるデータの量にも依存します。これは、随時変化します。 ユーザーは、プールの構成の一部として、Executor の動的割り当てオプションを有効にできます。これにより、Spark プールで使用可能なノードに基づく Spark アプリケーションへの Executor の自動割り当てが有効になります。

送信されるすべての Spark アプリケーションに対して動的割り当てオプションを有効にすると、システムはジョブ送信ステップの間に最小ノードに基づいて Executor を予約します。 自動スケーリングが正常に機能するように最大ノード数を指定します。