背景・目的

「【Databricks】Lakehouse Monitoringを試してみた」の続きで、Lakehouse Monitoringでのアラートの監視を試してみます。

まとめ

2024/1/5現在で、パブリックプレビューです。
モニターアラートは、他のDatabricks SQLアラートと同じ方法で作成可能
- Databricks SQLクエリは、モニタープロファイルメトリックテーブル、ドリフトメトリックテーブルに作成する
- クエリのSQLアラートを作成する。
- 必要な頻度でクエリーを評価し、アラートがトリガーされた場合に通知を送信するようにアラートを構成できる
通知先は下記の通り
- メール（デフォルト）
- Slack、Pagedutyなどにも送信可能

概要

アラートの監視について整理します。

このページでは、モニターメトリクステーブルからのメトリクスに基づいて Databricks SQL アラートを作成する方法について説明します。モニターアラートの一般的な用途には、次のようなものがあります。

統計が特定の範囲外に移動したときに通知を受け取ります。たとえば、欠損値の割合が特定のレベルを超えたときに通知を受け取るとします。

データの変更の通知を受け取ります。ドリフトメトリクステーブルには、データ分布の変化を追跡する統計が格納されます。

ベースラインテーブルと比較してデータがドリフトした場合に通知を受け取ります。アラートを設定して、データの変更を調査したり、 InferenceLog 分析のためにモデルを再トレーニングする必要があることを示すことができます。

モニターアラートの一般的な用途
- 統計が特定の範囲外に移動したときに通知を受ける
- データの変更の通知を受け取る
- ベースラインテーブルと比較してデータがドリフトした場合に通知を受ける

モニターアラートは、他の Databricks SQL アラートと同じ方法で作成および使用されます。 Databricks SQL クエリーは、モニタープロファイルメトリックテーブルまたはドリフトメトリックテーブルに作成します。次に、このクエリーの Databricks SQL アラートを作成します。必要な頻度でクエリーを評価し、アラートがトリガーされた場合に通知を送信するようにアラートを構成できます。デフォルトにより、Eメール通知が送信されます。ウェブフックを設定したり、SlackやPagerdutyなどの他のアプリケーションに通知を送信したりすることもできます。

モニターアラートは、他のDatabricks SQLアラートと同じ方法で作成可能
- Databricks SQLクエリは、モニタープロファイルメトリックテーブル、ドリフトメトリックテーブルに作成する
- クエリのSQLアラートを作成する。
- 必要な頻度でクエリーを評価し、アラートがトリガーされた場合に通知を送信するようにアラートを構成できる
通知先は下記の通り
- メール（デフォルト）
- Slack、Pagedutyなどにも送信可能

実践

事前準備

Workspaceにサインインします。
こちらで作成したproductsテーブルを選択します。
①「Quality」タブをクリックし、②「Get started」をクリックします。
マニュアル更新で作成します。
Refresh metricsをクリックします。
しばらくしてから、「View refresh history」をクリックします。
Refreshが完了していました。
View dashboardをクリックします。
ダッシュボードが確認できました。

アラートの設定

アラートを設定します。

Row countの①「：」メニューをクリックし、②「View query」をクリックしSQLエディタを開きます。
①「：」メニューをクリックし、②「Create alert」をクリックします。
10件超えたらアラートを出すように設定します。
画面右上の「Refresh」をクリックします。
OKになりました。

アラートの確認

下記のクエリを実行し、20件の追加します。

INSERT INTO test.retail.products (product_id, product_name, price, stock)
VALUES
(103, 'ラズベリー', 91.74, 145),
(104, 'マンゴー', 132.79, 77),
(105, 'ブルーベリー', 140.19, 186),
(106, 'アボカド', 206.82, 114),
(107, 'パパイア', 229.05, 49),
(108, 'プラム', 251.57, 193),
(109, 'アボカド', 154.91, 83),
(110, 'ブルーベリー', 119.88, 44),
(111, 'ラズベリー', 96.07, 104),
(112, 'パパイア', 150.68, 58),
(113, '梨', 157.68, 11),
(114, 'ブルーベリー', 259.92, 26),
(115, 'プラム', 214.2, 72),
(116, 'グレープフルーツ', 70.72, 186),
(117, 'オレンジ', 253.94, 25),
(118, 'イチゴ', 95.68, 168),
(119, 'キウイ', 220.74, 25),
(120, 'スイカ', 267.77, 100),
(121, 'アボカド', 196.17, 100),
(122, 'ラズベリー', 197.52, 76);

再び「Refresh」をクリックします。
OKのままです。期待としてはエラーになってほしいところでした。
Catalog Explorerに戻り、「Refresh metrics」をクリックします。
完了しました。
再びAlertに戻り、「Refresh」をクリックします。
「TRIGGERED」になりました。
ダッシュボードを確認し、「Refresh」をクリックすると、件数は22件になりました。期待値としてはグラフ上でアラートがわかるようにしてほしいところ。

考察

今回、Lakehouse monitoringで作成した項目に対してしきい値を設けてAlertを発生することを確認しました。
Lakehouse monitoringで蓄積されたデータを活かしたアラートの検知ができると便利だと感じました。

Alertが発生したら Lakehouse monitoringのダッシュボードで目視で確認できること
- 例えば、背景や文字の色を変えるなど
~~静的な比較以外にも動的な式を設定できること~~
~~- 例えば、AWS GlueのAnomaly Detectionのように、過去の値のうち最小値と最大値を設定し、そのレンジから外れた場合に、エラーにするなど~~
- こちらは、カスタムでAlertを作れば実装できますね。

今後、機能が追加されることを期待しています。

参考