Partager via


Vidage des données

S’applique à : ✅Azure Data Explorer

Remarque

Cet article explique comment supprimer les données personnelles de l’appareil ou du service et il peut être utilisé dans le cadre de vos obligations en vertu du Règlement général sur la protection des données. Pour obtenir des informations générales concernant le Règlement général sur la protection des données (RGPD), consultez la section relative au RGPD du Centre de gestion de la confidentialité de Microsoft et la section relative au RGPD du Portail d’approbation de services.

La plateforme de données prend en charge la possibilité de supprimer des enregistrements individuels à l’aide de Kusto .purge et de commandes associées. Vous pouvez également vider une table entière ou vider des enregistrements dans une vue matérialisée.

Avertissement

La suppression des données via la .purge commande est conçue pour être utilisée pour protéger les données personnelles et ne doit pas être utilisée dans d’autres scénarios. Il n’est pas conçu pour prendre en charge les demandes de suppression fréquentes ou la suppression de quantités massives de données et peut avoir un impact significatif sur les performances sur le service.

Instructions pour le vidage

Concevez soigneusement votre schéma de données et examinez les stratégies pertinentes avant de stocker des données personnelles.

  1. Dans un scénario optimal, la période de rétention sur ces données est suffisamment courte et les données sont automatiquement supprimées.
  2. Si l’utilisation de la période de rétention n’est pas possible, isolez toutes les données soumises à des règles de confidentialité dans quelques tables. De façon optimale, utilisez une seule table et liez-la à partir de toutes les autres tables. Cette isolation vous permet d’exécuter le processus de vidage des données sur quelques tables contenant des données sensibles et d’éviter toutes les autres tables.
  3. L’appelant doit effectuer chaque tentative de traitement par lot des .purge commandes sur 1 à 2 commandes par table par jour. N’émettez pas plusieurs commandes avec des prédicats d’identité utilisateur uniques. Au lieu de cela, envoyez une seule commande dont le prédicat inclut toutes les identités utilisateur qui nécessitent une purge.

Processus de vidage

Le processus de purge sélective des données se produit dans les étapes suivantes :

  1. Phase 1 : donnez une entrée avec un nom de table et un prédicat par enregistrement, indiquant les enregistrements à supprimer. Kusto analyse la table qui cherche à identifier les étendues de données qui participeraient au vidage des données. Les étendues identifiées sont celles ayant un ou plusieurs enregistrements pour lesquels le prédicat retourne true.

  2. Phase 2 : (Suppression réversible) Remplacez chaque étendue de données dans la table (identifiée à l’étape (1)) par une version reingestée. La version reingested ne doit pas avoir les enregistrements pour lesquels le prédicat retourne true. Si de nouvelles données ne sont pas ingérées dans la table, les requêtes ne retournent plus de données pour lesquelles le prédicat retourne la valeur true. La durée de la phase de suppression réversible de vidage dépend des paramètres suivants :

    • Nombre d’enregistrements qui doivent être vidés
    • Distribution d’enregistrements dans les étendues de données dans le cluster
    • Nombre de nœuds dans le cluster
    • Capacité de rechange dont elle dispose pour les opérations de vidage
    • Plusieurs autres facteurs

    La durée de la phase 2 peut varier de quelques secondes à plusieurs heures.

  3. Phase 3 : (Suppression définitive) Revenez à tous les artefacts de stockage susceptibles d’avoir les données « incohérentes » et supprimez-les du stockage. Cette phase est effectuée au moins cinq jours après la fin de la phase précédente, mais pas plus de 30 jours après la commande initiale. Ces chronologies sont définies pour respecter les exigences de confidentialité des données.

L’émission d’une .purge commande déclenche ce processus, ce qui prend quelques jours. Si la densité d’enregistrements pour lesquels le prédicat s’applique est suffisamment grande, le processus revient efficacement à réinscrire toutes les données de la table. Cette réingestion a un impact significatif sur les performances et COGS (coût des biens vendus).

