Ingénierie des données un guide inspiré de la Formule 1 pour les débutants

Ingénierie des données un guide inspiré de la Formule 1 pour les novices

Un glossaire avec des cas d’utilisation pour les débutants en ingénierie des données

Êtes-vous un débutant en ingénierie des données intéressé à en savoir plus sur les infrastructures de données modernes? Je parie que oui, cet article est pour vous!

Dans ce guide, l’ingénierie des données rencontre la Formule 1. Mais, nous allons simplifier les choses.

Introduction

Je crois fermement que la meilleure façon de décrire un concept est par des exemples, même si certains de mes professeurs à l’université disaient: “Si vous avez besoin d’un exemple pour l’expliquer, cela signifie que vous ne l’avez pas compris”. De toute façon, je n’étais pas assez attentif pendant les cours à l’université, et aujourd’hui je vais vous guider à travers les couches de données en utilisant – devinez quoi – un exemple.

Scénario d’entreprise et architecture des données

Imaginez ceci : l’année prochaine, une nouvelle équipe sur la grille, Red Thunder Racing, nous appellera (oui, moi et vous) pour configurer leur nouvelle infrastructure de données.

• 34% Plus Rapide Algorithme de Conversion d’Entier en Chaîne de Caractères
• Prévisions de rétention évolutive Naviguer entre les interventions et la formation continue
• 9 façons dont l’IA améliore la sécurité des centres de données

Dans la Formule 1 d’aujourd’hui, les données sont au cœur du sport, bien plus qu’il y a 20 ou 30 ans. Les équipes de course améliorent leurs performances avec une approche phénoménale axée sur les données, en réalisant des améliorations milliseconde par milliseconde.

Il ne s’agit pas seulement du temps au tour ; la Formule 1 est une entreprise de plusieurs milliards de dollars. Augmenter l’engagement des fans n’est pas seulement pour le plaisir ; rendre le sport plus attractif n’est pas seulement pour le plaisir des pilotes. Ces activités génèrent des revenus. Une infrastructure de données robuste est indispensable pour concourir dans le secteur de la F1.

Nous allons construire une architecture de données pour soutenir notre équipe de course en commençant par les trois couches canoniques: Data Lake, Data Warehouse et Data Mart.

Lake de données

Un lac de données servirait de référentiel pour les données brutes et non structurées générées à partir de diverses sources de l’écosystème de la Formule 1 : données de télémétrie des voitures (par exemple, pression des pneus par seconde, vitesse, consommation de carburant), configurations des pilotes, temps au tour, conditions météorologiques, flux des médias sociaux, billetterie, fans inscrits aux événements marketing, achats de produits dérivés, etc.

Tous types de données peuvent être stockés dans notre lac de données consolidé : non structurées (audio, vidéo, images), semi-structurées (JSON, XML) et structurées (CSV, Parquet, AVRO).

Nous serons confrontés à notre premier défi pendant que nous intégrons et consolidons tout en un seul endroit. Nous créerons des travaux par lots extrayant des enregistrements à partir d’outils marketing et nous traiterons également des données de télémétrie en streaming en temps réel (et soyez sûr, il y aura des exigences de latence très faibles avec cela).

Nous aurons une longue liste de systèmes à intégrer et chacun prendra en charge un protocole ou une interface différente : Kafka Streaming, SFTP, MQTT, API REST et plus encore.

Nous ne serons pas seuls dans cette collecte de données ; heureusement, il existe des outils d’intégration de données disponibles sur le marché qui peuvent être adoptés pour configurer et maintenir les pipelines d’ingestion en un seul endroit (par exemple, par ordre alphabétique : Fivetran, Hevo, Informatica, Segment, Stitch, Talend, …). Au lieu de s’appuyer sur des centaines de scripts Python programmés sur crontab ou d’avoir des processus personnalisés gérant la diffusion des données à partir des sujets Kafka, ces outils nous aideront à simplifier, automatiser et orchestrer tous ces processus.

Entrepôt de données

Après quelques semaines à définir tous les flux de données que nous devons intégrer, nous ingérons maintenant une remarquable variété de données dans notre lac de données. Il est temps de passer à la couche suivante.

L’entrepôt de données est utilisé pour nettoyer, structurer et stocker les données traitées provenant du lac de données, fournissant un environnement structuré et performant pour l’analyse et les rapports.

À cette étape, il ne s’agit plus d’ingérer des données et nous nous concentrerons de plus en plus sur les cas d’utilisation commerciale. Nous devons réfléchir à la façon dont les données seront utilisées par nos collègues en proposant des ensembles de données structurées, régulièrement actualisées, concernant :

• Performance des voitures : les données de télémétrie sont nettoyées, normalisées et intégrées pour fournir une vue unifiée.
• Stratégie et revue des tendances : les données de course passées sont utilisées pour identifier les tendances, la performance des pilotes et comprendre l’impact de stratégies spécifiques.
• KPI de l’équipe : temps d’arrêt aux stands, température des pneus avant le ravitaillement, contrôle budgétaire sur les développements de la voiture.

