Freigeben über

Verwenden von benutzerdefinierten Metriken mit Databricks Lakehouse Monitoring

  • Artikel

Auf dieser Seite wird beschrieben, wie Sie eine benutzerdefinierte Metrik in Databricks Lakehouse Monitoring erstellen. Zusätzlich zu den automatisch berechneten Analyse- und Driftstatistiken können Sie auch benutzerdefinierte Metriken erstellen. Sie können beispielsweise einen gewichteten Mittelwert nachverfolgen, der einige Aspekte der Geschäftslogik erfasst, oder einen benutzerdefinierten Modellqualitätsscore verwenden. Sie können auch benutzerdefinierte Driftmetriken erstellen, die Änderungen an den Werten in der primären Tabelle (im Vergleich zur Baseline oder dem vorherigen Zeitfenster) nachverfolgen.

Weitere Informationen zur Verwendung der MonitorMetric-API finden Sie in der API-Referenz.

Typen von benutzerdefinierten Metriken

Databricks Lakehouse Monitoring enthält die folgenden Arten von benutzerdefinierten Metriken:

  • Aggregierte Metriken, die basierend auf Spalten in der primären Tabelle berechnet werden. Aggregierte Metriken werden in der Profilmetriktabelle gespeichert.
  • Abgeleitete Metriken, die basierend auf zuvor berechneten aggregierten Metriken berechnet werden und nicht direkt auf Daten aus der primären Tabelle zurückgreifen. Abgeleitete Metriken werden in der Profilmetriktabelle gespeichert.
  • Driftmetriken, die zuvor berechnete aggregierte oder abgeleitete Metriken aus zwei verschiedenen Zeitfenstern oder aus der primären und der Baselinetabelle vergleichen. Driftmetriken werden in der Driftmetriktabelle gespeichert.

Bei der Verwendung von abgeleiteten Metriken und Driftmetriken wird die Neuberechnung über die vollständige primäre Tabelle minimiert. Nur aggregierte Metriken greifen auf Daten aus der primären Tabelle zu. Abgeleitete und Driftmetriken können dann direkt aus den aggregierten Metrikwerten berechnet werden.

Parameter für benutzerdefinierte Metriken

Um eine benutzerdefinierte Metrik zu definieren, erstellen Sie eine Jinja-Vorlage für einen SQL-Spaltenausdruck. In den Tabellen in diesem Abschnitt werden die Parameter zum Definieren der Metrik und die in der Jinja-Vorlage verwendeten Parameter beschrieben.

Parameter Beschreibung
type Einer der folgenden Werte: MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE, MonitorMetricType.CUSTOM_METRIC_TYPE_DERIVED oder MonitorMetricType.CUSTOM_METRIC_TYPE_DRIFT.
name Spaltenname für die benutzerdefinierte Metrik in Metriktabellen.
input_columns Liste der Spaltennamen in der Eingabetabelle, für die die Metrik berechnet werden soll. Um anzugeben, dass mehrere Spalten in der Berechnung verwendet werden, verwenden Sie :table. Beispiele dazu finden Sie weiter unten in diesem Artikel.
definition Jinja-Vorlage für einen SQL-Ausdruck, der angibt, wie die Metrik berechnet werden soll. Weitere Informationen finden Sie unter Erstellen einer Definition.
output_data_type Spark-Datentyp der Metrik-Ausgabe in einem JSON-Zeichenfolgenformat.

Erstellen einer definition

Der Parameter definition muss ein einzelner Zeichenfolgenausdruck in Form einer Jinja-Vorlage sein. Er kann keine Joins oder Unterabfragen enthalten.

In der folgenden Tabelle sind die Parameter aufgeführt, über die Sie beim Erstellen einer SQL-Jinja-Vorlage angeben können, wie die Metrik berechnet werden soll.

Parameter Beschreibung
{{input_column}} Spalte zum Berechnen der benutzerdefinierten Metrik.
{{prediction_col}} Spalten mit ML-Modellvorhersagen. Wird mit der InferenceLog-Analyse verwendet.
{{label_col}} Spalte mit Grundwahrheitsbezeichnungen für das ML-Modell. Wird mit der InferenceLog-Analyse verwendet.
{{current_df}} Für Drift im Vergleich zum vorherigen Zeitfenster. Daten aus dem vorherigen Zeitfenster.
{{base_df}} Für Drift im Vergleich zur Baselinetabelle. Baselinedaten.

Beispiel für aggregierte Metriken

