背景・目的
Databricksのコンピュートについて整理します。
まとめ
下記の特徴があります。
- Databricksのコンピュートのワークロードは、下記の通り
- 本番運用 ETL パイプライン
- ストリーミング アナリティクス
- アドホック アナリティクス
- 機械学習
- 下記のコンピュートタイプがある。
- 汎用コンピュート
- ジョブコンピュート
- SQL Warehouse
概要
コンピュートを元に整理しました。
Databricks コンピュートは、本番運用 ETL パイプライン、ストリーミング アナリティクス、アドホック アナリティクス、機械学習など、 データエンジニアリング、データサイエンス、データ アナリティクスのワークロードを実行するコンピューティング リソースと構成です。 ワークスペースのコンピュート リソースは、ワークスペースの [コンピュート ] セクションを使用して作成および管理できます。
- Databricksのコンピュートは、下記のようなワークロードを実行するために利用します。
- 本番運用 ETL パイプライン
- ストリーミング アナリティクス
- アドホック アナリティクス
- 機械学習
下記の種類のコンピュートが使用できます。
- 汎用コンピュート
- 対話型ノートブックを使用してデータを共同で分析するために使用する。
- ジョブコンピュート
- 高速で堅牢な自動ジョブを実行するために使用される。
- Databricks ジョブスケジューラは、新しいコンピュートでジョブを実行すると、ジョブ コンピュートを作成する。
- コンピュートは、ジョブが完了すると終了する。
- ジョブクラスターは再起動できない。
- SQL Warehouse
- Databricks SQL 内のデータ オブジェクトに対して SQL コマンドを実行するために使用される。
- SQLウェアハウスは、UI、CLI、またはREST APIを使用して作成できる
- インスタンス・プール
- アイドル状態のすぐに使用できるインスタンスでコンピューティングし、開始時間とオートスケール時間を短縮するために使用される。
Databricks Runtime
Databricks Runtime は、コンピュートで実行されるコア コンポーネントのセットです。 Databricks Runtime の各バージョンには、ビッグデータ分析の使いやすさ、パフォーマンス、セキュリティを向上させる更新プログラムが含まれています。 コンピュート上の Databricks Runtime には、次のような多くの機能が追加されています。
- Delta Lake は、Apache Spark 上に構築された次世代のストレージ レイヤーで、データパイプラインを構築するための ACIDトランザクション、最適化されたレイアウトとインデックス、実行エンジンの改善を提供します。 「Delta Lake とは」を参照してください。
- Java、Scala、Python、R ライブラリをインストールしました。
- Ubuntuとそれに付随するシステムライブラリ。
- GPU 対応クラスターの GPU ライブラリ。
- プラットフォームの他のコンポーネント (ノートブック、ジョブ、クラスター管理など) と統合される Databricks サービス。
- Databricks Runtimeはコンピュートで実行されるコアコンポーネント
- Databricks Runtimeの各バージョンには、ビッグデータ分析の使いやすさ、パフォーマンス、セキュリティを向上させる更新プログラムが含まれる。
- GPU対応クラスターのGPUライブラリが含まれる
- Java、Scala、Python、Rライブラリ
- 他のコンポーネントと統合されるDatabricksサービス
汎用コンピューティング
ポリシー
ポリシー は、ユーザーがクラスターを作成するときに使用できる構成オプションを制限するために管理者が使用する一連のルールです。 ポリシーに従ってクラスターを構成するには、 [ ポリシー ] ドロップダウンからポリシーを選択します。
- ポリシーは、ユーザがクラスタを作成するときに使用する構成オプションを制限するためのルール
コンピュートポリシーの作成と管理
コンピュートポリシーの作成と管理を元に整理します。
コンピュート ポリシーとは何ですか?
ポリシーは、ワークスペース管理者が一連のポリシー ルールに基づいてユーザーまたはグループのコンピュート作成アクセス許可を制限するために使用できるツールです。
ポリシーには、次の利点があります。
- ユーザーによるクラスターの作成を所定の設定に制限します。
- ユーザーによるクラスターの作成を特定の数に制限します。
（一部の値を修正および非表示にすることによって）ユーザーインターフェースを簡素化し、より多くのユーザーが独自のクラスターを作成できるようにします。- クラスターごとの最大コストを制限してコストを制御します（時間単位の価格に寄与する値を持つ属性に制限を設定します）。
- クラスター スコープのライブラリのインストールを強制します。
- クラスタの作成を所定の設定に制限する
- クラスタの作成を特定の数に制限する
- クラスタごとのコストを制御する
- ライブラリのインストールを強制する
パーソナルコンピューティングポリシー
デフォルトでは、すべてのユーザーが個人用コンピュート ポリシーにアクセスでき、単一マシンのコンピュート リソースを作成できます。 クラスターの作成時に [Personal conピュート] ポリシーがオプションとして表示されない場合は、ポリシーへのアクセス権が付与されていません。 ワークスペース管理者に問い合わせて、パーソナル・コンピュート・ポリシーまたは適切な同等のポリシーへのアクセスを要求してください。
- デフォルトでは、個人用のコンピュートポリシーにアクセスでき、コンピュートリソースを作成できる
アクセスモード
クラスターアクセスモードは、クラスターを使用できるユーザーと、クラスターを介してアクセスできるデータを決定するセキュリティ機能です。Databricksでクラスターを作成するときは、アクセスモードを選択する必要があります。
- クラスターアクセスモードは、クラスタを使用できるユーザと、クラスタを介してアクセスできるデータを決定するセキュリティ機能
- クラスタ作成時に、アクセスモードを選択する必要がある
| Access Mode | Visible to user | UC Support | Supported Languages | Notes |
|---|---|---|---|---|
| Single user | 常に | Python SQL Scala R |
1人のユーザに割り当てて使用できる | |
| Shared | 常に | Python SQL Scala |
ユーザ間でデータを分離することで、複数のユーザが使用できる | |
| No Isolation Shared | 管理者は、非表示にできる | Python、SQL、Scala、R | 分離なし共有クラスターに関連するアカウントレベルの設定がある | |
| Custom | 非常時 | Python、SQL、Scala、R | アクセスモードが指定されない既存のクラスターがある場合にのみ表示される |
ワーカー ノードとドライバー ノードの種類
クラスターは、1つのドライバーノードと0個以上のワーカーノードで構成されます。ドライバーノードとワーカーノードに別々のクラウドプロバイダーインスタンスタイプを選択できますが、デフォルトでは、ドライバーノードはワーカーノードと同じインスタンスタイプを使用します。インスタンスタイプのファミリーが異なれば、メモリ集約型またはコンピュート集約型のワークロードなど、さまざまなユースケースに適合します。
- クラスタは、1つのドライバーノードと0個以上のワーカーノードで構成される
- ドライバノードとワーカーノードに別々のインスタんタイプを指定できるが、デフォルトでは同じ
ワーカー type
Databricksワーカーノードは、クラスターが適切に機能するために必要なSparkエグゼキューターとその他のサービスを実行します。Sparkを使用してワークロードを分散すると、すべての分散処理がワーカーノードで行われます。Databricksでは、ワーカーノードごとに1つのエグゼキューターを実行します。そのため、エグゼキューターとワーカーという用語は、Databricksアーキテクチャのコンテキストでは同じ意味で使用されます。
- Databricksでは、ワーカーノードに1つのExecutorを実行する
- つまり、Executor＝Worker
ワーカーノードのIPアドレス
Databricksは、それぞれ2つのプライベートIPアドレスを持つワーカーノードを起動します。ノードのプライマリプライベート IP アドレスは、Databricksの内部トラフィックをホストします。セカンダリプライベートIPアドレスは、クラスター内通信のためにSparkコンテナーで使用されます。このモデルにより、Databricksでは同じワークスペース内の複数のクラスター間の分離が可能となります。
- 2つのプライベートIPアドレスを持つワーカーノードを起動する
- プライマリプライベートIPアドレスは、Databricksの内部のトラフィックをホストする
- セカンダリIPアドレスは、クラスタ内通信のためにSparkコンテナで使用される
ドライバーの種類
ドライバーノードは、クラスターに接続されているすべてのノートブックの状態情報を保持します。また、ドライバーノードはSparkContextを維持し、クラスター上のノートブックまたはライブラリから実行するすべてのコマンドを解釈し、Sparkエグゼキューターと連携するApache Sparkマスターを実行します。
- クラスタに接続されているすべてのノートブックの状態情報を保持する
- ドライバーノードは
- SparkContextを維持する
- Sparkのマスターを実行する
- ドライバーノードは
ドライバーノードタイプのデフォルト値は、ワーカーノードタイプと同じです。 Sparkワーカーから大量のデータをcollect()により収集してノートブックで分析する場合は、より多くのメモリを備えたより大きなドライバーノードの種類を選択できます。
- デフォルトではワーカーノードタイプと同じノードタイプ
GPUインスタンスタイプ
ディープラーニングに関連するタスクなど、高いパフォーマンスを必要とする計算量が多いタスクの場合、Databricksはグラフィックス処理装置（GPU）で高速化されたクラスターをサポートします。詳細については、「GPU対応クラスター」を参照してください。
AWS Graviton instance types
Databricks クラスターでは、 AWS Graviton インスタンスがサポートされています。 これらのインスタンスは、Arm64 命令セットアーキテクチャ上に構築された AWS 設計の Graviton プロセッサを使用します。 AWS は、これらのプロセッサを搭載したインスタンスタイプは、Amazon EC2 のどのインスタンスタイプよりも価格対パフォーマンス比が高いと主張しています。 Graviton インスタンスタイプを使用するには、[Worker type] (ワーカータイプ)、[Driver type] (ドライバータイプ)、またはその両方で使用可能な AWS Graviton インスタンスタイプのいずれかを選択します。#### 入手方法
Databricks は、AWS Graviton 対応クラスターをサポートしています。
- Photon 以外の場合は Databricks Runtime 9.1 LTS 以降、Photon の場合は Databricks Runtime 10.2 (サポート対象外) 以降。
- すべての AWS リージョン。 ただし、すべてのインスタンスタイプがすべてのリージョンで使用できるわけではないことに注意してください。 ワークスペースのリージョンで使用できないインスタンスタイプを選択すると、クラスターの作成が失敗します。
- AWS Graviton2 および Graviton3 プロセッサの場合。
- Grabitonをサポートしている
Enable オートスケール
[ Enable autoscale ] をオンにすると、クラスターのワーカーの最小数と最大数を指定できます。 その後、Databricks によって、ジョブの実行に必要な適切な数のワーカーが選択されます。
クラスターがオートスケールするワーカーの最小数と最大数を設定するには、[ワーカーの種類] ドロップダウンの横にある [最小ワーカー] フィールドと [最大ワーカー] フィールドを使用します。
オートスケールを有効にしない場合は、ワーカー タイプ ドロップダウンの横にある ワーカー フィールドに固定数のワーカーを入力します。
- オートスケールにより、ワーカー数が増減する
オートスケールのメリット
オートスケーリングを使用すると、Databricksはジョブの特性を考慮してワーカーを動的にアカウントに再割り当てします。パイプラインの特定の部分は他の部分よりも計算負荷が高い場合があり、Databricksはジョブのこれらのフェーズ中にワーカーを自動的に追加（さらに、ワーカーが不要になったときにワーカーを削除）します。
- 動的にワーカーをアサインする
オートスケールを使用すると、ワークロードに合わせてクラスターをプロビジョニングする必要がないため、高いクラスター使用率を簡単に実現できます。 これは特に、時間の経過と共に要件が変化するワークロード (1 日のうちにデータセットを探索するなど) に適用されますが、プロビジョニング要件が不明な 1 回限りの短いワークロードにも適用できます。 したがって、オートスケールには2つの利点があります。
- ワークロードは、固定サイズのプロビジョニング不足のクラスターと比較して高速に実行できます。
- クラスターのオートスケーリングでは、静的サイズのクラスターと比較して全体的なコストを削減できます。
- 変化の激しいワークロードで有効
- コスト削減につながる
クラスターとワークロードの固定サイズに応じて、オートスケーリングでは、これらの利点の一方または両方が同時に実現されます。クラスターのサイズは、クラウドプロバイダーがインスタンスを終了するときに選択されたワーカーの最小数を下回る可能性があります。 この場合、Databricksは、ワーカーの最小数を維持するために、インスタンスの再プロビジョニングを継続的に再試行します。
- クラウドプロバイダーにより、インスタンスがTerminateするときに、選択されたワーカの最小数を下回る可能性がある。このとき、最プロビジョニングする
オートスケーリングの動作
Premium および Enterprise 料金プランのワークスペースでは、最適化されたオートスケールが使用されます。 標準料金プランのワークスペースでは、標準のオートスケールが使用されます。
最適化されたオートスケールには、次の特性があります。
- 2つのステップで最小から最大にスケールアップします。
- クラスターがアイドル状態でない場合でも、シャッフル ファイルの状態を確認することでスケールダウンできます。
- 現在のノードの割合に基づいてスケールダウンします。
- ジョブクラスターでは、過去40秒間にクラスターが十分に活用されていない場合にスケールダウンします。
- All-Purposeクラスターでは、過去150秒間にクラスターが十分に活用されていない場合にスケールダウンします。
- spark.databricks.aggressiveWindowDownS Spark 構成プロパティは、クラスターがダウンスケーリングの決定を行う頻度を秒単位で指定します。値を大きくすると、クラスターのスケールダウンが遅くなります。 最大値は600です。
- PremiumとEnterpriseでは、最適化されたオートスケールが利用される
- 標準の料金プランでは、標準のオートスケール
- 現在のノードの割合に基づきスケールダウンする
- ジョブクラスターでは、過去40秒間にクラスターが十分に活用されない場合にスケールダウンする
- All-Purposeクラスタでは、過去150秒間にクラスターが十分に活用されてない場合にスケールダウンする
Standard オートスケールは、Standard プランのワークスペースで使用されます。 標準オートスケールには、次の特徴があります。
- 8 つのノードを追加することから始めます。 その後、指数関数的にスケールアップし、最大値に達するために必要な数のステップを実行します。
- ノードの 90% が 10 分間ビジー状態ではなく、クラスターが 30 秒以上アイドル状態になると、スケールダウンします。
- 1 ノードから指数関数的にスケールダウンします。
オートスケール local storage
クラスター作成時に固定数の EBS ボリュームを割り当てない場合は、オートスケールローカルストレージを使用します。 オートスケール ローカル ストレージを使用すると、Databricks はクラスターの Spark ワーカーで使用可能な空きディスク領域の量を監視します。 ワーカーの実行がディスクの少なすぎる状態になると、Databricks は、ディスク領域が不足する前に、新しい EBS ボリュームをワーカーに自動的にアタッチします。 EBS ボリュームは、インスタンスあたり (インスタンスのローカルストレージを含む) の合計ディスク容量が 5 TB まで制限されてアタッチされます。
- クラスタ作成時に固定数のEBSボリュームを割り当てない場合、オートスケールローカルストレージを使用する
- オートスケールローカルストレージでは、
- DatabricksはクラスタのSparkワーカーで使用可能な空きディスクの領域の量を監視し、ワーカーの実行がディスクが少なすぎる状態になると、Databricksはディスク領域が不足する前に、新しいEBSボリュームをワーカーに自動的にアタッチする
- 5TBまでアタッチされる。
オートスケールストレージを設定するには、[ Enable autoscale local storage] (オートスケールローカルストレージを有効にする) を選択します。
インスタンスにアタッチされた EBS ボリュームは、インスタンスが AWS に返却されたときにのみデタッチされます。 つまり、EBS ボリュームは、稼働中のクラスターの一部である限り、インスタンスからデタッチされることはありません。 EBS の使用をスケールダウンするには、 オートスケール コンピュート または 自動終了で構成されたクラスターでこの機能を使用することをお勧めします。
- EBSボリュームは、インスタンスがAWSに戻されたときにデタッチされる
- オートスケール、自動終了で構成されたクラスタでの使用を推奨
ローカルディスクの暗号化
クラスターの実行に使用する一部のインスタンスタイプには、ローカルにアタッチされたディスクがある場合があります。 Databricks は、これらのローカルに接続されたディスクにシャッフル データまたはエフェメラル データを格納する場合があります。 クラスターのローカルディスクに一時的に保存されるシャッフルデータを含め、すべてのストレージタイプで保存されているすべてのデータが暗号化されるようにするには、ローカルディスクの暗号化を有効にします。
- エフェメラルデータを格納する場合に、暗号化を有効化する
SQLウェアハウスの構成
SQLウェアハウスの構成を元に整理します。
SQLウェアハウスとは
SQLウェアハウスは、Databricks SQL内のデータオブジェクトに対してSQLコマンドを実行できるコンピュートリソースです。コンピュートリソースは、クラウドにおける処理能力を提供するインフラストラクチャ・リソースです。
要件
SQLウェアハウスには、次の要件があります。
- SQLウェアハウスを作成するには、ワークスペース管理者であるか、または、無制限のクラスター作成権限を持つユーザーでなければなりません。
- SQLウェアハウスを管理するには、ワークスペース管理者であるか、または、SQLウェアハウスの[管理可能] 権限を持っている必要があります。
- この機能をサポートするリージョンでサーバーレスSQLウェアハウスを作成する前に、いくつかの手順が必要とされる場合があります。サーバーレスのSQLウェアハウスを使用するを参照してください。
考察
今まで、なんとなく利用してましたが、あらためて認識したり、新たに下記の気づきを得られました。
- Executor数 = Worker数
- ローカルストレージもオートスケールが可能
参考