Databricksレイクハウスモニタリングで高品質な予測を確保する

予測モデルは、多くの企業が将来のトレンドを予測するために重要ですが、その精度は入力データの品質に大きく依存します。 データの品質が低いと、予測が不正確になり、最適な意思決定ができなくなる可能性があります。 ここで、 Databricksレイクハウスモニタリングが登場します。これは、予測モデルに流入するデータの品質とモデルのパフォーマンス自体の両方を監視するための統合ソリューションを提供します。

モニタリングは、予測モデルにとって特に重要です。 予測は時系列データを扱うため、データの時間的コンポーネントとシーケンシャルな性質により、複雑さが増します。 入力データの統計的プロパティが時間の経過とともに変化するデータ ドリフトなどの問題は、迅速に検出および対処しないと、予測精度を大幅に低下させる可能性があります。

さらに、予測モデルのパフォーマンスは、予測値と実際の値を比較する平均絶対パーセント誤差 (MAPE) などのメトリクスによって測定されることがよくあります。 ただし、グラウンド トゥルース値はすぐには利用できず、予測期間が経過した後にのみ到着します。 この遅延フィードバック ループにより、潜在的な問題を早期に特定するために、入力データの品質とモデル出力を積極的にモニタリングすることがさらに重要になります。

最近のデータを使用して統計予測モデルを頻繁に再トレーニングすることは一般的ですが、モニタリングはドリフトを早期に検出し、不必要な計算コストを回避するために依然として価値があります。 PatchTSTのようなディープラーニングを使用し、GPU を必要とする複雑なモデルの場合、リソースの制約により再トレーニングの頻度が低くなる可能性があり、モニタリングがさらに重要になります。

自動ハイパーチューニングを使用すると、実行全体にわたってモデルのパフォーマンスに偏りが生じ、一貫性がなくなる可能性があります。 モニタリングにより、モデルのパフォーマンスが低下したタイミングを迅速に特定し、ハイパーパラメータを手動で調整したり、入力データに異常がないか調査するなどの修正アクションを実行できます。 さらに、モニタリングは、モデルのパフォーマンスと計算コストの間で適切なバランスをとるのに役立ちます。 自動チューニングは、特に再トレーニング サイクルごとに盲目的に実行される場合、リソースを大量に消費する可能性があります。 モデルのパフォーマンスを長期にわたって監視することで、自動チューニングによって実際に大幅な改善がもたらされているのか、それとも不要なオーバーヘッドが追加されているだけなのかを判断できます。 この知見により、モデルのトレーニング パイプラインを最適化できます。

Databricksレイクハウスモニタリングは、すべてのテーブルにわたるデータの統計的特性と品質を監視するために構築されていますが、モデルの入力と予測を含むモニタリング推論テーブルを介して機械学習モデルのパフォーマンスを追跡するために調整された特定の機能も含まれています。 予測モデルの場合、これにより次のことが可能になります。

• ベースラインと比較して、時間の経過に伴う入力フィーチャのデータ ドリフトをモニタリングする
• 予測ドリフトと予測の分布の追跡
• 実績値が利用可能になったときの MAPE、バイアスなどのモデル パフォーマンス メトリクスの測定
• データ品質またはモデルのパフォーマンスが低下した場合のアラートの設定

Databricks での予測モデルの作成

予測モデルを監視する方法について説明する前に、Databricks プラットフォームで予測モデルを開発する方法について簡単に説明します。 Databricks 、時系列予測モデルを含む機械学習モデルを大規模に構築、トレーニングし、デプロイするための統合環境を提供します。

予測を生成するために使用できる一般的なライブラリやテクニックがいくつかあります。たとえば、次のとおりです。