Limitations et considérations relatives au vidage

  • Le processus de vidage est définitif et irréversible. Il n’est pas possible d’annuler ce processus ou de récupérer les données qui ont été vidées. Les commandes telles que la suppression de table d’annulation ne peuvent pas récupérer les données purgées. La restauration des données vers une version précédente ne peut pas être passée avant la dernière commande de vidage.

  • Avant d’exécuter le vidage, vérifiez le prédicat en exécutant une requête et en vérifiant que les résultats correspondent au résultat attendu. Vous pouvez également utiliser le processus en deux étapes qui retourne le nombre attendu d’enregistrements qui seront vidés.

  • La .purge commande est exécutée sur le point de terminaison Gestion des données : https://ingest-[YourClusterName].[region].kusto.windows.net. La commande nécessite des autorisations d’administrateur de base de données pour les bases de données appropriées.

  • En raison de l’impact sur les performances du processus de vidage et de garantir que les instructions de vidage ont été suivies, l’appelant est censé modifier le schéma de données afin que les tables minimales incluent des données pertinentes et des commandes de traitement par lot pour réduire l’impact significatif du processus de vidage.

  • Le predicate paramètre de la commande .purge est utilisé pour spécifier les enregistrements à purger. Predicate la taille est limitée à 1 Mo. Lors de la construction du predicate:

    • Utilisez l’opérateur 'in', par exemplewhere [ColumnName] in ('Id1', 'Id2', .. , 'Id1000').
    • Notez les limites de l’opérateur « in » (la liste peut contenir jusqu’à 1,000,000 des valeurs).
    • Si la taille de la requête est grande, utilisez externaldata un opérateur, par exemple where UserId in (externaldata(UserId:string) ["https://...blob.core.windows.net/path/to/file?..."]). Le fichier stocke la liste des ID à vider.
    • La taille totale de la requête, après avoir développé tous les externaldata objets blob (taille totale de tous les objets blob), ne peut pas dépasser 64 Mo.

Vider les performances

Une seule demande de vidage peut être exécutée sur le cluster, à tout moment. Toutes les autres demandes sont mises en file d’attente dans l’état Scheduled . Surveillez la taille de la file d’attente de demande de vidage et conservez des limites adéquates pour répondre aux exigences applicables à vos données.

Pour réduire le temps d’exécution du vidage :

  • Suivez les instructions de vidage pour réduire la quantité de données purgées.

  • Ajustez la stratégie de mise en cache, car le vidage prend plus de temps sur les données à froid.

  • Effectuer un scale-out du cluster

  • Augmentez la capacité de vidage du cluster, après une considération minutieuse, comme détaillé dans la capacité de reconstruction de vidage des étendues.

Déclencher le processus de vidage

Remarque

L’exécution du vidage est appelée en exécutant la commande d’enregistrements TableName de la table de vidage sur le point de terminaison https://ingest-Gestion des données [YourClusterName].[ Region].kusto.windows.net.

Commande Vider table TableName records

La commande purge peut être appelée de deux façons pour différents scénarios d’utilisation :

  • Appel par programmation : étape unique destinée à être appelée par les applications. L’appel de cette commande déclenche directement la séquence d’exécution de vidage.

    Syntaxe

    // Connect to the Data Management service
    #connect "https://ingest-[YourClusterName].[region].kusto.windows.net"
    
    // To purge table records
    .purge table [TableName] records in database [DatabaseName] with (noregrets='true') <| [Predicate]
    
    // To purge materialized view records
    .purge materialized-view [MaterializedViewName] records in database [DatabaseName] with (noregrets='true') <| [Predicate]
    
  • Appel humain : processus en deux étapes qui nécessite une confirmation explicite en tant qu’étape distincte. Tout d’abord, l’appel de la commande retourne un jeton de vérification, qui doit être fourni pour exécuter le vidage réel. Cette séquence réduit le risque de suppression accidentelle de données incorrectes.

Remarque

La première étape de l’appel en deux étapes nécessite l’exécution d’une requête sur l’ensemble du jeu de données pour identifier les enregistrements à vider. Cette requête peut expirer ou échouer sur des tables volumineuses, en particulier avec une quantité importante de données de cache à froid. En cas d’échecs, validez le prédicat vous-même et après avoir vérifié que l’exactitude utilise le vidage en une seule étape avec l’option noregrets .

