15 prompts prets a l emploi pour le data engineering#

<schema>
Entrepot : [BIGQUERY_SNOWFLAKE_POSTGRES_DUCKDB_AUTRE]

Table : [NOM_DE_LA_TABLE]
Grain : une ligne = [CE_QUE_REPRESENTE_UNE_LIGNE]
Volume : [NOMBRE_DE_LIGNES] lignes, [TAILLE]
Partitionnement / clustering : [COLONNES_OU_AUCUN]
Colonnes :
- [COLONNE] : [TYPE] - [SIGNIFICATION] - nullable oui/non
- [COLONNE] : [TYPE] - [SIGNIFICATION] - nullable oui/non

Pieges connus : [DOUBLONS_FUSEAUX_HORAIRES_VALEURS_SENTINELLES_AUTRE]
</schema>

Tu es un data architect specialiste de la modelisation analytique.

BESOIN METIER
[DECRIS_LE_BESOIN_MEME_MALADROITEMENT]

Les questions auxquelles ce modele doit repondre :
- [QUESTION_1]
- [QUESTION_2]

CONTRAINTES
- Entrepot : [MOTEUR]
- Volume attendu : [LIGNES_PAR_JOUR]
- Frequence de rafraichissement : [TEMPS_REEL_HORAIRE_QUOTIDIEN]
- Historisation : [BESOIN_DE_GARDER_L_HISTORIQUE_OUI_NON]

FORMAT DE SORTIE
1. Le modele propose : tables de faits, tables de dimensions, grain de chaque table.
2. Le DDL complet.
3. Les cles, index, partitions et leur justification en une ligne chacune.
4. Les 3 decisions que tu as prises a ma place et qu il faut que je valide.

[COLLE_ICI_LE_BLOC_SCHEMA]

QUESTION
[FORMULE_TA_QUESTION_EN_LANGAGE_NATUREL]

CONTRAINTES
- Dialecte : [MOTEUR].
- Periode : [PLAGE_DE_DATES].
- Exclure : [CE_QU_IL_FAUT_FILTRER, ex : commandes de test, comptes internes].

FORMAT DE SORTIE
1. La requete, commentee aux endroits non evidents.
2. Les hypotheses que tu as du prendre, en puces.
3. Une requete de controle qui verifie que le resultat est coherent
   (comptage, somme de reference, absence de doublons).

Explique-moi cette requete comme a quelqu un qui connait le SQL de base
mais pas ce projet.

[COLLE_ICI_LA_REQUETE]

FORMAT DE SORTIE
1. Ce qu elle calcule, en 2 phrases.
2. Le grain du resultat : une ligne = quoi ?
3. Chaque CTE ou sous-requete : son role en une ligne.
4. Les jointures : type, cle, et ce qui se passe si la cle n est pas unique.
5. Les pieges : doublons possibles, NULL mal geres, filtres dans le WHERE
   qui annulent un LEFT JOIN.

Cette requete met [DUREE] et je veux descendre sous [OBJECTIF].

[COLLE_ICI_LA_REQUETE]

[COLLE_ICI_LE_BLOC_SCHEMA]

Plan d execution : [COLLE_LE_PLAN_OU_ECRIS_"je ne l ai pas, dis-moi comment l obtenir"]

FORMAT DE SORTIE
1. Le diagnostic : ou part le temps, et pourquoi.
2. Les optimisations classees par rapport gain / effort.
3. La requete reecrite, avec le meme resultat exactement.
4. Une requete qui compare les deux resultats ligne a ligne pour prouver l equivalence.

CONTRAINTE
Ne change pas le resultat metier. Si une optimisation le change, signale-le au lieu de l appliquer.

Traduis cette requete de [DIALECTE_SOURCE] vers [DIALECTE_CIBLE].

[COLLE_ICI_LA_REQUETE]

FORMAT DE SORTIE
1. La requete traduite.
2. Un tableau des differences : element source | equivalent cible | risque de changement de resultat.
3. La liste des pieges specifiques a cette traduction : fonctions de date, gestion des NULL,
   division entiere, sensibilite a la casse, quotes et identifiants.
4. Ce que tu n as pas pu traduire a l identique, s il y a lieu.

CONTRAINTE
Si une fonction n a pas d equivalent exact, dis-le clairement plutot que d en inventer une.

