Détection des anomalies (fonctions optimisées par ML Snowflake Cortex)¶

Limitations¶

• Vous ne pouvez pas choisir ou ajuster l’algorithme de détection des anomalies. L’algorithme ne fournit pas de paramètres permettant de remplacer la tendance, la saisonnalité ou les amplitudes saisonnières ; ces paramètres sont déduits des données.

• Le nombre minimum de lignes pour l’algorithme principal de détection des anomalies est de 12 par série temporelle. Pour les séries temporelles comportant entre 2 et 11 observations, la détection des anomalies produit un résultat « naïf » dans lequel toutes les valeurs prédites sont égales à la dernière valeur cible observée. Dans le cas de la détection d’anomalies étiquetées, le nombre d’observations utilisé est le nombre de lignes dont la colonne d’étiquettes est fausse.

• La granularité minimale acceptable des données est d’une seconde. (Les horodatages ne doivent pas être espacés de moins d’une seconde.)

• La granularité minimale des composantes saisonnières est d’une minute. (La fonction ne peut pas détecter de modèles cycliques à des deltas temporels plus petits.)

• Les horodatages de vos données doivent représenter des intervalles de temps fixes. Si vos données d’entrée sont irrégulières, essayez DATE_TRUNC ou TIME_SLICE sur votre colonne d’horodatage lors de l’entraînement du modèle.

• La « longueur de la saison » des fonctions autorégressives est liée à la fréquence d’entrée (24 pour des données horaires, 7 pour des données journalières, et ainsi de suite).

• Les modèles de détection des anomalies, une fois entraînés, sont immuables. Vous ne pouvez pas mettre à jour les modèles existants avec de nouvelles données ; vous devez entraîner un modèle entièrement nouveau. Les modèles ne prennent pas en charge la gestion des versions. En règle générale, vous devez entraîner les modèles à intervalles réguliers, par exemple une fois par semaine ou par mois, en fonction de la fréquence à laquelle vous recevez de nouvelles données, afin d’aider le modèle à suivre l’évolution des tendances.

• Cette fonction ne détecte que les anomalies dans les données de test par rapport aux données d’entraînement. Elle ne peut pas détecter les anomalies dans les données d’entraînement. Les données d’entraînement étant la source du modèle, elles ne présentent par définition aucune valeur aberrante par rapport à elles-mêmes. Assurez-vous que les données d’entraînement couvrent une période typique exempte de valeurs aberrantes réelles, ou étiquetez les valeurs aberrantes connues dans une colonne booléenne.

• Vous ne pouvez pas cloner de modèles ni les partager entre rôles ou comptes. Lors du clonage d’un schéma ou d’une base de données, les objets du modèle sont ignorés.

• Vous ne pouvez pas répliquer une instance de la classe ANOMALY_DETECTION.

Sélection d’un entrepôt virtuel¶

Un entrepôt virtuel Snowflake fournit les ressources de calcul nécessaires à l’entraînement et à l’utilisation des modèles de machine learning pour cette fonction. Cette section fournit des conseils généraux sur le choix de la meilleure taille et du meilleur type d’entrepôt à cette fin, en se concentrant sur l’étape d’entraînement (la partie du processus qui prend le plus de temps et qui mobilise le plus de mémoire).

Octroi de privilèges pour la création d’objets de détection d’anomalies¶

L’entraînement d’un modèle de détection d’anomalies aboutit à un objet au niveau du schéma. Par conséquent, le rôle que vous utilisez pour créer des modèles doit avoir le privilège CREATE SNOWFLAKE.ML.ANOMALY_DETECTION sur le schéma où le modèle est créé, ce qui permet au modèle d’y être stocké. Ce privilège est similaire à d’autres privilèges de schéma tels que CREATE TABLE ou CREATE VIEW.

Snowflake vous recommande de créer un rôle nommé analyst qui sera utilisé par les personnes devant détecter des anomalies.

