Azure Databricks

The presented resiliency recommendations in this guidance include Azure Databricks and dependent resources and settings.

Summary of Recommendation

Recommendations Details

DBW-1 - Databricks ランタイムのバージョンが最新ではないか、LTS バージョンではありません

Category: Governance

Impact: Medium

Guidance

12.2 LTS 以降を使用してください。Databricks では、次の順序でワークロードを移行することをお勧めします。:

  • ワークロードが現在 Databricks Runtime 11.3 LTS 以降で実行されている場合は、この記事の後半で説明するように、最新バージョンの Databricks Runtime 12.x に直接移行できます。
  • ワークロードが現在 Databricks Runtime 11.3 LTS 以下で実行されている場合は、次の操作を行います。
    • 最初に Databricks Runtime 11.3 LTS に移行します。Databricks Runtime 11.x 移行ガイドを参照してください。
    • この記事のガイダンスに従って、Databricks Runtime 11.3 LTS から最新バージョンの Databricks Runtime 12.x に移行します。

Resources

Resource Graph Query

// under-development



DBW-2 - Databricks プールを使用します

Category: System Efficiency

Impact: High

Guidance

Databricks プールはサービスの標準機能であり、VM をオンデマンドでスピンアップするのではなく、事前にプロビジョニングすることで、クラスターの開始時またはスケーリング時の “プロビジョニング” エラーのリスクを大幅に軽減できます。

Resources

Resource Graph Query

// under-development



DBW-3 - Worker VM Type と Driver type に SSD ベースの VM を使用します

Category: System Efficiency

Impact: Medium

Guidance

Premium 対応の仮想マシンで標準ハード ディスクを使用していることが確認されたため、Standard HDD ディスクを Standard SSD または Premium ディスクにアップグレードすることを検討することをお勧めします。すべてのオペレーティング システム ディスクとデータ ディスクに Premium Storage を使用する単一インスタンス仮想マシンについては、マイクロソフトは、仮想マシンの接続性が 99.9% 以上であることを保証します。アップグレードを決定する際には、これらの要素を考慮してください。1 つ目は、アップグレードには VM の再起動が必要であり、このプロセスが完了するまでに 3 分から 5 分かかることです。2 つ目は、一覧にある VM がミッション クリティカルな運用 VM である場合は、Premium ディスクのコストに対して可用性の向上を評価することです。

  • Premium SSD ディスクは、I/O 集中型のアプリケーションや運用ワークロードに対して、高パフォーマンスで待機時間の短いディスク サポートを提供します。
  • Standard SSD ディスクは、低い IOPS レベルで一貫したパフォーマンスを必要とするワークロード向けに最適化された、コスト効率の高いストレージ オプションです。
  • Standard HDD ディスクは、開発/テストのシナリオと重要度の低いワークロードに最小のコストで使用します。

Standard SSD は、一部の運用ワークロードでも使用できます。

Resources

Resource Graph Query

// under-development



DBW-4 - バッチ ワークロードの自動スケーリングを有効にします

Category: System Efficiency

Impact: High

Guidance

自動スケーリングを使用すると、ワークロードに基づいてクラスターのサイズを自動的に変更できます。自動スケーリングは、コストとパフォーマンスの両方の観点から、多くのユース ケースとシナリオにメリットをもたらします。このドキュメントでは、自動スケーリングを使用するかどうか、および最大のメリットを得る方法を決定するための考慮事項について説明します。

ストリーミング ワークロードの場合、Databricks では、自動スケーリングで Delta Live Tables を使用することをお勧めします。

Resources

Resource Graph Query

// under-development



DBW-5 - SQL warehouse の自動スケーリングを有効にします

Category: System Efficiency

Impact: High

Guidance

SQL ウェアハウスのスケーリング パラメーターは、ウェアハウスに送信されたクエリが分散されるクラスターの最小数と最大数を設定します。デフォルトは、最小で 1 つ、最大で 1 つのクラスターです。

特定のウェアハウスでより多くの同時ユーザーを処理するには、クラスター数を増やします。

Resources

Resource Graph Query

// under-development



DBW-6 - Delta Live Tables の拡張自動スケーリングを使用します

Category: System Efficiency

Impact: Medium

Guidance

Databricks の拡張自動スケーリングでは、パイプラインのデータ処理待機時間への影響を最小限に抑えながら、ワークロード ボリュームに基づいてクラスター リソースを自動的に割り当てることで、クラスターの使用率を最適化します。

