Databricksのコストを把握するためのシステムテーブルクエリ トップ5

Databricks システムテーブルは、Databricksの使用状況やコストに関する豊富な情報を提供します。コストに焦点を当てると、 `system.billing.usage` テーブルは、Databricksアカウント全体のコストをグローバルに集計したビューを提供します。これと `system.billing.list_prices` を組み合わせることで、どこに費用が配分されているかについて深い洞察を得ることができます。Databricksは、コストを理解するための優れた出発点となる、事前構築済みの 使用状況ダッシュボードを提供していますが、基盤となるテーブルを理解し、それらに対するクエリを作成することで、特にDatabricksのビジュアライゼーション機能を活用する場合に、洞察を次のレベルへと引き上げることができます。

以下は、支出をより深く理解するための出発点として使用できる5つのクエリです。まずは製品別のシンプルな日次支出内訳から始め、次に特定の SQL Warehouses やタグの観点から支出を理解し、最終的には異常な支出が発生した日を特定するとともに、AI を使用して将来の支出を予測します。すべてのクエリは返された結果を通じて洞察を提供しますが、データを可視化し、Genie でさらに詳しく調査できる AI/BI ダッシュボードのデータセットとして使用すると、さらに効果的です。

クエリ 1：製品別の日次支出

クエリが示す内容

最初のクエリは、日別および製品別の支出のシンプルな内訳です。使用状況テーブル（ファクト）と価格設定テーブル（SCD Type 2 ディメンション）を結合して、リスト価格での経時的な支出を取得します。前述のように、提供されているリスト価格テーブルを、関連する割引を反映したカスタムテーブルに置き換えて、正確なコストを確認することもできます。

クエリを使用するタイミング

このクエリは、Databricks環境がどのように使用されているか、どの製品の使用量が増減しているか、および総支出がどのくらいか把握するのに最適です。Databricksの支出を調査する際は、常にここから始めることをお勧めします。

注意点

`system.billing.usage` には Databricks のコストのみが含まれます。つまり、サーバーレス以外のコンピュートが使用されている場合、クラウドインフラストラクチャの支出は含まれないため、関連するクラウドコンソール（コンピュート、ネットワーク、ストレージなど）で確認する必要があります。

クエリ 2：ウェアハウスのコストトレンド

クエリが示す内容

Databricks SQL Warehouses は、SQLアナリスト、ダッシュボード、Genie エージェントを強力にサポートする非常に強力なツールであり、そのコストトレンドを理解することは Databricks アカウントを管理するすべての人にとって極めて重要です。クエリ2を使用すると、ウェアハウスの日次使用量のトレンドを確認できます。消費量に応じて支払う仕組みであるため、これは使用状況のトレンドを把握することと同義です。

クエリを使用するタイミング

Databricksでは消費量に応じて支払いが発生するため、ウェアハウスのコストトレンドを確認することは、その使用状況のトレンドを確認することと同じです（少なくとも稼働時間が使用状況に連動するという意味において）。したがって、このクエリは本質的にウェアハウスの使用状況を示すことができ、使用量が多い場合は稼働時間が長いか、スケールアップしている時間が長いことが原因と考えられます。このクエリで詳細な分析対象となるウェアハウスを特定した後、 `system.compute.warehouse_events` システムテーブルや ウェアハウスのモニタリングページを使用してそのウェアハウスをさらに調査し、異なるスケーリングや自動停止設定を適用できるかどうかを確認できます。また、ウェアハウスの使用状況から、その上に構築されたダッシュボードや Genie スペースがどのように使用されているかを素早く把握し、ビジネスユーザーへのプロモーションをさらに行うべきかどうかを判断することもできます。

注意点

デフォルトでは、このクエリには、削除されたものも含め、調査対象の期間中にアクティブだったすべてのウェアハウスが含まれます。削除されたウェアハウスを分析から除外したい場合は、フィルターとして使用できる列（is_deleted）が含まれています。

クエリ 3：タグベースのコスト配分

クエリが示す内容