Dans l’exemple suivant, le rôle admin est le propriétaire du schéma admin_db.admin_schema. Le rôle analyst doit créer des modèles dans ce schéma.

USE ROLE admin;
GRANT USAGE ON admin_db TO ROLE analyst;
GRANT USAGE ON admin_schema TO ROLE analyst;
GRANT CREATE SNOWFLAKE.ML.ANOMALY_DETECTION ON SCHEMA admin_db.admin_schema TO ROLE analyst;

Pour utiliser ce schéma, un utilisateur assume le rôle analyst :

USE ROLE analyst;
USE SCHEMA admin_db.admin_schema;

Si le rôle analyst dispose des privilèges CREATE SCHEMA dans la base de données analyst_db, il peut créer un nouveau schéma analyst_db.analyst_schema et créer des modèles de détection d’anomalies dans ce schéma :

USE ROLE analyst;
CREATE SCHEMA analyst_db.analyst_schema;
USE SCHEMA analyst_db.analyst_schema;

Pour révoquer le privilège de création de modèle d’un rôle sur le schéma, utilisez REVOKE <privilèges> :

REVOKE CREATE SNOWFLAKE.ML.ANOMALY_DETECTION ON SCHEMA admin_db.admin_schema FROM ROLE analyst;

Détection d’anomalies pour une série temporelle unique (non supervisée)¶

Pour détecter les anomalies dans vos données :

1. Entraînez un modèle de détection d’anomalies à l’aide de données historiques.

2. Utilisez le modèle de détection d’anomalies entraîné pour détecter les anomalies dans les données historiques ou projetées. Les horodatages des données de test doivent suivre chronologiquement les horodatages des données d’entraînement. Vous avez besoin d’au moins 2 points de données pour entraîner un modèle, d’au moins 12 pour des résultats non naïfs et d’au moins 60 pour des résultats non linéaires.

Consultez ANOMALY_DETECTION pour obtenir des informations sur les paramètres utilisés lors de la création et de l’utilisation d’un modèle.

BEGIN
  CALL basic_model!DETECT_ANOMALIES(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_to_analyze'),
     TIMESTAMP_COLNAME =>'date',
     TARGET_COLNAME => 'sales'
  );
  LET x := SQLID;
  CREATE TABLE my_anomalies AS SELECT * FROM TABLE(RESULT_SCAN(:x));
END;

SELECT * FROM my_anomalies;

Entraînement d’un modèle de détection d’anomalies avec des données balisées¶

Dans l’exemple précédent, le résultat du modèle semble inexact. Cela s’explique probablement par le fait que :

• Le modèle de détection d’anomalies a été entraîné sur très peu de données d’entrée.

• Un plus grand nombre de vestes (30) ont été vendues le 03/01/2020. Cela a eu pour effet de biaiser les prédictions à la hausse et d’augmenter la taille de l’intervalle de prédiction.

Pour améliorer la précision du modèle de détection d’anomalies, vous pouvez soit inclure davantage de données d’entraînement, soit baliser les données d’entraînement (entraînement supervisé). Les données d’entraînement balisées comportent une colonne booléenne supplémentaire qui indique si chaque ligne est une anomalie connue. Le balisage peut aider le modèle de détection d’anomalies à éviter l’adaptation excessive aux anomalies connues dans les données d’entraînement.

Pour inclure des données balisées dans des données d’entraînement, spécifiez la colonne contenant la balise dans l’argument du constructeur LABEL_COLNAME de la commande CREATE SNOWFLAKE.ML.ANOMALY_DETECTION. Par exemple :

1. Créez une vue ou concevez une requête qui renvoie les balises avec les données d’entraînement.

   Pour cet exemple, exécutez la commande CREATE VIEW pour créer une vue nommée view_with_labeled_data qui contient les balises dans une colonne nommée label :

   CREATE OR REPLACE VIEW view_with_labeled_data_for_training
     AS SELECT date, sales, label FROM historical_sales_data
       WHERE store_id=1 and item='jacket';
   

   Copy