Resources

Resource Graph Query

// under-development



DBW-7 - ジョブの自動終了が有効になっており、ユーザー定義のローカルプロセスがないことを確認します

Category: Availability

Impact: Medium

Guidance

クラスタ リソースを節約するために、クラスタを終了できます。終了したクラスターの構成は、後で再利用 (ジョブの場合は自動開始) できるように保存されます。クラスタを手動で終了することも、指定した非アクティブな期間が経過すると自動的に終了するようにクラスタを設定することもできます。終了したクラスタの数が 150 を超えると、最も古いクラスタが削除されます。 また、クラスタの自動終了を設定することもできます。クラスターの作成時に、クラスターを終了するまでの非アクティブ期間を分単位で指定できます。 ただし、自動終了機能では、ユーザー定義のローカル プロセスではなく、Spark ジョブのみが監視されます。そのため、すべての Spark ジョブが完了すると、ローカル プロセスが実行されている場合でも、クラスターが終了する可能性があります。

Resources

Resource Graph Query

// under-development



DBW-8 - Logging-Cluster ログ配信を有効にします

Category: Monitoring

Impact: Medium

Guidance

クラスターを作成するときに、Spark ドライバー ノード、ワーカー ノード、およびイベントのログを配信する場所を指定できます。ログは 5 分ごとに配信され、選択した宛先に 1 時間ごとにアーカイブされます。クラスターが終了すると、Azure Databricks は、クラスターが終了するまでに生成されたすべてのログを配信することを保証します。

ログの宛先は、クラスター ID によって異なります。指定した宛先が dbfs:/cluster-log-delivery の場合、0630-191345-leap375 のクラスター ログは dbfs:/cluster-log-delivery/0630-191345-leap375 に配信されます。

Resources

Resource Graph Query

// under-development



DBW-9 - Delta Lake を使用して信頼性を高めます

Category: Availability

Impact: High

Guidance

Delta Lake は、データ レイクに信頼性をもたらすオープン ソースのストレージ形式です。Delta Lake は、ACID トランザクション、スキーマの適用、スケーラブルなメタデータ処理を提供し、ストリーミングとバッチのデータ処理を統合します。Delta Lake は、既存のデータ レイク上で実行され、Apache Spark API と完全に互換性があります。Databricks 上の Delta Lake では、ワークロード パターンに基づいて Delta Lake を構成できます。

Resources

Resource Graph Query

// under-development



DBW-10 - Photon アクセラレーションを使用します

Category: Availability

Impact: Low

Guidance

Apache Spark は、Databricks レイクハウスのコンピューティング エンジンとして、回復力のある分散データ処理に基づいています。内部 Spark タスクが期待どおりの結果を返さない場合、Apache Spark は不足しているタスクを自動的に再スケジュールし、ジョブ全体の実行を続行します。これは、短いネットワークの問題やスポット VM の失効など、コード外のエラーに役立ちます。SQL API と Spark DataFrame API の両方を使用すると、エンジンにこの回復性が組み込まれます。

Databricks レイクハウスでは、完全に C++ で記述されたネイティブ ベクトル化エンジンである Photon は、Apache Spark API と互換性のあるハイ パフォーマンス コンピューティングです。

Resources

Resource Graph Query

// under-development



DBW-11 - Databricks Auto Loader または Delta Live Tables を使用して、無効なデータや不適合なデータを自動的に復旧します

Category: Application Resilience

Impact: Low

Guidance

無効なデータや不適合なデータは、確立されたデータ形式に依存するワークロードのクラッシュにつながる可能性があります。プロセス全体のエンドツーエンドの回復性を高めるには、インジェスト時に無効なデータや不適合なデータを除外することをお勧めします。レスキューされたデータをサポートすることで、取り込みやETL中にデータを失ったり見逃したりすることがなくなります。復旧されたデータ列には、指定されたスキーマに存在しないか、型の不一致があったか、レコードまたはファイルの列の大文字と小文字がスキーマの大文字と小文字が一致しなかったために、解析されなかったデータが含まれます。

  • Databricks 自動ローダー: 自動ローダーは、ファイルのインジェストをストリーミングするための理想的なツールです。JSON と CSV のレスキューされたデータをサポートします。
  • Delta Live Tables: 回復性のためのワークフローを構築するための別のオプションは、品質制約のある Delta Live Tables を使用することです。

