La façon dont les organisations ont conçu et exploité leurs plateformes de données a subi un changement sismique au cours de la dernière décennie. Au cœur de cette transformation, l'adoption de l'architecture Event Driven (EDA), un paradigme de conception de logiciel qui modifie fondamentalement la façon dont les flux de données entre les systèmes. Lorsqu'elle est appliquée à l'intégration des lacs de données et des entrepôts de données, l'EDA débloque des capacités qui étaient auparavant difficiles ou impossibles à réaliser avec des approches traditionnelles axées sur les lots.

Comprendre les lacs et les entrepôts de données

Avant de plonger dans l'impact de l'EDA, il est essentiel d'apprécier les rôles distincts que les Data Lakes et Data Warehouses jouent dans une pile de données moderne.

Lacs de données

Un Data Lake est un dépôt centralisé conçu pour stocker des quantités massives de données brutes non traitées dans son format natif. Cela comprend des données structurées de systèmes transactionnels, des données semi-structurées comme des journaux et des fichiers JSON, et des données non structurées comme des images et des vidéos. Data Lakes offre une grande flexibilité grâce à une approche schématique en lecture, ce qui signifie que la structure est appliquée uniquement lorsque les données sont posées.

Entrepôts de données

Un Data Warehouse, en revanche, stocke des données traitées, structurées et nettoyées optimisées pour l'intelligence d'affaires (BI) et le reporting. Data Warehouses utilise une approche schéma-on-write, où les données sont transformées et organisées en modèles dimensionnels (par exemple, des schémas étoiles) avant le chargement.

Traditionnellement, les organisations ont maintenu ces deux systèmes comme silos séparés, avec des pipelines ETL/ELT en lots qui déplacent les données entre eux. Cependant, le besoin croissant d'analyse en temps réel et la vitesse croissante des données ont exposé les limites du traitement par lots, ce qui a conduit à la montée en puissance des architectures axées sur les événements.

Qu'est-ce que l'architecture animée par l'événement?

Event Driven Architecture est un modèle de conception de logiciel dans lequel les composants communiquent en produisant et en consommant events — notifications de quelque chose d'intéressant. Un événement contient généralement une charge utile décrivant le changement et les métadonnées comme un horodatage et un identifiant unique. Les événements sont publiés à un courtier d'événements (ou un bus événement) qui découple les producteurs des consommateurs, permettant aux systèmes de réagir asynchronement.

Composantes clés de l'EDA

  • Producers: Services ou applications qui détectent un changement d'état et publient un événement. Par exemple, un outil de saisie de données de changement (CDC) qui publie des changements de ligne de base de données.
  • Courtier d'événements: Le middleware qui reçoit, stocke et fait route les événements vers les consommateurs intéressés.
  • Consommateurs d'événements:[ Services ou processus qui souscrivent à des types d'événements spécifiques et agissent sur eux, comme la mise à jour d'un entrepôt de données ou le déclenchement d'un pipeline de données.

L'EDA favorise un couplage souple, ce qui signifie que les producteurs et les consommateurs peuvent évoluer de façon indépendante. Cette architecture excelle dans les scénarios exigeant un traitement en temps réel, une grande évolutivité et la capacité de gérer diverses sources de données.

Le passage de l'intégration de données par lots à l'intégration de données par événements

L'intégration traditionnelle des données repose sur des tâches par lots périodiques, souvent programmées quotidiennement ou à l'heure, pour extraire, transformer et charger les données des sources vers le lac Data et ensuite vers l'entrepôt Data. Bien que le traitement par lots soit simple et déterministe, il introduit une latence importante.

Lorsqu'un changement se produit dans un système source (p. ex., une nouvelle commande est passée ou un utilisateur met à jour son profil), un événement est publié et immédiatement ingéré dans le lac de données. Les consommateurs en aval, comme l'entrepôt de données, peuvent alors réagir à l'événement pour mettre à jour des vues matérialisées ou des tableaux agrégés en temps quasi réel. Ce changement réduit la latence des données d'heures à secondes.

Toutefois, le passage à des modèles axés sur les événements n'est pas sans complexité, mais nécessite une infrastructure robuste pour la commande des événements, le traitement de la sémantique et la gestion des schémas.

Impact de l'EDA sur l'intégration des lacs de données

Le lac Data, en tant que dépôt de données brutes, est un premier bénéficiaire naturel de l'ingestion induite par les événements.

Ingestion des données en temps réel

Avec EDA, les données peuvent circuler dans le lac de données en continu lorsque des événements se produisent. Au lieu d'attendre une fenêtre de lot nocturne, de nouvelles données sont disponibles pour les requêtes en quelques secondes. Ceci est critique pour les cas d'utilisation tels que la surveillance de capteur IoT, l'analyse de clicstream, et les moteurs de personnalisation en temps réel.

