Post de Achille Huet

Dans le nouvel épisode de DataGen, Mabrouk vous explique comment Fivetran peut considérablement aider vos équipes data pour leur data integration, c'est par ici ! 📢

Vous pouvez ajouter la donnée client dans le Data Warehouse ? L’équipe Data Engineering : “Avec plaisir, ce sera prêt dans 6 mois.” 🤯 Toutes les équipes Data font face à cet effet goulot d’étranglement à un moment ou un autre. 🧐 Pourquoi ? C’est génial, les boîtes sont de plus en plus data-driven et collectent toutes les données disponibles pour prendre des meilleures décisions ou alimenter des algorithmes. 🚀 Le problème, c’est que le nombre de demandes à destination des équipes Data explose. 💥 Les Data Engineers se retrouvent avec trop de demandes de mise à disposition de données et deviennent un goulot d’étranglement. 😩 Résultat, il y a 6 mois d’attente pour obtenir des données et les équipes Data Engineering ont la sensation de dépiler des tickets toute la journée sans trop comprendre quel est leur impact sur l’entreprise. 💣 La solution ? Une des tendances qui a émergé pour y faire face est celle des ETL Modernes. 🧐 Ces outils permettent d’ingérer en quelques clics les données de centaines de sources. 🤩 L’équipe Data peut donc couvrir beaucoup plus de besoins en gardant la même taille. ✅ Mabrouk, Senior Solution Engineer chez Fivetran est venu nous parler de cette tendance dans le dernier épisode de DataGen. 🎙 Pour l’écouter :  1/ Un like sur ce post (pour soutenir Mabrouk ❤️) 2/ Liens en commentaire👇 Cheers, Robin 😘 PS : j’ai découvert cette tendance lorsque le Directeur Data d’Aircall (👋 Edouard) m’a parlé de Fivetran il y a 2 ans dans l’épisode 14 et depuis, je ne compte plus le nombre de fois ou la solution a été mentionnée sur le podcast.

6 mois d'attente pour avoir accès à la donnée ---> "Fivetran enters in the room" --> 6 minutes d'attentes Voilà en résumé pourquoi écouter le dernier podcast de Robin Conquet et Mabrouk GADRI sur DataGen ;) Virginie Brard Marshall Wilson Shane O'Connell Lisa Di Martino Agnes Rocher Irina Slavitch Julien Goulley Loïc Poulmarc'k Aymen Ben Azouz, PhD #datagen #dataintegration #ETL #ELT #dataingestion

Comment choisir le bon propriétaire de la donnée ? Après avoir choisi le bon outil de data catalog, effectué la modélisation des métadonnées, il vient l’enrichissement dudit data catalog. Il est fortement recommandé de définir des data owners, également appelés référents métiers ou tout simplement propriétaires des données. Dans le cadre de la mise en place d’une gouvernance au sein d’une organisation, c’est important de définir des propriétaires pour les données, et cela pour plusieurs raisons : * Créer une synergie data avec les métiers en incluant les propriétaires dans les features teams qui délivrent les usages data. * Responsabiliser les métiers sur les données qu’ils produisent => améliore la qualité des données, notion de data contract. * Avoir un interlocuteur clairement défini pour la validation des règles de gestion métiers et des définitions métiers => améliore également la qualité des données. Maintenant, qui va-t-on choisir ? C’est important de sélectionner, dans un premier temps, un petit groupe de collaborateurs ayant une appétence et/ou une forte motivation à utiliser la data en plus de leur connaissances métiers. Trouver les champions data, ces collaborateurs qui seront un vrai catalyseur à la transformation data de l’organisation, va permettre de créer petit à petit une base solide à une effervescence grandissante autour de la data. #data #datagovernance #datacatalog #gouvernancedesdonnées #datacontract #dataaddict #dataforever #TechInnovation

Très intéressant de comprendre les étapes nécessaires à la mise en place d'un Data Catalog. Merci Robin et Sebastien pour les explications et n'hésitez pas à aller sur le post pour accéder au podcast. Vous avez également envie de partager votre expertise en tant que Data Steward ? DecideOm - Expert Data recrute ! Le lien est en commentaire !

