Poste

Ingénieur données

À quelle vitesse apprenez-vous qu'une source a changé de structure : par une alerte ou parce qu'un analyste demande pourquoi le rapport est vide ? Toute la différence de ce poste est là.

Entretien préalable

Quatre questions par lesquelles nous commencerions

À quelle vitesse apprenez-vous un changement dans une source ?

Si c'est seulement quand le flux s'arrête ou que les données ressortent vides, la réaction commence par une explication et non par une correction.

Comment savez-vous que les données en sortie sont correctes ?

Si la seule preuve est que le flux s'est exécuté, la correction est une hypothèse.

Que se passe-t-il quand un flux ne s'exécute pas à l'heure ?

Si les destinataires le savent avant d'ouvrir le rapport ou après.

Que ne savez-vous pas d'un flux tant qu'il n'a pas cessé de fonctionner ?

En général : ce qui l'utilise et qui le remarquerait s'il disparaissait.

Bureau, schéma sur un tirage : une personne marque sur le tirage une liaison entre deux tables.

Nous prenons la surveillance et la documentation, vous gardez la conception des flux

Détecter les changements de sources, les contrôles de qualité, la surveillance des flux et la documentation peuvent être retirés du bureau. Concevoir le traitement et les décisions sur le modèle de données restent à l'ingénieur.

  • Un changement de source est un signal, pas une panne. - Une colonne nouvelle, un type modifié ou un champ manquant s'annoncent avant de casser le traitement.
  • La qualité des données se mesure, elle ne se suppose pas. - L'exhaustivité, les plages et les règles se vérifient à chaque exécution, et un écart parvient à l'ingénieur avant d'arriver dans un rapport.
  • On sait ce qui utilise quoi. - Les dépendances entre flux, tables et rapports se voient, donc l'effet d'un changement se juge avant de le faire.

Périmètre

Ce qui peut être retiré de l'ingénierie des données

Vingt tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à votre architecture de données.

Sources et leurs changements

  • Un registre des sources avec leur responsable et leur structure
  • Détection d'un changement de structure d'une source
  • Un signal quand un champ a cessé d'être alimenté
  • Comparaison du volume avec les exécutions précédentes

Traitement

  • Un projet de transformation pour les motifs répétitifs (appréciation : l'ingénieur)
  • Signalement des flux à logique similaire
  • Retraitement d'une plage après une correction
  • Un registre des exécutions avec l'heure et le résultat

Qualité des données

  • Des règles de qualité en entrée et en sortie
  • Un signal quand une valeur s'écarte de la plage attendue
  • Signalement des enregistrements rejetés avec leur motif
  • Qualité récapitulée par source (appréciation : l'ingénieur)

Surveillance des flux

  • Statut des flux avec les délais de livraison
  • Un signal quand un flux est en retard au regard de ce qui a été convenu avec le destinataire
  • Prévenir les destinataires d'un retard
  • Pannes récapitulées par cause

Documentation des données

  • La traçabilité des données d'une table de sortie
  • Les dépendances entre flux, tables et rapports
  • Signalement des tables et des flux inutilisés
  • Des descriptions de champs générées depuis les transformations (vérification : l'ingénieur)

Une journée de travail

Aujourd'hui

  • Vous apprenez un changement de source quand le flux tombe
  • Vous vérifiez la qualité des données quand quelqu'un signale un résultat étrange
  • Un destinataire découvre qu'un flux est en retard en ouvrant le rapport
  • Vous connaissez les dépendances entre flux de mémoire
  • Il existe de la documentation pour une partie des flux
  • Vous ne savez pas quelles tables et quels flux ne servent plus

Avec l'assistance de l'IA

  • Un changement de structure d'une source s'annonce avant la panne
  • Les règles de qualité tournent à chaque exécution
  • Les destinataires sont prévenus d'un retard avant d'ouvrir le rapport
  • Les dépendances se voient, donc l'effet d'un changement se juge
  • Les descriptions de champs sont générées depuis les transformations et vous les vérifiez
  • Les flux et les tables sans usage sont signalés
  • Des données à l'heure

    moins de rapports ouverts sur des données périmées

    un retard est signalé aux destinataires

  • Détection des changements de sources

    un changement est un signal et non une panne

    les structures des sources sont comparées à chaque exécution

  • Qualité des données en sortie

    moins de chiffres faux arrivant jusqu'à une décision

    les règles tournent avant la publication

  • Un flux transparent

    on sait d'où vient un chiffre d'un rapport

    la traçabilité et les dépendances sont consignées

Nous commençons par détecter les changements de sources, parce qu'ils causent la plupart des pannes.

  1. Étape 1

    Un registre des sources et la détection des changements

    La structure, le responsable, un signal au changement et sur les champs qui ont cessé d'être alimentés.

  2. Étape 2

    Règles de qualité

    Exhaustivité, plages et règles métier en entrée et en sortie.

  3. Étape 3

    Surveillance et avis aux destinataires

    Statuts, délais de livraison, information sur un retard.

  4. Étape 4

    Traçabilité et dépendances

    Ce qui se construit à partir de quoi et ce qui utilise quoi. En dernier, parce que cela exige des flux en ordre.

Questions fréquentes

Les questions qui reviennent à la première réunion

En quoi est-ce différent d'un analyste de données ?

L'analyste répond à des questions avec les données. L'ingénieur répond de l'existence même de ces données, à l'heure et en bon état. Un poste travaille sur le résultat, l'autre sur le chemin qui y mène.

Moins d'ingénieurs suffisent-ils pour les flux ?

Le nombre de flux croît avec chaque nouvelle source et chaque nouveau rapport, et les équipes données croissent rarement à ce rythme ; de là viennent l'arriéré et les flux que personne ne comprend. Reprendre la surveillance et la documentation ne remplace personne : cela permet de maintenir ce qui tourne déjà sans renoncer à construire du nouveau.

Cela relève-t-il du règlement sur l'IA ?

Construire des flux de données n'est pas un usage à haut risque. Si les flux couvrent des données personnelles, les règles de protection des données s'appliquent (minimisation, base légale et conservation) et il vaut la peine que le registre des sources montre quels flux en contiennent.

Une question qui ne figure pas ici ? Réservez un appel

Étape suivante

Combien de fois le trimestre dernier un flux est-il tombé à cause d'un changement de source ?

Nous vous montrerons à quoi ressemble le travail sur les données quand un changement de source est un signal et que la qualité se vérifie avant la publication.