Resources

Resource Graph Query

// under-development



DBW-12 - 自動再試行と自動終了のジョブを構成します

Category: Availability

Impact: High

Guidance

バッチ推論とストリーミング推論の場合は、Databricks ジョブと MLflow を使用してモデルを Apache Spark UDF としてデプロイし、ジョブのスケジュール設定、再試行、自動スケーリングなどを活用します。 モデル提供は、スケーラブルで実稼働グレードのモデルリアルタイムサービスインフラストラクチャを提供します。MLflow を使用して機械学習モデルを処理し、REST API エンドポイントとして公開します。この機能ではサーバーレス コンピューティングが使用されるため、エンドポイントと関連するコンピューティング リソースは Databricks クラウド アカウントで管理および実行されます。

Resources

Resource Graph Query

// under-development



DBW-13 - スケーラブルで実稼働グレードのモデル提供用インフラストラクチャを使用します

Category: System Efficiency

Impact: High

Guidance

バッチ推論とストリーミング推論の場合は、Databricks ジョブと MLflow を使用してモデルを Apache Spark UDF としてデプロイし、ジョブのスケジュール設定、再試行、自動スケーリングなどを活用します。 モデル提供は、スケーラブルで実稼働グレードのモデルリアルタイムサービスインフラストラクチャを提供します。MLflow を使用して機械学習モデルを処理し、REST API エンドポイントとして公開します。この機能ではサーバーレス コンピューティングが使用されるため、エンドポイントと関連するコンピューティング リソースは Databricks クラウド アカウントで管理および実行されます。

Resources

Resource Graph Query

// under-development



DBW-14 - 階層型ストレージアーキテクチャを使用します

Category: Application Resilience

Impact: Medium

Guidance

階層化されたアーキテクチャを作成し、データが階層を通過するにつれてデータ品質が向上するようにすることで、データをキュレーションします。一般的な階層化のアプローチは次のとおりです。

未加工レイヤー (ブロンズ): ソース データはレイクハウスの最初のレイヤーに取り込まれ、そこに保持する必要があります。すべての下流データが未加工レイヤーから作成されたら、必要に応じて、このレイヤーから後続のレイヤーを再構築できます。

キュレーションされたレイヤー (シルバー): 2 番目のレイヤーの目的は、クレンジング、絞り込み、フィルター処理、および集計されたデータを保持することです。このレイヤーの目標は、すべての役割と機能にわたる分析とレポートのための健全で信頼性の高い基盤を提供することです。

最終層 (ゴールド): 3 番目の層は、ビジネスまたはプロジェクトのニーズに基づいて作成されます。他の部署やプロジェクトに対してデータ製品として異なるビューを提供し、セキュリティ ニーズに関するデータ (匿名化されたデータなど) を準備したり、パフォーマンスを最適化したり (事前集計されたビューなど) したりします。このレイヤーのデータ製品は、ビジネスにとっての事実と見なされます。

最後のレイヤーには、高品質のデータのみを含める必要があり、ビジネスの観点から完全に信頼できるものでなければなりません。

Resources

Resource Graph Query

// under-development



DBW-15 - データの冗長性を削減することでデータの整合性を向上させます

Category: Application Resilience

Impact: Low

Guidance

データをコピーまたは複製すると、データの冗長性が生じ、整合性が失われ、データ系列が失われ、多くの場合、それぞれのアクセス許可が異なります。これにより、レイクハウス内のデータの品質が低下します。データの一時的または使い捨て用のデータのコピーは、それ自体では有害ではなく、俊敏性、実験、イノベーションを促進するために必要になる場合があります。ただし、これらのコピーが運用可能になり、ビジネス上の意思決定に定期的に使用されるようになると、データのサイロ化が進みます。これらのデータサイロが同期しなくなると、データの整合性と品質に重大な悪影響を及ぼし、「どのデータセットがマスターなのか」や「データセットは最新か」などの疑問が生じます。

Resources

Resource Graph Query

// under-development



DBW-16 - スキーマをアクティブに管理します

Category: Governance

Impact: Medium

Guidance

