Databricksによるコスト管理成熟度の向上：混乱状態から統制された運用へ

導入：データとAI環境におけるFinOpsの重要性

あらゆる業界の企業において、限られたリソースでより大きな成果を上げる効率化への取り組みが継続的に重視されています。特に現在のデータ環境において、デジタルネイティブ企業ではAIやデータ集約型ワークロードへの需要が急速に高まっています。これらの組織は、さまざまなクラウドやプラットフォーム環境で数千のリソースを管理しています。イノベーションの創出と迅速な反復開発を実現するため、これらのリソースはチームやビジネスユニット全体で民主化されています。しかし、データ実務者の開発速度向上は、適切なコスト管理と両立させなければ運用の混乱を招く恐れがあります。

デジタルネイティブ組織では、クラウドやプラットフォームリソースのコスト管理と統制を担当する中央プラットフォームチーム、DevOpsチーム、またはFinOpsチームを設置することが一般的です。The FinOps Foundation™により体系化されたコスト管理と監督の正式な手法は、Databricksにおいてもタグ付け、予算管理、コンピュートポリシーなどの機能を通じてサポートされています。ただし、コスト管理の優先順位付けと体系的な責任体制の確立を決定しても、コスト管理の成熟度が一朝一夕で向上するわけではありません。本記事で紹介する手法と機能により、チームはデータインテリジェンスプラットフォームにおけるコスト管理を段階的に成熟させることができます。

本記事がカバーする内容：

• コスト配分：タグ付けと予算ポリシーを活用したコスト配分における主要な考慮事項を解説します。
• コストレポーティング：Databricks AI/BIダッシュボードでコストを監視します。
• コストコントロール：Terraform、コンピュートポリシー、Declarative Automation Bundlesを使用したコスト統制の自動化。
• コスト最適化：一般的なDatabricks最適化チェックリスト項目。

エンジニア、アーキテクト、またはFinOps専門家であろうと、このブログは効率を最大化しながらコストを最小化し、Databricks環境が高性能かつコスト効率的であることを確保するのに役立ちます。

技術的な解決策の分析

ここからは、Databricksプラットフォーム上で成熟したコスト管理手法を段階的に実装する方法を説明します。これは混乱状態から統制された運用への「段階的な成長プロセス」と捉えることができます。私たちはこの旅をステップバイステップで実装する方法を説明します。

ステップ1：コスト割り当て

最初のステップは、費用を正しくチーム、プロジェクト、またはワークロードに割り当てることです。これには、すべてのリソース（サーバーレスコンピュートを含む）への効率的なタグ付けを行い、コスト発生箇所を明確に把握することが含まれます。適切な属性付けにより、チーム間での正確な予算策定と責任の明確化が実現できます。

コスト配分は、クラシックコンピュートモデルとサーバーレスコンピュートモデルのいずれにおいても、すべてのコンピュートSKUに対してタグ付け戦略を適用することで実現できます。クラシックコンピュート（ワークフロー、宣言的パイプライン、SQLウェアハウスなど）はクラスター定義のタグを継承し、サーバーレスはサーバーレス予算ポリシー（AWS | Azure | GCP）に準拠します。

一般的に、タグを追加できるリソースは2種類あります：

1. コンピューティングリソース：SQLウェアハウス、ジョブ、インスタンスプールなどを含む。
2. Unity Catalogのセキュリティ可能オブジェクト：カタログ、スキーマ、テーブル、ビューなどを含む。

両方のタイプのリソースにタグを付けることは、効果的なガバナンスと管理に貢献します：

1. 計算リソースのタグ付けは、コスト管理に直接影響を与えます。
2. タグ付けされたUnity Catalogのセキュリティ可能オブジェクトは、整理と検索に役立ちますが、これはこのブログの範囲外です。

この記事（AWS | AZURE | GCP）を参照して、異なるコンピューティングリソースのタグ付けについて詳しく知り、この記事（AWS | Azure | GCP）を参照して、Unity Catalog securablesのタグ付けについて詳しく知ることができます。