• Prophet : 使いやすく調整しやすい時系列予測用のオープンソース ライブラリ。 季節的な影響が強いデータの処理に優れており、外れ値を平滑化することで乱雑なデータにもうまく対応します。 Prophet のシンプルで直感的な API により、専門家以外の人でも利用できます。 PySpark を使用すると、クラスター全体で Prophet モデルのトレーニングを並列化し、製品と店舗の組み合わせごとに何千ものモデルを構築できます。 ブログ
• ARIMA/SARIMA: 時系列予測のための古典的な統計手法。 ARIMA モデルは、データ内の自己相関を記述することを目的としています。 SARIMA は ARIMA を拡張して季節性をモデル化します。 最近のベンチマーク調査では、SARIMAは他のアルゴリズムと比較して、小売売上高データで優れたパフォーマンスを示しました。 ブログ

予測を生成するための Prophet や ARIMA/SARIMA などの一般的なライブラリに加えて、Databricks は予測用のAutoMLも提供しています。 AutoML 、アルゴリズムの選択、ハイパーチューニング、分散トレーニングなどのタスクを自動的に処理することで、予測モデルの作成プロセスを簡素化します。 AutoML を使用すると、次のことが可能になります。

• ユーザーフレンドリーなUIを通じてベースライン予測モデルとノートブックを素早く生成
• ProphetやAuto-ARIMAなどの複数のアルゴリズムを内部で活用
• Sparkを使用して、データの準備、モデルのトレーニングとチューニング、分散計算を自動的に処理します。

AutoMLを使用して作成されたモデルを、エクスペリメント追跡のためのMLflowと、デプロイとモニタリングのためのDatabricksモデルサービングと簡単に統合できます。 生成されたノートブックは、カスタマイズして本番運用ワークフローに組み込むことができるコードを提供します。

モデル開発ワークフローを効率化するには、機械学習ライフサイクル用のオープンソース プラットフォームであるMLflow を活用できます。 MLflow 、 Prophet 、 ARIMA 、およびその他のモデルをすぐに使用できるようにサポートし、時系列エクスペリメントに最適なエクスペリメント トラッキングを可能にし、各種、メトリクス、およびアーティファクトのロギングを可能にします。 これによりモデルのデプロイが簡素化され、再現性が促進されますが、レイクハウスモニタリングではMLflowの使用はオプションです。MLflow を使用せずにモデルをデプロイしても、レイクハウスモニタリングは引き続きモデルを追跡できます。

トレーニング済みの予測モデルを作成したら、ユースケースに応じて推論のためにデプロイする方法に柔軟性を持たせることができます。 今後予測の場合、 Databricksモデルサービングを使用して、わずか数行のコードでモデルを低遅延RESTエンドポイントとしてデプロイできます。 モデルがリアルタイム推論用にデプロイされると、Databricks は入力機能と予測を推論ログ テーブルと呼ばれる管理された Delta テーブルに自動的に記録します。 このテーブルは、レイクハウスモニタリングを使用して本番運用でモデルをモニタリングするための基盤として機能します。

しかし、予測モデルは、スケジュールに従って予測が生成されるバッチスコアリングシナリオで使用されることが多い（例： 翌日の予報を毎晩生成します)。 この場合、データのバッチに対してモデルにスコアを付け、その結果を Delta テーブルに記録する別のパイプラインを構築できます。 モデルを Databricks クラスターに直接ロードし、そこでデータのバッチにスコアを付ける方がコスト効率が高くなります。 このアプローチにより、 API背後にモデルをデプロイし、複数の場所でコンピュート リソースを支払うオーバーヘッドが回避されます。 ログに記録されたバッチ予測のテーブルは、引き続き推論テーブルと同じようにレイクハウスモニタリングを使用して監視できます。

予測モデルにリアルタイム推論とバッチ推論の両方が必要な場合は、リアルタイムのユースケースにモデルサービングを使用し、バッチスコアリングのためにモデルをクラスターに直接ロードすることを検討できます。 このハイブリッド アプローチにより、必要な機能を提供しながらコストを最適化します。 Lakeviewダッシュボードを活用して、インタラクティブな視覚化を構築し、予測レポートに関する知見を共有できます。 電子メールの購読を設定して、スケジュールに従ってダッシュボードのスナップショットを自動的に送信することもできます。

