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

  • Article

Cet article décrit l’exportation continue des données de Kusto vers une table externe avec une requête exécutée régulièrement. Les résultats sont stockés dans la table externe, qui définit la destination, par exemple Stockage Blob Azure, et le schéma des données exportées. Ce processus garantit que tous les enregistrements sont exportés « exactement une fois », à quelques exceptions près. Par défaut, l’exportation continue s’exécute en mode distribué, où tous les nœuds s’exportent simultanément, de sorte que le nombre d’artefacts dépend du nombre de nœuds dans le cluster. L’exportation continue n’est pas conçue pour le streaming de données à faible latence hors de votre cluster.

Pour activer l’exportation continue des données, 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 de Administration de base de données.

Instructions relatives à l’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 elle dans la intervalBetweenRuns propriété . La valeur recommandée pour cet intervalle est d’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é.

      Notes

      Le intervalBetweenRuns sert de recommandation uniquement et n’est pas garanti d’être précis. L’exportation continue ne convient pas pour l’exportation d’agrégations périodiques. Par exemple, une configuration de intervalBetweenRuns=1h avec une agrégation horaire (T | summarize by bin(Timestamp, 1h)) ne fonctionnera 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 exporter vers une commande de table externe. Chaque itération d’exportation continue écrit toujours dans de nouveaux fichiers et n’ajoute jamais de 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 table externes :

    • Pour de meilleures performances, le cluster et le ou 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 du cluster sont exportés simultanément. Sur les clusters volumineux, et si le volume de données exporté est volumineux, cela peut entraîner une limitation du stockage. Il est recommandé de configurer plusieurs comptes de stockage pour la table externe. Pour plus d’informations, consultez Échecs de stockage pendant les commandes d’exportation .

Exporter exactement une fois

Pour garantir une exportation « exactement une 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 des 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 fois » est uniquement pour les fichiers signalés dans la commande show exported artifacts. L’exportation continue ne garantit pas que chaque enregistrement ne sera é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 des 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 l’achèvement, 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 commande show export artifacts. La consommation des fichiers exportés à l’aide des show exported artifacts command garanties ne génère ni duplication ni 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 précédente de l’exportation. 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 des 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 alors que des enregistrements dans les tables de dimension sont manquants pour certaines clés, les enregistrements des clés respectives seront manqués ou incluront des valeurs null pour les colonnes de dimension dans les fichiers exportés. Le retour d’enregistrements manqués ou null varie selon 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 la correspondance des enregistrements.

Notes

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

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 - Retard maximal (en minutes) des exportations continues dans le cluster. Il s’agit de la durée comprise entre maintenant et la durée minimale ExportedTo de tous les travaux d’exportation continue dans le cluster. Pour plus d’informations, consultez .show continuous export 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 de l’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 incluent : 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 le cluster dépend de la requête que l’exportation continue est en cours d’exécution. 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 pouvant s’exécuter simultanément est limité par la capacité d’exportation de données du cluster. Pour plus d’informations, consultez Limitation des commandes de gestion. Si le cluster n’a pas la capacité suffisante pour gérer toutes les exportations continues, certaines commencent à être à la traîne.
  • La commande show commands-and-queries peut être utilisée pour estimer la consommation de 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 les données uniquement à partir du point de leur 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 des données exportées par exportation continue, utilisez StartCursor retourné par la commande show continuous export et exportez uniquement la where cursor_before_or_at 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 la 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 une stratégie de sécurité au niveau des lignes, vous devez :

Exportation continue vers la table delta - Préversion

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 de données continue.

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.

    Notes

    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, TSV, JSONet Parquet.
  • L’exportation continue n’est pas conçue pour fonctionner sur les 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 uniquement et jamais mises à jour.
  • L’exportation continue ne peut pas être créée sur les bases de données d’suiveur , car les bases de données d’suiveur 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 ingérer à partir de commandes de requête. Si les enregistrements sont déplacés dans la table à l’aide d’extensions .move ou à l’aide d’une table .rename, l’exportation continue peut 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 dans la documentation Event Grid.

Inter-bases de données et entre clusters :

  • L’exportation continue ne prend pas en charge les appels entre clusters.
  • L’exportation continue prend en charge les appels entre 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 Exporter à partir de tables de faits et de dimension.
  • Si l’exportation continue inclut des appels entre bases de données, elle doit être configurée avec une identité managée.

Stratégies :

Contenu connexe