Flexibilité Schema-on-Read

Les schémas d'événements peuvent évoluer sans briser le lac Data. Parce que le lac Data stocke les événements bruts, les consommateurs peuvent appliquer différents schémas ou transformations au besoin. Cela s'harmonise parfaitement avec le couplage libre d'EDA – un producteur peut modifier son schéma d'événements (suivant les meilleures pratiques de la version), et les consommateurs en aval peuvent s'adapter indépendamment.

Soutien pour l'approvisionnement en événements et le mesh de données

En stockant chaque événement, les organisations peuvent reconstruire l'état actuel à tout moment ou exécuter des analyses historiques. De plus, EDA facilite une architecture de maillage de données en permettant aux équipes de domaine de publier leurs données comme événements, que d'autres équipes peuvent consommer via le courtier d'événements. Cela favorise la propriété décentralisée et améliore la découverte des données.

Impact de l'EDA sur l'intégration des entrepôts de données

Les entrepôts de données ont traditionnellement été mis à jour par l'intermédiaire de travaux de lot ETL. EDA transforme cela en permettant des mises à jour progressives en temps quasi réel sans sacrifier la performance et la cohérence que les entrepôts exigent.

Changement de saisie des données et mise à jour de la diffusion

Les outils de saisie de données (CDC) peuvent saisir les modifications de base de données (insertions, mises à jour, suppressions) comme événements et les publier à un courtier. Les consommateurs d'entrepôt appliquent ensuite ces modifications aux tableaux correspondants en utilisant des opérations de fusion ou de mise à niveau. Cela maintient l'entrepôt en permanence synchronisé avec les systèmes transactionnels, en supportant des rapports de haut en bas. Par exemple, une entreprise de détail peut suivre les niveaux d'inventaire en temps réel en utilisant les événements CDC qui passent d'une base de données opérationnelle à un entrepôt Snowflake.

Vues matérialisées différentielles

Les plates-formes d'entrepôt modernes supportent des vues matérialisées qui peuvent être rafraîchies progressivement. Lorsqu'un événement indique un changement dans les données sous-jacentes, l'entrepôt peut recalculer uniquement les partitions touchées. EDA peut déclencher ces rafraîchissements automatiquement, réduisant les coûts de calcul et les temps de rafraîchissement par rapport aux reconstructions complètes.

Cohérence et commande des données

Pour y remédier, les entrepôts doivent mettre en œuvre la logique de mise à jour idémpotente et utiliser les métadonnées des événements (comme les horodatages ou les numéros de séquence) pour commander correctement les changements. De nombreuses plateformes prennent désormais en charge les garanties transactionnelles lors du traitement des flux d'événements, permettant aux entrepôts de maintenir une forte cohérence tout en bénéficiant de mises à jour à faible latence.

Architecture unifiée des données avec EDA : le modèle Lakehouse

La convergence des lacs et des entrepôts de données en architecture lakehouse est accélérée par une intégration par événement. Une maison de lac utilise un lac de données comme couche de stockage unique et ajoute des fonctions de type entrepôt — transactions ACID, requête SQL et application de schéma — en plus. EDA fournit le tissu conjonctif qui permet le flux de données en temps réel dans la maison de lac.

Dans une maison de lac, les événements se déversent directement dans une table Delta Lake ou Iceberg, où ils sont immédiatement disponibles pour les charges de travail BI et d'apprentissage automatique. Les vues matérialisées ou les couches de service peuvent être mises à jour via des fonctions déclenchées par des événements. Cela élimine le besoin de systèmes séparés et réduit le mouvement des données, ce qui entraîne des coûts plus faibles et des architectures plus simples.

Défis et considérations

Bien que les avantages de l'EDA pour l'intégration des données sur les lacs et les entrepôts soient importants, les organisations doivent relever plusieurs défis pour réussir.

Ordre des événements et temps de vie

Les événements peuvent arriver hors de la commande en raison de retards de réseau ou de stratégies de partitionnement. Sans une commande appropriée, les données d'entrepôt peuvent devenir incohérentes. Les solutions comprennent l'utilisation de partitions d'événements tachées par un identifiant d'entreprise, l'utilisation de temps d'événement (pas de temps de traitement) pour la commande, et l'utilisation de structures de données tolérantes à la latence comme les journaux en version.

Exactement une fois sémantique