どちらのアプローチを選択した場合でも、モデルの入力と出力を標準化された Delta テーブル形式で保存することで、データ ドリフトを監視し、予測の変化を追跡し、時間の経過に伴う精度を測定することが容易になります。 この可視性は、本番運用において信頼性の高い予測パイプラインを維持するために非常に重要です。

Databricksで時系列予測モデルを構築してデプロイする方法を説明したので、レイクハウスモニタリングを使用して時系列予測モデルをモニタリングする重要な側面を見ていきましょう。

データ ドリフトの監視とパフォーマンスのモデル化

本番運用において予測モデルが引き続き良好なパフォーマンスを発揮できるようにするには、入力データとモデル予測の両方を監視して潜在的な問題がないか確認することが重要です。 Databricksレイクハウスモニタリングを使用すると、入力特徴量テーブルと推論ログ テーブルにモニターを作成できるため、これが簡単になります。 レイクハウスモニタリングは、データを管理および監視するための統一された方法としてUnity Catalog上に構築されており、ワークスペースでUnity Catalogを有効にする必要があります。

推論プロファイルモニタの作成

予測モデルを監視するには、モデルの入力特徴、予測、およびオプションでグラウンドトゥルースラベルを含む推論プロファイルモニターをテーブルに作成します。 Databricks UI または Python API を使用してモニターを作成できます。

UI で推論テーブルに移動し、「品質」タブをクリックします。 「開始する」をクリックし、モニターの種類として「推論プロファイル」を選択します。 次に、次のキーを構成します。

• 問題の種類: 予測モデルの回帰を選択します
• タイムスタンプ列: 各予測のタイムスタンプを含む列。 これは推論のタイムスタンプであり、データ自体のタイムスタンプではありません。
• 予測列: モデルの予測値を含む列
• ラベル列 (オプション): 実際の値を含む列。 これは、実績が到着したときに後で入力できます。
• モデル ID 列: 各予測を行ったモデル バージョンを識別する列
• 粒度: メトリクスを集計するための時間枠。例: 毎日または毎週

オプションで、次の項目も指定できます。

• トレーニングセットのような参照データを含むベースラインテーブル。データドリフトを比較するために使用します。
• 異なる製品カテゴリなど、監視するデータのサブセットを定義するスライス式
• SQL式で定義された、計算するカスタム メトリクス
• 更新スケジュールを設定する

Python REST APIを使用すると、次のようなコードで同等のモニターを作成できます。

ベースライン テーブルは、本番運用データと比較するための、モデルのトレーニング データなどの参照データセットを含むオプションのテーブルです。 繰り返しになりますが、予測モデルの場合、モデルは頻繁に再トレーニングされるため、モデルが頻繁に変更されるため、ベースラインの比較は必要ないことがよくあります。 以前の時間枠との比較を行うことができ、ベースラインの比較が必要な場合は、ハイパーチューニングや実績値の更新など、より大きな更新がある場合にのみベースラインを更新します。

予測におけるモニタリングは、再トレーニングの頻度が毎週や毎月など事前に設定されているシナリオでも役立ちます。 このような場合でも、予測メトリクスが実績から逸脱したり、実績が予測と一致しなくなったりしたときに、例外ベースの予測管理を行うことができます。 これにより、基になる時系列を再診断する必要があるかどうか (再トレーニングの正式な予測言語であり、計量経済学モデルを使用する場合にトレンド、季節性、周期性が個別に識別されます)、または個々の偏差を異常または外れ値として分離できるかどうかを判断できます。 後者の場合、再診断はしませんが、偏差を外れ値としてマークし、将来、カレンダー イベントまたは外生変数をモデルにアタッチする可能性があります。

