【Databricks】Lakehouse Monitoringを試してみた

Posted at 2023-12-30

背景・目的

Introduction to Databricks Lakehouse Monitoringについて、どのようなものか整理し、簡単に試してみます。

まとめ

Lakehouse Monitoringでは、３つのプロファイルがある
- 時系列
- スナップショット
- 推論
アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できます。
パフォーマンスの変化を検出すると、レイクハウスモニタリングによって作成されたテーブルが変更をキャプチャしてアラートを上げることが可能です。
2023/12/30現在、Public Previewです。

概要

Databricks レイクハウスモニタリングの概要

Databricks レイクハウスモニタリングの概要を元に整理します。

Databricks レイクハウスモニタリングを使用すると、アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できます。また、これを使用して、モデルの入力と予測を含む推論テーブルを監視することで、機械学習モデルとモデルサービングエンドポイントのパフォーマンスを追跡することもできます。この図は、Databricks のデータと機械学習パイプラインを介したデータのフローと、モニタリングを使用してデータ品質とモデルのパフォーマンスを継続的に追跡する方法を示しています。

アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できる。
モデルの入力と予測を含む推論テーブルを監視し、モデルとモデルサービングエンドポイントのパフォーマンスを追跡できる
下記の図は、MLシステムにおけるデータフローとモデルのモニタリングを説明している。

Databricks レイクハウスモニタリングを使用する理由

データから有用な知見を引き出すには、データの品質に自信を持っている必要があります。モニタリングデータでは、データの品質と一貫性を経時的に追跡および確認するのに役立つ定量的な測定値が提供されます。テーブルのデータ分布または対応するモデルのパフォーマンスの変化を検出すると、Databricks レイクハウスモニタリングによって作成されたテーブルが変更をキャプチャしてアラートし、原因を特定するのに役立ちます。

インサイトを出すには、データ品質が重要
モニタリングデータでは、データの品質と一貫性を経時的に追跡、確認するために役立つ定量的な測定値が提供される
パフォーマンスの変化を検出すると、レイクハウスモニタリングによって作成されたテーブルが変更をキャプチャしてアラートを上げる

Databricks レイクハウスモニタリングは、次のような質問に答えるのに役立ちます。

データ完全性はどのように見え、時間とともにどのように変化しますか? たとえば、現在のデータの null 値または 0 値の割合はどのくらいで、増加していますか?

データの統計分布はどのように表示され、時間の経過とともにどのように変化しますか? たとえば、数値列の90パーセンタイルは何ですか? または、カテゴリ列の値の分布は何ですか、そしてそれは昨日とどう違うのですか?

現在のデータと既知のベースラインの間、またはデータの連続する時間枠の間にドリフトがありますか?

データのサブセットまたはスライスの統計的分布またはドリフトはどのように見えますか?

機械学習モデルの入力と予測は時間の経過とともにどのように変化していますか?

モデルのパフォーマンスは時間の経過と共にどのように推移していますか? モデルバージョン A のパフォーマンスはバージョン B よりも優れていますか?

さらに、Databricks レイクハウスモニタリングを使用すると、観測の時間粒度を制御し、カスタムメトリクスを設定できます。

要件

Databricks Lakehouse モニタリングを使用するには、次のものが必要です。

ワークスペースで Unity Catalog を有効にし、Databricks SQL にアクセスできる必要があります。

モニタリングでは、Delta マネージドテーブル、外部テーブル、ビュー、および具体化されたビューのみがサポートされています。

Unity catalog
SQL Warehouse
Deltaマネージドテーブルと、外部テーブル、ビュー、materialized views

レイクハウスモニタリングが Databricksでどのように機能するか

Databricks でテーブルを監視するには、テーブルにアタッチされたモニターを作成します。機械学習モデルのパフォーマンスを監視するには、モデルの入力と対応する予測を保持する推論テーブルにモニターをアタッチします。