クラシックコンピューティングのタグ付け

クラシックコンピューティングでは、コンピューティングを作成する際の設定でタグを指定できます。以下に、UIとDatabricks SDKを使用して、それぞれのコンピューティングタイプに対してタグを定義する方法を示すいくつかの例を示します。

SQLウェアハウスの計算：

SQLウェアハウスのタグは、詳細オプションセクションで設定できます。

Databricks SDKを使用して:

汎用コンピュート

Databricks SDKを使用:

ジョブコンピュート

Databricks SDKを使用:

宣言的パイプライン：

サーバーレスコンピュートのタグ付け

サーバーレスコンピュートの場合、予算ポリシーでタグを割り当てるべきです。ポリシーを作成することで、ポリシー名と文字列キーと値のタグを指定することができます。

これは3ステップのプロセスです：

• ステップ1：予算ポリシーを作成します（ワークスペースの管理者が作成し、管理アクセスを持つユーザーが管理できます）
• ステップ2：ユーザー、グループ、およびサービスプリンシパルに予算ポリシーを割り当てます
• ステップ3：ポリシーが割り当てられると、ユーザーはサーバーレスコンピューティングを使用する際にポリシーを選択する必要があります。ユーザーに割り当てられたポリシーが1つだけの場合、そのポリシーが自動的に選択されます。ユーザーに複数のポリシーが割り当てられている場合、その中から1つを選択することができます。

サーバーレスの予算ポリシーの詳細については、これらの記事（AWS/AZURE/GCP）を参照してください。

予算ポリシーについて考慮すべき特定の側面：

• 予算ポリシーは、予算（AWS | Azure | GCP）とは大きく異なります。ステップ2：コストレポーティングで予算について取り上げます。
• 予算ポリシーはアカウントレベルで存在しますが、ワークスペースから作成および管理することができます。管理者は、特定のワークスペースにポリシーをバインドすることで、ポリシーが適用されるワークスペースを制限できます。
• 予算ポリシーは、サーバーレスのワークロードにのみ適用されます。現在、このブログを書いている時点では、ノートブック、ジョブ、パイプライン、サービングエンドポイント、アプリ、ベクターサーチエンドポイントに適用されます。
• タスクがいくつかあるジョブの例を考えてみましょう。各タスクは自身のコンピューティングを持つことができ、予算ポリシータグはジョブレベルで割り当てられます（タスクレベルではありません）。したがって、1つのタスクがサーバーレスで実行される一方で、他のタスクが一般的な非サーバーレスの計算で実行される可能性があります。次のシナリオで予算ポリシーのタグがどのように動作するか見てみましょう：
  • ケース1：両方のタスクがサーバーレスで実行される
    • この場合、予算ポリシータグはシステムテーブルに伝播します。
  • ケース2：サーバーレスで1つのタスクのみが実行される
    • この場合、予算ポリシータグはサーバーレス計算の使用に対するシステムテーブルにも伝播し、クラシックコンピュートの請求記録はクラスター定義からタグを継承します。
  • ケース3：両方のタスクがサーバーレスでないコンピュートで実行されます
    • この場合、予算ポリシータグはシステムテーブルに伝播しません。

Terraformを使用:

タグに関連するベストプラクティス：

• 一般的なキーの適用を全員に推奨し、より詳細な洞察を求める組織には、その組織に適したきめ細やかなキーの適用を推奨します。
• 固定キーと値について、組織全体で適用したいビジネスポリシーを開発し、全ユーザーと共有するべきです。ステップ4では、タグの値と必要なタグを系統的に制御するために、どのようにコンピュートポリシーが使用されるかを見ていきます。
• タグは大文字と小文字を区別します。タイトルケース、パスカルケース、またはケバブケースなど、一貫性のある読みやすい大文字小文字のスタイルを使用してください。
• 初期のタグ付けコンプライアンスのために、タグを問い合わせて組織のポリシーとの不一致を報告するスケジュールされたジョブを作成することを検討してください。
• すべてのユーザーが少なくとも1つの予算ポリシーに対する権限を持つことを推奨します。そうすることで、ユーザーがサーバーレスコンピュートを使用してノートブック/ジョブ/パイプライン/などを作成するたびに、割り当てられた予算ポリシーが自動的に適用されます。