タグは、ユーザー、プロジェクト、チーム、またはワークスペース全体の利用状況を追跡するために使用できる強力な機能です。具体的には、カスタムタグはコンピュートポリシーを介して強制適用でき、さらにサーバーレス利用ポリシーでも強制適用できます。その後、システムテーブルの利用状況データを分析する際にそれらのタグを使用できます。例えば、許可される値がマーケティング、財務、エンジニアリングなどのビジネスユニットにマッピングされるように、チームごとのタグ付けを強制することを選択できます。そして、グループ化するタグをパラメータ化したこのクエリを使用することで、チームごとの利用状況を確認できます。

クエリを使用するタイミング

このクエリは、タグ付け戦略が採用されており、タグの値に基づいてコストを確認したい場合にいつでも使用できます。テーブル内のすべてのレコードにタグを付ける必要はありません。レコードにタグキーが存在しない場合、それは「タグなし」として記録され、分析からフィルタリングして除外したり、タグ付けが適切に強制されていない場所を特定したりするために使用できます。

注意点

前述のように、タグ付けされていないレコードは「タグなし」として返されます。これは、タグ付けが強制されていない領域を特定するのに役立ちますが、タグが利用状況の一部にしか関連していない場合には好ましくないこともあります。where句に `u.custom_tags[:tag_key] is not null` を含めることでクエリを修正し、タグのないレコードを完全に除外することができます。また、複数のタグでフィルタリングしたり、クエリの `group by` に複数のタグを追加したりして、さらに詳細にカスタマイズすることもできます。

クエリ 4：日次のコスト異常検知

クエリが示す内容

コンピュートポリシー、ジョブのタイムアウト設定、予算による適切な制御は、Databricksプラットフォーム管理者が支出を制限内に抑えるのに役立ちます。しかし、十分な権限を持つユーザーが、長時間実行されたり予想を超えてスケールしたままになったりするジョブやウェアハウスを作成し、予期せぬ支出の急増を引き起こす可能性は常にあります。クエリ 4は、これをできるだけ早く検出できるように構築されています。簡単に言うと、これは14日間の移動平均支出を使用し、日次の支出が平均より1標準偏差以上高い場合は「上昇」、2標準偏差以上の場合は「異常」として分類します。

クエリを使用するタイミング

このクエリは、コスト監視ダッシュボードでの使用に最適です。また、このアイデアをアラートのベースとして使用し、前日の支出が上昇または異常であった場合に管理者に自動的にメールを送信することもできます。

注意点

ワークロードが日によって大きく異なる場合、利用状況の標準偏差が非常に高くなり、このクエリでは最大規模の利用急増以外は検出できない可能性があります。

クエリ 5：支出予測

クエリが示す内容

これまでの4つのクエリでは過去の支出を振り返ることに焦点を当ててきましたが、Databricksの利用状況の全体像を把握するには、将来の支出を把握することが極めて重要です。通常、これには複雑な予測モデリングが必要になる場合がありますが、Databricks SQL AI Functionsには、Databricksの利用データなどの時系列データセットを将来にわたって外挿できる強力なai_forecastが含まれています。関数に提供するデータ量を微調整し、結果をグラフで可視化することで、Databricksの支出予測を非常に素早く作成できます。

クエリを使用するタイミング

繰り返しになりますが、このクエリはコスト監視ダッシュボードへの追加に最適です。将来の支出を把握できるため、計画や予算編成に役立ちます。

注意点

このクエリは過去のデータに基づいて予測を行っているため、将来の計画に使用する場合は、この予測では予測できない、計画中の新しいワークロードも考慮に入れるようにしてください。

システムテーブルクエリを試す 

これらのクエリを一度実行するだけで、何が起きたのかを把握できます。これらをAI/BIダッシュボードにピン留めすることで、チームの支出管理の方法が大きく変わります。各クエリをデータセットとして追加し、日付範囲やタグのパラメータを紐付ければ、ダッシュボードを週次のコストレビューに活用できます。ここからの次のステップは2つあります。まず、 Databricksシステムテーブルのリファレンスをブックマークして、クエリ可能なテーブルの完全なカタログを確認してください。そして、さらに多くの サンプルクエリ を探索して、これら5つ以外のツールキットを拡張しましょう。ワークスペースをまだお持ちでない場合は、 無料トライアルを開始してください。    

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事