Vue d’ensemble des stratégies de mise à jour

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

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 table unique, ce qui permet différentes transformations et l’enregistrement 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érentes 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, scénarios courants.

Le diagramme suivant illustre une vue générale d’une stratégie de mise à jour. Il affiche deux stratégies de mise à jour déclenchées lorsque les données sont ajoutées à la deuxième table source. Une fois qu’elles sont déclenchées, les données transformées sont ajoutées aux deux tables cibles.

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

Remarque

• La table source et cible doit 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, types et ordre de colonne.
• La fonction de stratégie de mise à jour peut référencer des tables dans d’autres bases de données. Pour ce faire, la stratégie de mise à jour doit être définie avec une ManagedIdentity propriété et l’identité managée doit avoir viewerun rôle sur les bases de données référencées. L’ingestion de données mises en forme améliore les performances, et le format CSV est préféré en raison d’un format bien défini. Toutefois, vous n’avez pas de contrôle sur le format des données, ou vous souhaitez enrichir les données ingérées, par exemple en joignant des enregistrements à 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 des 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 inter-événements.
  • Il ne peut pas accéder aux données externes ni 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 dont la stratégie RestrictedViewAccess est activée.
• Par défaut, la stratégie d’ingestion streaming est activée pour toutes les tables de l’Eventhouse. Pour utiliser des fonctions avec l’opérateur join dans une stratégie de mise à jour, la stratégie d’ingestion de streaming doit être désactivée. Utilisez la commande .altertableTableNamepolicystreamingingestionPolicyObject pour la désactiver.

Avertissement

Une requête incorrecte peut empêcher l’ingestion des 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 des 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 lorsque des fonctions stockées arbitraires que la requête peut référencer sont mises à jour. 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("<EventhouseName>").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 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	États si la stratégie de mise à jour a la valeur 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 dans la table source, telles que les balises d’étendue et le temps de création, s’appliquent à la table cible.
Identitémanagée	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 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.

Remarque

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 d’échecs temporaires.

Remarque

Les mises à jour en cascade sont autorisées, par exemple de la table A, à la table B, à 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 coupée. Les données sont ingérées 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 :

• .show table *TableName* policy update affiche la stratégie de mise à jour actuelle d’une table.
• .alter table *TableName* policy update définit la stratégie de mise à jour actuelle d’une table.
• .alter-merge table *TableName* policy update ajoute des définitions à la stratégie de mise à jour actuelle d’une table.
• .delete table *TableName* policy update supprime la stratégie de mise à jour actuelle d’une table.

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

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

• .ingestion (pull)
• .ingestion (inline)
• .set | .append | .set-or-append | .set-or-replace
• .move extents
• .replace extents
  • La PropagateIngestionProperties commande prend uniquement en charge les opérations d’ingestion. Lorsque la stratégie de mise à jour est déclenchée dans le cadre d’une ou .move extents d’une .replace extents commande, cette option n’a aucun effet.

Avertissement

Lorsque la stratégie de mise à jour est appelée dans le cadre d’une .set-or-replace commande, les données par défaut dans les tables dérivées sont remplacées de la même façon que dans la table source. Les 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 la supprimer de la table source. Définissez une période de suppression réversible de (ou0sec) dans la stratégie de rétention de 00:00:00la table source et la stratégie de mise à jour comme transactionnelle. Les conditions suivantes s’appliquent :

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

Remarque

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

Impact sur les performances

Les stratégies de mise à jour peuvent affecter les performances 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 des performances d’une stratégie de mise à jour 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 propriété, le nom de la Source table source, en tant que MySourceTable
• Définir 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

Paramètres transactionnels

Le paramètre de stratégie de mise à jour définit si la stratégie de mise à jour est transactionnelle et peut affecter le comportement de la mise à IsTransactional jour de stratégie, comme suit :

• IsTransactional:false: si la valeur est définie sur la valeur par défaut, false, la stratégie de mise à jour ne garantit pas la cohérence entre les données de la table source et cible. Si une stratégie de mise à jour échoue, les données sont ingérées uniquement dans la table source et non dans la table cible. Dans ce scénario, l’opération d’ingestion réussit.
• IsTransactional:true: Si la valeur est définie sur true, le paramètre garantit la cohérence entre les données dans les tables source et cible. Si une stratégie de mise à jour échoue, les données ne sont pas ingérées dans la table source ou cible. Dans ce scénario, l’opération d’ingestion échoue.

Gestion des échecs

Lorsque les mises à jour de stratégie échouent, elles sont gérées différemment selon que le IsTransactional paramètre est true ou false. Les raisons courantes des échecs de stratégie de mise à jour sont les suivantes :

• Incompatibilité entre le schéma de sortie de requête et la table cible.
• Toute erreur de requête.

Vous pouvez afficher les échecs de mise à jour de stratégie à l’aide de la .show ingestion failures commande suivante : dans tout autre cas, vous pouvez réessayer manuellement l’ingestion.

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

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 exécuter ETL. Tout d’abord, nous créons deux tables :

• Table source : contient une seule colonne typée par chaîne 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. Nous allons créer 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 une fois que les données sont ingérées dans la table cible, définissez la stratégie de rétention sur la table source pour avoir 0s comme son SoftDeletePeriod.

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

Contenu connexe

• Scénarios courants d’utilisation des stratégies de mise à jour de table
• Tutoriel : Acheminer les données à l’aide de stratégies de mise à jour de table