制御されていないスキーマ変更は、無効なデータや、これらのデータ・セットを使用するジョブの失敗につながる可能性があります。Databricks には、スキーマを検証して適用するためのいくつかの方法があります。

  • Delta Lake は、スキーマのバリエーションを自動的に処理して、取り込み中に不適切なレコードが挿入されるのを防ぐことで、スキーマの検証とスキーマの適用をサポートします。
  • 自動ローダーは、データの処理中に新しい列の追加を検出します。既定では、新しい列を追加すると、ストリームは UnknownFieldException で停止します。自動ローダーでは、スキーマの進化のためにいくつかのモードがサポートされています。

Resources

Resource Graph Query

// under-development



DBW-17 - 制約とデータの期待値を使用します

Category: Application Resilience

Impact: Low

Guidance

Delta テーブルでは、テーブルに追加されるデータの品質と整合性が自動的に検証されるようにする標準の SQL 制約管理句がサポートされています。制約に違反すると、Delta Lake は InvariantViolationException エラーをスローして、新しいデータを追加できないことを通知します。「Azure Databricks の制約」を参照してください。

この処理をさらに改善するために、Delta Live Tables では、期待値: 期待値は、データ セットの内容に対するデータ品質の制約を定義します。期待値は、説明、不変条件、およびレコードが不変条件に失敗した場合に実行するアクションで構成されます。クエリへの期待は、Python デコレーターまたは SQL 制約句を使用します。「Delta Live Tables を使用したデータ品質の管理」を参照してください。

Resources

Resource Graph Query

// under-development



DBW-18 - 定期的なバックアップを作成します

Category: Disaster Recovery

Impact: Low

Guidance

障害から回復するには、定期的なバックアップを利用できる必要があります。Databricks Labs プロジェクトの移行を使用すると、ワークスペース管理者は、ワークスペースのほとんどの資産をエクスポートしてバックアップを作成できます (このツールはバックグラウンドで Databricks CLI/API を使用します)。「Databricks 移行ツール」を参照してください。バックアップは、ワークスペースの復元、または移行の場合の新しいワークスペースへのインポートに使用できます。

Resources

Resource Graph Query

// under-development



DBW-19 - 構造化ストリーミングのクエリ エラーから復旧します

Category: Availability

Impact: High

Guidance

構造化ストリーミングは、ストリーミング クエリのフォールト トレランスとデータの一貫性を提供します。Azure Databricks ワークフローを使用すると、障害発生時に自動的に再起動するように構造化ストリーミング クエリを簡単に構成できます。再開されたクエリは、失敗したクエリが中断したところから続行されます。

Resources

Resource Graph Query

// under-development



DBW-20 - Delta のタイム トラベルに基づいて ETL ジョブを復旧します

Category: Disaster Recovery

Impact: Medium

Guidance

徹底的なテストを行ったとしても、本番環境のジョブは失敗したり、予期しないデータや無効なデータが生成されたりする可能性があります。追加のジョブにより問題の原因を理解し、この問題を最初に引き起こしたパイプラインを修正すれば、これを解決できる場合があります。ただし、多くの場合、この作業は単純ではなく、それぞれのジョブをロールバックする必要が生じます。Delta Time Travel を使用すると、ユーザーは変更を古いバージョンまたはタイムスタンプに簡単にロールバックし、パイプラインを修復し、修正されたパイプラインを再起動できます。

Resources

Resource Graph Query

// under-development



DBW-21 - Databricks Workflows と組み込みの復旧機能を使用します

Category: Disaster Recovery

Impact: Low

Guidance

Databricks ワークフローは復旧用に構築されています。マルチタスク ジョブのタスク (および、すべての依存タスク) が失敗した場合、Azure Databricks Workflows では実行のマトリックス ビューが提供され、失敗の原因となった問題を調べることができます。「ジョブの実行の表示」を参照してください。ネットワークが短い問題であった場合でも、データの実際の問題であった場合でも、Azure Databricks Workflows で修正して修復実行を開始できます。失敗したタスクと依存するタスクのみを実行し、以前の実行から成功した結果を保持するため、時間とコストを節約できます。

Resources

Resource Graph Query

// under-development



DBW-22 - ディザスター リカバリー パターンを構成します

Category: Disaster Recovery

Impact: High

Guidance

明確なディザスター リカバリー パターンは、Azure Databricks のようなクラウドネイティブなデータ分析プラットフォームにとって重要です。一部の企業では、ハリケーンや地震などの地域的な災害やその他の発生源によって引き起こされるかどうかにかかわらず、地域のサービス全体のクラウドサービスプロバイダーが停止するというまれなケースでも、データチームがDatabricksプラットフォームを使用できることが重要です。