レイクハウスモニタリングは、入力特徴の統計的プロパティを長期にわたって自動的に追跡し、ベースラインまたは以前の時間枠と比較して重大なドリフトが検出された場合はアラートを追跡します。 これにより、予測の精度を低下させる可能性のあるデータ品質の問題を特定できます。 例えば：

• 売上高などの主要な入力機能の分布を監視します。 突然のシフトがある場合は、予測精度を低下させる可能性のあるデータ品質の問題を示している可能性があります。
• 欠損値または外れ値の数を追跡します。 最近の期間の欠落データの増加は、予測を歪める可能性があります。

安心メトリクスに加えて、 SQL式を使用してカスタム メトリクスを定義し、ビジネス固有のロジックや複雑な比較をキャプチャできます。 予測に関連する例をいくつか示します。

• 季節や年をまたいだメトリクスの比較。例: 現在の四半期と前年同期の平均売上高の差の計算
• 予測される項目に基づいて誤差の重み付けが異なる (例: 高価値製品のエラーに対する罰則を強化する
• 許容誤差許容範囲内の予測の割合を追跡する

カスタム メトリクスには次の 3 つのタイプがあります。

• 推論テーブルの列から計算された集計メトリクス
• 他の集計メトリクスから計算された派生メトリクス
• 時間枠全体またはベースラインと集計または派生メトリクスを比較するドリフト メトリクス

これらのカスタム メトリクスの例は、上記のPython API例に示されています。 特定の予測ユースケースに合わせてカスタマイズされたカスタム メトリックを組み込むことで、モデルのパフォーマンスとデータ品質に関するより深く関連性の高い知見を得ることができます。

重要な考え方は、モデルの入力特徴、予測、およびグラウンド トゥルース ラベルを 1 つの推論ログ テーブルにまとめることです。 レイクハウスモニタリングは、データのドリフト、予測のドリフト、パフォーマンス メトリクスを時間の経過とともに指定したディメンションごとに自動的に追跡します。

予測モデルが の外部で提供されている場合は、リクエストDatabricks ETLDeltaログを テーブルに 、それに モニタリング を適用できます。これにより、外部モデルであってもモニタリングを一元化できます。

時系列モニターまたは推論プロファイルモニターを初めて作成するときは、モニターの作成前の 30 日間のデータのみが分析されることに注意してください。 このカットオフにより、最初の解析ウィンドウは部分的になる場合があります。 たとえば、30 日の制限が週または月の半ばに当たる場合、週全体または月全体は含まれません。

この 30 日間のルックバック制限は、モニターが作成されたときの初期ウィンドウにのみ影響します。 その後、推論テーブルに流入するすべての新しいデータは、指定された粒度に従って完全に処理されます。

メトリクスを更新するためのモニターの更新

予測モデルの推論プロファイル モニターを作成した後は、定期的に更新して、メトリックを最新のデータに更新する必要があります。 モニターを更新すると、推論ログ テーブルの現在の内容に基づいて、プロファイル テーブルとドリフト メトリック テーブルが再計算されます。 次の場合にはモニターを更新する必要があります。

• 新しい予測はモデルからログに記録されます
• 以前の予測には実際の値が追加されます
• 推論テーブル スキーマの変更 (新しい機能列の追加など)
• カスタム メトリクスを追加するなど、モニター設定を変更する

モニターを更新するには、スケジュールに従って更新する方法と手動で更新する方法の 2 つがあります。

更新スケジュールを設定するには、UI またはPython APIを使用してモニターを作成するときにスケジュールを指定します。

`CronSchedule` を使用すると、毎日、毎時間などの更新頻度を定義する cron 式を指定できます。 「skip_builtin_dashboard」をTrueに設定すると、モニターの新しいダッシュボードの生成がスキップされます。 これは、ダッシュボードを既に作成している場合や、ダッシュボードに保持したいカスタムグラフがあり、新しいグラフが必要ない場合に特に便利です。

あるいは、UI または Python API を使用してモニターを手動で更新することもできます。 Databricks UI で、推論テーブルの [品質] タブに移動し、モニターを選択して、[メトリクスを更新] をクリックします。

Python API を使用すると、モデルの再トレーニング後など、アクション駆動型になるようにモニターを更新するパイプラインを作成できます。 ノートブックのモニターを更新するには、実行関数を使用します。

これにより、サーバーレス ジョブが送信され、モニターのメトリクス テーブルが更新されます。 バックグラウンドで更新が実行されている間も、ノートブックを引き続き使用できます。

更新が完了すると、 SQL使用して、更新されたプロファイルとドリフト メトリクス テーブルをクエリできます。 ただし、生成されたダッシュボードは個別に更新されることに注意してください。これは、DBSQL ダッシュボード自体の「更新」ボタンをクリックすることで実行できます。 同様に、ダッシュボードで「更新」をクリックしても、モニターの計算はトリガーされません。 代わりに、ダッシュボードが視覚化を生成するために使用するメトリクス テーブルに対してクエリを実行します。 ダッシュボードに表示される視覚化を作成するために使用されるテーブル内のデータを更新するには、モニターを更新してからダッシュボードを更新する必要があります。

モニタリングの出力を理解する

予測モデルの推論プロファイル モニターを作成すると、レイクハウスモニタリングは、データ ドリフト、モデルのパフォーマンス、パイプラインの全体的な健全性を追跡するのに役立ついくつかの重要な資産を生成します。

プロファイルとドリフトのメトリクス テーブル

レイクハウスモニタリングは 2 つの主要なメトリクス テーブルを作成します。

1. プロファイル メトリクス テーブル: 時間枠とスライスごとにグループ化された、各特徴列と予測の概要統計が含まれます。 予測モデルの場合、これには次のようなメトリクスが含まれます。
   • 数値列の count、mean、stddev、min、max
   • count、null の数、categorical 列の個別の値の数
   • 予測列の count、mean、stddev、min、max
2. ドリフト メトリクス テーブル: ベースラインと比較して、データと予測分布の変化を経時的に追跡します。 予測のための主要なドリフト メトリクスには次のものがあります。
   • 数値列の場合は Wasserstein 距離 (分布形状の違いを測定し、予測列の場合は予測分布のシフトを検出します)
   • カテゴリカル列のJensen-Shannon発散、確率分布間の差の定量化

次のような特定の質問を調査するために、SQL を使用して直接クエリを実行できます。

• 平均的な予測はどのくらいで、前週比でどのように変化しましたか?
• 製品カテゴリー間でモデルの精度に違いはありますか?
• 昨日の主要な入力機能とトレーニング データには、欠損値がいくつありましたか?

モデルパフォーマンスダッシュボード

メトリクス テーブルに加えて、レイクハウスモニタリングは、予測モデルのパフォーマンスを経時的に視覚化するためのインタラクティブなダッシュボードを自動的に生成します。 ダッシュボードには、いくつかの主要なコンポーネントが含まれています。

1. モデル パフォーマンス パネル: MAPE、RMSE、バイアスなど、予測モデルの主要な精度メトリクスを表示します。 これらのメトリクスは、予測値と実際の値を比較することによって計算され、遅延して提供されることもあります（例： daily actuals for a daily forecast) です。 パネルには、メトリクスが時間の経過とともに、製品カテゴリや地域などの重要なスライスごとに表示されます。
2. ドリフト メトリクス パネル: 選択した特徴と予測列のドリフト メトリクスを経時的に視覚化します。
3. データ品質パネル: 欠損値の割合、NAS の割合、カウント、平均、最小値、最大値などのさまざまな統計、および時間の経過に伴う数値機能とカテゴリ機能の両方のその他のデータ異常などのさまざまなメトリックを表示します。 これにより、予測精度を低下させる可能性のあるデータ品質の問題をすばやく見つけることができます。