Im folgenden Beispiel wird der quadratische Mittelwert der Werte in einer Spalte berechnet und auf die Spalten f1 und f2 angewandt. Die Ausgabe wird als neue Spalte in der Tabelle mit den Profilmetriken gespeichert und in den Analysezeilen angezeigt, die den Spalten f1 und f2 entsprechen. Für den Jinja-Parameter {{input_column}} werden die jeweiligen Spaltennamen eingesetzt.

from databricks.sdk.service.catalog import MonitorMetric, MonitorMetricType
from pyspark.sql import types as T

MonitorMetric(
    type=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE,
    name="squared_avg",
    input_columns=["f1", "f2"],
    definition="avg(`{{input_column}}`*`{{input_column}}`)",
    output_data_type=T.StructField("output", T.DoubleType()).json(),
)

Der folgende Code definiert eine benutzerdefinierte Metrik, die den Durchschnitt der Differenz zwischen den Spalten f1 und f2 berechnet. Dieses Beispiel zeigt die Verwendung von [":table"] im Parameter input_columns, um anzugeben, dass mehrere Spalten aus der Tabelle in der Berechnung verwendet werden.

from databricks.sdk.service.catalog import MonitorMetric, MonitorMetricType
from pyspark.sql import types as T

MonitorMetric(
    type=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE,
    name="avg_diff_f1_f2",
    input_columns=[":table"],
    definition="avg(f1 - f2)",
    output_data_type=T.StructField("output", T.DoubleType()).json(),
)

In diesem Beispiel wird ein gewichteter Modellqualitätsscore berechnet. Bei Beobachtungen, bei denen die Spalte critical den Wert True aufweist, wird eine höhere Strafe zugewiesen, wenn der vorhergesagte Wert für diese Zeile nicht mit der Grundwahrheit übereinstimmt. Da er für die unformatierten Spalten (prediction und label) definiert ist, ist er eine Aggregatmetrik. Die Spalte :table gibt an, dass diese Metrik aus mehreren Spalten berechnet wird. Die Jinja-Parameter {{prediction_col}} und {{label_col}} werden durch die Namen der Spalten für die Vorhersage und die Grundwahrheit für den Monitor ersetzt.

from databricks.sdk.service.catalog import MonitorMetric, MonitorMetricType
from pyspark.sql import types as T

MonitorMetric(
    type=MonitorMetricType.CUSTOM_METRIC_TYPE_AGGREGATE,
    name="weighted_error",
    input_columns=[":table"],
    definition="""avg(CASE
      WHEN {{prediction_col}} = {{label_col}} THEN 0
      WHEN {{prediction_col}} != {{label_col}} AND critical=TRUE THEN 2
      ELSE 1 END)""",
    output_data_type=T.StructField("output", T.DoubleType()).json(),
)

Beispiel für abgeleitete Metriken

Der folgende Code definiert eine benutzerdefinierte Metrik, die die Quadratwurzel der weiter oben in diesem Abschnitt definierten Metrik squared_avg berechnet. Da es sich um eine abgeleitete Metrik handelt, verweist sie nicht auf die Daten der primären Tabelle, sondern wird anhand der Aggregatmetrik squared_avg definiert. Die Ausgabe wird als neue Spalte in der Profilmetriktabelle gespeichert.

from databricks.sdk.service.catalog import MonitorMetric, MonitorMetricType
from pyspark.sql import types as T

MonitorMetric(
    type=MonitorMetricType.CUSTOM_METRIC_TYPE_DERIVED,
    name="root_mean_square",
    input_columns=["f1", "f2"],
    definition="sqrt(squared_avg)",
    output_data_type=T.StructField("output", T.DoubleType()).json(),
)

Beispiel für Driftmetriken

Der folgende Code definiert eine Driftmetrik, die die Änderung in der weiter oben in diesem Abschnitt definierten Metrik weighted_error nachverfolgt. Durch die Parameter {{current_df}} und {{base_df}} kann die Metrik auf die Werte weighted_error für das aktuelle Fenster und das Vergleichsfenster verweisen. Das Vergleichsfenster kann die Baselinedaten oder die Daten aus dem vorherigen Zeitfenster aufweisen. Driftmetriken werden in der Driftmetriktabelle gespeichert.

from databricks.sdk.service.catalog import MonitorMetric, MonitorMetricType
from pyspark.sql import types as T

MonitorMetric(
    type=MonitorMetricType.CUSTOM_METRIC_TYPE_DRIFT,
    name="error_rate_delta",
    input_columns=[":table"],
    definition="{{current_df}}.weighted_error - {{base_df}}.weighted_error",
    output_data_type=T.StructField("output", T.DoubleType()).json(),
)