Resources

Resource Graph Query

// under-development



DBW-23 - デプロイとワークロードを自動化します

Category: Automation

Impact: High

Guidance

Databricks Terraform プロバイダーは、柔軟で強力なツールを使用して、Azure Databricks ワークスペースと関連するクラウド インフラストラクチャを管理します。Databricks Terraform プロバイダーの目標は、すべての Azure Databricks REST API をサポートし、データ プラットフォームのデプロイと管理の最も複雑な側面の自動化をサポートすることです。Databricks Terraform プロバイダーは、クラスターとジョブを確実にデプロイして管理し、Azure Databricks ワークスペースをプロビジョニングし、データ アクセスを構成するための推奨ツールです。

Resources

Resource Graph Query

// under-development



DBW-24 - 監視、アラート、ログ記録を設定します

Category: Monitoring

Impact: High

Guidance

Databricks Terraform プロバイダーは、柔軟で強力なツールを使用して、Azure Databricks ワークスペースと関連するクラウド インフラストラクチャを管理します。Databricks Terraform プロバイダーの目標は、すべての Azure Databricks REST API をサポートし、データ プラットフォームのデプロイと管理の最も複雑な側面の自動化をサポートすることです。Databricks Terraform プロバイダーは、クラスターとジョブを確実にデプロイして管理し、Azure Databricks ワークスペースをプロビジョニングし、データ アクセスを構成するための推奨ツールです。

Resources

Resource Graph Query

// under-development



DBW-25 - ワークスペースを個別のサブスクリプションにデプロイします

Category: System Efficiency

Impact: High

Guidance

Customers commonly partition workspaces based on teams or departments and arrive at that division naturally. But it is also important to partition keeping Azure Subscription and ADB Workspace limits in mind.

Resources

Resource Graph Query

// under-development



DBW-26 - 各ワークスペースを独自の VNet に分離します

Category: System Efficiency

Impact: High

Guidance

関連付けられているサブネット ペアを他のワークスペースから分離することで、VNet に複数のワークスペースをデプロイできますが、どの VNet にも 1 つのワークスペースのみをデプロイすることをお勧めします。これを行うことは、ADBのワークスペースレベルの分離モデルと完全に一致しています。ほとんどの場合、組織では、vnet 内のプライベート アドレス空間がすべてのリソースで共有されるため、DNS などの共通のネットワーク リソースを共有できるように、複数のワークスペースを同じ VNet に配置することを検討します。ハブ アンド スポーク モデルに従い、Vnet ピアリングを使用してワークスペース VNet のプライベート IP 空間を拡張することで、ワークスペースを分離しながら同じことを簡単に実現できます。

Resources

Resource Graph Query

// under-development



DBW-27 - 既定の DBFS フォルダーに運用データを格納しないでください

Category: Availability

Impact: High

Guidance

この推奨事項は、セキュリティとデータの可用性に関する懸念によって推進されています。すべてのワークスペースには、主にライブラリや、Init スクリプトなどの他のシステムレベルの構成アーティファクトを格納するように設計された既定の DBFS が付属しています。次の理由により、運用データを格納しないでください。

  • 既定の DBFS のライフサイクルは、ワークスペースに関連付けられています。ワークスペースを削除すると、既定の DBFS も削除され、その内容が完全に削除されます。
  • この既定のフォルダーとその内容へのアクセスを制限することはできません。

Resources

Resource Graph Query

// under-development



DBW-28 - 重要な運用ワークロードに Azure Sport VM を使用しないでください

Category: Availability

Impact: High

Guidance

Azure スポット VM は、高可用性と信頼性を必要とする重要な運用ワークロードには推奨されません。Azure スポット VM は、フォールト トレラントで中断を許容できるワークロード向けに設計されています。使用可能な容量は、サイズ、リージョン、時刻などによって異なります。Azure Spot Virtual Machines をデプロイする場合、使用可能な容量がある場合、Azure によって VM が割り当てられますが、これらの VM には SLA がありません。Azure Spot Virtual Machine では、高可用性は保証されません。Azure で容量の回復が必要になった時点で、Azure インフラストラクチャは 30 秒前に通知して Azure Spot Virtual Machines を削除します。

Resources

Resource Graph Query

// under-development



DBW-29 - レガシーワークスペースを移行します

Category: Availability

Impact: High

Guidance