2. Créez un objet pour le modèle de détection d’anomalies et entraînez le modèle sur les données de cette vue.

   Pour cet exemple, exécutez la commande CREATE SNOWFLAKE.ML.ANOMALY_DETECTION pour créer un objet de détection d’anomalies nommé model_trained_with_labeled_data. L’instruction suivante crée l’objet de détection des anomalies :

   CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION model_trained_with_labeled_data(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_labeled_data_for_training'),
     TIMESTAMP_COLNAME => 'date',
     TARGET_COLNAME => 'sales',
     LABEL_COLNAME => 'label'
   );
   

   Copy

3. En utilisant ce nouveau modèle de détection d’anomalies, appelez la méthode <nom>!DETECT_ANOMALIES en lui transmettant les mêmes arguments que ceux que vous avez utilisés dans Détection d’anomalies pour une série temporelle unique (non supervisée) :

   CALL model_trained_with_labeled_data!DETECT_ANOMALIES(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_to_analyze'),
     TIMESTAMP_COLNAME =>'date',
     TARGET_COLNAME => 'sales'
   );
   

   Copy

   La méthode renvoie une table qui comprend des lignes pour les données actuellement dans la vue view_with_data_to_analyze ainsi que la prédiction du détecteur. Pour une description des colonnes de cette table, consultez Sortie.

Sortie

Les résultats ont été arrondis pour faciliter la lecture.

+-------------------------+----+----------+---------------+--------------+------------+--------------+------------+
| TS                      |  Y | FORECAST |   LOWER_BOUND |  UPPER_BOUND | IS_ANOMALY |   PERCENTILE |   DISTANCE |
|-------------------------+----+----------+---------------+--------------+------------+--------------+------------|
| 2020-01-16 00:00:00.000 |  6 |        6 |  0.82         | 11.18        | False      | 0.5          | 0          |
| 2020-01-17 00:00:00.000 | 20 |        6 | -0.39         | 12.33        | True       | 0.99         | 5.70       |
+-------------------------+----+----------+---------------+--------------+------------+--------------+------------+

Spécification de l’intervalle de prédiction pour la détection d’anomalies¶

Vous pouvez détecter les anomalies avec différents niveaux de sensibilité. Pour spécifier le pourcentage d’observations à classer comme anomalies, créez un OBJECT qui contient les paramètres de configuration de <nom>!DETECT_ANOMALIES, et attribuez à la clé prediction_interval le pourcentage d’observations à classer comme anomalies.

Pour construire cet objet, vous pouvez utiliser soit une constante d’objet soit la fonction OBJECT_CONSTRUCT.

Ensuite, lorsque vous appelez la méthode <nom>!DETECT_ANOMALIES, transmettez cet objet en tant qu’argument CONFIG_OBJECT.

Par défaut, la valeur associée à la clé prediction_interval est définie sur 0,99, ce qui signifie qu’environ 1 % des données sont marquées comme des anomalies. Vous pouvez spécifier une valeur entre 0 et 1 :

• Pour marquer moins d’observations comme des anomalies, spécifiez une valeur plus élevée pour prediction_interval.

• Pour marquer plus d’observations comme des anomalies, réduisez la valeur de prediction_interval.

L’exemple suivant configure la détection des anomalies de manière plus stricte en définissant l”prediction_interval à 0,995. L’exemple utilise également le modèle entraîné sur des données balisées (que vous avez configuré dans Entraînement d’un modèle de détection d’anomalies avec des données balisées) avec la vue contenant les données à analyser (que vous avez configurée dans Détection d’anomalies pour une série temporelle unique (non supervisée)).

CALL model_trained_with_labeled_data!DETECT_ANOMALIES(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_to_analyze'),
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales',
  CONFIG_OBJECT => {'prediction_interval':0.995}
);

Cette instruction produit une table qui comprend des lignes pour les données actuellement dans la vue view_with_data_to_analyze. Chaque ligne comprend une colonne avec la prédiction du détecteur. Vous pouvez constater que le résultat de ce modèle est plus précis que celui de l’exemple non balisé.