サンプルタグ - キー：バリューのペア

ステップ2：コストレポーティング

システムテーブル

次に、ステップ1で提供されたコンテキストを使用してコストを監視するコストレポーティングについて説明します。Databricksは、 システムテーブル system.billing.usage などを組み込んでおり、これがコストレポーティングの基盤となります。システムテーブルは、顧客がレポーティングソリューションをカスタマイズしたい場合にも役立ちます。

例えば、次に示すアカウント使用ダッシュボードはDatabricks AI/BIダッシュボードで、すべてのクエリを表示し、ダッシュボードを非常に簡単に自分のニーズに合わせてカスタマイズすることができます。Databricksの使用状況に対して特定のフィルターでアドホッククエリを書く必要がある場合、これを利用できます。

アカウント使用状況ダッシュボード

リソースにタグを付けてコストをコストセンター、チーム、プロジェクト、または環境に割り当て始めると、コストが最も高いエリアを発見することができます。Databricksは、AI/BIダッシュボードとして自分のワークスペースに簡単にインポートできる使用状況ダッシュボードを提供しており、すぐに利用できるコストレポートが得られます。

このダッシュボードの新しいバージョン2.0がプレビューで利用可能で、以下に示すいくつかの改善が含まれています。アカウント使用状況ダッシュボードを以前にインポートしたことがある場合でも、今日GitHubから新しいバージョンをインポートしてください！

このダッシュボードは、以下のようなデータを含む、多くの有用な情報と視覚化を提供します：

• 使用概要、時間経過による総使用量のトレンド、SKUやワークスペースなどのグループ別のハイライト。
• Top N使用量は、job_id、warehouse_id、cluster_id、endpoint_idなどの選択可能な課金対象オブジェクトによるトップ使用量をランク付けします。
• タグに基づいた使用量分析（ステップ1で行うタグ付けが多ければ多いほど、これが有用になります）。
• 今後数週間から数ヶ月にわたる支出がどのようになるかを示すAIの予測。

このダッシュボードでは、日付範囲、ワークスペース、製品によるフィルタリングや、プライベートレートのカスタム割引の入力も可能です。このダッシュボードには多くの機能が詰まっているため、ほとんどのコストレポートニーズに対する主要なワンストップショップとなります。

ジョブ監視ダッシュボード

Lakeflowのジョブについては、リソースベースのコストや最適化の機会などをすばやく確認できるジョブシステムテーブルAI/BIダッシュボードを推奨します。

• 月ごとの潜在的な節約額で見るトップ25のジョブ
• 平均CPU利用率が最も低いトップ10のジョブ
• 平均メモリ利用率が最も高いトップ10のジョブ
• 過去30日間で固定数のワーカーを持つジョブ
• 過去30日間で古いDBRバージョンで実行されているジョブ

DBSQL監視

Databricks SQLの詳細な監視については、当社のSQL SMEブログであるこちらを参照してください。このガイドではDatabricks SQLの専門家が、ユーザー、ソース、さらにはクエリレベルのコストまでSQLのコストを見ることができるきめ細やかなコストモニタリングダッシュボードの設定方法を説明します。

モデルサービング

同様に、モデルサービングのコストを監視するための専門的なダッシュボードもあります！これは、バッチ推論、トークンごとの使用料、プロビジョニングされたスループットエンドポイントなど、より詳細なレポート作成に役立ちます。詳細情報については、この関連ブログをご覧ください。

予算アラート

私たちは以前、サーバーレスコンピュートの使用量を属性付けまたはタグ付けする方法としてサーバーレス予算ポリシーについて話しましたが、Databricksには別の機能として予算（AWS | Azure | GCP）もあります。予算は、アカウント全体の支出を追跡するために使用することも、特定のチーム、プロジェクト、ワークスペースの支出を追跡するためにフィルターを適用することもできます。