Ecris un modele dbt nomme [NOM_DU_MODELE].

CONTEXTE
- Sources amont : [MODELES_OU_SOURCES]
- Couche : [STAGING_INTERMEDIAIRE_MART]
- Materialisation : [VIEW_TABLE_INCREMENTAL]
- Convention du projet : regarde [CHEMIN_D_UN_MODELE_EXISTANT] et suis le meme style.

REGLE METIER A IMPLEMENTER
[DECRIS_LA_REGLE, ex : une commande est valide si statut != annule et montant > 0]

FORMAT DE SORTIE
1. Le fichier `.sql` du modele.
2. Le bloc YAML de documentation : description du modele et de chaque colonne.
3. Les tests dbt a ajouter (`unique`, `not_null`, `accepted_values`, `relationships`).

CONTRAINTE
Si tu proposes une materialisation incrementale, explique la strategie de mise a jour
et ce qui se passe lors d un rejeu complet.

Propose une batterie de tests de qualite pour la table [NOM_DE_LA_TABLE].

[COLLE_ICI_LE_BLOC_SCHEMA]

Ce qui est deja arrive en production : [INCIDENT_PASSE_OU_"rien de connu"]

FORMAT DE SORTIE
Un tableau : test | ce qu il detecte | severite bloquant/alerte | requete ou regle.

Couvre au minimum ces familles :
- unicite de la cle
- fraicheur (la donnee du jour est-elle arrivee ?)
- completude (colonnes obligatoires non nulles)
- plage de valeurs acceptables
- coherence entre tables (chaque ligne enfant a un parent)
- volumetrie (variation anormale par rapport a la moyenne des 7 derniers jours)

CONTRAINTE
Chaque test doit etre executable tel quel dans [DBT_GREAT_EXPECTATIONS_SQL_PUR].

Ecris un DAG Airflow nomme [NOM_DU_DAG].

ETAPES ATTENDUES
1. [ETAPE_1]
2. [ETAPE_2]
3. [ETAPE_3]

CONTRAINTES
- Version d Airflow : [VERSION] (l API a change entre les versions majeures, respecte celle-ci).
- Planification : [CRON_OU_DESCRIPTION].
- `catchup` : [TRUE_OU_FALSE], et explique la consequence.
- Chaque tache doit etre idempotente : un rejeu ne doit pas dupliquer les donnees.
- Alerte en cas d echec vers [CANAL].

FORMAT DE SORTIE
1. Le code du DAG.
2. Un schema texte des dependances entre taches.
3. Ce qui se passe si la tache [ETAPE_2] echoue au milieu : quelles donnees restent a moitie ecrites.

CONTRAINTE
Si tu n es pas certain de la signature d un operateur dans cette version, dis-le
et indique-moi la page de documentation a verifier.

Lis [CHEMIN_DU_PIPELINE] et ecris sa documentation.

FORMAT DE SORTIE
1. Une phrase : a quoi sert ce pipeline et pour qui.
2. Un tableau des sources : systeme | table | frequence | volume.
3. Un tableau des sorties : table | consommateurs connus | SLA.
4. Les transformations importantes, en francais, sans code.
5. Les regles metier codees en dur, avec leur emplacement exact dans le code.
6. Le mode d emploi en cas d incident : comment relancer, comment rejouer une date.
7. Ce que je devrais documenter mais que le code ne permet pas de deviner.

CONTRAINTE
N invente aucun SLA ni aucun consommateur. Si l information n est pas dans le code, ecris
« a completer par un humain ».

Le job [NOM_DU_JOB] a echoue cette nuit.

LOGS
[COLLE_ICI_LES_LOGS_OU_L_EXTRAIT_UTILE]

CONTEXTE
- Derniere execution reussie : [DATE]
- Changements recents : [DEPLOIEMENT_MIGRATION_CHANGEMENT_DE_SOURCE_OU_RIEN]
- Volume traite habituellement : [CHIFFRE]

FORMAT DE SORTIE
1. Ce qui a echoue exactement, et a quelle etape.
2. Les 3 causes les plus probables, classees, avec la commande ou la requete
   qui permet de trancher pour chacune.
