Vue d’ensemble de la stratégie de mise à jour

  • Article

Les stratégies de mise à jour sont des mécanismes d’automatisation déclenchés lorsque de nouvelles données sont écrites dans une table. Ils éliminent la nécessité d’une orchestration spéciale en exécutant une requête pour transformer les données ingérées et enregistrer le résultat dans une table de destination. Plusieurs stratégies de mise à jour peuvent être définies sur une seule table, ce qui permet d’effectuer différentes transformations et d’enregistrer des données dans plusieurs tables simultanément. Les tables cibles peuvent avoir un schéma, une stratégie de rétention et d’autres stratégies différents de la table source.

Par exemple, une table source de trace à haut débit peut contenir des données formatées sous la forme d'une colonne de texte libre. La table cible peut inclure des lignes de trace spécifiques, avec un schéma bien structuré généré à partir d'une transformation des données en texte libre de la table source à l'aide de l'opérateur d'analyse. Pour plus d’informations, consultez scénarios courants.

Le diagramme suivant illustre une vue générale d’une stratégie de mise à jour. Il montre deux stratégies de mise à jour qui sont déclenchées lorsque des données sont ajoutées à la deuxième table source et entraîne l’ajout de données transformées aux deux tables cibles.

Diagramme montrant une vue d’ensemble de la stratégie de mise à jour.

Une stratégie de mise à jour est soumise aux mêmes restrictions et bonnes pratiques que l’ingestion régulière. La stratégie évolue en fonction de la taille du cluster et est plus efficace lors de la gestion de l’ingestion en bloc.

Notes

  • La table source et la table cible doivent se trouver dans la même base de données.
  • Le schéma de fonction de stratégie de mise à jour et le schéma de table cible doivent correspondre dans leurs noms de colonnes, types et ordre.

L’ingestion de données mises en forme améliore les performances, et le format CSV est préféré, car il s’agit d’un format bien défini. Parfois, toutefois, vous n’avez aucun contrôle sur le format des données, ou vous souhaitez enrichir les données ingérées, par exemple, en joignant des enregistrements avec une table de dimension statique dans votre base de données.

Mettre à jour la requête de stratégie

Si la stratégie de mise à jour est définie sur la table cible, plusieurs requêtes peuvent s’exécuter sur les données ingérées dans une table source. S’il existe plusieurs stratégies de mise à jour, l’ordre d’exécution n’est pas nécessairement connu.

Limitations des requêtes

  • La requête liée à la stratégie peut appeler des fonctions stockées, mais :
    • Il ne peut pas effectuer de requêtes entre clusters.
    • Il ne peut pas accéder aux données externes ou aux tables externes.
    • Il ne peut pas créer de légendes (à l’aide d’un plug-in).
  • La requête n’a pas d’accès en lecture aux tables pour lesquelles la stratégie RestrictedViewAccess est activée.
  • Pour connaître les limitations de stratégie de mise à jour dans l’ingestion en streaming, consultez Limitations de l’ingestion en streaming.

Avertissement

Une requête incorrecte peut empêcher l’ingestion de données dans la table source. Il est important de noter que les limitations, ainsi que la compatibilité entre les résultats de la requête et le schéma des tables source et de destination, peuvent entraîner une requête incorrecte pour empêcher l’ingestion de données dans la table source.

Ces limitations sont validées lors de la création et de l’exécution de la stratégie, mais pas lors de la mise à jour des fonctions stockées arbitraires que la requête peut référencer. Par conséquent, il est essentiel d’apporter des modifications avec précaution pour garantir que la stratégie de mise à jour reste intacte.

Lors du référencement de la Source table dans la Query partie de la stratégie ou dans les fonctions référencées par la Query partie :

  • N’utilisez pas le nom qualifié de la table. Utilisez plutôt TableName.
  • N'utilisez pas database("DatabaseName").TableName ou cluster("ClusterName").database("DatabaseName").TableName.

Objet de stratégie de mise à jour

Une table peut avoir zéro ou plusieurs objets de stratégie de mise à jour qui lui sont associés. Chaque objet de ce type est représenté sous la forme d’un conteneur de propriétés JSON, avec les propriétés suivantes définies.

Propriété Type Description
IsEnabled bool Indique si la stratégie de mise à jour est true - activée ou false - désactivée
Source string Nom de la table qui déclenche l’appel de la stratégie de mise à jour
Requête string Requête utilisée pour produire des données pour la mise à jour
IsTransactional bool Indique si la stratégie de mise à jour est transactionnelle ou non, la valeur par défaut est false. Si la stratégie est transactionnelle et que la stratégie de mise à jour échoue, la table source n’est pas mise à jour.
PropagateIngestionProperties bool Indique si les propriétés spécifiées pendant l’ingestion de la table source, telles que les balises d’étendue et l’heure de création, s’appliquent à la table cible.
ManagedIdentity string Identité managée pour le compte de laquelle la stratégie de mise à jour s’exécute. L’identité managée peut être un ID d’objet ou le system mot réservé. La stratégie de mise à jour doit être configurée avec une identité managée lorsque la requête référence des tables dans d’autres bases de données ou des tables avec une stratégie de sécurité au niveau des lignes activée. Pour plus d’informations, consultez Utiliser une identité managée pour exécuter une stratégie de mise à jour.

Notes

Dans les systèmes de production, définissez IsTransactional:true pour vous assurer que la table cible ne perd pas de données en cas de défaillances temporaires.

Notes

Les mises à jour en cascade sont autorisées, par exemple de la table A, à la table B et à la table C. Toutefois, si les stratégies de mise à jour sont définies de manière circulaire, cela est détecté au moment de l’exécution et la chaîne de mises à jour est interrompue. Les données ne sont ingérées qu’une seule fois dans chaque table de la chaîne.