予算では、予算がマッチするワークスペースやタグを指定し、金額（USD）を設定すると、予算を超過したときに受信者リストにメールを送ることができます。これは、ユーザーの支出が指定した金額を超えたときに自動的にユーザーに警告するのに役立ちます。予算はSKUのリスト価格を使用することに注意してください。

ステップ3：コストコントロール

次に、チームはデータチームが自己完結型でありながらもコスト意識を持つためのガードレールを設定する能力を持つ必要があります。Databricksは、コンピュートポリシー（AWS | Azure | GCP）を用いて、管理者と実践者の両方に対してこれを簡素化します。

コンピュートポリシーでは、すべてのクラスタ属性やdbu_per_userのような重要な仮想属性など、いくつかの属性を制御することができます。コストコントロールのために特に管理すべき主要な属性をいくつか見直します：

ユーザーごとのDBU制限と最大クラスター数制限

よくあるのは、チームが自己サービスのクラスター作成を可能にするためのコンピューティングポリシーを作成するときに、ユーザーの最大支出を制御したいと思うことです。ここで、コスト制御のための最も重要なポリシー属性の1つ：dbus_per_hourが適用されます。

dbus_per_hourは、ユーザーが作成できるクラスターのDBUコストの下限と上限を設定するために、rangeポリシータイプと一緒に使用することができます。しかし、これはポリシーを使用するクラスターの最大DBUを強制するだけで、このポリシーに権限を持つ単一のユーザーはまだ多くのクラスターを作成することができ、それぞれが指定されたDBU制限で上限が設定されます。

さらに進めて、各ユーザーが無制限の数のクラスターを作成するのを防ぐために、別の設定、max_clusters_by_userを使用することができます。これは実際にはポリシー定義内で見つける属性ではなく、トップレベルのコンピュートポリシー上の設定です。

汎用 vs ジョブクラスターの制御

ポリシーは、cluster_type仮想属性を使用して、どのクラスタータイプを使用できるかを強制するべきです。これは、「all-purpose」、「job」、「dlt」のいずれかになります。ポリシーを作成する際には、fixedタイプを使用して、ポリシーが設計されたクラスタタイプを正確に強制することを推奨します：

一般的なパターンは、ジョブとパイプライン用のポリシーと、汎用クラスター用のポリシーを別々に作成し、汎用クラスター（例：Databricksのデフォルトのパーソナルコンピュート ポリシーの定義方法）に対して max_clusters_by_user を1に設定し、ジョブ用にはユーザーごとのクラスター数を増やすことを許可することです。

インスタンスタイプの強制

VMインスタンスタイプは、allowlistまたはregexタイプを使用して便利に制御することができます。これにより、ユーザーはインスタンスタイプに一部の柔軟性を持たせつつ、高すぎるか予算外のサイズを選択することができます。

最新のDatabricksランタイムを強制する

新しいDatabricks Runtimes（DBR）に常に最新の状態を保つことが重要であり、長期サポート（LTS）リリースを検討することで、サポート期間を延長することができます。コンピューティングポリシーには、 spark_version 属性でこれを簡単に強制するためのいくつかの特別な値があります。以下にその一部を紹介します：

• auto:latest-lts: は最新の長期サポート（LTS）Databricksランタイムバージョンにマッピングされます。
• auto:latest-lts-ml: は最新のLTS Databricks Runtime MLバージョンにマッピングされます。
• また、auto:latest やauto:latest-ml を使用して、最新の一般公開（GA）Databricksランタイムバージョン（またはML）を設定することもできますが、これらはLTSではないかもしれません。
  • 注: これらのオプションは、LTSに到達する前に最新の機能にアクセスする必要がある場合に役立つかもしれません。

ポリシーでspark_versionを制御するために、allowlistタイプを使用することをお勧めします：

スポットインスタンス