La livraison au moins une fois est courante chez les courtiers en événements, ce qui signifie que les consommateurs peuvent voir des événements en double. Les entrepôts de données nécessitent exactement une sémantique une fois pour éviter le double comptage en mesures. Cela peut être obtenu en faisant des consommateurs idéopontes — en utilisant des clés de déduplication (par exemple, ID de l'événement) et en exécutant des upserts — ou en se fondant sur des éviers transactionnels qui supportent exactement une fois le traitement, comme Kafka , exactement une fois sémantique lorsqu'ils sont combinés avec un connecteur d'évier compatible.

Qualité des données et gouvernance du schéma

Les schémas d'événements changent souvent au fil du temps à mesure que les exigences commerciales évoluent.Sans gouvernance, les consommateurs en aval peuvent se rompre. Les meilleures pratiques comprennent l'utilisation d'un registre de schémas avec des vérifications de compatibilité, des événements de version et la mise en oeuvre de politiques d'évolution de schémas (p. ex., compatibles avec l'arrière, compatibles avec l'avant).

Complexité opérationnelle et surveillance

La surveillance des taux de latence, de débit et d'erreur dans l'ensemble du pipeline est difficile. Les organisations devraient investir dans des outils d'observation qui suivent la lignage des événements, alertent sur la contre-pression et fournissent des tableaux de bord de latence de bout en bout. La gestion d'un flux de qualité (p. ex. dans les flux Kafka ou Flink) nécessite des compétences spécialisées et une disponibilité prudente des ressources.

Meilleures pratiques pour la mise en œuvre de l'AED dans les plateformes de données

Pour maximiser les avantages de l'intégration axée sur les événements tout en minimisant les risques, suivez ces modèles éprouvés.

Commencez par modifier la saisie des données

CDC est un point d'entrée à faible friction pour EDA. En streaming des changements de base de données des systèmes transactionnels, vous pouvez immédiatement apporter des données en temps réel dans votre lac de données et entrepôt sans modifier les applications sources.

Choisissez le bon courtier d'événement

Apache Kafka est le standard de facto pour le streaming d'événements à haut débit et durable. Pour des cas d'utilisation plus simples ou des environnements cloud-natif, considérez Amazon Kinesis, Google Pub/Sub ou Azure Event Hubs. Évaluer des facteurs tels que l'évolutivité, les exigences de latence, l'intégration avec les outils existants, et les frais généraux opérationnels.

Embrassez les consommateurs d'idéopontes

Concevez tous les consommateurs pour gérer les événements en double avec grâce. Utilisez une combinaison d'opérations UPSERT et de logique de déduplication. Dans les entrepôts SQL, utilisez les instructions MERGE avec les identifiants d'événements. Dans les environnements de data lake, utilisez l'idemppotency au niveau des fichiers (par exemple, en écrivant sur des chemins de fichiers uniques) ou les journaux de transactions.

Mettre en œuvre la gouvernance du schéma

Adopter un registre Schema (p. ex. Confluent, registre de Glue Schema AWS) pour faire respecter les règles de compatibilité entre la production et la consommation.

Surveiller la latence de bout en bout

Mettre en place des mesures pour la latence de production d'événements, le délai de livraison des courtiers et le temps de traitement des consommateurs. Viser une boucle de rétroaction où la latence augmente les alarmes de déclenchement et l'échelle automatique.

Le rôle des plateformes de données flexibles dans un monde animé par des événements

Une plate-forme de données flexible comme Directus agit à la fois en tant que consommateur d'événements et producteur, permettant une connectivité sans faille entre les courtiers d'événements, les bases de données et les systèmes d'analyse. Directus peut publier des webhooks ou écouter des flux d'événements externes pour mettre à jour sa base de données sous-jacente en temps réel. Cela en fait un excellent outil pour construire des tableaux de bord en temps réel, des backends de gestion de contenu ou des applications opérationnelles qui dépendent des dernières données de Data Lakes et Entrepôts.

En exposant une API unifiée sur des sources de données hétérogènes, Directus réduit la complexité de l'intégration des outils EDA à la logique d'affaires. Les équipes peuvent se concentrer sur la valeur de l'événement plutôt que d'écrire un code de colle personnalisé pour chaque type d'événement.

Conclusion

En passant de la distribution à la distribution en temps réel, les modèles d'événements, les organisations obtiennent une latence plus faible, une plus grande évolutivité et des systèmes de données plus réactifs. Data Lakes devient un flux continu d'événements bruts, tandis que Data Warehouses reçoit des mises à jour progressives qui maintiennent les tableaux de bord BI frais. Le modèle lakehouse, activé par EDA, unifie ces deux mondes en une seule plateforme cohésive.

Cependant, le succès exige une attention particulière à la commande d'événements, à la cohérence des données, à la gouvernance des schémas et au suivi opérationnel.Avec la bonne architecture et l'outillage – y compris les CDC, les registres de schémas, les consommateurs idéopontes et les plateformes flexibles comme Directus – les organisations peuvent exploiter toute la puissance de l'intégration des données par événement.

Liens externes: