Traitement des données batch et en streaming dans Databricks

Le batch et le streaming sont deux sémantiques de traitement des données utilisées pour les charges de travail de data engineering, y compris l'ingestion, la transformation et le traitement en temps réel.

Le streaming est généralement associé à un traitement continu et à faible latence à partir de bus de messages, tels qu'Apache Kafka.

Cependant, chez Databricks, sa définition est plus large. Le moteur sous-jacent des LakeFlow Pipelines (Apache Spark et Structured Streaming) a une architecture unifiée pour le traitement par batch et en streaming :

• Le moteur peut traiter les sources telles que le stockage d’objets cloud et Delta Lake comme des sources de streaming pour un traitement incrémentiel efficace.
• Le traitement en streaming peut être exécuté de manière Trigger et continue, vous offrant la flexibilité de contrôler les compromis entre coût et performances pour vos charges de travail en streaming.

Vous trouverez ci-dessous les différences sémantiques fondamentales qui distinguent le traitement par batch et le streaming, y compris leurs avantages et inconvénients, et les considérations pour les choisir pour vos charges de travail.

Sémantique de batch

Avec le traitement par batch, le moteur ne suit pas les données déjà traitées dans la source. Toutes les données actuellement disponibles dans la source sont traitées au moment du traitement. En pratique, une source de données batch est généralement partitionnée logiquement, par exemple, par jour ou par région, pour limiter le retraitement des données.

Par exemple, le calcul du prix de vente moyen des articles, agrégé par granularité horaire, pour un événement de ventes géré par une entreprise de commerce électronique peut être planifié comme un traitement par batch pour calculer le prix de vente moyen toutes les heures. Avec le batch, les données des heures précédentes sont retraitées chaque heure, et les résultats précédemment calculés sont écrasés pour refléter les derniers résultats.

Sémantique du streaming

Avec le traitement en streaming, le moteur assure le suivi des données en cours de traitement et ne traite que les nouvelles données lors des exécutions ultérieures. Dans l'exemple ci-dessus, vous pouvez planifier le traitement en streaming au lieu du traitement par batch pour calculer le prix de vente moyen toutes les heures. Avec le streaming, seules les nouvelles données ajoutées à la source depuis la dernière exécution sont traitées. Les résultats nouvellement calculés doivent être ajoutés aux résultats précédemment calculés pour vérifier l'intégralité des résultats.

Batch contre streaming

Dans l'exemple ci-dessus, le traitement en streaming est meilleur que le traitement batch car il ne traite pas les mêmes données que celles traitées lors des exécutions précédentes. Cependant, le traitement en streaming devient plus complexe avec des scénarios tels que des données désordonnées et des données arrivant en retard dans la source.

Un exemple de données arrivées tardivement est si certaines données de ventes de la première heure n’arrivent pas à la source avant la deuxième heure :

• En traitement batch, les données arrivées en retard de la première heure sont traitées avec les données de la deuxième heure et les données existantes de la première heure. Les résultats précédents de la première heure sont écrasés et corrigés avec les données d'arrivée tardive.
• Dans le traitement en streaming, les données arrivant en retard de la première heure sont traitées sans aucune des autres données de la première heure qui ont déjà été traitées. La logique de traitement doit stocker les informations de somme et de comptage des calculs de moyenne de la première heure pour mettre à jour correctement les résultats précédents.

Ces complexités de streaming sont généralement introduites lorsque le traitement est avec état, comme les jointures, les agrégations et les déduplications.

Pour le traitement streaming sans état, tel que l'ajout de nouvelles données à partir de la source, la gestion des données désordonnées et à arrivée tardive est moins complexe, car les données à arrivée tardive peuvent être ajoutées aux résultats précédents à mesure que les données arrivent dans la source.

Le tableau ci-dessous décrit les avantages et les inconvénients du traitement par batch et du traitement en streaming, ainsi que les différentes fonctionnalités produit qui prennent en charge ces deux sémantiques de traitement dans Databricks Lakeflow.

