Tables de streaming

Une table de diffusion en continu est une table Delta qui prend en charge la diffusion en continu ou le traitement incrémentiel des données. Une table de diffusion en temps réel peut être ciblée par un ou plusieurs flux dans un pipeline.

Pour savoir quand utiliser des tables de streaming plutôt que des vues matérialisées ou des vues, consultez Qu’est-ce qu’un pipeline ?.

Les tables de diffusion en continu constituent un bon choix pour l’ingestion des données pour les raisons suivantes :

• Chaque ligne d'entrée est traitée une seule fois, ce qui correspond à la grande majorité des charges de travail d'ingestion (c'est-à-dire, en ajoutant ou en mettant à jour des lignes dans une table).
• Elles peuvent gérer de grands volumes de données d’ajout uniquement.

Les tables de streaming sont également un bon choix pour les transformations de diffusion en continu à faible latence, car elles peuvent raisonner sur les lignes et les fenêtres de temps, gérer des volumes élevés de données et fournir un traitement à faible latence.

Le diagramme suivant montre comment des flux lisent à partir de sources de données en streaming et écrivent de façon incrémentielle dans une table de streaming au sein d’un pipeline.

Sur chaque mise à jour, les flux associés à une table de diffusion en continu lisent les informations modifiées dans une source de diffusion en continu et ajoutent de nouvelles informations à cette table.

Les tables de streaming sont détenues et mises à jour par un seul pipeline. Vous définissez des tables de flux explicitement dans le code source du pipeline. Les tables définies par un pipeline ne peuvent pas être modifiées ou mises à jour par un autre pipeline. Vous pouvez définir plusieurs flux à ajouter à une table de diffusion en continu unique.

Azure Databricks crée des tables internes pour prendre en charge le traitement des tables de données en streaming. Ces tableaux s’affichent dans system.information_schema.tables, mais ne sont pas visibles dans l’Explorateur de catalogue ou dans d’autres pages d’interface utilisateur d’espace de travail.

Pour plus d’informations sur les flux, consultez Charger et traiter des données de manière incrémentielle avec des flux de pipeline Lakeflow.

Tables de streaming pour l’ingestion de données

Les tables de streaming sont conçues pour les sources de données à ajout unique et traitent les données une seule fois. Cela les rend bien adaptés aux charges de travail d’ingestion où les données arrivent en continu et doivent être capturées de manière fiable sans retraiter les enregistrements existants. Azure Databricks prend en charge l’ingestion dans des tables de streaming depuis le stockage d’objets dans le cloud (à l’aide d’Auto Loader) et depuis des bus de messages en streaming tels qu’Apache Kafka, Azure Event Hubs et Google Pub/Sub. Pour obtenir des exemples de procédure et de code d’ingestion, consultez Charger des données dans des pipelines.

Le diagramme suivant illustre le fonctionnement des tables de diffusion en continu d’ajout uniquement.

Une ligne qui a déjà été ajoutée à une table en continu ne sera pas réinterrogée avec les mises à jour ultérieures du pipeline. Si vous modifiez la requête (par exemple, de SELECT LOWER (name) à SELECT UPPER (name)), les lignes existantes ne sont pas mises à jour en majuscules, mais les nouvelles lignes seront en majuscules. Vous pouvez déclencher une actualisation complète pour redemander toutes les données précédentes de la table source afin de mettre à jour toutes les lignes de la table de streaming.

Tables de streaming et diffusion à faible latence

Les tables de diffusion en continu sont conçues pour une diffusion en continu à faible latence via un état limité. Les tables de diffusion en continu utilisent la gestion des points de contrôle, ce qui les rend bien adaptées à la diffusion en continu à faible latence. Toutefois, elles attendent des flux qui sont naturellement délimités ou délimités avec un filigrane.

Un flux naturellement limité est produit par une source de données de diffusion en continu qui a un début et une fin bien définis. Un exemple de flux naturellement limité lit les données à partir d’un répertoire de fichiers où aucun nouveau fichier n’est ajouté après un lot initial de fichiers placé. Le flux est considéré comme limité, car le nombre de fichiers est fini et le flux se termine une fois que tous les fichiers ont été traités.

Vous pouvez également utiliser un filigrane pour lier un flux. Un filigrane dans Structured Streaming est un mécanisme qui permet de gérer les données tardives en spécifiant la durée pendant laquelle le système doit attendre les événements retardés avant de considérer la fenêtre de temps comme terminée. Un flux non borné qui n’a pas de repères temporels peut entraîner l’échec d’un pipeline en raison de la pression de la mémoire.

Pour les charges de travail opérationnelles nécessitant la latence la plus faible possible, vous pouvez exécuter le pipeline en mode temps réel pour traiter les enregistrements avec une latence de bout en bout sous-seconde.

Pour en savoir plus, consultez :

• Utiliser le mode en temps réel dans les pipelines Lakeflow
• Optimiser le traitement avec état à l’aide de repères temporels

Limitations de la table de diffusion en continu

Les tables de diffusion en continu présentent les limitations suivantes :

• Évolution limitée : Vous pouvez modifier la requête sans recomputer l’intégralité du jeu de données. Sans actualisation complète, une table de diffusion en continu ne voit que chaque ligne une seule fois, de sorte que différentes requêtes auront traité différentes lignes. Par exemple, si vous ajoutez UPPER() un champ dans la requête, seules les lignes traitées après la modification seront en majuscules. Cela signifie que vous devez connaître toutes les versions précédentes de la requête qui s’exécutent sur votre jeu de données. Pour retraiter les lignes existantes qui ont été traitées avant la modification, une actualisation complète est requise.
• Gestion de l’état : les tables de streaming ont une faible latence et nécessitent des flux naturellement bornés ou bornés à l’aide d’un repère temporel. Pour plus d’informations, consultez Optimiser le traitement avec état à l’aide de repères temporels.
• Les jointures ne sont pas recalculées : les jointures dans les tables de streaming ne sont pas recalculées quand les dimensions changent. Cette caractéristique peut être adaptée aux scénarios « rapides mais incorrects ». Si vous souhaitez que votre vue soit toujours correcte, vous pouvez utiliser une vue matérialisée. Les vues matérialisées sont toujours correctes, car elles recompilent automatiquement les jointures lorsque les dimensions changent. Pour plus d’informations, consultez Vues matérialisées. Pour obtenir un exemple de jointure d’un flux à une table de dimension statique, consultez jointures statiques Stream.
• Aucune prise en charge de CLONE : les tables de streaming ne peuvent pas être utilisées comme source ou cible d’un clone complet ou superficiel. Pour les autres commandes non prises en charge, consultez Limitations.
• REFRESH privilège requis pour afficher le pipeline : Pour afficher le pipeline qui sous-tend une table de streaming, un utilisateur non administrateur doit disposer du privilège REFRESH sur la table de streaming, en plus des autorisations sur le pipeline. Voir Qui peut afficher un pipeline et sa sortie ?.

Ressources additionnelles

• Charger des données dans des pipelines
• Actualisation complète des tables de diffusion en continu