Tables de streaming

Une table de streaming est une table Delta avec un support supplémentaire pour le traitement des données en streaming ou incrémentiel. Une table en streaming peut être ciblée par un ou plusieurs flux dans un pipeline.

Pour obtenir des conseils sur l’utilisation des tables de streaming par rapport aux vues matérialisées ou aux vues, consultez Que sont les pipelines ?.

Les tables de streaming sont un bon choix pour l'ingestion de données pour les raisons suivantes :

• Chaque ligne d’entrée est traitée une seule fois, ce qui modélise la grande majorité des charges de travail d’ingestion (c’est-à-dire, en ajoutant ou en insérant des lignes dans une table).
• Ils peuvent gérer de grands volumes de données en mode ajout seul.

Les tables de streaming sont également un bon choix pour les transformations de streaming à faible latence, car elles peuvent traiter des lignes et des fenêtres temporelles, gérer de grands volumes de données et fournir un traitement à faible latence.

Le diagramme suivant montre comment les flux lisent à partir de sources en streaming et écrivent de manière incrémentielle dans une table en streaming au sein d'un pipeline.

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

Les tables de streaming sont détenues et mises à jour par un seul pipeline. Vous définissez explicitement les tables de streaming 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 seule table de streaming.

Databricks crée des tables internes pour prendre en charge le traitement des tables de streaming. Ces tables apparaissent dans system.information_schema.tables mais ne sont pas visibles dans Catalog Explorer ou d'autres pages d'interface utilisateur de workspace.

remarque

Lorsque vous créez une table de streaming autonome, en dehors d'un Lakeflow pipeline, Databricks crée un pipeline qui est utilisé pour mettre à jour la table. Vous pouvez voir le pipeline en sélectionnant Jobs et pipelines dans la navigation de gauche de votre Workspace. Vous pouvez ajouter la colonne Type de pipeline à votre vue. Les tables de streaming définies dans un pipeline ont un type de ETL. Les tables de streaming autonomes sont de type MV/ST.

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

Tables de streaming pour l'ingestion

Les tables de streaming sont conçues pour les sources de données en ajout uniquement et ne traitent les entrées qu'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. Databricks prend en charge l'ingestion dans des tables de streaming à partir du stockage d'objets cloud (à l'aide d'Auto Loader) et à partir de bus de messages en streaming tels qu'Apache Kafka, Azure Event Hubs et Google Pub/Sub. Pour les guides pratiques et les exemples de code d'ingestion, consultez Charger des données dans des pipelines.

remarque

Pour diffuser des données source qui changent au fil du temps (par exemple, des enregistrements mis à jour ou supprimés à la source), utilisez AUTO CDC pour appliquer ces modifications à une table de streaming au lieu de les ajouter. Consultez Change data capture et instantanés.

Le diagramme suivant illustre le fonctionnement des tables de streaming en mode append-only.

Une ligne qui a déjà été ajoutée à une table de streaming ne sera pas ré-interrogée lors des mises à jour ultérieures du pipeline. Si vous modifiez la query (par exemple, de SELECT LOWER (name) à SELECT UPPER (name)), les lignes existantes ne seront pas mises à jour en majuscules, mais les nouvelles lignes seront en majuscules. Vous pouvez Trigger une full refresh pour réinterroger toutes les données précédentes de la table source afin de mettre à jour toutes les lignes de la table de streaming.

Tables en streaming et streaming à faible latence

Les tables de streaming sont conçues pour le streaming à faible latence sur un état borné. Les tables de streaming utilisent la gestion des points de contrôle, ce qui les rend bien adaptées au streaming à faible latence. Cependant, ils s’attendent à des flux naturellement bornés ou bornés avec un watermark.

Un Stream naturellement borné est produit par une source de données de streaming qui a un start et une fin bien définis. Un exemple de Stream naturellement délimité consiste à lire des données à partir d'un répertoire de fichiers où aucun nouveau fichier n'est ajouté après le placement d'un batch initial de fichiers. Le stream est considéré comme borné car le nombre de fichiers est fini, et le stream se termine une fois que tous les fichiers ont été traités.

Vous pouvez également utiliser un filigrane pour borner un stream. Un filigrane dans Structured Streaming est un mécanisme qui permet de gérer les données tardives en spécifiant combien de temps le système doit attendre les événements retardés avant de considérer que la fenêtre de temps est complète. Un Stream non borné et sans watermark peut entraîner l'échec d'un pipeline en raison d'une pression sur la mémoire.

Pour les charges de travail opérationnelles qui nécessitent 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 inférieure à la seconde.

Pour plus d'informations, voir :

• Utilisez le mode temps réel dans les LakeFlow Pipelines.
• Optimiser le traitement avec état avec des filigranes.

Limitations des tables de streaming

Les tables de streaming présentent les limitations suivantes :

• Évolution limitée : Vous pouvez modifier la query sans recalculer l'intégralité du dataset. Sans un refresh complet, une table de streaming ne voit chaque ligne qu'une seule fois, de sorte que différentes queries auront traité différentes lignes. Par exemple, si vous ajoutez UPPER() à un champ dans la query, seules les lignes traitées après la modification seront en majuscules. Cela signifie que vous devez être conscient de toutes les versions précédentes de la query qui s'exécutent sur votre dataset. Pour retraiter les lignes existantes qui ont été traitées avant la modification, un refresh complet est requis.
• Gestion de l'état : Les tables de streaming ont une faible latence et nécessitent des streams naturellement bornés ou bornés par un filigrane. Pour plus d'informations, voir Optimiser le traitement avec état avec des filigranes.
• Les jointures ne sont pas recalculées : les jointures dans les tables de streaming ne sont pas recalculées lorsque les dimensions changent. Cette caractéristique peut être bonne pour les scénarios « rapides mais erronés ». Si vous souhaitez que votre vue soit toujours correcte, vous pourriez vouloir utiliser une vue matérialisée. Les vues matérialisées sont toujours correctes car elles recalculent automatiquement les jointures lorsque les dimensions changent. Pour plus d'informations, consultez les vues matérialisées. Pour un exemple de jonction d'un Stream à une table de dimension statique, voir jonctions Stream-statiques.
• Pas de support CLONE : Les tables de streaming ne peuvent pas être utilisées comme source ou cible d'un clone profond ou superficiel. Pour les autres commandes non prises en charge, consultez les Limitations.
• PrivilègeREFRESH requis pour afficher le pipeline : Pour afficher le pipeline qui prend en charge une table de streaming, un utilisateur non-administrateur a besoin du privilège REFRESH sur la table de streaming en plus des autorisations sur le pipeline. Consultez Qui peut afficher un pipeline et sa sortie ?.

Ressources supplémentaires

• Charger des données dans les pipelines
• refresh complète pour les tables de streaming