Nous aurons de nombreux pipelines dédiés à la transformation et à la normalisation des données. Tout comme pour l’intégration des données, il existe de nombreux produits disponibles sur le marché pour simplifier et gérer efficacement les pipelines de données. Ces outils peuvent rationaliser nos processus de données, réduire les coûts opérationnels et augmenter l’efficacité des développements (par exemple, par ordre alphabétique : Apache Airflow, Azure Data Factory, DBT, Google DataForm, …).

Data Marts

Il existe une frontière mince entre les entrepôts de données et les data marts. N’oublions pas que nous travaillons pour Red Thunder Racing, une grande entreprise, avec des milliers d’employés impliqués dans des domaines divers. Les données doivent être accessibles et adaptées aux besoins spécifiques des unités commerciales. Les modèles de données sont construits en fonction des besoins commerciaux.

Les data marts sont des sous-ensembles spécialisés des entrepôts de données qui se concentrent sur des fonctions commerciales spécifiques.

• Data Mart sur les performances des voitures : l’équipe R&D analyse les données liées à l’efficacité du moteur, à l’aérodynamique et à la fiabilité. Les ingénieurs utiliseront ce data mart pour optimiser la configuration de la voiture sur différentes pistes de course ou effectuer des simulations pour comprendre la meilleure configuration de la voiture en fonction des conditions météorologiques.
• Data Mart sur l’engagement des fans : l’équipe marketing analyse les données des médias sociaux, les enquêtes auprès des fans et les audiences des téléspectateurs pour comprendre les préférences des fans. L’équipe marketing utilise ces données pour mettre en œuvre des stratégies marketing personnalisées, développer des marchandises et améliorer leurs connaissances sur les fans avec le Fan360.
• Data Mart sur l’analyse de la comptabilité : l’équipe financière a également besoin de données (beaucoup de chiffres, je crois !). Plus que jamais, les équipes de course doivent faire face à des restrictions budgétaires et réglementaires. Il est important de suivre les allocations budgétaires, les revenus et les aperçus des coûts en général.

De plus, il est souvent nécessaire de veiller à ce que les données sensibles ne soient accessibles qu’aux équipes autorisées. Par exemple, l’équipe de recherche et développement peut avoir besoin d’un accès exclusif aux informations de télémétrie, et elle a besoin que les données puissent être analysées à l’aide d’un modèle de données spécifique. Cependant, elle peut ne pas être autorisée (ou intéressée) à accéder aux rapports financiers.

Notre architecture de données en couches permettra à Red Thunder Racing de tirer parti de la puissance des données pour optimiser les performances des voitures, prendre des décisions stratégiques, améliorer les campagnes marketing… et bien plus encore !

C’est tout ?

Absolument pas ! Nous avons à peine effleuré la surface d’une architecture de données. Il y a probablement des centaines d’autres points d’intégration que nous devrions prendre en compte, en plus de simplement mentionner la transformation des données et la modélisation des données.

Nous n’avons pas du tout abordé le domaine de la science des données, qui mérite probablement son propre article, de même que la gouvernance des données, l’observabilité des données, la sécurité des données et bien d’autres.

Mais bon, comme on dit, « Rome ne s’est pas construite en un jour ». Nous avons déjà beaucoup à faire aujourd’hui, y compris le premier brouillon de notre architecture des données (ci-dessous).

Conclusions

L’ingénierie des données est un royaume magique, avec une multitude de livres qui lui sont consacrés.

Tout au long du parcours, les ingénieurs de données utiliseront des outils d’intégration illimités, des plates-formes de données diverses visant à couvrir une ou plusieurs des couches mentionnées ci-dessus (par exemple, dans l’ordre alphabétique : AWS Redshift, Azure Synapse, Databricks, Google BigQuery, Snowflake, …), des outils de business intelligence (par exemple, Looker, PowerBI, Tableau, ThoughtSpot, …) et des outils de pipelines de données.

Notre parcours d’ingénierie des données chez Red Thunder Racing vient de commencer et nous devons laisser beaucoup d’espace pour la flexibilité dans notre boîte à outils !

Les couches de données peuvent souvent être combinées, parfois sur une seule plate-forme. Les plates-formes et les outils de données élèvent la barre et réduisent les écarts jour après jour en lançant de nouvelles fonctionnalités. La concurrence est intense sur ce marché.

• Avez-vous toujours besoin d’un lac de données ? Cela dépend.
• Avez-vous toujours besoin d’avoir des données stockées dès que possible (également appelé streaming et traitement en temps réel) ? Cela dépend, quelle est l’exigence de fraîcheur des données par les utilisateurs métier ?
• Avez-vous toujours besoin de vous appuyer sur des outils tiers pour la gestion des pipelines de données ? Cela dépend !
• <Espace réservé pour toute autre question que vous pourriez avoir> ? Cela dépend !

Si vous avez des questions ou des suggestions, n’hésitez pas à me contacter sur LinkedIn. Je promets de répondre avec quelque chose de différent de : Cela dépend !

Les opinions exprimées dans cet article n’engagent que moi et ne reflètent pas les opinions de mon employeur. Sauf indication contraire, toutes les images sont de l’auteur.

L’histoire, tous les noms et incidents décrits dans cet article sont fictifs. Aucune identification avec des lieux, des bâtiments et des produits réels n’est prévue ou ne devrait être déduite.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!