テーブルを監視するには、テーブルにアタッチされたモニターを作成する
MLモデルのパフォーマンスを監視するには、モデルの入力と対応する予測を保持する推論テーブルをアタッチする

Databricks レイクハウスモニタリングには、時系列、スナップショット、推論の種類の分析が用意されています。

プロファイルのタイプ	説明
時系列	タイムウィンドウでのデータ分布を比較する。メトリクスを計算する粒度（1日など）を指定し、時間の経過に伴うデータ分布の変化を比較する。タイムスタンプ列が必要。
スナップショット	テーブルの間z年あ内容が時間の経過とともにどのように変化するか監視する。メトリクスはテーブル内のすべてのデータに対して計算され、モニターが更新されるたびにテーブルの状態を監視する
推論	機械学習の分類モデル、回帰モデルにより出力された予測値を含むテーブル。モデル品質のモデルも含む

このセクションでは、Databricks レイクハウスモニタリングで使用される入力テーブルと、それが生成するメトリクステーブルについて簡単に説明します。この図は、入力テーブル、メトリクステーブル、モニター、およびダッシュボードの関係を示しています。

主表とベースライン表

「プライマリテーブル」と呼ばれる監視対象のテーブルに加えて、必要に応じて、ドリフトまたは時間の経過に伴う値の変化を測定するための参照として使用するベースラインテーブルを指定できます。ベースラインテーブルは、データがどのようになるかを示すサンプルがある場合に便利です。アイデアは、ドリフトが期待されるデータ値と分布に対してコンピュートになるということです。

監視対象テーブル=プライマリーテーブル
ベースラインテーブル＝ドリフトまたは時間の経過に伴う値の変化を測定するための参照として使用
- データがどのようになるかを示すサンプルがある場合に便利

ベースラインテーブルには、統計分布、個々の列の分布、欠損値、およびその他の特性の観点から、入力データの予想される品質を反映するデータセットが含まれている必要があります。監視対象テーブルのスキーマと一致する必要があります。例外は、時系列プロファイルまたは推論プロファイルで使用されるテーブルのタイムスタンプ列です。主表またはベースライン表のいずれかで列が欠落している場合、モニタリングはベストエフォート型ヒューリスティックを使用して出力メトリクスをコンピュートします。

ベースラインテーブルは、統計分布、個々の列の分布、欠損値等の観点から、入力データの予測される品質をハネイするデータセットが含まれている必要がある。
監視対象テーブルのスキーマと一致する必要がある
モニタリングはベストエフォート型ヒューリスティックを使用する

スナップショットプロファイルを使用するモニターの場合、ベースラインテーブルには、分布が許容可能な品質基準を表すデータのスナップショットが含まれている必要があります。たとえば、成績分布データでは、成績が均等に分布している前のクラスにベースラインを設定できます。

スナップショットプロファイルを使用するモニターの場合、ベースラインテーブルには、分布が許容可能な品質基準を表すデータのスナップが含まれている必要がある

時系列プロファイルを使用するモニターの場合、ベースラインテーブルには、データ分布が許容可能な品質基準を表すタイムウィンドウを表すデータが含まれている必要があります。たとえば、気象データでは、気温が予想される通常の気温に近い週、月、または年にベースラインを設定できます。

時系列プロファイルの場合、ベースラインテーブルには、データ分布が許容可能な品質基準を表すタイムウィンドウを表すデータが含まれている必要がある。

推論プロファイルを使用するモニターの場合、ベースラインに適した選択は、監視対象のモデルのトレーニングまたは検証に使用されたデータです。このようにして、モデルがトレーニングおよび検証された内容に対してデータがドリフトしたときに、ユーザーにアラートを受け取ることができます。このテーブルには、プライマリテーブルと同じ特徴列が含まれている必要があり、さらに、データが一貫して集計されるように、プライマリテーブルの InferenceLog に指定されたものと同じ model_id_col が必要です。理想的には、モデルの評価に使用されるテストまたは検証セットを使用して、同等のモデル品質を確保する必要がありますメトリクス。

