Créer et construire vos modèles de données - Datasets externes
Ce tutoriel vous aidera à utiliser le Lakehouse Manager pour la deuxième étape et le data processing engine pour la troisième étape du démarrage
Objectif
Ce tutoriel vous aidera à utiliser le Lakehouse Manager pour la deuxième étape et le data processing engine pour la troisième étape du tutoriel de démarrage avec les Datasets externes.
Organiser vos données en tables
Créer votre schéma principal
Ajouter des tables au modèle de données
Vous devez vous assurer d'avoir créé un dataset externe avant de continuer. Les étapes pour créer un dataset externe se trouvent ici.
Une fois vos métadonnées extraites, il est temps de vous rendre sur le dashboard Tables. C'est ici que vous allez construire une vue unifiée et interrogeable de toutes vos données.
La page Tables vide devrait ressembler à ceci.
L'onglet All tables est celui où vous avez accès à l'intégralité de vos données. L'onglet New View vous permet de créer des vues portant sur une partie seulement de vos données afin de mieux collaborer au sein de grandes équipes. Puisqu'il s'agit ici d'un tutoriel simple, vous devriez travailler dans l'onglet All tables.
Concentrons-nous maintenant sur la création de vos tables principales et de leurs attributs.
Tout d'abord, survolez avec votre curseur l'icône bleue ➕ sur le côté gauche de l'écran. Cela affichera les options de création :
- Upload a file
- Create from Connectors source
- Create an empty tables
Pour les besoins de ce tutoriel, nous allons poursuivre avec Create from a Connectors source.
Une fois que vous cliquez sur create from a connectors source, une liste des sources de l'étape précédente s'affiche. Cliquez sur la source que vous voulez ajouter et poursuivez en cliquant sur Next. Ici, nous pouvons choisir l'un des datasets externes que vous avez créés. Il n'est pas nécessaire de modifier les autres paramètres par défaut.
Les options Build the table, load the table once, and generate Load action for later peuvent être désactivées et chaque étape peut également être réalisée individuellement. Cela peut être exploré en détail dans le guide Tables
Appuyez sur Create et procédez de la même manière pour la seconde table.
Notez qu'à chaque changement effectué sur la page Tables, votre configuration visuelle est automatiquement sauvegardée.
À ce stade, votre page Tables devrait ressembler à ceci.
Vous remarquerez peut-être que certains attributs de vos tables sont écrits en gras. La platform a automatiquement détecté qu'il s'agissait de clés primaires, c'est-à-dire l'attribut (ou l'ensemble d'attributs) utilisé pour identifier de manière unique chaque ligne de données dans la table.
Vous pouvez modifier manuellement les clés primaires de n'importe quelle table en survolant l'attribut avec votre curseur et en cliquant sur l'icône étoile ⭐.
Vous remarquerez peut-être qu'en utilisant les Datasets externes, certains attributs de vos tables sont écrits en gras. La Platform a automatiquement détecté qu'il s'agissait de clés primaires, c'est-à-dire l'attribut (ou l'ensemble d'attributs) utilisé pour identifier de manière unique chaque ligne de données dans la table. Le Lakehouse Manager Engine est davantage un moteur big data, et par défaut, le concept de clés primaires n'existe pas. Vous ne verrez donc aucun attribut en gras.
Notez que la Platform utilise les informations de métadonnées capturées lors de l'étape Analyzer pour créer automatiquement les tables et attribuer les noms et types d'attributs. Les fichiers sources fournis sont prêts à l'emploi ; toutefois, dans un Projet réel, vous devriez utiliser l'Analyzer pour vérifier les sources de données avant de les glisser-déposer dans la page Tables.
Joindre des tables entre elles
Vous devez indiquer au Lakehouse Manager comment vos tables sont liées entre elles.
Vous allez joindre des tables qui sont liées entre elles selon une relation parent/enfant. Un parent est une table qui contient des informations détaillées sur un sujet particulier : par exemple, la météo à Chicago à une date donnée. Une table enfant référence plusieurs tables parentes. Une autre manière de voir les choses est qu'une table enfant hérite des valeurs de la table parente (tout comme les enfants dans la vraie vie, sauf qu'un enfant peut avoir plus de deux parents !)
La table stations_rides est une table enfant. Elle contient des informations de fréquentation par date et par station de train. Mais elle ne dispose pas d'informations détaillées sur les jours. Vos deux tables ont date comme clé primaire. Ainsi, si vous liez la table parente chicago_calendar_full à la table enfant stations_rides, vous aurez automatiquement ajouté des informations météorologiques à votre fréquentation, pour chaque jour de l'année.
Tout d'abord, cliquez une fois sur la table parente chicago_calendar_full pour la sélectionner, puis cliquez sur le cercle blanc en bas de la table :
Faites simplement glisser la flèche vers la table enfant stations_rides et relâchez. Votre écran devrait ressembler à ceci :
Créer votre table d'agrégation
Vous allez maintenant agréger toutes les données importantes des sources (à savoir les trajets, les dates et les températures) dans une seule table qui sera utilisée dans l'application finale. Les tables d'agrégation consolident les données provenant de plusieurs tables sources.
Pour créer votre première table d'agrégation, cliquez sur l'icône bleue ➕. Sélectionnez Create an empty table, une configuration de nouvelle table s'affiche alors dans laquelle vous définissez un nom (dataset_history par exemple) puis l'enregistrez.
Ensuite, glissez-déposez date et station_id depuis la table source stations_rides vers la table dataset_history et définissez ces attributs comme clés primaires.
Déplacez les attributs ci-dessous vers dataset_history et ne les définissez pas comme clés (puisqu'il s'agit de données simples de chaque ligne, non uniques) :
Enfin, vous devrez créer un nouvel attribut pour aider à traduire les données de température numériques en catégories compréhensibles (froid, chaud, ...).
Commencez par cliquer sur l'icône ➕ qui apparaît en haut de la table dataset_history lorsque vous cliquez dessus. Vous pouvez alors créer ou modifier un attribut au sein d'une table.
Définissez l'attribut comme suit :
Pour le moment, cet attribut n'est pas physiquement spécifié. Cela sera fait plus loin dans un autre composant : le Data Processing Engine.
Finaliser le build
Une dernière petite vérification ! Assurez-vous de vérifier deux fois que votre modèle de données ressemble exactement à celui des captures d'écran avant de passer à l'étape suivante. Si certains attributs sont manquants, vous risquez de rester bloqué dans les étapes ultérieures du tutoriel.
Maintenant, cliquez sur l'icône Build (sous l'icône bleue ➕) pour effectivement créer/mettre à jour les tables et attributs dans votre dataset. Cela ne charge pas encore les données dans les tables (ce qui sera fait dans le prochain article) ; cela applique simplement le schéma logique aux tables et attributs de votre dataset sous-jacent.
Alors que le schéma logique visuel des données est automatiquement sauvegardé, les changements apportés à vos tables ne seront pas visibles dans le reste de la Platform tant qu'elles ne sont pas buildées.
La tâche de build pour ce tutoriel ne devrait pas prendre plus de quelques minutes à s'exécuter. Une fois terminée, vous pouvez continuer.
Ajouter des métriques pertinentes avec les Virtual Attributes
Avant de passer au traitement physique (ETL/ELT) des données dans ce modèle, préparons des métriques supplémentaires pour l'analytique ultérieure. L'application finale que vous construisez en suivant ce tutoriel inclut un graphique avec le nombre de trajets par jour pour une station donnée :
Cependant, vous ne disposez pas des données nécessaires pour construire ce graphique directement sur les sources principales. Vous aurez besoin d'une métrique qui vous donne le nombre moyen de trajets par jour pour une station donnée et qui puisse être utilisée dans des requêtes et des dashboards.
Mais comment calculer cela avec la platform ? Une manière de le faire est de créer un attribut virtuel. Les virtual attributes vous permettent de calculer des formules SQL qui seront calculées à la volée et ne seront pas stockées dans la base de données. Elles peuvent être utilisées dans une requête ou un graphique de votre dashboard final.
Ajouter ou modifier des virtual attributes ne nécessite pas de reconstruire le schéma.
Basculez vers la page Attributes. Cette page liste tous les attributs physiques et virtuels de votre modèle de données, ainsi que le lineage de votre Projet.
Cliquez sur le bouton New Attribute pour créer un virtual attribute.
Dans la fenêtre de création, assurez-vous de sélectionner Virtual comme realm.
Ajoutez maintenant ces deux attributs et leur code SQL respectif :
L'attribut yearmonth vous donne l'année et le mois au format yyyy-mm. Vous l'utiliserez plus tard.
Remarquez que vous venez d'utiliser deux méthodes différentes pour générer de nouveaux attributs/métriques à partir des données importées : ajouter un attribut physique à une table et les virtual attributes.
- Ajouter un nouvel attribut physique occupe de l'espace de stockage et nécessite de le définir physiquement dans le Data Processing Engine, mais cela les rend plus rigoureux car leurs spécifications peuvent ensuite être modifiées sans changer l'ensemble du modèle de données.
- Les virtual attributes constituent une solution rapide mais peuvent devenir difficiles à gérer si vous devez les modifier à mesure que vous montez en charge.
Actions
Une action consiste en une opération physique unitaire sur les données. Les Actions peuvent être organisées en stages afin de produire des pipelines de traitement de données automatisés appelés workflows.
Cliquez sur le menu Actions de votre Data Processing Engine. Vous devriez voir les deux actions Load qui ont été automatiquement générées à l'étape précédente :
Ces actions Load vont physiquement extraire les données de vos sources et les charger dans votre data warehouse, en suivant le schéma défini dans le Lakehouse Manager.
Créer plus d'actions
Notre Marketplace vous donne accès à une dizaine d'actions organisées pour démarrer rapidement vos Projets de traitement de données : des actions load, des actions aggregate, des actions delete, etc. Si vous ne trouvez pas ce dont vous avez besoin dans le catalogue, vous pouvez toujours recourir à une action custom qui vous permet d'exécuter n'importe quel morceau de code Python 3+ dans le cadre de vos pipelines de données.
En savoir plus sur les actions personnalisées.
Pour ce tutoriel, vous allez créer une action utilisée pour agréger vos données dans la table dataset_history que vous avez créée dans la partie précédente.
Cliquez sur New action et sélectionnez le modèle Aggregate action depuis le Platform Store.
Il y aura 2 étapes simples pour configurer l'action Aggregate :
- (1) Sélectionner une table source : stations_rides
- (2) Sélectionner la table de destination : dataset_history
Après quelques secondes, le Data Processing Engine trouvera automatiquement toutes les conditions de jointure requises, et mappera les attributs.
Changez la condition de jointure en un INNER join à l'aide du menu déroulant. Cela garantira que vous n'aurez aucun champ nul dans les enregistrements de votre table dataset_history.
Les attributs ont été mappés automatiquement. Trouvez l'attribut rides, qui est la métrique que vous cherchez à agréger, et basculez-le vers une fonction SUM. Partout ailleurs, laissez la fonction MAX telle quelle : la plupart des SGBD exigent d'appliquer une clause d'agrégation aux attributs qui ne font pas partie de la clause GROUP BY.
Enfin, définissons l'attribut catégoriel cat_temperature que vous avez créé précédemment. Cliquez sur l'option < map > (abréviation de « mapping ») dans le menu déroulant bleu comme indiqué ci-dessous, et basculez-la vers < sql >.
Copiez-collez simplement la commande SQL ci-dessous :
Laisser un attribut de destination non mappé dans la configuration de l'action Aggregate déclenchera une erreur au lancement de l'action. Si vous préférez laisser le champ de destination vide, veillez simplement à le retirer de la liste des attributs mappés.
En savoir plus sur les actions Aggregate
Cliquez sur Create en haut à droite.
Vous avez maintenant généré toutes les actions requises pour ce tutoriel.
Bien sûr, votre Projet réel comportera probablement plus de 3 actions. Vous pouvez organiser vos actions en dossiers et les renommer si besoin. Vous pouvez également utiliser plus d'un repository, en particulier si vous travaillez en collaboration avec des coéquipiers. Les repositories d'actions peuvent être versionnés et également synchronisés avec des repositories Git externes. Consultez la page de documentation produit dédiée pour en savoir plus sur la façon de procéder !
En savoir plus sur les Actions dans la documentation produit
Workflows
Un workflow définit l'ordre d'exécution de vos actions.
Au sein d'un workflow, les actions sont organisées en stages séquentiels. Au sein d'un stage, toutes les actions seront exécutées en parallèle, tandis que les stages s'exécuteront toujours les uns après les autres. La même action peut être utilisée plusieurs fois dans le même workflow. Un workflow, tout comme une action, peut être lancé manuellement, configuré pour s'exécuter selon une planification, ou déclenché via un appel API.
Notez qu'il est important de retenir que les stages s'exécutent les uns après les autres dans l'ordre où vous les avez planifiés, tandis que les actions contenues dans un stage s'exécutent toutes en même temps, quel que soit leur ordre. En résumé, l'ordre des actions au sein d'un stage n'a pas d'importance, contrairement à l'ordre des stages au sein d'un workflow.
Pour créer votre premier workflow, vous devrez vous rendre dans l'onglet Workflow et cliquer sur New Workflow. Rendez-vous dans les préférences ou double-cliquez sur le nom d'en-tête pour définir un nouveau nom Import Chicago Data.
Commençons par définir deux stages différents en cliquant sur Add a stage. Ensuite, ajoutez des actions dans chaque stage à l'aide du sélecteur de recherche déroulant, en suivant la capture d'écran fournie comme guide pour chaque stage.
Après avoir créé le workflow (create), appuyez sur Play.
Veuillez noter que les workflows peuvent prendre quelques minutes à s'exécuter lorsque vous les lancez pour la première fois. Le temps total ne devrait pas dépasser 10 minutes - si c'est le cas, veuillez contacter notre équipe support.
Pendant que le workflow s'exécute, vous pouvez en profiter pour le planifier pour qu'il s'exécute quotidiennement à l'aide d'un trigger.
Rendez-vous dans l'onglet Preferences de vos workflows et faites défiler jusqu'au widget Triggers en bas à gauche. Cliquez sur +Add.
Sélectionnez le type de trigger CRON et le mode Simple. Naviguez vers l'onglet Daily et, dans la liste des options, sélectionnez Every 1 day(s) comme indiqué dans l'image ci-dessous :
Appuyez sur le bouton Confirm pour créer le nouvel événement de trigger avec le nom de votre choix, et il sera ajouté sous le Launch Endpoint présent par défaut dans le tableau des Trigger event.
Il y a bien plus que vous pouvez configurer dans les préférences d'un workflow. Notamment, vous pouvez monter en charge horizontalement et verticalement n'importe quel job de traitement, utiliser la segmentation de charge de travail pour accélérer le traitement des données, et même sauvegarder toutes ces configurations pour une utilisation répétée grâce aux environnements.
En savoir plus sur la configuration des préférences d'exécution.
Assurez-vous de cliquer sur le bouton Save en haut à droite de l'écran chaque fois que vous apportez une modification à vos workflows. Les actions sont stockées dans des repositories qui peuvent être versionnés, ce qui n'est pas le cas pour les workflows ou les environnements. Autosave est donc désactivé pour les workflows comme pour les environnements.
Jobs
Pour conclure cette section, voici quelques mots sur le dernier onglet du composant Data Processing Engine : les jobs.
L'onglet Jobs résume toutes les exécutions déclenchées dans le Data Processing Engine et inclut des rapports de métriques avancés. Les jobs sont listés sous trois catégories principales : running, queued et past executions. En consultant les derniers jobs exécutés, vous pouvez vérifier le statut du workflow que vous venez de lancer.
Vous avez maintenant terminé la section Data Engineering du tutoriel Premiers pas.
Une bonne manière de vous assurer que vos données ont été correctement chargées est de retourner dans le Lakehouse Manager et de regarder le nombre de lignes chargées dans la table. Ouvrez simplement le mode d'affichage liste et vérifiez la colonne rows ; si le champ affiche un nombre (indiquant combien de lignes ont été chargées), alors tout s'est bien passé.
Si vous souhaitez poursuivre le tutoriel de démarrage, vous pouvez passer directement à l'étape 4 : l'Analytics Manager
Aller plus loin
Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le canal Discord dédié.
Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre centre d'aide.
Rejoignez notre communauté d'utilisateurs.