Commandes de gestion

Les commandes de gestion des stratégies de mise à jour sont les suivantes :

La stratégie de mise à jour est lancée après l’ingestion

Les stratégies de mise à jour prennent effet lorsque des données sont ingérées ou déplacées vers une table source, ou lorsque des étendues sont créées dans une table source, à l’aide de l’une des commandes suivantes :

Avertissement

Lorsque la stratégie de mise à jour est appelée dans le cadre d’une .set-or-replace commande, par défaut, les données des tables dérivées sont remplacées de la même manière que dans la table source. Des données peuvent être perdues dans toutes les tables avec une relation de stratégie de mise à jour si la replace commande est appelée. Utilisez .set-or-append à la place.

Supprimer des données de la table source

Après avoir ingéré des données dans la table cible, vous pouvez éventuellement les supprimer de la table source. Définissez une période de suppression réversible de 0sec (ou 00:00:00) dans la stratégie de rétention de la table source et la stratégie de mise à jour comme transactionnelle. Les conditions suivantes s’appliquent :

  • Les données sources ne sont pas interrogeables à partir de la table source
  • Les données sources ne sont pas conservées dans un stockage durable dans le cadre de l’opération d’ingestion
  • Les performances opérationnelles s’améliorent. Les ressources post-ingestion sont réduites pour les opérations de nettoyage en arrière-plan sur les étendues dans la table source.

Notes

Lorsque la table source a une période de suppression réversible de (ou 00:00:00), toute stratégie de 0sec mise à jour faisant référence à cette table doit être transactionnelle.

Impact sur les performances

Les stratégies de mise à jour peuvent affecter les performances du cluster et l’ingestion des étendues de données est multipliée par le nombre de tables cibles. Il est important d’optimiser la requête liée à la stratégie. Vous pouvez tester l’impact d’une stratégie de mise à jour sur les performances en appelant la stratégie sur des étendues déjà existantes, avant de créer ou de modifier la stratégie, ou sur la fonction utilisée avec la requête.

Évaluer l’utilisation des ressources

Utilisez .show queries, pour évaluer l’utilisation des ressources (processeur, mémoire, et ainsi de suite) avec les paramètres suivants :

  • Définissez la Source propriété, le nom de la table source, comme MySourceTable
  • Définissez la Query propriété pour appeler une fonction nommée MyFunction()
// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

Échecs

Avec le paramètre par défaut , IsTransactional:falseles données peuvent toujours être ingérées dans la table source même si la stratégie ne s’exécute pas.

La définition IsTransactional:true garantit la cohérence entre les données de la table source et cible. Toutefois, si les conditions de stratégie échouent, les données ne sont pas ingérées dans la table source. Selon les conditions, les données sont parfois ingérées dans la table source, mais pas dans la table cible. Toutefois, si votre stratégie est incorrectement définie ou s’il existe une incompatibilité de schéma, les données ne sont pas ingérées dans la table source ou cible. Par exemple, une incompatibilité entre le schéma de sortie de requête et la table cible peut être provoquée par la suppression d’une colonne de la table cible.

Vous pouvez afficher les échecs à l’aide de la .show ingestion failures commande .

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

Traitement des échecs

Stratégie non transactionnelle

Lorsque la valeur est définie IsTransactional:falsesur , tout échec d’exécution de la stratégie est ignoré. L’ingestion n’est pas automatiquement retentée. Vous pouvez réessayer manuellement d’ingestion.

Stratégie transactionnelle

Si la valeur est définie sur IsTransactional:true, si la méthode d’ingestion est pull, le service Gestion des données est impliqué et l’ingestion est automatiquement retentée selon les conditions suivantes :

  • Les nouvelles tentatives sont effectuées jusqu’à ce que l’un des paramètres de limite configurables suivants soit respecté : DataImporterMaximumRetryPeriod ou DataImporterMaximumRetryAttempts
  • Par défaut, le DataImporterMaximumRetryPeriod paramètre est de deux jours et DataImporterMaximumRetryAttemptsest de 10
  • La période de backoff commence à 2 minutes et double. Ainsi, l’attente commence par 2 min, puis augmente à 4 min, à 8 min, à 16 min et ainsi de suite.

Dans tous les autres cas, vous pouvez réessayer manuellement d’ingestion.

Exemple d’extraction, de transformation, de chargement

Vous pouvez utiliser les paramètres de stratégie de mise à jour pour effectuer l’extraction, la transformation, le chargement (ETL).

Dans cet exemple, utilisez une stratégie de mise à jour avec une fonction simple pour effectuer ETL. Tout d’abord, nous créons deux tables :

  • Table source : contient une colonne de type chaîne unique dans laquelle les données sont ingérées.
  • Table cible : contient le schéma souhaité. La stratégie de mise à jour est définie sur cette table.

  1. Créons la table source :

    .create table MySourceTable (OriginalRecord:string)

  2. Ensuite, créez la table cible :

    .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)

  3. Créez ensuite une fonction pour extraire des données :

    .create function
 with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
     ExtractMyLogs()
    {
    MySourceTable
    | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
    | project-away OriginalRecord
}

  4. À présent, définissez la stratégie de mise à jour pour appeler la fonction que nous avons créée :

    .alter table MyTargetTable policy update
@'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'

  5. Pour vider la table source après l’ingestion des données dans la table cible, définissez la stratégie de rétention sur la table source afin d’avoir 0s comme son SoftDeletePeriod.

     .alter-merge table MySourceTable policy retention softdelete = 0s

Contenu connexe