Partager via

Vue d’ensemble de l’exportation de données continue

  • Article

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

Cet article décrit l’exportation continue de données de Kusto vers une table externe avec une requête régulièrement exécutée. Les résultats sont stockés dans la table externe, qui définit la destination, telle que Stockage Blob Azure, et le schéma des données exportées. Ce processus garantit que tous les enregistrements sont exportés « exactement une seule fois », avec certaines exceptions.

Par défaut, l’exportation continue s’exécute en mode distribué, où tous les nœuds exportent simultanément, de sorte que le nombre d’artefacts dépend du nombre de nœuds. L’exportation continue n’est pas conçue pour les données de diffusion en continu à faible latence.

Pour activer l’exportation de données continues, créez une table externe, puis créez une définition d’exportation continue pointant vers la table externe.

Dans certains cas, vous devez utiliser une identité managée pour configurer correctement un travail d’exportation continue. Pour plus d’informations, consultez Utiliser une identité managée pour exécuter un travail d’exportation continue.

autorisations

Toutes les commandes d’exportation continue nécessitent au moins des autorisations d’administrateur de base de données.

Recommandations en matière d’exportation continue

  • Schéma de sortie :

    • Le schéma de sortie de la requête d’exportation doit correspondre au schéma de la table externe vers laquelle vous exportez.

  • Fréquence :

    • L’exportation continue s’exécute en fonction de la période configurée pour celle-ci dans la intervalBetweenRuns propriété. La valeur recommandée pour cet intervalle est au moins plusieurs minutes, en fonction des latences que vous êtes prêt à accepter. L’intervalle de temps peut être aussi faible qu’une minute, si le taux d’ingestion est élevé.

      Remarque

      La intervalBetweenRuns recommandation sert uniquement de recommandation et n’est pas garantie d’être précise. L’exportation continue n’est pas adaptée à l’exportation d’agrégations périodiques. Par exemple, une configuration d’une intervalBetweenRuns=1h agrégation horaire (T | summarize by bin(Timestamp, 1h)) ne fonctionne pas comme prévu, car l’exportation continue ne s’exécute pas exactement à l’heure. Par conséquent, chaque bac horaire reçoit plusieurs entrées dans les données exportées.

  • Nombre de fichiers :

    • Le nombre de fichiers exportés dans chaque itération d’exportation continue dépend de la façon dont la table externe est partitionnée. Pour plus d’informations, consultez la commande Exporter vers une table externe. Chaque itération d’exportation continue écrit toujours dans de nouveaux fichiers et n’ajoute jamais aux fichiers existants. Par conséquent, le nombre de fichiers exportés dépend également de la fréquence d’exécution de l’exportation continue. Le paramètre de fréquence est intervalBetweenRuns.

  • Comptes de stockage de tables externes :

    • Pour des performances optimales, la base de données et les comptes de stockage doivent être colocalisés dans la même région Azure.
    • L’exportation continue fonctionne de manière distribuée, de sorte que tous les nœuds s’exportent simultanément. Sur les bases de données volumineuses et si le volume de données exporté est volumineux, cela peut entraîner une limitation du stockage. La recommandation consiste à configurer plusieurs comptes de stockage pour la table externe. Pour plus d’informations, consultez échecs de stockage pendant les commandes d’exportation.

Exactement une fois l’exportation

Pour garantir une exportation « exactement une seule fois », l’exportation continue utilise des curseurs de base de données. La requête d’exportation continue ne doit pas inclure de filtre d’horodatage : le mécanisme de curseurs de base de données garantit que les enregistrements ne sont pas traités plusieurs fois. L’ajout d’un filtre d’horodatage dans la requête peut entraîner des données manquantes dans les données exportées.

La stratégie IngestionTime doit être activée sur toutes les tables référencées dans la requête qui doivent être traitées « exactement une fois » dans l’exportation. La stratégie est activée par défaut sur toutes les tables nouvellement créées.