クラウド属性もポリシーで制御でき、スポットインスタンスのインスタンス可用性を強制し、オンデマンドにフォールバックするなどが可能です。スポットインスタンスを使用する場合は常に、“first_on_demand”を少なくとも1に設定して、クラスタのドライバノードが常にオンデマンドであるようにするべきです。

AWS上：

Azure上：

GCP上（注：GCPは現在、first_on_demand属性をサポートしていません）：

タグ付けの強制

上で見たように、タグ付けは、組織がコストを割り当てて詳細レベルで報告する能力にとって重要です。Databricksで一貫したタグを強制する際に考慮すべき2つのことがあります：

1. custom_tags.属性を制御するコンピュートポリシー。
2. サーバーレスの場合は、ステップ1で議論したように、サーバーレス予算ポリシーを使用してください。

コンピュートポリシーでは、タグ名でそれらを接尾辞として付けることで、複数のカスタムタグを制御することができます。ユーザーの手動入力を減らすために、可能な限り多くの固定タグを使用することを推奨しますが、allowlistは複数の選択肢を許しつつ値を一貫性を保つのに優れています。

ウェアハウスのクエリタイムアウト

長時間実行されるSQLクエリは非常に高価で、多くのクエリがキューに入ると他のクエリを混乱させることもあります。長時間実行されるSQLクエリは、最適化されていないクエリ（フィルターが不十分または全くない）や最適化されていないテーブルが原因であることが多いです。

管理者は、ワークスペースレベルでステートメントタイムアウトを設定することでこれを制御できます。ワークスペースレベルのタイムアウトを設定するには、ワークスペースの管理設定に移動し、Computeをクリックし、次にSQLウェアハウスの横にあるManageをクリックします。SQL設定パラメータ設定で、タイムアウト値が秒単位の設定パラメータを追加します。

モデルのレート制限

MLモデルとLLMも、リクエストが多すぎると乱用され、予期しないコストが発生する可能性があります。Databricksは、モデルサービングエンドポイントに対して使用量の追跡とレート制限をAI Gatewayで簡単に提供します。

エンドポイント全体またはユーザーごとにレート制限を設定することができます。これはDatabricks UI、SDK、API、またはTerraformで設定することができます。例えば、Terraformを使用してレート制限付きのFoundation Modelエンドポイントをデプロイすることができます:

実用的なコンピュートポリシーの例

実際のコンピューティングポリシーの例については、こちらのソリューションアクセラレーターをご覧ください: https://github.com/databricks-industry-solutions/cluster-policy  

ステップ4：コスト最適化

最後に、ワークスペース、クラスタ、ストレージレイヤで確認できるいくつかの最適化を見てみましょう。これらのほとんどは自動的に確認および/または実装できるもので、これについて探ってみましょう。いくつかの最適化はコンピュートレベルで行われます。これには、VMインスタンスタイプの適切なサイズ設定、Photonを使用するタイミングの把握、適切なコンピューティングタイプの選択などが含まれます。

最適なリソースの選択

• 汎用の代わりにジョブコンピュートを使用します（これについては次に詳しく説明します）。
• 最高のコスト効率を得るために、SQL専用のワークロードにはSQLウェアハウスを使用します。
• 最新のパッチとパフォーマンスの改善を受け取るために、最新のランタイムを使用してください。例えば、DBR 17.0はSpark 4.0 (ブログ) を採用しており、多くのパフォーマンス最適化を含んでいます。
• サーバーレスを使用すると、起動、終了が早く、総所有コスト（TCO）も改善します。
• 連続ストリーミングやAvailableNowトリガーを使用していない限り、オートスケーリングワーカーを使用してください。
  • Lakeflow Declarative Pipelinesの進歩により、Enhanced Autoscalingという機能のおかげで、ストリーミングワークロードに対するオートスケーリングがうまく機能します（AWS | Azure | GCP）。