Sortie

Les résultats ont été arrondis pour faciliter la lecture.

+-------------------------+----+----------+---------------+--------------+------------+--------------+------------+
| TS                      |  Y | FORECAST |   LOWER_BOUND |  UPPER_BOUND | IS_ANOMALY |   PERCENTILE |   DISTANCE |
|-------------------------+----+----------+---------------+--------------+------------+--------------+------------|
| 2020-01-16 00:00:00.000 |  6 |        6 |  0.36         | 11.64        | False      | 0.5          | 0          |
| 2020-01-17 00:00:00.000 | 20 |        6 | -0.90         | 12.90        | True       | 0.99         | 5.70       |
+-------------------------+----+----------+---------------+--------------+------------+--------------+------------+

Ajout de colonnes supplémentaires pour l’analyse¶

Vous pouvez inclure des colonnes supplémentaires dans les données (par exemple temperature, weather, is_black_friday) à des fins d’entraînement et d’analyse, si ces colonnes peuvent vous aider à améliorer l’identification de véritables anomalies.

Pour inclure de nouvelles colonnes pour l’analyse :

1. Pour les données d’entraînement, créez une vue ou concevez une requête qui inclut les nouvelles colonnes, et créez un nouvel objet de détection d’anomalies, en lui transmettant une référence à cette vue ou à cette requête.

2. Pour les données à analyser, créez une vue ou concevez une requête qui inclut les nouvelles colonnes et transmettez une référence à cette vue ou requête à la méthode <nom>!DETECT_ANOMALIES.

Le modèle de détection d’anomalies détecte et utilise automatiquement les colonnes supplémentaires.

Par exemple, supposons que vous souhaitiez ajouter les colonnes temperature, humidity, et holiday :

1. Créez une vue ou concevez une requête qui renvoie les données d’entraînement avec ces colonnes supplémentaires.

   Pour cet exemple, exécutez la commande CREATE VIEW pour créer une vue nommée view_with_training_data_extra_columns :

   CREATE OR REPLACE VIEW view_with_training_data_extra_columns
     AS SELECT date, sales, label, temperature, humidity, holiday
       FROM historical_sales_data
       WHERE store_id=1 AND item='jacket';
   

   Copy

2. Créez un objet pour le modèle de détection d’anomalies et entraînez le modèle sur les données de cette vue.

   Pour cet exemple, exécutez la commande CREATE SNOWFLAKE.ML.ANOMALY_DETECTION pour créer un objet de détection d’anomalies nommé model_with_additional_columns, en y ajoutant une référence à la nouvelle vue :

   CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION model_with_additional_columns(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_training_data_extra_columns'),
     TIMESTAMP_COLNAME => 'date',
     TARGET_COLNAME => 'sales',
     LABEL_COLNAME => 'label'
   );
   

   Copy

3. Créez une vue ou concevez une requête qui renvoie les données à analyser avec ces colonnes supplémentaires.

   Pour cet exemple, exécutez la commande CREATE VIEW pour créer une vue nommée view_with_data_for_analysis_extra_columns :

   CREATE OR REPLACE VIEW view_with_data_for_analysis_extra_columns
     AS SELECT date, sales, temperature, humidity, holiday
       FROM new_sales_data
       WHERE store_id=1 AND item='jacket';
   

   Copy

4. À l’aide de ce nouvel objet de détection d’anomalies, appelez la méthode <nom>!DETECT_ANOMALIES en lui transmettant la nouvelle vue :

   CALL model_with_additional_columns!DETECT_ANOMALIES(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_for_analysis_extra_columns'),
     TIMESTAMP_COLNAME => 'date',
     TARGET_COLNAME => 'sales',
     CONFIG_OBJECT => {'prediction_interval':0.93}
   );
   

   Copy

   Cette instruction produit une table qui comprend des lignes pour les données actuellement dans la vue view_with_data_for_analysis_extra_columns ainsi que la prédiction du détecteur. Le format de sortie est le même que celui de la sortie affichée pour les commandes que vous avez exécutées précédemment.

