Connaissances

Qu'est-ce qu'un produit de données ?

Un produit de données donne accès à des données gérées et possède un propriétaire clairement identifié.

Produit de données et données comme produit

Le terme produit vient de l'approche du product thinking, qui s'est imposée ces dernières années dans le développement logiciel. Zhamak Dehghani l'a repris dans le deuxième principe fondateur du Data Mesh : data as a product, les données comme produit. Cela signifie qu'un logiciel, et désormais les données, se conçoit toujours du point de vue du consommateur, afin de lui offrir la meilleure expérience possible. Comme pour un produit physique, la conception doit partir des besoins de celui qui l'utilise. On l'explique au client de façon compréhensible (de manière intuitive ou via un mode d'emploi), on l'optimise pour qu'il soit facilement accessible sous la forme qui convient le mieux à son utilisateur, et on va parfois jusqu'à en faire la promotion en interne pour montrer son potentiel. En toute logique, il peut donc aussi avoir un prix que les consommateurs acceptent de payer. Les données sont désormais considérées comme une valeur pour l'entreprise, et non plus comme un simple sous-produit du développement logiciel.

Le terme produit de données découle du principe data as a product et en reprend les idées, sans pour autant en être un synonyme. Tentons une définition :

Un produit de données est donc un objet technique, réalisé par des Data Product Developers. Il s'appuie sur des technologies de données pour stocker et traiter de grands volumes, souvent des millions d'enregistrements, voire davantage. Sa taille est calibrée pour couvrir des concepts métier cohérents ou des cas d'usage qui ont une valeur en eux-mêmes. La taille maximale correspond à ce qu'une seule équipe peut prendre en charge. On peut grossièrement comparer les produits de données à des microservices ou à des self-contained systems, mais reposant sur des technologies de données et répondant à des besoins analytiques. Malgré le terme produit, les Data Product Consumers sont en général d'autres équipes internes, et non des clients externes.

Exemples de produits de données

• L'équipe Product Search propose un produit de données Search Queries qui contient toutes les requêtes saisies par les utilisateurs dans la barre de recherche, le nombre de résultats et des informations sur le résultat cliqué.
• L'équipe Article Management propose un produit de données Articles avec les données de référence des articles, à la fois l'état courant et l'historique.
• L'équipe Checkout propose un produit de données Orders avec toutes les commandes depuis 2020. Il comporte deux Output Ports : l'un avec les données personnelles, l'autre avec les données personnelles masquées.
• L'équipe Fulfillment dispose d'un produit de données Shelf Warmers regroupant tous les articles qui n'ont pas été vendus au cours des 3 derniers mois.
• L'équipe Management Support s'appuie sur d'autres produits de données pour créer un produit de données Realtime Business Dashboard destiné au dirigeant. Il ne partage aucune donnée et n'a pas d'Output Port.
• L'équipe Recommendations utilise d'autres produits de données pour entraîner un modèle de machine learning de recommandation. Le modèle est partagé sous la forme d'un répertoire Tensorflow SavedModel sur un object store. L'équipe Marketing s'en sert pour proposer des recommandations personnalisées dans la newsletter.

Les composants internes d'un produit de données

Output Ports

Les Output Ports constituent l'API principale d'un produit de données : ils donnent un accès en lecture seule à des jeux de données structurés, sous forme de tables, de fichiers ou de topics. Un produit de données peut exposer plusieurs Output Ports : ils peuvent fournir le même jeu de données dans plusieurs technologies, ou des jeux de données différents dans une même technologie, par exemple un Output Port contenant des données personnelles et un second où ces données sont masquées. Un nouvel Output Port peut aussi être ajouté lorsqu'une évolution structurelle du produit de données devient nécessaire.

La technologie d'interface privilégiée pour un Output Port est SQL. Elle permet d'accéder simplement à de grands volumes de données et elle est prise en charge par pratiquement tous les outils analytiques. Un Output Port est souvent implémenté sous forme de vue SQL, qui sert de couche d'abstraction et permet de modifier la structure de données sous-jacente sans impacter les Data Consumers. Les autres technologies d'interface possibles sont les fichiers ou les topics, pour le traitement en flux ou comme API asynchrone vers les systèmes opérationnels.

Les Output Ports définissent le modèle du jeu de données fourni. Ce modèle est décrit dans un schéma qui recense toutes les tables, tous les attributs et tous les types. Les technologies courantes sont SQL DDL, les modèles dbt, Protobuf, Avro ou JSON Schema. Le modèle peut également être documenté dans une entrée de catalogue de données.

  models:
    - name: stock_last_updated_v1
      description: >
        Current state of the stock.
        One record per SKU and location with the last updated timestamp.
      columns:
        - name: sku
          type: string
          description: Stock Keeping Unit (SKU), the business key of an article.
          tests:
            - not_null
        - name: location
          type: string
          description: The ID of the warehouse location.
          tests:
            - not_null
        - name: available
          type: number
          description: The number of articles with this SKU that are available at this location.
          tests:
            - not_null
            - dbt_utils.expression_is_true:
                expression: "col_a >= 0"
        - name: updated_at
          type: timestamptz
          description: The business timestamp in UTC when the available was changed.
          tests:
            - not_null

Les Output Ports sont facultatifs, ou peuvent rester privés si le produit de données ne sert que des cas d'usage analytiques internes à l'équipe.

L'accès aux Output Ports est encadré par des Data Contracts.

Input Ports

Un produit de données peut avoir deux types de sources : les systèmes opérationnels ou d'autres produits de données.

Les équipes qui développent les systèmes opérationnels exposent elles aussi les données pertinentes de leur domaine dans des produits de données. Cela passe souvent par des topics asynchrones, de préférence à l'aide d'événements métier bien définis. Au final, c'est toutefois à l'équipe du domaine de décider comment ses données sont ingérées dans ses produits de données.

Un produit de données peut également consommer d'autres produits de données via leur Output Port, dès lors qu'un Data Contract a été conclu. Ces produits peuvent appartenir à la même équipe ou à d'autres équipes. C'est le cas typique des produits de données orientés consommateur ou agrégés, mais un produit orienté source peut lui aussi rattacher d'autres données de domaine lorsque c'est utile, par exemple pour retrouver des données de référence.

Discovery Port

Les Data Consumers doivent pouvoir trouver les produits de données qui les concernent. Comme les données ont généralement un sens propre à un domaine, il est essentiel de décrire en détail la sémantique du modèle de données.

D'autres métadonnées, comme les coordonnées de contact, le niveau de maturité, l'usage qu'en font d'autres équipes, les tests de qualité et les objectifs de niveau de service, sont tout aussi importantes : elles permettent aux Data Consumers de juger si un produit de données est fiable et adapté à leur cas d'usage.

Une bonne pratique consiste à publier automatiquement ces métadonnées depuis la pipeline CI/CD vers un catalogue de données et vers l'inventaire des produits de données, comme Entropy Data.

Propriété

Un produit de données est développé et maintenu par une seule équipe, qui comprend le domaine métier, les processus métier et les données. Cette équipe s'engage sur la qualité de données et les objectifs de niveau de service promis. Un produit de données a un interlocuteur dédié, le Data Product Owner de l'équipe, responsable en dernier ressort du produit et de sa qualité.

Le Data Product Owner pilote le cycle de vie et l'évolution du produit de données, en tenant compte des besoins des consommateurs actuels et potentiels ainsi que des besoins analytiques internes au domaine. C'est également lui qui fixe le prix facturé pour l'utilisation du produit de données.

Code de transformation

Les données doivent être nettoyées, agrégées, assemblées et transformées pour alimenter le schéma de l'Output Port ou pour répondre à des questions analytiques.

La technologie retenue et l'organisation interne du code sont des détails d'implémentation du produit de données. Ils dépendent de la plateforme de données et relèvent du choix des équipes de développement.

Bien souvent, les requêtes SQL servent aux transformations simples et Apache Spark aux pipelines complexes.

Un outil de planification et d'orchestration, comme Airflow, se charge d'exécuter le code de transformation.

Stockage des données

Un produit de données doit généralement stocker un volume important de données, sous forme de tables ou de fichiers dans un object store. Le stockage est fourni en self-service par la plateforme de données. Chaque produit de données dispose de son propre espace privé, isolé des autres produits de données.

La technologie retenue et l'organisation interne des données sont des détails d'implémentation du produit de données. Ils dépendent de la plateforme de données et relèvent du choix des équipes de développement. Dans bien des cas, on utilise des technologies de stockage orientées colonnes.

Tests

Un produit de données fournit des jeux de données gérés et de haute qualité : comme dans toute discipline d'ingénierie logicielle, les tests sont donc indispensables. Il en existe plusieurs types :

Les tests unitaires portent sur le code de transformation lui-même. Ils s'appuient sur des données d'entrée figées et définissent les données de sortie attendues.

Les tests d'attentes s'exécutent au moment du déploiement sur les modèles de données réels et vérifient que les données sources issues des Input Ports, les modèles intermédiaires et l'Output Port respectent les attentes définies.

Les tests de qualité s'exécutent régulièrement sur les données réelles afin de surveiller les objectifs de niveau de service.

Documentation

Lorsque les données d'un domaine sont partagées avec d'autres équipes, il est important de décrire leur sémantique ainsi que le contexte métier dans lequel elles ont été produites.

Au-delà de la description des attributs du modèle de données, une bonne documentation explique ce que l'on peut attendre des jeux de données et donne des premières pistes sur les données intéressantes et la façon d'y accéder.

Une manière efficace de documenter un produit de données consiste à fournir un notebook interactif (Jupyter, Google Colab, Databricks Notebook) avec des exemples de requêtes.

Gestion des coûts

Les technologies de données deviennent vite coûteuses à grande échelle. Il est donc important de suivre les coûts des produits de données. Ils peuvent servir de base au prix facturé aux Data Consumers, tel qu'il est convenu dans les Data Contracts.

Policies as Code

Les policies globales sont les règles du jeu du Data Mesh, définies par le groupe de gouvernance fédérée : conventions de nommage, schémas de classification des données ou contrôle d'accès, par exemple.

La plupart de ces règles ont vocation à être appliquées au niveau de la plateforme de données, mais certaines doivent être configurées au niveau du produit de données, en particulier lorsqu'elles supposent une connaissance du domaine ou une décision du Data Product Owner sur les autorisations. C'est le cas de la classification des données au niveau des colonnes, du marquage des données personnelles et du contrôle d'accès.

Pipeline CI/CD et planification

Un produit de données possède sa propre pipeline CI/CD et ses propres définitions de ressources d'infrastructure. La pipeline se déclenche à chaque modification du code de transformation ou du modèle de données : les tests s'exécutent, puis le produit de données est déployé sur la plateforme de données conformément aux policies globales. L'équipe plateforme peut mettre à disposition des modules ou des templates réutilisables par les équipes produit.

Un outil de planification et d'orchestration, comme Airflow, se charge d'exécuter le code de transformation et les tests.

Observabilité

Un produit de données peut exposer des ports et des fonctions supplémentaires qui ne sont pas utilisés directement par les Data Consumers, mais qui sont importants pour son exploitation. On y trouve notamment les ports de supervision, de journalisation et d'administration.

Open Data Product Standard

apiVersion: "v1.0.0"
kind: "DataProduct"
id: "shelf-warmers"
name: "Shelf Warmers"
status: "active"
description:
  purpose: "A list of articles with no sales in last 6 months"
team:
  name: "fulfillment"
tags:
- "demo"
outputPorts:
- name: "snowflake_fulfillment_shelf_warmers"
  version: "1"
  description: "A list of articles with no sales in last 6 months"
  type: "snowflake"
  contractId: "snowflake_fulfillment_shelf_warmers"
  authoritativeDefinitions:
  - type: "Snowflake WebUI"
    url: "https://example.com"
  customProperties:
  - property: "platformRole"
    value: "op_shelf_warmers_snowflake_fulfillment_shelf_warmers_role"
  - property: "status"
    value: "active"
  - property: "autoApprove"
    value: true
  - property: "containsPii"
    value: false
  - property: "server"
    value:
      schema: "SHELF_WARMERS"
      account: "lmtabcd-xn12345"
      database: "FULFILLMENT_DB"
  - property: "environment"
    value: "prod"
- name: "s3_fulfillment_shelf_warmers"
  version: "1"
  description: "A list of articles with no sales in last 6 months"
  type: "s3"
  contractId: "snowflake_fulfillment_shelf_warmers"
  authoritativeDefinitions:
  - type: "AWS Console"
    url: "https://example.com"
  customProperties:
  - property: "platformRole"
    value: "op_shelf_warmers_s3_fulfillment_shelf_warmers_role"
  - property: "status"
    value: "active"
  - property: "autoApprove"
    value: true
  - property: "containsPii"
    value: false
  - property: "server"
    value:
      location: "s3://my-bucket"
  - property: "environment"
    value: "prod"
customProperties:
- property: "platformRole"
  value: "dp_shelf_warmers_role"
- property: "type"
  value: "consumer-aligned"

Une spécification formelle du produit de données sert de socle à l'automatisation et permet d'alimenter d'autres systèmes en métadonnées, par exemple un catalogue de données ou une marketplace de données.

Implémenter un produit de données

Voyons maintenant à quoi ressemble concrètement l'implémentation d'un produit de données. Selon la plateforme de données, les approches diffèrent :

• Databricks : le produit de données s'implémente sous forme de Databricks Asset Bundle
• Snowflake : le produit de données est en général un projet dbt
• BigQuery : le produit de données est en général un projet dbt
• AWS S3 et Athena : le produit de données est souvent géré comme un projet Terraform
• Kafka : un projet Java

Dans cet exemple, nous partons d'une stack technique AWS S3 et Athena. L'équipe plateforme fournit un module Terraform qui provisionne tous les services nécessaires au fonctionnement d'un produit de données sur la plateforme, conformément aux policies et aux conventions définies par le groupe de gouvernance.

Les Data Product Developers disposent d'un dépôt Git par produit de données. Ils y utilisent le module Terraform fourni et le configurent pour leur produit. Dans ce même dépôt, ils définissent le code de transformation sous forme de requête SQL, ainsi qu'un fichier JSON Schema décrivant le modèle de l'Output Port et documentant le modèle de données en détail.

# dataproduct.tf
module shelf_warmers {
  source = "git@github.com:datamesh-architecture/terraform-dataproduct-aws-athena.git"
  version = "0.2.1"

  domain   = "fulfillment"
  name     = "shelf_warmers"
  description = "Shelf warmers are products that are not selling for 3 months and are taking up space on the shelf."

  schedule = "0 0 * * ? *" # Run at 00:00 am (UTC) every day

  transform = {
    query = "sql/transform.sql"
  }

  output = {
    format   = "PARQUET"
    schema   = "schema/shelf_warmers.schema.json"
    roles_allowed = ["coo"] # Policy as code
  }
}

Un terraform apply, généralement déclenché par la pipeline CI/CD, provisionne toutes les ressources nécessaires : buckets S3, ressources AWS Athena et fonctions Lambda. Les autorisations sont également créées dans AWS IAM.

La pipeline pousse par ailleurs les métadonnées vers le catalogue de données et l'inventaire des produits de données.

Un exemple d'implémentation de module Terraform est disponible sur GitHub.

Entropy Data

Entropy Data est un logiciel qui permet de gérer les produits de données et les Data Contracts, et d'en faire une marketplace de données simple à utiliser. Il s'appuie sur le standard ODPS pour construire un inventaire complet des produits de données. Les produits de données peuvent être importés depuis les plateformes et les catalogues de données, et leurs métadonnées enrichies facilement via une interface web, un éditeur YAML, des API et même des éditeurs Excel. Les Data Consumers parcourent l'inventaire, trouvent les produits de données qui les intéressent et demandent un accès.

Grâce à son API REST, Entropy Data s'intègre à toutes les plateformes de données et déclenche automatiquement la création des autorisations IAM dès qu'un Data Contract est créé ou mis à jour.

Créer un compte gratuitement, ou explorer la démo cliquable d'Entropy Data.