• 正しいVMインスタンスタイプを選択します：
  • 新世代のインスタンスタイプと現代のプロセッサアーキテクチャは通常、パフォーマンスが良く、コストも低くなることが多いです。例えば、AWSでは、DatabricksはGraviton対応のVM（例えば、c7g.xlargeの代わりにc7i.xlarge); これらは最大3倍のコストパフォーマンスをもたらす可能性があります(ブログ)。
  • ほとんどのMLワークロードに対してメモリ最適化。例えば、r7g.2xlarge
  • ストリーミングワークロードに最適化された計算。例：c6i.4xlarge
  • ストレージ最適化は、ディスクキャッシングから利益を得るワークロード（アドホックおよび対話型データ分析）に適しています。例えば、i4g.xlargeとc7gd.2xlarge。
  • GPUインスタンスは、GPUアクセラレーションライブラリを使用するワークロードにのみ使用してください。さらに、分散トレーニングを行っていない限り、クラスタは単一ノードであるべきです。
  • それ以外の一般的な目的では例えば、m7g.xlarge。
  • DevやStageのような下位の環境では、SpotまたはSpot Fleetインスタンスを使用します。

汎用コンピュートでのジョブの実行を避ける

コストコントロールで述べたように、クラスタのコストは、ジョブコンピュートを使用して自動化されたジョブを実行することで最適化できます。正確な価格はプロモーションやアクティブな割引による場合がありますが、ジョブコンピュートは通常、汎用コンピュートよりも2-3倍安価です。

ジョブコンピュートは、各作業ごとに新しいコンピュートインスタンスを提供し、作業負荷を互いに隔離しながら、マルチタスクワークフローがすべてのタスクでコンピュートリソースを再利用することを許可します。ジョブコンピュートを設定する方法は次をご覧ください (AWS | Azure | GCP)。

Databricks Systemテーブルを使用して、以下のクエリを使用して、インタラクティブな汎用クラスターで実行中のジョブを見つけることができます。これは、あなたのワークスペースに簡単にインポートできるJobs System Tables AI/BI Dashboardの一部としても含まれています！

汎用クラスタと連続ジョブのPhotonを監視

Photonは、Databricks Data + AI Platform上のSpark用に最適化されたベクトル化エンジンで、非常に高速なクエリパフォーマンスを提供します。Photonは、ジョブクラスターでは2.9倍、汎用クラスターでは約2倍、クラスターのDBUコストを増加させます。DBUの乗数にもかかわらず、Photonはランタイムの期間を短縮することでジョブの全体的なTCOを低減することができます。

一方、汎用クラスターは、ユーザーがコマンドを実行していないときに大量のアイドル時間が発生する可能性があります。汎用クラスターに自動終了設定が適用されていることを確認し、このアイドルコンピューティングコストを最小限に抑えてください。常にそうとは限りませんが、これによりPhotonのコストが高くなる可能性があります。この観点では、サーバーレスノートブックも非常に適しています。なぜなら、アイドル時の支出を最小限に抑え、Photonを使用して最高のパフォーマンスを発揮し、セッションを数秒で立ち上げることができるからです。

同様に、Photonは24時間365日稼働する連続ストリーミングジョブには必ずしも有益ではありません。Photonを使用するときに必要なワーカーノードの数を減らすことができるかどうかを監視し、これによりTCOが低下する場合は、そうでなければPhotonは連続ジョブに適していないかもしれません。

注：以下のクエリは、Photonで設定されたインタラクティブクラスターを見つけるために使用できます：

データストレージとパイプラインの最適化

データ、ストレージ、Sparkの最適化戦略はここでは取り扱いきれません。幸いなことに、DatabricksはこれらをDatabricks、Spark、Delta Lakeワークロードの最適化に関する包括的ガイドにまとめており、データレイアウトやスキューからDeltaテーブルのマージの最適化まで、すべてをカバーしています。Databricksは、パフォーマンス最適化のためのさらなるヒントを提供するビッグブックオブデータエンジニアリングも提供しています。

実世界のアプリケーション

組織のベストプラクティス