Sortie

Les résultats ont été arrondis pour faciliter la lecture.

+-------------------------+----+----------+-------------+--------------+------------+--------------+------------+
| TS                      |  Y | FORECAST | LOWER_BOUND |  UPPER_BOUND | IS_ANOMALY |   PERCENTILE |   DISTANCE |
|-------------------------+----+----------+-------------+--------------+------------+--------------+------------|
| 2020-01-16 00:00:00.000 |  6 |        6 | 2.34        |  9.64        | False      | 0.5          | 0          |
| 2020-01-17 00:00:00.000 | 20 |        6 | 1.56        | 10.451       | True       | 0.99         | 5.70       |
+-------------------------+----+----------+-------------+--------------+------------+--------------+------------+

Détection d’anomalies dans des séries multiples¶

Les sections précédentes ont fourni des exemples de détection d’anomalies pour une série unique. Ces exemples ont mis en évidence des anomalies pour la vente d’un type d’article (vestes) dans un magasin (ID magasin 1). Détecter les anomalies pour plusieurs séries temporelles en même temps (par exemple, pour plusieurs combinaisons d’articles et de magasins) :

1. Pour les données d’entraînement, créez une vue ou concevez une requête qui inclut une colonne identifiant la série, et créez un nouvel objet de détection d’anomalies, en transmettant une référence à cette vue ou requête et en spécifiant le nom de la colonne de la série pour l’argument SERIES_COLNAME.

2. Pour les données à analyser, créez une vue ou concevez une requête qui inclut la colonne qui identifie la série. Appelez la méthode <nom>!DETECT_ANOMALIES, en transmettant une référence à cette vue ou requête et en spécifiant le nom de la colonne de la série pour l’argument SERIES_COLNAME.

Supposons par exemple que vous souhaitiez utiliser la combinaison des colonnes store_id et item pour identifier la série :

1. Créez une vue ou concevez une requête qui renvoie les données d’entraînement avec la colonne correspondant à la série.

   Pour cet exemple, exécutez la commande CREATE VIEW pour créer une vue nommée view_with_training_data_multiple_series qui contient une colonne nommée store_item qui identifie la série comme une combinaison d’un ID de magasin et un article :

   CREATE OR REPLACE VIEW view_with_training_data_multiple_series
     AS SELECT
       [store_id, item] AS store_item,
       date,
       sales,
       label,
       temperature,
       humidity,
       holiday
     FROM historical_sales_data;
   

   Copy

2. Créez un objet pour la détection d’anomalies et entraînez le modèle sur les données de cette vue.

   Pour cet exemple, exécutez la commande CREATE SNOWFLAKE.ML.ANOMALY_DETECTION pour créer un objet de détection d’anomalies nommé model_for_multiple_series, en transmettant une référence à la nouvelle vue et en spécifiant store_item pour l’argument SERIES_COLNAME :

   CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION model_for_multiple_series(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_training_data_multiple_series'),
     SERIES_COLNAME => 'store_item',
     TIMESTAMP_COLNAME => 'date',
     TARGET_COLNAME => 'sales',
     LABEL_COLNAME => 'label'
   );
   

   Copy

3. Créez une vue ou concevez une requête qui renvoie les données à analyser avec la colonne des séries.

   Pour cet exemple, exécutez la commande CREATE VIEW pour créer une vue nommée view_with_data_for_analysis_multiple_series qui contient une colonne nommée store_item pour la série :

   CREATE OR REPLACE VIEW view_with_data_for_analysis_multiple_series
     AS SELECT
       [store_id, item] AS store_item,
       date,
       sales,
       temperature,
       humidity,
       holiday
     FROM new_sales_data;
   

   Copy