推論プロファイルの場合、監視対象のモデルのトレーニングまたは検証に使用されたデータ
ドリフトしたときに、アラートを出す。

メトリクステーブルとダッシュボード

テーブルモニターは、2 つのメトリクステーブルとダッシュボードを作成します。メトリック値は、テーブル全体、およびモニターの作成時に指定するタイムウィンドウとデータサブセット (または「スライス」) のコンピュートです。また、推論分析のために、メトリクスはモデルID毎にコンピュートされる。メトリクステーブルの詳細については、「メトリクステーブルのモニター」を参照してください。

プロファイルメトリクステーブルには、要約統計量が含まれています。プロファイルメトリクステーブルスキーマを参照してください。

ドリフトメトリクステーブルには、時間の経過に伴うデータのドリフトに関連する統計が含まれています。ベースラインテーブルが指定されている場合、ベースライン値に対するドリフトも監視されます。ドリフトメトリクステーブルのスキーマを参照してください。

メトリクステーブルは Delta テーブルであり、指定した Unity Catalog スキーマに格納されます。これらのテーブルは、Databricks UI を使用して表示したり、Databricks SQL を使用してクエリを作成したり、それらに基づいてダッシュボードとアラートを作成したりできます。

モニターごとに、Databricks によってダッシュボードが自動的に作成され、モニターの結果を視覚化して表示するのに役立ちます。ダッシュボードは、他の Databricks SQL ダッシュボードと同様に完全にカスタマイズできます。

実践

事前準備

メトリクス用のカタログと、スキーマを作成します。
```
CREATE CATALOG metrics;

CREATE SCHEMA metrics.monitoring;
```

Databricks UIを使用したモニターの作成

Databricks UIを使用したモニターの作成を元に試してみます。

ここでは、スナップショットプロファイルで試します。

ワークスペースにサインインします。
ナビベーションペインで「Catalog」をクリックします。
任意のテーブルを選択します。なお、このテーブルは、こちらで作成したものです。
①「Quality」タブをクリックし、②「Get started」をクリックします。
下記を入力し、「Create」をクリックします。
- Profiling:Snapshot profiles
- Schedule:Refresh manually
- Metric tables schema name:
作成後、「Profile」のテーブルをクリックします。
テーブルができています。「Sample Data」タブをクリックします。
データは作られているようです。
テーブルに戻り、「Quality」タブの「View dashboard」をクリックします。
customers Monitoringというダッシュボードが作られていました。

データを登録し、モニタリングの変化を確認する

下記のクエリでデータを登録します。空白とNULLを仕込んでみます。

--顧客
INSERT INTO test.retail.customers (customer_id, name, address, phone)
VALUES
(3, 'Sato', '千葉県',''),
(4, '木村','' , '080-YYY-YYYY'),
(5,'吉田','埼玉県',NULL);

下記のクエリで、データの中身を確認します。
```
SELECT * FROM test.retail.customers
```
テーブルのQualityで「Refresh metrics」をクリックします。
View refresh historyをクリックします。
refreshの履歴が確認できます。二回ほどクリックしたのでPendingになっています。また以前は、リフレッシュに5mから8mほどかかっているようでした。
refreshされました。
Monitoringのダッシュボードで「Refresh」をクリックします。
結果は下記のとおりです。
- Row countが2から5になりました。
- 1つのカラムがNULLの割合が高くなりました。
- 時間の経過とともにレコードやカラムの状態がわかります。
- カラムに「phone」を指定します。percet nullの値が 20%に増えたのがわかります。
- MetricにMedianを指定します。時系列で変化しました。
- Time seriesでは、nameの平均文字列長が短くなっていることがわかります。
- Distribution for inspection timeでは、計測ごとに、nameの件数の変化がわかります。