Azure Databricks は当初、一部のリージョンが別のリージョンとコントロール プレーン リソースを共有していた共有コントロール プレーンでリリースされました。その後、この共有コントロール プレーン モデルは、リージョン内の専用のコントロール プレーン (北ヨーロッパ、米国中部、米国東部など) に進化し、リージョンの停止が他のリージョンのお客様のワークスペースに影響を与えないようにしました。

専用のコントロールプレーンを持つようになったリージョンには、次の 2 つの構成で実行されているワークスペースがあります。

  • レガシーワークスペース - 専用コントロールプレーンが利用可能になる前に作成されたワークスペースです。
  • ワークスペース - 専用コントロールプレーンが使用可能になった後に作成されたワークスペースです。

リージョン内コントロール プレーンを使用するようにレガシ ワークスペースを移行するためのパスは、再デプロイ です。

Microsoft のドキュメントで各リージョンで使用されているネットワーク アドレスの一覧を確認し、コントロール プレーンを共有しているリージョンを特定します。たとえば、テーブルでカナダ東部を検索すると、その SCC リレーのアドレスが “tunnel.canadacentral.azuredatabricks.net” であることがわかります。リレー アドレスはカナダ中部にあるため、「カナダ東部」が別のリージョンでコントロール プレーンを使用していることがわかります。

一部のリージョンでは、Azure Databricks コントロール プレーン ネットワーク テーブルに 2 つの異なるアドレスが一覧表示されます。たとえば、北ヨーロッパでは、SCC リレー アドレスに「tunnel.westeurope.azuredatabricks.net」と「tunnel.northeuropec2.azuredatabricks.net」の両方がリストされます。これは、北ヨーロッパがかつて西ヨーロッパのコントロールプレーンを共有していましたが、現在は独自の独立したコントロールプレーンを持っているためです。北ヨーロッパには、古いコントロール プレーンに関連付けられた古いレガシ ワークスペースがまだいくつかありますが、切り替え以降に作成されたすべてのワークスペースは、新しいコントロール プレーンを使用します。

新しい Azure Databricks ワークスペースが作成されたら、元のレガシ ワークスペースと一致するように構成する必要があります。 Databricks, Inc.(データブリックス) では、初期コピーとワークスペースの保守の両方に Databricks Terraform Exporter を使用することをお勧めします。ただし、このエクスポーターはまだ実験段階にあります。実験的なプロジェクトを信頼しないお客様や、Terraform を使用したくない場合は、Databricks, Inc. が GitHub で管理している “移行” ツールを使用できます。これは、すべてのオブジェクト (ノートブック、クラスター定義、メタデータなど) を 1 つのワークスペースからエクスポートし、それらを別のワークスペースにインポートするスクリプトのコレクションです。 お客様は “移行” ツールを使用して、新しい ワークスペースに移動し、CI/CD デプロイ プロセスを使用してワークスペースの同期を維持します。

上級者のヒント: 特定の Databricks ワークスペースのコントロール プレーンがどこにあるかを判断する必要がある場合は、ワークスペース アドレスを指定して Windows または Linux で “nslookup” コンソール コマンドを使用できます。 結果から、コントロールプレーンがどこにあるかがわかります。

Resources



DBW-30 - 代替 VM SKU を定義します

Category: System Efficiency

Impact: Medium

Guidance

Azure Databricks の可用性計画には、容量の制約に基づいて VM SKU をスワップする計画を含める必要があります。

Azure Databricks は、その VM をリージョン VM として作成し、VM に最適な可用性ゾーンを選択するために Azure に依存します。 過去には、ゾーンまたはリージョンの VM の制約のためにコンピューティングを割り当てられないまれなインスタンスがありました。 したがって、「CLOUD PROVIDER」エラーが発生します。

このような状況では、お客様には 2 つのオプションがあります。

  • Databricks プールを使用します。 コストを管理するには、プールのサイズを選択する際に注意が必要です。Azure VM がプール内でアイドル状態の場合でも、その料金を支払う必要があります。 Databricks プールに含めることができる VM の SKU は 1 つだけです。同じプールに複数のSKUを混在させることはできません。お客様が管理する必要があるプールの数を減らすには、別の VM を使用する代わりに、ジョブを処理するいくつかの SKU に落ち着く必要があります 各ジョブの SKU。
  • 優先リージョンの代替 SKU を計画する。

Resources

Resource Graph Query

// under-development