La garantie pour l’exportation « exactement une seule fois » est uniquement pour les fichiers signalés dans la commande show export artefacts. L’exportation continue ne garantit pas que chaque enregistrement n’est écrit qu’une seule fois dans la table externe. Si une défaillance se produit après le début de l’exportation et que certains artefacts ont déjà été écrits dans la table externe, la table externe peut contenir des doublons. Si une opération d’écriture a été abandonnée avant la fin, la table externe peut contenir des fichiers endommagés. Dans ce cas, les artefacts ne sont pas supprimés de la table externe, mais ils ne sont pas signalés dans la afficher la commande d’artefacts exportés. Consommer les fichiers exportés à l’aide des show exported artifacts command garanties sans duplications et aucune altération.

Exporter à partir de tables de faits et de dimension

Par défaut, toutes les tables référencées dans la requête d’exportation sont supposées être des tables de faits. Par conséquent, elles sont limitées au curseur de base de données. La syntaxe déclare explicitement quelles tables sont délimitées (faits) et qui ne sont pas délimitées (dimension). Pour plus d’informations, consultez le over paramètre dans la commande create.

La requête d’exportation inclut uniquement les enregistrements joints depuis l’exécution d’exportation précédente. La requête d’exportation peut contenir des tables de dimension dans lesquelles tous les enregistrements de la table de dimension sont inclus dans toutes les requêtes d’exportation. Lorsque vous utilisez des jointures entre les tables de faits et de dimension dans l’exportation continue, gardez à l’esprit que les enregistrements de la table de faits ne sont traités qu’une seule fois. Si l’exportation s’exécute pendant que les enregistrements des tables de dimension sont manquants pour certaines clés, les enregistrements des clés respectives sont manqués ou incluent des valeurs Null pour les colonnes de dimension dans les fichiers exportés. Le retour d’enregistrements manqués ou null dépend du fait que la requête utilise une jointure interne ou externe. La forcedLatency propriété dans la définition d’exportation continue peut être utile dans de tels cas, où les tables de faits et de dimensions sont ingérées en même temps pour les enregistrements correspondants.

Remarque

L’exportation continue de tables de dimension uniquement n’est pas prise en charge. La requête d’exportation doit inclure au moins une table de faits unique.

Surveiller l’exportation continue

Surveillez l’intégrité de vos travaux d’exportation continue à l’aide des métriques d’exportation suivantes :

  • Continuous export max lateness - Latence maximale (en minutes) des exportations continues dans la base de données. Il s’agit de l’heure actuelle et de la durée minimale ExportedTo de toutes les tâches d’exportation continue dans la base de données. Pour plus d’informations, consultez .show continuous export la commande.
  • Continuous export result - Résultat de réussite/échec de chaque exécution d’exportation continue. Cette métrique peut être divisée par le nom d’exportation continue.

Utilisez la .show continuous export failures commande pour voir les échecs spécifiques d’un travail d’exportation continue.

Avertissement

Si une exportation continue échoue pendant plus de 7 jours en raison d’un échec permanent, l’exportation est automatiquement désactivée par le système. Les erreurs permanentes sont les suivantes : table externe introuvable, incompatibilité entre le schéma de requête d’exportation continue et le schéma de table externe, le compte de stockage n’est pas accessible. Une fois l’erreur corrigée, vous pouvez réactiver l’exportation continue à l’aide de la .enable continuous export commande.

Consommation des ressources

  • L’impact de l’exportation continue sur la base de données dépend de la requête exécutée par l’exportation continue. La plupart des ressources, telles que le processeur et la mémoire, sont consommées par l’exécution de la requête.
  • Le nombre d’opérations d’exportation qui peuvent s’exécuter simultanément est limité par la capacité d’exportation de données de la base de données. Pour plus d’informations, consultez Limitation des commandes de gestion. Si la base de données ne dispose pas d’une capacité suffisante pour gérer toutes les exportations continues, certaines commencent à se retarder.
  • La commande show commands-and-queries peut être utilisée pour estimer la consommation des ressources.
    • Filtrez sur | where ClientActivityId startswith "RunContinuousExports" pour afficher les commandes et les requêtes associées à l’exportation continue.

