Partage via

Vidage des données

  • Article

Notes

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.

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

Avertissement

La suppression de données par le biais de 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 du 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 dans Azure Data Explorer.

  1. Dans le meilleur des cas, 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 aux règles de confidentialité dans quelques tables Azure Data Explorer. De manière optimale, utilisez une seule table et créez un lien vers celle-ci à partir de toutes les autres tables. Cette isolation vous permet d’exécuter le processus de purge 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 de l’exécution des .purge commandes sur 1 à 2 commandes par table et 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 purge

Le processus de purge sélective des données d’Azure Data Explorer se produit dans les étapes suivantes :

  1. Phase 1 : Fournissez une entrée avec un nom de table Azure Data Explorer et un prédicat par enregistrement, indiquant les enregistrements à supprimer. Kusto analyse la table afin d’identifier les étendues de données qui participeraient à la purge des données. Les étendues identifiées sont celles qui ont 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 réinstétée. La version réingérée 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, à la fin de cette phase, les requêtes ne retournent plus les données pour lesquelles le prédicat retourne true. La durée de la phase de suppression réversible de purge dépend des paramètres suivants :

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

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

  3. Phase 3 : (Suppression matérielle) Rééduisez tous les artefacts de stockage qui peuvent contenir les données « empoisonnées » 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, qui prend quelques jours. Si la densité des enregistrements pour lesquels le prédicat s’applique est suffisamment importante, le processus réinscrira efficacement toutes les données de la table. Cette réingestion a un impact significatif sur les performances et le COGS (coût des biens vendus).

Limitations et considérations relatives à l’épuration

  • Le processus de vidage est définitif et irréversible. Il n’est pas possible d’annuler ce processus ou de récupérer des données qui ont été purgées. Les commandes telles que annuler la suppression de table 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 accéder à avant la dernière commande de purge.

  • Avant d’exécuter la purge, 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 purge et pour garantir que les instructions de purge 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 par lot par table 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 de :predicate

    • Utilisez l’opérateur « in », par exemple . where [ColumnName] in ('Id1', 'Id2', .. , 'Id1000')
    • Notez les limites de l’opérateur « in » (la liste peut contenir jusqu’à des 1,000,000 valeurs).
    • Si la taille de la requête est grande, utilisez externaldata l’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 à purger.
    • 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.

Performances de purge

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

Pour réduire le temps d’exécution de la purge :

Déclencher le processus de purge

Notes

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

Commande Vider les enregistrements TableName

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

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

    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, effectuée dans le cadre d’une étape distincte. Le premier appel de la commande retourne un jeton de vérification, qui doit être fourni pour exécuter la purge réelle. Cette séquence réduit le risque de suppression par inadvertance de données incorrectes.

Notes

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, afin d’identifier les enregistrements à purger. 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’échec, validez vous-même le prédicat et, après avoir vérifié l’exactitude, utilisez la purge en une seule étape avec l’option noregrets .

Syntaxe

Notes

Pour vous connecter à un cluster à l’aide de l’interface utilisateur web 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, et remplacez TableName par le MaterializedViewName.

Paramètres Description
DatabaseName Nom de la base de données
TableName / MaterializedViewName Nom de la table / vue matérialisée à purger.
Predicate Identifie les enregistrements à purger. Consultez Limitations du prédicat de purge.
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. Si verificationtoken n’est pas spécifié, la première étape de la commande est déclenchée. Les informations sur la purge seront retournées avec un jeton qui doit être renvoyé à la commande pour effectuer l’étape 2.

Vider les limitations du prédicat

  • 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 des tables autres que la table en cours de vidage (TableName). Le prédicat ne peut inclure que l’instruction selection (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 e43c7184ed22f4f23c7a9d7b124d196be2e570096987e5baadf65057fa65736b

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

Pour effectuer un vidage 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=...

Commande Annuler l’opération de vidage

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

Notes

Cette opération est destinée aux scénarios de récupération d’erreur. Il n’est pas garanti 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 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 opération de vidage unique

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

Sortie

La sortie de cette commande est identique à la sortie de la commande « show purges OperationId », montrant la status mise à jour de l’opération de vidage en cours d’annulation. Si la tentative réussit, l’état de l’opération est mis à jour vers 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 Opération annulée 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 la commande show purges, montrant toutes les opérations dans la base de données avec leur status mis à jour. Les opérations qui ont été annulées avec succès verront leur status mis à jour vers 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
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 Opération annulée 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 les status de l’opération de vidage

Notes

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 que la première phase de l’opération de vidage a réussi, 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 définitive). Cette phase est supervisée en interne par Azure Data Explorer.

Commande Afficher les vidages

Show purgesla commande affiche les status d’opération de vidage en spécifiant l’ID d’opération dans 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 L’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. En cas d’omission, la valeur par défaut est l’heure actuelle. Facultatif
DatabaseName Nom de la base de données pour filtrer les résultats. Facultatif

Notes

L’état est fourni uniquement sur les bases de données pour lesquelles le client dispose d’autorisations de Administration 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 Effectué Vidage effectué avec succès (artefacts de stockage en attente de suppression) 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 vidage.
  • DatabaseName** - nom de la base de données (respectant la casse).
  • TableName - nom de la table (respectant 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 temps d’attente de la file d’attente DM d’exécution.
  • EngineOperationId - ID d’opération du vidage réel en cours d’exécution dans le moteur.
  • State - état de vidage, peut être l’une des valeurs suivantes :
    • Scheduled - l’exécution de l’opération de vidage est planifiée. Si le travail reste planifié, il existe probablement un backlog d’opérations de vidage. Consultez Performances de vidage pour effacer ce backlog. Si une opération de vidage échoue en cas d’erreur temporaire, elle est retentée par le DM et définie à nouveau sur Planifié (vous pouvez donc voir une opération passer de Scheduled à InProgress et de nouveau à Scheduled).
    • InProgress - l’opération de vidage est en cours dans le moteur.
    • Completed - le vidage s’est terminé avec succès.
    • BadInput - Le vidage a échoué en cas d’entrée incorrecte et ne sera pas retenté. Cet échec peut être dû à divers 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 1 M d’entités dans un externaldata opérateur ou plus de 64 Mo de taille de requête développée totale) et des erreurs 404 ou 403 pour externaldata les objets blob.
    • Failed - le vidage a échoué et ne sera pas retenté. Cet échec peut se produire si l’opération attendait trop longtemps dans la file d’attente (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 supervision interne et sera examinée par l’équipe Azure Data Explorer.
  • StateDetails - description de l’état.
  • EngineStartTime : heure à laquelle la commande a été émise au moteur. S’il existe une grande différence entre cette heure et ScheduledTime, il y a généralement un backlog important 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 la commande de vidage.

Purge d’une table entière

Le vidage d’une table inclut la suppression de la table et son marquage comme étant purgé afin que le processus de suppression matérielle décrit dans Processus de vidage s’exécute dessus. La suppression d’une table sans la 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.

Notes

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

Commande Purger table TableName allrecords

Semblable à la commande « .purger les enregistrements de table », cette commande peut être appelée dans un mode programmatique (en une étape) ou manuel (en deux étapes).

  1. Appel programmatique (é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 (en 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. Si verificationtoken n’est pas spécifié, la première étape de la commande est déclenchée. Au cours de cette étape, un jeton est retourné pour passer à 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
    e43c7184ed22f4f23c7a9d7b124d196be2e570096987e5baadf65057fa65736b

  2. Pour effectuer un vidage 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 la 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 la commande « .show tables » (retournée sans la table vidée).

Sortie

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

Contenu connexe