Syntaxe

Remarque

Pour vous connecter à un cluster à l’aide de l’interface utilisateur web d’Azure Data Explorer, consultez Ajouter des clusters.

// Connect to the Data Management service - this command only works in Kusto.Explorer
#connect "https://ingest-[YourClusterName].[region].kusto.windows.net"

// Step #1 - retrieve a verification token (no records will be purged until step #2 is executed)
.purge table [TableName] records in database [DatabaseName] <| [Predicate]

// Step #2 - input the verification token to execute purge
.purge table [TableName] records in database [DatabaseName] with (verificationtoken=h'<verification token from step #1>') <| [Predicate]

Pour vider une vue matérialisée, remplacez le table mot clé par materialized-view, puis remplacez TableName par materializedViewName.

Paramètres Description
DatabaseName Nom de la base de données
TableName / MaterializedViewName Nom de la table / vue matérialisée à vider.
Predicate Identifie les enregistrements à vider. Consultez les limitations du prédicat de vidage.
noregrets Si cette option est définie, déclenche une activation en une seule étape.
verificationtoken Dans le scénario d’activation en deux étapes (noregrets n’est pas défini), ce jeton peut être utilisé pour exécuter la deuxième étape et valider l’action. S’il verificationtoken n’est pas spécifié, il déclenche la première étape de la commande. Les informations sur le vidage sont retournées avec un jeton qui doit être repassé à la commande pour effectuer l’étape 2.