4. À l’aide de ce nouvel objet de détection d’anomalies, appelez la méthode <nom>!DETECT_ANOMALIES, en lui transmettant la nouvelle vue et en spécifiant store_item pour l’argument SERIES_COLNAME :

   CALL model_for_multiple_series!DETECT_ANOMALIES(
     INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_for_analysis_multiple_series'),
     SERIES_COLNAME => 'store_item',
     TIMESTAMP_COLNAME => 'date',
     TARGET_COLNAME => 'sales',
     CONFIG_OBJECT => {'prediction_interval':0.995}
   );
   

   Copy

   Cette instruction produit une table qui comprend des lignes pour les données actuellement dans la vue view_with_data_for_analysis_multiple_series ainsi que la prédiction du détecteur. La sortie comprend la colonne qui identifie la série.

Sortie

Les résultats ont été arrondis pour faciliter la lecture.

+--------------+-------------------------+----+----------+---------------+--------------+------------+---------------+--------------+
| SERIES       | TS                      |  Y | FORECAST |   LOWER_BOUND |  UPPER_BOUND | IS_ANOMALY |    PERCENTILE |     DISTANCE |
|--------------+-------------------------+----+----------+---------------+--------------+------------+---------------+--------------|
| [            | 2020-01-16 00:00:00.000 |  3 |      6.3 |  2.07         | 10.53        | False      | 0.01          | -2.19         |
|   2,         |                         |    |          |               |              |            |               |              |
|   "umbrella" |                         |    |          |               |              |            |               |              |
| ]            |                         |    |          |               |              |            |               |              |
| [            | 2020-01-17 00:00:00.000 | 70 |      2.9 | -1.33         |  7.13        | True       | 1             | 44.54         |
|   2,         |                         |    |          |               |              |            |               |              |
|   "umbrella" |                         |    |          |               |              |            |               |              |
| ]            |                         |    |          |               |              |            |               |              |
| [            | 2020-01-16 00:00:00.000 |  6 |      6   |  0.36         | 11.64        | False      | 0.5           |  0           |
|   1,         |                         |    |          |               |              |            |               |              |
|   "jacket"   |                         |    |          |               |              |            |               |              |
| ]            |                         |    |          |               |              |            |               |              |
| [            | 2020-01-17 00:00:00.000 | 20 |      6   | -0.90         | 12.90        | True       | 0.99          |  5.70         |
|   1,         |                         |    |          |               |              |            |               |              |
|   "jacket"   |                         |    |          |               |              |            |               |              |
| ]            |                         |    |          |               |              |            |               |              |
+--------------+-------------------------+----+----------+---------------+--------------+------------+---------------+--------------+

Entraînement récurrent avec une tâche Snowflake¶

Vous pouvez mettre à jour votre modèle pour refléter les données les plus récentes en utilisant les tâches Snowflake.

Pour créer une tâche qui actualise l’objet de détection des anomalies toutes les heures, exécutez l’instruction suivante, en remplaçant your_warehouse_name par le nom de votre entrepôt :

CREATE OR REPLACE TASK ad_model_retrain_task
WAREHOUSE = <your_warehouse_name>
SCHEDULE = '60 MINUTE'
AS
EXECUTE IMMEDIATE
$$
BEGIN
  CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION model_trained_with_labeled_data(
    INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_labeled_data_for_training'),
    TIMESTAMP_COLNAME => 'date',
    TARGET_COLNAME => 'sales',
    LABEL_COLNAME => 'label'
  );
END;
$$;

Par défaut, les tâches venant d’être créées sont suspendues.

Pour reprendre la tâche, exécutez la commande ALTER TASK … RESUME :

ALTER TASK ad_model_retrain_task RESUME;

Pour mettre la tâche en pause, exécutez la commande ALTER TASK … SUSPEND :

ALTER TASK ad_model_retrain_task SUSPEND;

Surveillance à l’aide d’une tâche Snowflake¶

Vous pouvez également utiliser les tâches Snowflake pour surveiller vos données à une fréquence donnée.