ダッシュボードは高度にインタラクティブで、時間範囲でフィルタリングしたり、特定の機能やスライスを選択したり、個々のメトリックにドリルダウンしたりできます。 ダッシュボードは、多くの場合、作成後にカスタマイズされ、組織が見慣れているビューやグラフが含まれます。 ダッシュボードで使用されるクエリはカスタマイズして保存することができ、任意のビューから「クエリの表示」をクリックしてから「アラートの作成」をクリックすることでアラートを追加できます。 本稿執筆時点では、ダッシュボード用にカスタマイズされたテンプレートはサポートされていません。

これはdata scientistsモデルのパフォーマンスをデバッグするのにも、ビジネス関係者が予測の信頼を維持するのにも役立つ貴重なツールです。

正確さのために実績を活用するモニタリング

MAPE のようにモデル パフォーマンス メトリクスを計算するには、モニタリング システムが各予測の実際の値にアクセスする必要があります。 ただし、予測では、多くの場合、予測が行われてからしばらく経つまで実績を使用できません。

1 つの戦略は、実際の値が利用可能になったときに推論ログ テーブルに実際の値を追加する別のパイプラインを設定し、その後モニターを更新してメトリクスを更新することです。 たとえば、毎日の予測を生成する場合、前日の予測の実際の値を追加するために毎晩実行されるジョブを作成できます。