3. Est-ce que des donnees partielles ont ete ecrites ? Comment le verifier.
4. La procedure de remise en etat, etape par etape.
5. Ce qu il faudrait ajouter pour que cet echec soit detecte plus tot.

Avant que je lance cette requete sur [BIGQUERY_SNOWFLAKE_AUTRE], analyse-la.

[COLLE_ICI_LA_REQUETE]

[COLLE_ICI_LE_BLOC_SCHEMA]

FORMAT DE SORTIE
1. Quelles tables sont scannees, et est-ce que le partitionnement est utilise ou non.
2. L ordre de grandeur des donnees lues, et sur quoi tu te bases pour l estimer.
3. Les 3 modifications qui reduiraient le plus le volume scanne.
4. La commande exacte qui me donne l estimation reelle avant execution
   (mode simulation, plan d execution, ou equivalent dans ce moteur).

CONTRAINTE
Ne donne pas de prix en euros sans me demander d abord mon modele de facturation.
Une estimation de volume scanne est plus utile qu un chiffre invente.

Ecris une transformation [PANDAS_OU_PYSPARK].

ENTREE
DataFrame `[NOM]` avec les colonnes : [COLONNE:TYPE, COLONNE:TYPE]
Volume : [NOMBRE_DE_LIGNES]

SORTIE ATTENDUE
[DECRIS_LE_RESULTAT : colonnes, grain, tri]

REGLES
- [REGLE_METIER_1]
- Valeurs manquantes : [COMMENT_LES_TRAITER]
- Doublons : [COMMENT_LES_TRAITER]

CONTRAINTES
- Pas de boucle ligne a ligne, uniquement des operations vectorisees.
- Chaque etape sur sa propre ligne, avec un commentaire court.

VERIFICATION
Genere un petit jeu de donnees d exemple couvrant les cas limites,
applique la transformation, et montre-moi l entree et la sortie.

Aujourd hui le pipeline [NOM] recharge tout a chaque execution et ca devient trop long.

CONTEXTE
- Source : [TABLE_OU_API], [VOLUME], colonne de date disponible : [COLONNE_OU_AUCUNE]
- Les lignes passees peuvent-elles etre modifiees apres coup ? [OUI_NON_JE_NE_SAIS_PAS]
- Arrivees en retard possibles ? [OUI_NON_DELAI_MAX]

FORMAT DE SORTIE
1. Les strategies possibles (fenetre glissante, cle de fusion, capture de changements),
   avec pour chacune : condition d application, risque principal.
2. Ta recommandation pour mon cas, en une phrase.
3. Le code de la strategie recommandee.
4. Comment garantir l idempotence : un rejeu du 12 mars doit donner le meme resultat.
5. Comment detecter une ligne oubliee : la requete de reconciliation.

Ecris un contrat de donnees pour la table [NOM_DE_LA_TABLE] que mon equipe publie.

[COLLE_ICI_LE_BLOC_SCHEMA]

Consommateurs connus : [EQUIPES_OU_OUTILS]

FORMAT DE SORTIE
1. Le contrat en YAML : nom, proprietaire, grain, colonnes avec type et description,
   colonnes obligatoires, valeurs autorisees.
2. Les garanties : fraicheur, frequence, delai de disponibilite.
3. La politique de changement : ce qui est un changement cassant, le preavis associe.
4. Les tests automatiques qui verifient que le contrat est respecte.

CONTRAINTE
N invente ni proprietaire ni SLA. Laisse un champ a completer si je ne te l ai pas donne.

Je dois rejouer [PIPELINE_OU_TABLE] sur la periode [DATE_DEBUT] a [DATE_FIN].

CONTEXTE
- Raison du rejeu : [CORRECTION_DE_BUG_CHANGEMENT_DE_REGLE_DONNEE_MANQUANTE]
- Volume concerne : [ESTIMATION]
- La table est-elle lue en production pendant ce temps ? [OUI_NON]

FORMAT DE SORTIE
1. La procedure, etape par etape, avec les commandes exactes.
2. Comment decouper pour ne pas saturer l entrepot (taille de lot recommandee).
3. Le plan de retour arriere si le rejeu se passe mal.
4. Les requetes de controle a lancer avant, pendant et apres.
5. Ce qu il faut prevenir aux consommateurs, et quand.

CONTRAINTE
Ne lance rien. Donne-moi la procedure, je l executerai.