Comment mettre en place un Data Catalog ? 🤔 Sebastien : Assieds-toi ! 👇 Il y a 6 étapes : 1) Valider qu’on a le “sponsorship” : mettre en place un Data Catalog nécessite un investissement conséquent en temps côté Tech et Métier. La direction doit être convaincue de l’importance d’investir dans la data (ex : une stratégie data est déjà en cours d’exécution, des cas d’usage ont été lancés…). 2) Déployer par use case et par itération (ex : un tableau de bord) : l’objectif est de mesurer des ROI rapidement et de créer de la confiance. Ce sera crucial pour accélérer le déploiement à l’échelle de toute l’entreprise. 3) Créer le dictionnaire : ici, on va collecter les données de nos données (aka les métadonnées : la liste des tables, des colonnes, des fichiers…). L’objectif est de centraliser ces informations dans ce qu’on appelle le dictionnaire. Les Data Catalogs modernes permettent de le faire automatiquement mais on peut également le faire à la mano sur Excel. 4) Créer le glossaire : on va travailler avec le Métier pour lister les métriques Business, ajouter leurs définitions, la méthode de calcul, identifier s’il s’agit d’une donnée sensible, préciser un niveau de confidentialité… Idem, les Data Catalogs modernes permettent de réaliser une V1 automatiquement à partir du dictionnaire. 5) Documenter le lineage : en parallèle du glossaire, on va collecter à nouveau des métadonnées mais cette fois sur les “transformations” (ex : la liste des scripts, les données concernées, les dates d'exécution…) et sur l’usage des données (ex : dans quel tableau de bord on la retrouve, dans quel algorithme…). 6) Mettre à disposition ces infos : tout ce travail a pour objectif de faciliter le déploiement de projets data pour les équipes Tech et l’usage de la donnée pour les équipes Métier. Par exemple, on va rendre accessible les définitions des métriques en un clic directement depuis les outils de BI. Sébastien est un expert en Data Gouvernance et a d’ailleurs lancé l’outil de Data Catalog leader en France : DataGalaxy. Il nous a fait une véritable masterclass sur la mise en place d’un Data Catalog dans le dernier épisode de DataGen. 🎙 Pour l’écouter, mettez-nous un petit like et rdv en commentaire. 👇 Cheers, Robin 😘

1 minute ⏰ pour comprendre l’évolution vers l’ère des 𝙙𝙤𝙣𝙣𝙚́𝙚𝙨 𝙢𝙖𝙞𝙡𝙡𝙚́𝙚𝙨. Nous sommes entrés dans une nouvelle ère des données. Les grandes organisations depuis quelques mois orientent leur stratégie vers ce que l’on nomme les données maillées. Petit focus sur cette nouvelle architecture, organisation, et les capacités associées. Les ères des données se suivent … mais l’une n’efface pas l’autre. Il est nécessaire de tenir compte de l’historique de construction des systèmes data dans le temps. Le poids de l’existant (services rendus, investissements, maintenance) est prépondérant. A chaque ère ses capacités, ses usages, et ses contraintes. Ère des données enfouies : Les données sont enfermées dans des traitements, elles sont uniquement connues au travers des traitements.  Les données ne sont pas gérées en tant que tel et elles peuvent être « oubliées ». Ère des données centralisées : Les données sont regroupées dans des entrepôts (Data Warehouse > Data Lake) Elles sont traitées par les équipes équipes BI et les Data Scientist (Big Data). Les métiers sont de plus en plus éloignés des données … et ils s’en écartent. Ils n’en n’ont plus la responsabilité. Ère des données maillées : Les systèmes de centralisation de données n’arrivent pas à répondre aux enjeux autour des données. Les paradigmes de data mesh, data fabric (au sens tissus) émergent pour répondre à cette situation.  Des plates-formes data en support au maillage émergent. www.orkestra-data.com

Ces dernières années, j’ai vu de nombreux projets Big Data qui, malgré les ressources disponibles, ne respectent pas les fondamentaux des best practices . Que ce soit : • En architecture de stockage, souvent mal conçue et peu scalable, • En distribution des applications, mal optimisée pour les grandes volumétries, • En modélisation des données, qui manque de structure et de clarté, • Ou encore dans le lien entre la data et le reporting, souvent flou et peu aligné avec les objectifs métiers. Et vous, partagez-vous ce constat ? 🤔

Comment modéliser ses métadonnées dans son data catalog ? Le choix du data catalog est fait … on découvre l’outil … aïe .. comment on va modéliser ses métadonnées. Je ne peux pas faire exactement ce que je veux, il manque une fonctionnalité, à quoi sert cette fonctionnalité ? …. On passe tous par cette étape où l’on se pose des tas de questions. Effectivement, on observe un manque de maturité général sur les data catalog concernant le glossary. cette couche métier qui permet de colliger les termes et concepts métiers, classifier, identifier les owners, les points de vérités, les points d’acquisition, les règles de gestion métiers, etc. La bonne méthode est de définir un modèle de métadonnées simple et d’enrichir, dans un premier temps, les informations importantes comme la définition des concepts métiers, le propriétaire de la donnée ou encore le point de vérité de la donnée. Il convient ensuite de définir des domaines métiers, une hiérarchie métier si besoin. Puis arrive la classification avec les tags, très pratique. Notre modèle est prêt, il faut l’enrichir. Il est conseillé de procéder par petites étapes, repérer les référents métiers pour valider les concepts métiers, les champions Data qui vont nous aider à promouvoir l’outil. Enrichir au rythme des usages délivrés, faire adhérer le data catalog métier par métier. #data #datagovernance #datacatalog

1 minute 💪 pour comprendre l’évolution vers l’ère des données maillées. Nous sommes entrés dans une nouvelle ère des données. Les grandes organisations depuis quelques mois orientent leur stratégie vers ce que l’on nomme les données maillées. Petit focus sur cette nouvelle architecture, organisation, et les capacités associées. Les ères des données se suivent … mais l’une n’efface pas l’autre. Il est nécessaire de tenir compte de l’historique de construction des systèmes data dans le temps. Le poids de l’existant (services rendus, investissements, maintenance) est prépondérant. A chaque ère ses capacités, ses usages, et ses contraintes. Ère des données enfouies : Les données sont enfermées dans des traitements, elles sont uniquement connues au travers des traitements.  Les données ne sont pas gérées en tant que tel et elles peuvent être « oubliées ». Ère des données centralisées : Les données sont regroupées dans des entrepôts (Data Warehouse > Data Lake) Elles sont traitées par les équipes équipes BI et les Data Scientist (Big Data). Les métiers sont de plus en plus éloignés des données … et ils s’en écartent. Ils n’en n’ont plus la responsabilité. Ère des données maillées : Les systèmes de centralisation de données n’arrivent pas à répondre aux enjeux autour des données. Les paradigmes de data mesh, data fabric (au sens tissus) émergent pour répondre à cette situation.  Des plates-formes data en support au maillage émergent. www.orkestra-data.com #datamesh #dataproduct #dataplatform