Tout d’abord, créez une table qui contiendra les résultats de la détection des anomalies :

CREATE OR REPLACE TABLE anomaly_res_table (
  ts TIMESTAMP_NTZ, y FLOAT, forecast FLOAT, lower_bound FLOAT, upper_bound FLOAT,
  is_anomaly BOOLEAN, percentile FLOAT, distance FLOAT);

Créez une tâche pour stocker les résultats d’une opération récurrente de détection des anomalies dans la table. Cet exemple définit le paramètre WAREHOUSE sur snowhouse. Vous pouvez le remplacer par votre propre entrepôt :

CREATE OR REPLACE TASK ad_model_monitoring_task
WAREHOUSE = snowhouse
SCHEDULE = '1 minute'
AS
EXECUTE IMMEDIATE
$$
BEGIN
  CALL model_trained_with_labeled_data!DETECT_ANOMALIES(
    INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_to_analyze'),
    TIMESTAMP_COLNAME => 'date',
    TARGET_COLNAME => 'sales',
    CONFIG_OBJECT => {'prediction_interval':0.99}
  );

  INSERT INTO anomaly_res_table (ts, y, forecast, lower_bound, upper_bound, is_anomaly, percentile, distance)
    SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));
END;
$$;

Pour reprendre la tâche, exécutez la commande ALTER TASK … RESUME :

ALTER TASK ad_model_monitoring_task RESUME;

anomaly_res_table contiendra alors tous les résultats pour chaque tâche exécutée.

Pour mettre la tâche en pause, exécutez la commande ALTER TASK … SUSPEND :

ALTER TASK ad_model_monitoring_task SUSPEND;

Surveillance à l’aide d’une alerte Snowflake¶

Vous pouvez également utiliser des alertes Snowflake pour surveiller vos données à une fréquence donnée et vous envoyer un e-mail avec les anomalies détectées. Les instructions suivantes créent une alerte qui détecte les anomalies toutes les minutes. Vous définissez d’abord une procédure stockée pour détecter les anomalies, puis vous créez une alerte qui utilise cette procédure stockée.

CREATE OR REPLACE PROCEDURE extract_anomalies()
  RETURNS TABLE()
  LANGUAGE SQL
  AS
  $$
    BEGIN
      CALL model_trained_with_labeled_data!DETECT_ANOMALIES(
        INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'view_with_data_to_analyze'),
        TIMESTAMP_COLNAME => 'date',
        TARGET_COLNAME => 'sales',
        CONFIG_OBJECT => {'prediction_interval':0.99}
      );

      DECLARE
        res RESULTSET DEFAULT (SELECT * FROM TABLE(RESULT_SCAN(-1)) WHERE is_anomaly = TRUE);
      BEGIN
        RETURN TABLE(res);
      END;
    END;
  $$
  ;

CREATE OR REPLACE ALERT sample_sales_alert
WAREHOUSE = <your_warehouse_name>
SCHEDULE = '1 MINUTE'
IF (EXISTS (CALL extract_anomalies()))
THEN
CALL SYSTEM$SEND_EMAIL(
  'sales_email_alert',
  'your_email@snowflake.com',
  'Anomalous Sales Data Detected in data stream',
  CONCAT(
    'Anomalous Sales Data Detected in data stream \n',
    'Value outside of prediction interval detected in the most recent run at ',
    current_timestamp(1)
  ));

Pour démarrer ou reprendre l’alerte, exécutez la commande ALTER ALERT … RESUME :

ALTER ALERT sample_sales_alert RESUME;

Pour mettre l’alerte en pause, exécutez la commande ALTER ALERT … SUSPEND :

ALTER ALERT sample_sales_alert SUSPEND;

Limitations¶

• Vous ne pouvez pas choisir la technique utilisée pour calculer l’importance des fonctions.

• Les scores d’importance des fonctions peuvent être utiles pour obtenir une intuition sur les fonctions qui sont importantes pour la précision de votre modèle ; mais les valeurs réelles doivent être considérées comme des estimations.

