Cette revue est basée sur un ensemble de publications des mois de juillet et août 2024, issues de sources en lien avec le sujet Data. A piocher suivant vos centres d’intérêts.
Sommaire :
- Metrics layer, metrics store
- Tendances en architecture de données
- Le défi des silos de données … et de leur contexte
- Data mesh pragmatique : rôles des data product et data contract
- Enseignements de l’histoire de l’ingénierie des données
- Data worker
- En vrac (Est-il éthique d’utiliser des fausses données ?, Quantified organisation et confiance, L’éternel sujet du data ROI, Immigration et data, Actualité open data, Données et tennis de table, Rapport Informatica, Données infaillibles ou à rejeter, Catalogue de données et catalogue de métadonnées, FIDA)
Metrics layer, metrics store
Dans recherche de la maîtrise des données à une échelle globale, il apparait des solutions de gestion de métriques (couche de métriques, metrics store).
L’idée est gérer de manière unifiée les métriques versus leur silotage dans différents systèmes BI.
Et cette gestion passe par la définition d’une vue sémantique unificatrice.
Sujet pas simple :
- Les outils de BI proposent déjà pour leur portée, des couches sémantiques et des représentations unifiées (cubes OLAP, MOLAP),
- Les data platforms, data fabrics proposent maintenant des fonctions de type metrics store ou metrics layer (voir les derniers exemples de Microsoft Data Fabric et de Databricks),
- Ajouter une nouvelle couche pose question (Comment va-t-elle interagir avec les systèmes de BI ? Comment assurer l’homogénéité sémantique ?)
L’objectif est légitime : gérer la cohérence d’ensemble des métriques.
Plutôt que d’abord penser solution, il serait bien de revenir dans une démarche d’architecture d’entreprise, de construction des métriques en ayant une vue globale (voir par exemple l’idée d’arbre de performance –voir https://www.datassence.fr/2024/01/18/revue-data-du-mois-decembre-2023/#_ftn5 ).
Sources :
https://tdan.com/crossing-the-data-divide-metrics-stores-remind-me-that-data-work-is-hard/31940https://adrianmnastase.medium.com/microsoft-fabric-the-metrics-layer-new-feature-5bcec292e889https://www.databricks.com/dataaisummit/session/building-metrics-store-incremental-processing
Tendances en architecture de données
Architecture de données (dont modélisation des données) – tendances discutées au cours de la conférence Enterprise Data World 2024
– L’IA comme modélisateur
– Le modèle logique perdu au détriment d’un lien direct modèle physique – modèle sémantique (conceptuel) … et c’est dommage
– Un modèle de données d’entreprise (à son échelle) n’est pas réaliste, voir plutôt des modèles par domaines métiers à relier (aligner sémantiquement) entres eux (cf. data mesh)
– Le data mesh : oui mais “no standard definition of data mesh, huge investments required for its implementation, performance problems of combining data from different domains, etc.”
– L’interopérabilité techniques, sémantiques, opérationnelles des données est clé
– Data product et data contract deux concepts socles des architectures de données
Et aussi sur ce sujet des architectures de données, l’idée (non récente) de medallion architecture, les données organisées selon une logique bronze (données brutes), argent (données qualifiées) et or (données utilisables).
Le défi des silos de données … et de leur contexte
Le défi des silos de données …et de leur contexte
Le défi des silos de données passe par relever le défis des silos de contexte. Pour faire simple, l’IA va utiliser des données de différents silos, pour appuyer des acteurs dans des silos. Comment appréhender le contexte valide et nécessaire à la bonne interprétation des données par les agents IA ?
Source (lien cassé ?) : https://blog.getwren.ai/can-ai-solve-data-silos-challenge-new-challenges-to-the-multi-ai-agents-era-cec7fabc7c20.
Data mesh pragmatique : rôles des data product et data contract
Extrait : « Governing an increased number of data producers, possibly federated throughout the organization, has proven to be a challenge. Firstly, data products created across the entire organization, need to be made discoverable to everyone. Current data catalogs however are centered around data assets and their fields, not around data products.
Secondly, product thinking shifts the responsibility of capturing metadata to earlier in the development chain. This is where data contracts come in, which allow you to provide metadata up-front. These data contracts do not restrict themselves to schema metadata, but can also includes SLA information, versioning and many more. Again, the granular level of information in these data contracts conflicts with the one of data catalogs, and might require another location to be displayed.
Thirdly, as a data product is the combination of data, metadata, and business logic, this overview location should allow you to navigate easily between all these entities. Again something what current solutions are not designed for. »
-> Il faut passer des data catalogs aux data products catalogs (ou data products portals).
Data product – data contract les « nouveaux » quantum data
Dans la suite du point précédent, beaucoup d’actualité sur le sujet des data products et des data contracts : définition, processus de mise en œuvre, standardisation…
Quelques idées clés relevées :
– Un lien est maintenant fait entre les spécifications des définitions open des data products et des data contracts – Tel data product dans ses métadonnées de description va identifier les url des data contracts qui vont réguler son alimentation en données
– Pas de bonne data observabilité sans data contract (automatisation du recueil de la circulation des données et des événements associés – lineage, alerting)
– « Quelle est la différence entre un data product et un data asset ? » – voir l’article d’OpenDataSoft
– Les data contracts comme alliés de la gestion des tests (tests d’intégration entre autres)
– Data product, data contract sont aussi valables pour la diffusion de données à l’extérieur et cela doit être aligné sur les « Data Sharing Agreements », transformés en métadonnées -> à intégrer dans un sujet clé mais difficile, la gouvernance des métadonnées
– Quel est le cout d’un data product ? Exemple du cout de traitement / exécution des pipelines de données qui vont générer le data product
Sources :
https://medium.com/@wyaddow/ensuring-data-observability-success-with-data-contract-enforcement-tools-5ef14e8e6579 et https://medium.com/@wyaddow/ensure-data-contract-success-using-data-observability-tools-03ae8c1275c4,
https://www.opendatasoft.com/fr/blog/difference-data-product-data-asset/,
https://medium.com/@pflooky/data-contracts-in-action-testing-111631338657,
Data qualité boostée par l’IA dans un cadre de data products et data contracts
Une levée de fond représentative, d’une nouvelle génération d’outils dédiés à la qualité des données et boosté par l’IA. L’exemple de la solution Soda data https://www.soda.io/
A noter l’idée de s’appuyer sur la logique de data products et d’inclure les règles qualité (générées par l’IA) dans les data contracts. Source : https://siliconangle.com/2024/07/11/ai-data-reliability-startup-soda-data-raises-14m/.
Enseignements de l’histoire de l’ingénierie des données
Deux thèmes intéressants :
1) SQL résiste à tout, absorbe les évolutions autour des données dont l’IA et reste incontournable et même au cœur des data patforms. Source : https://towardsdatascience.com/the-evolution-of-sql-8d017ce566ff
Voir l’étude menée par Mike Stonebraker qui montre comment au fil du temps SQL a évolué et absorbé les évolutions de la data. Et aussi l’histoire de l’évolution du stockage sur les 20 dernières années pour montrer que le modèle relationnel et SQL restent au centre du jeu. « In his new paper, “What Goes Around Comes Around…And Around…,” which was published in the June 2024 edition of SIGMOD Record, the legendary MIT computer scientist and his writing partner, Carnegie Mellon University’s Andrew Pavlo, analyze the past 20 years of database design. As they note, “A lot has happened in the world of databases since our 2005 survey.” » – Source : https://www.datanami.com/2024/07/08/dont-believe-the-big-database-hype-stonebraker-warns/
Et le papier de l’étude : https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf
Dans cet esprit voir une recherche du MIT avec l’introduction d’extension permettant de produire des requêtes probabilistes en SQL – Source : https://www.datanami.com/2024/07/12/genql-extends-sql-for-probabilistic-modeling/
Voir aussi ce sujet dans une revue précédente : https://www.datassence.fr/2023/07/17/revue-data-du-mois-juin-2023/#_ftn5 et aussi https://www.coginiti.co/blog/the-evolution-of-sql-from-sql-86-to-sql-2023/
2) « How Data Engineering Evolved since 2014 » – Source : https://towardsdatascience.com/how-data-engineering-evolved-since-2014-9cc85f37fea6
Avec l’exemple Leboncoin – https://medium.com/leboncoin-tech-blog/from-a-hack-to-a-data-mesh-approach-the-18-year-evolution-of-data-engineering-at-leboncoin-b234fc05f091 d’une base de production+un script et excel à la logique data mesh en passant par une data platform ! Et une recommandation pour tous les acteurs data « We’re all software engineers » (les principes de bases du génie logiciel sont incontournables !).
Et sur la réalité du travail d’un data engineer : https://medium.com/@lgsoliveira/five-brutal-truths-about-being-a-data-engineer-e2455925e21d.
Voir aussi 10 data pain point vus d’un data engineer (conception de pipelines de données)
Extrait :
– Maîtriser les sources de données
– Les outils data à multiplier coutent cher
– Appliquer les règles du génie logiciel – exemple de l’évolutivité, de la gestion des tests
– Gérer les politiques de données : accès, sécurité, conservation…
– Attention aux fonctions en doublons entre les outils – exemple entre les ETL, atelier de constructions de pipelines et les solutions BI (exemples : couche sémantique, transformations SQL)
– L’orchestration des pipelines
Data worker
Sujet connu, développé par A. Casilli – https://www.casilli.fr/ , déjà évoqué de nombreuses fois dans des revues du mois précédentes.
Un nouveau rapport pour rendre visible la part ingrate, difficile (psychologiquement) du travail sur les données. Et l’IA a fait exploser le phénomène (taggage, modération). Avec des témoignages terrain effarants.
Source : https://techcrunch.com/2024/07/08/data-workers-detail-exploitation-by-tech-industry-in-dair-report/ et le rapport https://data-workers.org/wp-content/uploads/2024/06/Fasicas-Report-6th-review-After-Lawyer.pdf.
En vrac (Est-il éthique d’utiliser des fausses données ?, Quantified organisation et confiance, L’éternel sujet du data ROI, Immigration et data, Actualité open data, Données et tennis de table, Rapport Informatica, Données infaillibles ou à rejeter, Catalogue de données et catalogue de métadonnées, FIDA)
1) Est-il éthique d’utiliser des fausses données ?
Ask a Data Ethicist: When Is It OK to Use “Fake” Data?
Il est devenu très facile de produire des fausses données, des données synthétiques.
Qu’en est-t-il de leur usage ? Est-ce éthique ?
Source : https://www.dataversity.net/ask-a-data-ethicist-when-is-it-ok-to-use-fake-data/.
2) Quantified organisation et confiance
Quelle confiance dans une organisation dont la productivité, les collaborateurs, les relations de travail sont quantifiées et quelle confiance dans la quantification ?
Article à lire : https://www.duperrin.com/2024/07/23/lorganisation-quantifiee-graal-ou-big-brother/.
3) L’éternel sujet du data ROI
On peut chiffrer les coûts de la data : infrastructure, développements data, ressources data.
Plus difficile de chiffrer les revenus générés.
L’auteur propose une équation, en réalité des conseils (non nouveau et de bon sens) d’axe d’identification des ROI et de les matérialiser rapidement via des prototypes.
https://medium.com/abeadata/calculating-data-roi-a-new-equation-080b80de87f4
NB : la data fait partie du langage, comment mesurer le ROI d’un langage plus riche !
3) Un ouvrage écrit par une personne issue de l’immigration (aux US) et son rapport aux données (biais, politiques non explicite – conflictuelle).
Sources : https://medium.com/analysts-corner/data-is-not-something-it-was-but-something-it-can-become-a4fe89a48f93 et https://technicspub.com/humanizing-data-strategy/
4) Toujours intéressante, l’actualité open data : https://opendatafrance.fr/lactualite-opendata-du-mois-21/
Quand les données non structurées sont plus facilement sources des données structurées grâce à l’IA : https://medium.com/@thibaut_gourdel/unstructured-data-etl-in-2024-f0d716cde283
5) L’effet JO : données et tennis de table
6) 2024 Informatica Report : State of AI and Data with a Modern Data Architecture – Insights from 300 data leaders – « 94% of data leaders cite their top challenges as a lack of a defined data architecture and roadmap, insufficient specialized IT skills or resources and the complexities of cloud modernization and platform selection » https://www.informatica.com/resources.asset.b6f71adb1fb2bdc9b10cb788ebba20e2.pdf?
7) Une discussion sur les deux vues extrêmes des dirigeants : les données disponibles sont infaillibles ou elles sont à rejeter complètement.
Et l’éternel défi de la décision à l’aide des données « But at the same time, it’s not really about just having data. It’s about understanding both the strengths of the data that you have and the limitations and being able to effectively translate that into managerial decisions. »
Et la réponse est culturelle, une histoire de formation (statistiques de base, corrélation versus causalité, erreur d’échantillon, intervalle de confiance), de relation MOA (manager) – MOE (data scientist), contextuelle, ne pas se prendre pour les GAFAM, qu’un jeu de donnée n’est qu’une pièce dans un problème global-de système, croire que parce que les données sont vite là cela permet d’aller vite – il faut du temps d’analyse-partage-discussion-choix. Exemple de point important qu’un dirigeant doit prendre en compte : comprendre les sources de données, le défi des bonnes mesures). Rien de nouveau mais comme la problématique est vieille comme les données et se pose toujours en 2024 … si vous parlez data, l’effort numéro 1 est ici.
Source : https://hbr.org/podcast/2024/08/is-your-company-reading-data-the-wrong-way
8) Une discussion sur la différence entre catalogue de données et catalogue de métadonnées
https://www.datanami.com/2024/07/03/data-catalogs-vs-metadata-catalogs-whats-the-difference
NB : l’un sans l’autre a peu de sens
9) FIDA changement de méthode dans le recueil des données
« Agrégateurs de données financières : ce que change Fida » – du passage de la récupération de données via du scraping web (extraction des données des pages web) à l’utilisation d’API exposées par les institutions financières … Bref un changement « génie logiciel » améliorant largement l’industrialisation de l’ouverture des données – Source :
RDV maintenant en octobre pour la revue et les actualités de septembre !
Les commentaires sont fermés.