Traitement sémantique	Avantages	Consommation	Produits de Data Engineering
Batch	La logique de traitement est simple. Les résultats sont toujours précis et reflètent toutes les données disponibles dans la source.	Ce n'est pas aussi efficace ; les données sont retraitées dans une partition batch particulière. Plus lent, pourrait gérer les exigences de latence de quelques heures à quelques minutes, mais pas en secondes ou en millisecondes.	LakeFlow Pipelines flux de vues matérialisées et vue matérialisée. Databricks Runtime - Apache Spark (spark.read.load() et spark.write.save()).
Streaming	Efficace, seules les nouvelles données sont traitées. Plus rapide, peut gérer les exigences de latence allant des heures aux minutes, secondes et millisecondes.	La logique de traitement peut être complexe, en particulier pour le traitement avec état tel que les jointures, les agrégations, les déduplications, etc. Les résultats ne peuvent pas toujours être exacts, compte tenu des données désordonnées et à arrivée tardive.	Lakeflow Connect. LakeFlow Pipelines flux d'ajout, flux d'application de modifications, table de streaming et dépôt. Databricks Runtime - Spark Structured Streaming (spark.readStream.load() et spark.writeStream.start()).

Traitement sémantique	Avantages	Consommation	Produits de Data Engineering
Batch	La logique de traitement est simple. Les résultats sont toujours précis et reflètent toutes les données disponibles dans la source.	Ce n'est pas aussi efficace ; les données sont retraitées dans une partition batch particulière. Plus lent, pourrait gérer les exigences de latence de quelques heures à quelques minutes, mais pas en secondes ou en millisecondes.	LakeFlow Pipelines flux de vues matérialisées et vue matérialisée. Databricks Runtime - Apache Spark (spark.read.load() et spark.write.save()).
Streaming	Efficace, seules les nouvelles données sont traitées. Plus rapide, peut gérer les exigences de latence allant des heures aux minutes, secondes et millisecondes.	La logique de traitement peut être complexe, en particulier pour le traitement avec état tel que les jointures, les agrégations, les déduplications, etc. Les résultats ne peuvent pas toujours être exacts, compte tenu des données désordonnées et à arrivée tardive.	Lakeflow Connect. LakeFlow Pipelines flux d'ajout, flux d'application de modifications, table de streaming et dépôt. Databricks Runtime - Spark Structured Streaming (spark.readStream.load() et spark.writeStream.start()).

Recommandations

Le tableau ci-dessous présente la sémantique de traitement recommandée en fonction des caractéristiques des charges de travail de traitement des données à chaque couche de l'architecture en médaillon.

Couche Medallion	Caractéristiques du Workload	Recommandation
Bronze	Workloads d'ingestion. Implique généralement un traitement nul ou sans état pour l'ajout incrémentiel à partir de sources de données. La taille des données est généralement plus importante.	Le traitement en streaming est généralement un meilleur choix, étant donné que les utilisateurs peuvent bénéficier des avantages du streaming sans être exposés aux complexités du traitement en streaming avec état.
Argent	Charges de transformation. Implique généralement à la fois un traitement sans état tel que le filtrage et un traitement avec état tel que les jointures, les agrégations et les déduplications.	Utilisez le traitement par batch (avec incremental refresh dans les vues matérialisées). Utilisez le traitement de streaming comme option pour les cas d'utilisation où l'efficacité et la latence sont beaucoup plus importantes que la précision des résultats. Soyez attentif aux complexités introduites par le traitement de streaming avec état.
Gold	Charges de travail d'agrégation du dernier kilomètre. Comprend généralement un traitement avec état, tels que les jointures et les agrégations. La taille des données est généralement plus petite.	Utilisez le traitement par batch (avec incremental refresh dans les vues matérialisées).

Couche Medallion	Caractéristiques du Workload	Recommandation
Bronze	Workloads d'ingestion. Implique généralement un traitement nul ou sans état pour l'ajout incrémentiel à partir de sources de données. La taille des données est généralement plus importante.	Le traitement en streaming est généralement un meilleur choix, étant donné que les utilisateurs peuvent bénéficier des avantages du streaming sans être exposés aux complexités du traitement en streaming avec état.
Argent	Charges de transformation. Implique généralement à la fois un traitement sans état tel que le filtrage et un traitement avec état tel que les jointures, les agrégations et les déduplications.	Utilisez le traitement par batch (avec incremental refresh dans les vues matérialisées). Utilisez le traitement de streaming comme option pour les cas d'utilisation où l'efficacité et la latence sont beaucoup plus importantes que la précision des résultats. Soyez attentif aux complexités introduites par le traitement de streaming avec état.
Gold	Charges de travail d'agrégation du dernier kilomètre. Comprend généralement un traitement avec état, tels que les jointures et les agrégations. La taille des données est généralement plus petite.	Utilisez le traitement par batch (avec incremental refresh dans les vues matérialisées).