Exporter des données d’historique

L’exportation continue commence à exporter des données uniquement à partir du point de sa création. Les enregistrements ingérés avant cette heure doivent être exportés séparément à l’aide de la commande d’exportation non continue. Les données historiques peuvent être trop volumineuses pour être exportées dans une seule commande d’exportation. Si nécessaire, partitionnez la requête en plusieurs lots plus petits.

Pour éviter les doublons avec les données exportées par l’exportation continue, utilisez StartCursor retourné par la commande d’exportation continue et exportez uniquement where cursor_before_or_at la valeur du curseur. Par exemple :

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

Suivi de :

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

Exportation continue à partir d’une table avec sécurité au niveau des lignes

Pour créer un travail d’exportation continue avec une requête qui fait référence à une table avec la stratégie sécurité au niveau des lignes, vous devez :

Exportation continue vers une table delta - Aperçu

L’exportation continue vers une table delta est actuellement en préversion.

Important

Le partitionnement de table delta n’est pas pris en charge dans l’exportation continue des données.

Kusto n’écrit pas dans les tables delta existantes si la version de l’enregistreur de protocole delta est supérieure à 1.

Pour définir l’exportation continue vers une table delta, procédez comme suit :

  1. Créez une table delta externe, comme décrit dans Créer et modifier des tables externes delta sur Stockage Azure.

    Remarque

    Si le schéma n’est pas fourni, Kusto essaie de le déduire automatiquement s’il existe déjà une table delta définie dans le conteneur de stockage cible.
    Le partitionnement de table delta n’est pas pris en charge.

  2. Définissez l’exportation continue vers cette table à l’aide des commandes décrites dans Créer ou modifier l’exportation continue.

    Important

    Le schéma de la table delta doit être synchronisé avec la requête d’exportation continue. Si la table delta sous-jacente change, l’exportation peut commencer à échouer avec un comportement inattendu.

Limites

Général :

  • Les formats suivants sont autorisés sur les tables cibles : CSV, , TSVJSON, et Parquet.
  • L’exportation continue n’est pas conçue pour fonctionner sur vues matérialisées, car une vue matérialisée peut être mise à jour, tandis que les données exportées vers le stockage sont toujours ajoutées et jamais mises à jour.
  • L’exportation continue ne peut pas être créée sur bases de données de suivi, car les bases de données de suivi sont en lecture seule et l’exportation continue nécessite des opérations d’écriture.
  • Les enregistrements de la table source doivent être ingérés directement dans la table, à l’aide d’une stratégie de mise à jour ou à l’ingestion à partir de commandes de requête. Si les enregistrements sont déplacés dans la table à l’aide d’étendues .move ou d’une table .rename, l’exportation continue risque de ne pas traiter ces enregistrements. Consultez les limitations décrites dans la page Curseurs de base de données.
  • Si les artefacts utilisés par l’exportation continue sont destinés à déclencher des notifications Event Grid, consultez la section problèmes connus de la documentation Event Grid.

Inter-bases de données et inter-clusters :

  • L’exportation continue ne prend pas en charge les appels entre clusters.
  • L’exportation continue prend en charge les appels inter-bases de données uniquement pour les tables de dimension. Toutes les tables de faits doivent résider dans la base de données locale. Pour plus d’informations, consultez l’article Exporter à partir de tables de faits et de dimension.
  • Si l’exportation continue inclut des appels inter-bases de données, elle doit être configurée avec une identité managée.

Cross-database et cross-Eventhouse :

  • L’exportation continue ne prend pas en charge les appels inter-Eventhouse.
  • L’exportation continue prend en charge les appels inter-bases de données uniquement pour les tables de dimension. Toutes les tables de faits doivent résider dans la base de données locale. Pour plus d’informations, consultez l’article Exporter à partir de tables de faits et de dimension.

Stratégies :

Contenu connexe