実績をキャプチャし、モニターを定期的に更新することで、予測精度を経時的に追跡し、パフォーマンスの低下を早期に特定できます。 これは、予測パイプラインの信頼性を維持し、情報に基づいたビジネス上の意思決定を行うために非常に重要です。

さらに、実績と予測を個別にモニタリングすることで、強力な例外管理機能が可能になります。 例外管理は、需要計画で一般的な手法であり、期待される結果からの大幅な逸脱を事前に特定して解決します。 メトリクス上で予測精度やバイアスなどのアラートを設定すると、モデルのパフォーマンスが低下した時期をすぐに特定し、モデルの調整や入力データの異常の調査などの修正措置を講じることができます。

レイクハウスモニタリングは、主要なメトリクスを自動的に追跡し、カスタマイズ可能なアラートを提供することで、例外管理を簡単にします。 プランナーは、山のようなデータをふるいにかけるのではなく、最も影響力のある例外に注意を向けることができます。 この的を絞ったアプローチにより、効率が向上し、最小限の手動介入で高い予測品質を維持できます。

要約すると、レイクハウスモニタリングは、本番運用で予測モデルをモニタリングするための包括的なツールセットを提供します。 生成されたメトリクス テーブルとダッシュボードを活用することで、データ品質の問題をプロアクティブに検出し、モデルのパフォーマンスを追跡し、ドリフトを診断し、ビジネスに影響が出る前に例外を管理することができます。 製品、地域、時間などのディメンションにわたってメトリックを細分化できるため、問題の根本原因をすばやく特定し、予測の健全性と精度を維持するための的を絞ったアクションを実行できます。

モデルメトリクスにアラートを設定する

予測モデルに推論プロファイル モニターを設定したら、主要なメトリックに対してアラートを定義して、ビジネス上の意思決定に影響する前に問題を事前に特定できます。 DatabricksレイクハウスモニタリングはDatabricks SQLと統合されており、生成されたプロファイルとドリフト メトリクス テーブルに基づいてアラートを作成できるようになります。

予測モデルのアラートを設定する一般的なシナリオには、次のようなものがあります。