Limitations du prédicat de vidage

  • Le prédicat doit être une sélection simple (par exemple, où [ColumnName] == 'X’where / [ColumnName] in ('X', 'Y', 'Z') et [OtherColumn] == 'A').
  • Plusieurs filtres doivent être combinés à un « et » plutôt qu’à des clauses distinctes where (par exemple, where [ColumnName] == 'X' and OtherColumn] == 'Y' et non where [ColumnName] == 'X' | where [OtherColumn] == 'Y').
  • Le prédicat ne peut pas référencer les tables autres que la table en cours de vidage (TableName). Le prédicat ne peut inclure que l’instruction de sélection (where). Il ne peut pas projeter des colonnes spécifiques à partir de la table (schéma de sortie lors de l’exécution de 'table | Le prédicat doit correspondre au schéma de table).
  • Les fonctions système (telles que, , ingestion_time()extent_id()) ne sont pas prises en charge.

Exemple : vidage en deux étapes

Pour démarrer le vidage dans un scénario d’activation en deux étapes, exécutez l’étape 1 de la commande :

   // Connect to the Data Management service
   #connect "https://ingest-[YourClusterName].[region].kusto.windows.net"

   .purge table MyTable records in database MyDatabase <| where CustomerId in ('X', 'Y')

   .purge materialized-view MyView records in database MyDatabase <| where CustomerId in ('X', 'Y')

Sortie

NumRecordsToPurge EstimatedPurgeExecutionTime VerificationToken
1 596 00:00:02 e43c7184ed22f4f23c7a9d7b124d196be2e570096987e5baadf65057fa657fa65736b

Ensuite, validez numRecordsToPurge avant d’exécuter l’étape 2.

Pour effectuer une purge dans un scénario d’activation en deux étapes, utilisez le jeton de vérification retourné à l’étape 1 pour exécuter l’étape 2 :

.purge table MyTable records in database MyDatabase
 with(verificationtoken=h'e43c7....')
<| where CustomerId in ('X', 'Y')

.purge materialized-view MyView records in database MyDatabase
 with(verificationtoken=h'e43c7....')
<| where CustomerId in ('X', 'Y')

Sortie

OperationId DatabaseName TableName ScheduledTime Duration LastUpdatedOn EngineOperationId State StateDetails EngineStartTime EngineDuration Retries ClientRequestId Principal
c9651d74-3b80-4183-90bb-bbe9e42eadc4 MyDatabase MyTable 2019-01-20 11:41:05.4391686 00:00:00.1406211 2019-01-20 11:41:05.4391686 Planifié 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...

Exemple : Vidage en une seule étape

Pour déclencher un vidage dans un scénario d’activation en une seule étape, exécutez la commande suivante :

// Connect to the Data Management service
 #connect "https://ingest-[YourClusterName].[region].kusto.windows.net"

.purge table MyTable records in database MyDatabase with (noregrets='true') <| where CustomerId in ('X', 'Y')

.purge materialized-view MyView records in database MyDatabase with (noregrets='true') <| where CustomerId in ('X', 'Y')

Sortie

OperationId DatabaseName TableName ScheduledTime Duration LastUpdatedOn EngineOperationId State StateDetails EngineStartTime EngineDuration Retries ClientRequestId Principal
c9651d74-3b80-4183-90bb-bbe9e42eadc4 MyDatabase MyTable 2019-01-20 11:41:05.4391686 00:00:00.1406211 2019-01-20 11:41:05.4391686 Planifié 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...

Annuler l’opération de vidage, commande

Si nécessaire, vous pouvez annuler les demandes de vidage en attente.

Remarque

Cette opération est destinée aux scénarios de récupération d’erreurs. Elle n’est pas garantie de réussir et ne doit pas faire partie d’un flux opérationnel normal. Elle ne peut être appliquée qu’aux requêtes qui se trouvent toujours dans la file d’attente et qui n’ont pas encore été distribuées pour l’exécution.

Syntaxe

 // Cancel of a single purge operation
 .cancel purge <OperationId>

  // Cancel of all pending purge requests in a database
 .cancel all purges in database <DatabaseName>

 // Cancel of all pending purge requests, for all databases
 .cancel all purges

Exemple : Annuler une seule opération de vidage

 .cancel purge aa894210-1c60-4657-9d21-adb2887993e1

Sortie

La sortie de cette commande est identique à la sortie de commande « show purge OperationId », montrant l’état mis à jour de l’opération de vidage annulée. Si la tentative réussit, l’état de l’opération est mis à jour sur Canceled. Sinon, l’état de l’opération n’est pas modifié.

OperationId DatabaseName TableName ScheduledTime Duration LastUpdatedOn EngineOperationId State StateDetails EngineStartTime EngineDuration Retries ClientRequestId Principal
c9651d74-3b80-4183-90bb-bbe9e42eadc4 MyDatabase MyTable 2019-01-20 11:41:05.4391686 00:00:00.1406211 2019-01-20 11:41:05.4391686 Annulé 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...

Exemple : Annuler toutes les opérations de vidage en attente dans une base de données

 .cancel all purges in database MyDatabase

Sortie

La sortie de cette commande est identique à la sortie de commande show purges , affichant toutes les opérations de la base de données avec leur état mis à jour. Les opérations qui ont été annulées ont correctement leur état mis à Canceledjour . Sinon, l’état de l’opération n’est pas modifié.

OperationId DatabaseName TableName ScheduledTime Duration LastUpdatedOn EngineOperationId State StateDetails EngineStartTime EngineDuration Retries ClientRequestId Principal
5a34169e-8730-49f5-9694-7fde3a7a0139 MyDatabase MyTable 2021-03-03 05:07:29.7050198 00:00:00.2971331 2021-03-03 05:07:30.0021529 Annulé 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...
2fa7c04c-6364-4ce1-a5e5-1ab921f518f5 MyDatabase MyTable 2021-03-03 05:05:03.5035478 00:00:00.1406211 2021-03-03 05:05:03.6441689 InProgress 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...

Suivre l’état de l’opération de vidage

Remarque

Les opérations de vidage peuvent être suivies avec la commande show purges, exécutées sur le point de terminaison https://ingest-Gestion des données [YourClusterName].[ region].kusto.windows.net.

Status = 'Completed' indique la réussite de la première phase de l’opération de vidage, c’est-à-dire que les enregistrements sont supprimés de manière réversible et ne sont plus disponibles pour l’interrogation. Les clients ne sont pas censés suivre et vérifier la fin de la deuxième phase (suppression en dur). Cette phase est surveillée en interne.

Afficher la commande purges

Show purges la commande affiche l’état de l’opération de vidage en spécifiant l’ID d’opération au cours de la période demandée.

.show purges <OperationId>
.show purges [in database <DatabaseName>]
.show purges from '<StartDate>' [in database <DatabaseName>]
.show purges from '<StartDate>' to '<EndDate>' [in database <DatabaseName>]
Propriétés Description Obligatoire/facultatif
OperationId ID d’opération Gestion des données généré après l’exécution d’une phase unique ou d’une deuxième phase. Obligatoire
StartDate Limite de temps inférieure pour les opérations de filtrage. En cas d’omission, la valeur par défaut est 24 heures avant l’heure actuelle. Facultatif
EndDate Limite de temps supérieure pour les opérations de filtrage. S’il est omis, la valeur par défaut est l’heure actuelle. Facultatif
DatabaseName Nom de la base de données pour filtrer les résultats. Facultatif

Remarque

L’état est fourni uniquement sur les bases de données pour lesquelles le client dispose des autorisations d’administrateur de base de données.

Exemples

.show purges
.show purges c9651d74-3b80-4183-90bb-bbe9e42eadc4
.show purges from '2018-01-30 12:00'
.show purges from '2018-01-30 12:00' to '2018-02-25 12:00'
.show purges from '2018-01-30 12:00' to '2018-02-25 12:00' in database MyDatabase

Sortie

OperationId DatabaseName TableName ScheduledTime Duration LastUpdatedOn EngineOperationId State StateDetails EngineStartTime EngineDuration Retries ClientRequestId Principal
c9651d74-3b80-4183-90bb-bbe9e42eadc4 MyDatabase MyTable 2019-01-20 11:41:05.4391686 00:00:33.6782130 2019-01-20 11:42:34.6169153 a0825d4d-6b0f-47f3-a499-54ac5681ab78 Terminée Vidage terminé correctement (suppression en attente d’artefacts de stockage) 2019-01-20 11:41:34.6486506 00:00:04.4687310 0 KE. RunCommand ; 1d0ad28b-f791-4f5a-a60f-0e32318367b7 AAD app id=...
  • OperationId : ID d’opération DM retourné lors de l’exécution de la purge.
  • DatabaseName** : nom de la base de données (sensible à la casse).
  • TableName - nom de la table (sensible à la casse).
  • ScheduledTime - heure d’exécution de la commande de vidage sur le service DM.
  • Duration : durée totale de l’opération de vidage, y compris le délai d’attente de la file d’attente DM d’exécution.
  • EngineOperationId : ID d’opération du purge réel en cours d’exécution dans le moteur.
  • State - L’état de vidage peut être l’une des valeurs suivantes :
    • Scheduled : l’opération de vidage est planifiée pour l’exécution. Si le travail reste planifié, il y a probablement un backlog des opérations de vidage. Consultez les performances de vidage pour effacer ce backlog. Si une opération de vidage échoue sur une erreur temporaire, elle est retentée par le DM et définie sur Scheduled (vous pouvez donc voir une transition d’une opération planifiée vers InProgress et revenir à Scheduled).
    • InProgress - l’opération de vidage est en cours dans le moteur.
    • Completed - purge terminée avec succès.
    • BadInput - Le vidage a échoué lors d’une entrée incorrecte et ne sera pas retenté. Cet échec peut être dû à différents problèmes tels qu’une erreur de syntaxe dans le prédicat, un prédicat illégal pour les commandes de vidage, une requête qui dépasse les limites (par exemple, plus de 1M entités dans un externaldata opérateur ou plus de 64 Mo de taille totale de requête développée) et 404 ou 403 erreurs pour externaldata les objets blob.
    • Failed - Échec du vidage et ne sera pas retenté. Cet échec peut se produire si l’opération attendait trop longtemps (plus de 14 jours), en raison d’un backlog d’autres opérations de vidage ou d’un certain nombre d’échecs qui dépassent la limite de nouvelles tentatives. Cette dernière déclenchera une alerte de surveillance interne et sera examinée par l’équipe.
  • StateDetails - description de l’état.
  • EngineStartTime - heure à laquelle la commande a été émise au moteur. S’il existe une grande différence entre cette période et ScheduledTime, il existe généralement un backlog significatif des opérations de vidage et le cluster ne suit pas le rythme.
  • EngineDuration - heure de l’exécution réelle du vidage dans le moteur. Si le vidage a été retenté plusieurs fois, il s’agit de la somme de toutes les durées d’exécution.
  • Retries - nombre de fois où l’opération a été retentée par le service DM en raison d’une erreur temporaire.
  • ClientRequestId - ID d’activité client de la demande de vidage DM.
  • Principal - identité de l’émetteur de commande de vidage.

Purger une table entière

Purger une table inclut la suppression de la table et le marquage comme purgé afin que le processus de suppression dur décrit dans le processus de vidage s’exécute dessus. La suppression d’une table sans purger ne supprime pas tous ses artefacts de stockage. Ces artefacts sont supprimés en fonction de la stratégie de rétention dure initialement définie sur la table. La purge table allrecords commande est rapide et efficace et est préférable au processus d’enregistrement de vidage, le cas échéant pour votre scénario.

Remarque

La commande est appelée en exécutant la commande TableName allrecords de la table de vidage sur le point de terminaison https://ingest-Gestion des données [YourClusterName].[ region].kusto.windows.net.

Commande Purge table TableName allrecords

Comme pour la commande '.purge table records ', cette commande peut être appelée en mode programmatique (en une seule étape) ou en mode manuel (à deux étapes).

  1. Appel par programmation (étape unique) :

    Syntaxe

    // Connect to the Data Management service
    #connect "https://ingest-[YourClusterName].[Region].kusto.windows.net"
    
    .purge table [TableName] in database [DatabaseName] allrecords with (noregrets='true')
    
  2. Appel humain (deux étapes) :

    Syntaxe

    
    // Connect to the Data Management service
    #connect "https://ingest-[YourClusterName].[Region].kusto.windows.net"
    
    // Step #1 - retrieve a verification token (the table will not be purged until step #2 is executed)
    
    .purge table [TableName] in database [DatabaseName] allrecords
    
    // Step #2 - input the verification token to execute purge
    .purge table [TableName] in database [DatabaseName] allrecords with (verificationtoken=h'<verification token from step #1>')
    
    Paramètres Description
    DatabaseName Nom de la base de données.
    TableName Nom de la table.
    noregrets Si cette option est définie, déclenche une activation en une seule étape.
    verificationtoken Dans le scénario d’activation en deux étapes (noregrets n’est pas défini), ce jeton peut être utilisé pour exécuter la deuxième étape et valider l’action. S’il verificationtoken n’est pas spécifié, il déclenche la première étape de la commande. Dans cette étape, un jeton est retourné pour revenir à la commande et effectuer l’étape 2.

Exemple : vidage en deux étapes

  1. Pour démarrer le vidage dans un scénario d’activation en deux étapes, exécutez l’étape 1 de la commande :

    // Connect to the Data Management service
     #connect "https://ingest-[YourClusterName].[Region].kusto.windows.net"
    
    .purge table MyTable in database MyDatabase allrecords
    

    Sortie

    VerificationToken
    e43c7184ed22f4f23c7a9d7b124d196be2e570096987e5baadf65057fa657fa65736b
  2. Pour effectuer une purge dans un scénario d’activation en deux étapes, utilisez le jeton de vérification retourné à l’étape 1 pour exécuter l’étape 2 :

    .purge table MyTable in database MyDatabase allrecords
    with (verificationtoken=h'eyJT.....')
    

    La sortie est identique à la sortie de commande « .show tables » (retournée sans la table vidée).

    Sortie

    TableName nom_base_de_données Dossier DocString
    OtherTable MyDatabase --- ---

Exemple : Vidage en une seule étape

Pour déclencher un vidage dans un scénario d’activation en une seule étape, exécutez la commande suivante :

// Connect to the Data Management service
#connect "https://ingest-[YourClusterName].[Region].kusto.windows.net"

.purge table MyTable in database MyDatabase allrecords with (noregrets='true')

La sortie est identique à la sortie de commande « .show tables » (retournée sans la table vidée).

Sortie

TableName nom_base_de_données Dossier DocString
OtherTable MyDatabase --- ---