Exemple¶

Pour comprendre l’importance relative de vos fonctions pour votre modèle, entraînez un modèle, puis appelez <nom>!EXPLAIN_FEATURE_IMPORTANCE. Dans cet exemple, vous allez d’abord créer des données aléatoires avec deux variables exogènes, l’une qui est aléatoire et donc peu susceptible d’être très importante pour votre modèle, et l’autre qui est une copie de votre cible, et donc susceptible d’avoir une plus grande importance pour votre modèle.

Exécutez les instructions suivantes pour générer les données, entraîner un modèle sur celles-ci et obtenir l’importance des fonctions :

CREATE OR REPLACE VIEW v_random_data AS SELECT
  DATEADD('minute', ROW_NUMBER() over (ORDER BY 1), '2023-12-01')::TIMESTAMP_NTZ ts,
  MOD(SEQ1(),10) y,
  UNIFORM(1, 100, RANDOM(0)) exog_a
FROM TABLE(GENERATOR(ROWCOUNT => 500));

CREATE OR REPLACE VIEW v_feature_importance_demo AS SELECT
  ts,
  y,
  exog_a
FROM v_random_data;

SELECT * FROM v_feature_importance_demo;

CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION anomaly_model_feature_importance_demo(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v_feature_importance_demo'),
  TIMESTAMP_COLNAME => 'ts',
  TARGET_COLNAME => 'y',
  LABEL_COLNAME => ''
);

CALL anomaly_model_feature_importance_demo!EXPLAIN_FEATURE_IMPORTANCE();

Sortie

Comme cet exemple utilise des données aléatoires, ne vous attendez pas à ce que votre sortie corresponde exactement à celle-ci.

+------+--------------------------------------+-------+-------------------------+
| RANK | FEATURE_NAME                         | SCORE | FEATURE_TYPE            |
+------+--------------------------------------+-------+-------------------------+
|    1 | aggregated_endogenous_trend_features |  0.36 | derived_from_endogenous |
|    2 | exog_a                               |  0.22 | user_provided           |
|    3 | epoch_time                           |  0.15 | derived_from_timestamp  |
|    4 | minute                               |  0.13 | derived_from_timestamp  |
|    5 | lag60                                |  0.07 | derived_from_endogenous |
|    6 | lag120                               |  0.06 | derived_from_endogenous |
|    7 | hour                                 |  0.01 | derived_from_timestamp  |
+------+--------------------------------------+-------+-------------------------+

Exemple¶

CREATE TABLE t_error(date TIMESTAMP_NTZ, sales FLOAT, series VARCHAR);
INSERT INTO t_error VALUES
  (TO_TIMESTAMP_NTZ('2019-12-20'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-21'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-22'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-23'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-24'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-25'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-26'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-27'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-28'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-29'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-30'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-31'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-01'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-02'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-03'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-04'), 7.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-05'), 10.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-06'), 13.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-06'), 12.0, 'B'), -- duplicate timestamp
  (TO_TIMESTAMP_NTZ('2020-01-07'), 15.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-08'), 14.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-09'), 18.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-10'), 12.0, 'B');

CREATE SNOWFLAKE.ML.ANOMALY_DETECTION model(
  INPUT_DATA => SYSTEM$QUERY_REFERENCE('SELECT date, sales, series FROM t_error'),
  SERIES_COLNAME => 'series',
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales',
  LABEL_COLNAME => '',
  CONFIG_OBJECT => {'ON_ERROR': 'SKIP'}
);

CALL model!SHOW_TRAINING_LOGS();

Sortie

+--------+-------------------------------------------------------------------------------------------------+
| SERIES | LOGS                                                                                            |
+--------+-------------------------------------------------------------------------------------------------+
| "B"    | {   "Errors": [     "Frequency cannot be inferred when duplicate timestamps are present."   ] } |
| "A"    | NULL                                                                                            |
+--------+-------------------------------------------------------------------------------------------------+