• ローリング 7 日間の平均予測誤差 (MAPE) が 10% を超えた場合はアラート。 これは、モデルが正確でなくなり、再トレーニングが必要になる可能性があることを示している可能性があります。
• アラートは、キー入力特徴の欠損値の数がトレーニング データと比較して大幅に増加した場合に発生します。 データが欠落していると、予測が歪む可能性があります。
• 特徴の分布がベースラインに対してしきい値を超えた場合に通知します。 これは、データ品質の問題を示しているか、新しいデータ パターンに合わせてモデルを更新する必要があることを示している可能性があります。
• 過去 24 時間に新しい予測が記録されなかった場合はアラート。 これは、推論パイプラインが失敗し、注意が必要であることを意味している可能性があります。
• モデルのバイアス (平均誤差) が一貫して正または負であるかどうかを示します。 これは、モデルが体系的に予測を上回っているか、または下回っていることを示している可能性があります。

ダッシュボードのビューを構築するためにすでに生成された組み込みクエリがあります。 アラートを作成するには、プロファイルまたはドリフト メトリクス テーブルから監視するメトリクスを計算するSQLクエリに移動します。 次に、 Databricks SQLクエリ エディターで [アラートの作成] をクリックし、MAPE が 0.1 を超えたときにトリガーするなどのアラート条件を構成します。 アラートを1時間ごとや毎日などのスケジュールで実行するように設定したり、通知の受信方法を指定したりすることができます（例： 電子メール、Slack、PagerDuty)。

安心メトリクスのアラートに加えて、カスタムSQLクエリを記述して、特定のユースケースに合わせてオーダーメイドのメトリクスを計算できます。 たとえば、高価値製品の MAPE が低価値製品とは異なるしきい値を超えた場合にアラートを発したい場合があります。 プロファイル メトリクスを製品テーブルと結合して、MAPE 計算をセグメント化することができます。

重要なのは、すべての特徴データと予測データがメトリクス テーブルで利用できるため、 SQL柔軟に作成してビジネスにとって意味のあるカスタム メトリクスを定義できることです。 その後、同じプロセスを使用して、これらのカスタム メトリクスの上にアラートを作成できます。

予測モデル メトリクスにターゲットを絞ったアラートを設定すると、手動モニタリングなしでそのパフォーマンスを常に把握できます。 アラートを使用すると、異常に迅速に対応し、モデルの予測に対する信頼を維持できます。 レイクハウスモニタリングによって可能になる多次元分析と組み合わせることで、問題を効率的に診断して解決し、予測の品質を高く保つことができます。

レイクハウスモニタリング費用の監視

予測モデルに特有のものではありませんが、レイクハウスモニタリング自体の使用状況と費用を追跡する方法を理解することが重要です。 レイクハウスモニタリングの使用を計画する場合、適切な予算を立てるために関連コストを理解することが重要です。 レイクハウスモニタリングジョブはサーバレスコンピュートインフラ上で実行されるため、クラスターを自分で管理する必要はありません。 レイクハウスモニタリングのコストを見積もるには、次のステップに従ってください。

1. 作成する予定のモニターの数と頻度を決定します。 各モニターはスケジュールに従って実行され、メトリクスを更新します。
2. モニターのデータ量と SQL 式の複雑さを見積もります。 データ サイズが大きく、クエリが複雑になると、より多くの DBU が消費されます。
3. 層とクラウド DBUプロバイダーに基づいて、サーバーレス ワークロードの レートを調べます。Databricks
4. 推定 DBU に該当するレートを乗じて、レイクハウスモニタリングの推定コストを算出します。

実際のコストは、特定のモニター定義とデータによって異なり、時間の経過とともに変化する可能性があります。 Databricks 、 SQLハウスモニタリング コストを監視する 2 つの方法を提供します。SQL クエリを使用する方法と、請求ポータルを使用する方法です。 詳細については、 https://docs.databricks.com/ja/lakehouse-monitoring/expense.htmlを参照してください。

Databricksレイクハウスモニタリングを使用して予測モデルのモニタリングを開始する準備はできていますか? まずは無料トライアルにサインアップしてください。 すでに Databricks の顧客ですか? 当社のドキュメントをチェックして、今すぐ最初の推論プロファイルモニターを設定してください。