組織の構造と所有権のベストプラクティスは、次に進む技術的な解決策と同じくらい重要です。

Databricks Platformを含む高度に効果的なFinOpsの実践を行っているデジタルネイティブは、組織内で以下のことを優先しています:

• プラットフォーム管理と監視の明確な所有権。
• プロジェクト前、中、後でのソリューションコストの考慮。
• 継続的な改善の文化 - 常に最適化しています。

これらはFinOpsのための最も成功した組織構造の一部です:

• 中央集権型（例：エクセレンスセンター、ハブアンドスポーク）
  • これは、FinOpsを担当し、ポリシー、コントロール、ツールを他のチームに配布する中央のプラットフォームまたはデータチームの形を取る可能性があります。
• ハイブリッド/分散予算センター
  • 集中型モデルを異なるドメイン固有のチームに分散します。大きなプラットフォームとFinOpsの実践をローカライズされたプロセスと優先順位と一致させるために、そのドメイン/チームに一人以上の管理者が委任されている可能性があります。

センターオブエクセレンスの例

センターオブエクセレンスには、コアプラットフォームの管理を集中化し、ポリシーやバンドルテンプレートなどの安全で再利用可能なアセットでビジネスユニットを強化するなど、多くの利点があります。

センター・オブ・エクセレンスは、データプラットフォーム、プラットフォームエンジニア、データオペレーションズチームなどを中心、または「ハブ」として配置し、ハブアンドスポークモデルを採用することが多いです。このチームは、使用ダッシュボードを使ってコストを割り当て、報告する責任があります。チームが最適でコスト意識の高い自己サービス環境を提供するために、プラットフォームチームは、ユースケースやビジネスユニット（「スポーク」）に合わせたコンピューティングポリシーと予算ポリシーを作成するべきです。必須ではありませんが、これらのアーティファクトをTerraformとVCSで管理することをお勧めします。これにより、強固な一貫性、バージョニング、モジュール化の能力が得られます。

主要なポイント

これは、Databricksでコストをコントロールするためのかなり詳細なガイドであり、途中でいくつかのことをカバーしてきました。要約すると、段階的な成長プロセスは次のようなものです：

1. コスト割り当て
2. コストレポーティング
3. コストコントロール
4. コスト最適化

最後に、最も重要なポイントをいくつか再確認します：

• 堅実なタグ付けは、すべての良好なコスト割り当てと報告の基盤です。高品質なタグを強制するためにコンピュートポリシーを使用します。
• 使用状況ダッシュボードをインポートして、Databricksの支出の報告と予測の主要な停止点にします。
• ジョブシステムテーブルAI/BIダッシュボードをインポートして、コスト節約の機会を持つジョブを監視し、見つけます。
• クラスター作成に対するコスト制御とリソース制限を強制するためにコンピュートポリシーを使用してください。

次のステップ

今日始めて、最初のコンピュートポリシーを作成するか、私たちのポリシーの例の1つを使用してください。その後、使用状況ダッシュボードをインポートして、Databricksの支出の報告と予測の主要な停止点として使用します。先に共有したステップ3からの最適化をクラスタ、ワークスペース、データに対してチェックオフしてください。以前に共有したステップ3の最適化を、クラスター、ワークスペース、データに対してチェックオフします。

Databricksのデリバリーソリューションアーキテクト（DSA）は、組織全体のデータとAIのイニシアチブを加速します。彼らはアーキテクチャリーダーシップを提供し、プラットフォームのコストとパフォーマンスを最適化し、開発者体験を向上させ、プロジェクトの成功を推進します。DSAは初期デプロイメントと本番環境のソリューションの間のギャップを埋め、データエンジニアリング、技術リーダー、エグゼクティブ、その他のステークホルダーを含むさまざまなチームと密接に連携して、カスタマイズされたソリューションとより早い価値提供を確実にします。DSAからのカスタム実行プラン、戦略的ガイダンス、およびデータとAIの旅を通じたサポートを受けるためには、Databricksアカウントチームにご連絡ください。