# Document de passation
## Objectif de la mission
Migrer la base de donnée de teradata vers bigquery. Doit donc aussi migrer tous les traitements qui tournent dessus.
## Comment faire ?
Développemer des scripts Python (et un peu bash) pour faire le gros du travail en automatique, puis ajustement et vérification à la main (plus ou moins assisté again).
### Concepts
Le fichier de base est parsé, puis on génère un dag ainsi que différents fichiers annexes, pour qu'ils aient un traitement identique à l'existant.
Le dag est donc le V2 du traitement : pas la même apparence, mais le même travail de fond.
Celui-ci doit être testé par nous, pour vérifier que tout est ok.
## Les tâches :
Dev fait sur le serveur de dev (hc001xtk svt appelé xtk). Il y a aussi beaucoup d'interaction avec le serveur de prod (hc001xyd, svt appelé xyd).
Utilisation de airflow (plateforme de gestion de flux) pour remplacer les flux actuels.
Jira pour le suivi des taches.
Git pour mettre à disposition le code.
Notepad pour dev (permet d'éditer les fichiers directement sur le serveur avec NppFTP).
MRemote pour les connexions aux serveurs.
Teams et Slack pour la communication.
# Chemins
### Chemins ariflow:
dags → /app/gcpdev/airflow/dags
jcl → /app/odsdev/load/mvsp/<TRIGRAMME>/jcl
sql → /data/gcpdev/DOCKER/airflow-sql/<nom du flux>/<nom du sql>
data (fichiers données) → /data/gcpdev/DOCKER/airflow-data
misc (COBOL) → /data/gcpdev/DOCKER/airflow-misc
chemin log tpt dans xyd:/logs/tptdev/addgcp/mig
lien consol bigquery:
[bigquery](
https://console.cloud.google.com)
lien airflow (interface):
[airflow](
http://xc001xtk.siege.intra.groupe-casino.fr:8081/home)
user : airflow
mdp : gcpdev01;
pour relancer un step qui a planté dans mon flux, clique gauche dessus, bouton clear
pour avoir la log : clique gauche, log en haut
### Chemin vers les fichiers cobol
fichier conf pour check si cobol :
dans /app/gcpdev/mainframe-dag-generator : cat jcl_conf.yamls
## Migration d'un TPT
### Type de fichiers
Il sont stockés dans /app/odsdev/scriptstptV1/<nom_flux>.tpt
Pour la migration de ce flux, voir **autoMig.pdf**.
**autoMig** génère le dag, l'execute en intégralité, transfert les données de teradata vers
puis fait des tests.
Si ça ne marche pas, il doit comparer les données de la table Teradata avec celle de BigQuery pour comprendre pourquoi.
### Outils utilisés pour débuger
Essentiellement console BigQuery et software teradata studio (pour faire les requêtes sql)
### Problèmes
1. Le résultat de l'execution de la requete sur BigQuery est différent de celui sur Teradata.
- On va chercher les données de Teradata et on les met sur BigQuery.
→ on crée une table qui va accueillir les données de Teradata :
2. récuperation schéma de la table sur laquelle il y a des différences (select ddl, commande a faire sur BigQuery)
3. copier coller + changer nom table
4. executer
- export des données de Teradata vers BigQuery:
5. retrouver l'extracteur de données (commence par hist_extr, il a le même nom que ton flux normalement)
6. editer le dag. Au niveau de l'étape gcs_to_BigQuery_task, modifier le parametre destination_project_dataset_table et indiquer le nom de la table nouvellement créée
7. relancer l'extracteur (via l'interface d'aiflow)
- inspection entre les tables pour comprendre
### Problème : la requete sql ne s'execute pas.
1. consulter la log pour avoir l'erreur
2. dans notre recherche internet → duplicatas
3. on trouve bien des dupli dans notre table source
4. check si les dupli sont présents dans la base source → il n'y sont pas
5. duplis sont créés quand on recupère les données de base vers la table BigQuery (du a une erreur humaine sur la parallelisation de l'extraction des données)
6. corriger les bornes dans les odbc (/data/gcpdev/DOCKER/airflow-odbc/\<flux\>/\*.sql)
7. ajouter dans le fichier excel ajustement migration, onglet historique ([sharepoint]( https://groupecasino.sharepoint.com/\:x\:/r/sites/CasinoGCPBigQuerymigrationproject/_layouts/15/Doc.aspx?sourcedoc=%7B3115C166-E5FA-4425-AD64-137845D1F87A%7D&file=ajustements_migration.xlsx&action=default&mobileredirect=true&wdOrigin=TEAMS-ELECTRON.p2p.bim&wdExp=TEAMS-CONTROL&wdhostclicktime=1646902062373&cid=457653ce-6929-4a3d-9f89-c55c50ce623b))
## Migration des MVS
### Outils:
1. Générateur de dags (pour les MVS)
- cd /app/gcpdev/mainframe-dag-generator
2. commande pour générer un dag à partir d'un fichier source MVS:
- python3 jcl_analysis_to_dag.py --file \<chemin_vers_fichier_jcl_a_migrer\>
3. fichier jcl (les fichiers à convertir)
/app/odsdev/load/mvsp/\<TRIGRAMME\>/jcl/nom_fichier (le nom des fichiers à migrer commence par un $)
Exemple complet:
python3 jcl_analysis_to_dag.py --file /app/odsdev/load/mvsp/rev/jcl/\$REV0115
4. python3 jcl_extractor
- permet d'avoir sous forme textuelle les données extraites du fichier jcl.
- Lancer ce fichier pour le débug en mettant le chemin vers le fichier jcl en dur à la fin de jcl_extractor.py.
5. utilitaire création table/vue
Permet de générer les schémats de données (pour effectuer le transfert de strcture de tables de teradata vers BigQuery)
(**voir la partie sur le script extract_tables_names.py pour aider**)
faire:
cd /app/gcpdev/python3 translateSchema.py --u <teradata_user> --f <fichier_avec_nom_de_tables>
mettre dans le fichier txt dataset.nom_table. Une par lignes.
Cela va créer les vues et tables correspondantes. /!\ le script ne transfert pas les données.
exemple du fichier txt :
/app/gcpdev/tables.txt
Exemple de commande:
python3 translateSchema.py --u U880351 --f la_extr/tables.txt
6. utilitaire création d'extracteur historique
(dags hist_extr_xxx)
Pemret de générer les extracteur de données (pour effectuer le transfert de données de teradata vers BigQuery)
dans /app/gcpdev faire:
python3 lancerExtrPerl.py <fichier contenant les tables> --d "prj-datawh-poc" --k GOOGLE_APPLICATION_CREDENTIALS --e --c sa.json
--f <nom du projet (exemple: poc)>
Exemple:
python3 lancerExtrPerl.py la_extr/tables.txt --d "prj-datawh-poc" --k GOOGLE_APPLICATION_CREDENTIALS --e --c sa.json
Ancienne Version (encore utile si on souhaite migrer une table TMP):
Utiliser autoMakeTestFiles:
./autoMakeTestFiles.sh poc <Terdata_user> --p <Terdata Pasword> --u <Terdata User for the tpt> <Terdata passaword for the tpt> --f la_extr/tables.txt [--tmp (si on souhaite générer une table TMP)] --m TD2
Exemple:
./autoMakeTestFiles.sh poc UTPTRPS_DEV --p TPTRPSDEV --u "'UTPTRPS_DEV'" "'TPTRPSDEV'" --f la_extr/tables.txt --tmp --m TD2
Le fichier d'extraction est généré dans
/app/gcpdev/airflow-utils/migration-assets/conversion-assets/dag_generator/historic/out/
Il faut le déplacer dans /app/gcpdev/airflow/dags/
7. Utilisation de extract_tables_names pour obtenir le noms des tables dans un sql
Permet, à partir d'un fichier sql, d'écrire le nom des tables et/ou des vues dans un fichier.
dans /app/gcpdev faire:
python3 extract_tables_names.py --f <chemin_vers_le_fichier_sql/fichier_sql.sql> --t <True_si_on_veux_les_tables_tmp_False_sinon> --g <True_si_on_veux_les_vues_False_si_on_veux_les_tables_associées_aux_vues> --o la_extr/tables.txt
Exemple:
python3 extract_tables_names.py --f /data/gcpdev/DOCKER/airflow-sql/migration_rev2121/S010_BTQMAIN.sql --t False --g False --o la_extr/tables.txt
8. Extraction des steps et répartition du MVS/BQ
le script extract_steps.py permet d'écrire dans un fichier renseigné en entré la liste des étapes dans le JCL en entrée également.
python3 extract_steps.py --p \<Path\> --o <file out name> (si non renseigné, alors tout les fichiers du dossier seront utilisés) --m <write only if there are step on MVS> (paramètre booléen. Si il est Vrais, alors le flux ne sera écrite dans la sortie que si il y a au moins 1 étape sur MVS. Si il n'y a que du BigQuery, alors le flux ne sera pas écrit. Si il est Faux, alors quoi qu'il arrive, le flux sera présent dans la sortie.) --w <overwrite the out file> (paramèter booléen. Si True, supprime les contenue du fichier de sortie avant d'écrire dedans. Sinon, écrit dans ce fichier sans en effacer le contenu précédent)
Exemple:
python3 extract_steps.py --p /app/odsdev/load/mvsp/rev/jcl/ --o step_mvs_bq_distribution_rev --m True --w True
### Utilisation du script de transfert de données
./transfert.sh <teradata_user> <file.txt> [<password>]
- Readme d'aide pour différents problèmes courants qu'on rencontre
- Le script donne le nom des extracteurs générés (DAG Generated with name : 'extr_transfert_content_table_marketing_z84tpds' under 'out/' folder)
- le chercher dans airflow (peut prendre jusqu'à 5min pour qu'il s'actualise)
- aller sur la page du DAG pour le lancer petit triangle en haut a droite (play) → trigger DAG
- Si tout apprait en vert, la migration est terminée. Il faut alors mettre le MVS dans **DONE** s'il ne contiend pas de cobol et dans **STANDBY** s'il en contiend.
### Utilisation de MVS_TO_PROD
Ce script permet de modifier les DAG qui s ont généré par jcl_analysis_to_dag.py pour pouvoir être utiliser en prod.
En cas d'IDF manquant pour l'import/export de fichiers, ces fichiers apparaitrons en rouge dans la console.
Utilisation:
/app/gcpdev/python-switch-devtoprod>python3 --f migration_<JCL_name> --git
## Comment débugger un problème de taille de champs en un MLOAD/FASTLOAD/XPORT
S'il y a une erreur de type
File "/workspace/main.py", line 162, in fixedAndPackedToCsv
if val[-1] == "d" :
cela signifie que les valeurs de taille de champs ne sont pas bonnes.
Pour trouver les bonne taille, on peux utiliser le fichier **test_col_size.py** qui se trouve dans **/app/gcpdev/python-switch-devtoprod**.
Ce fichier s'utilise de la manière suivante:
python3 test_col_size.py --d path_file_in --i file_in --o file_out --l1 limit1
--l2 limit2 --f function_name --c col_size --p packed_infos --s separator
Certain de ces paramètres sont obligatoires et d'autres non. Pour plus de détail, voir la descrption des champs dans scripts.
Exemple d'utilisation:
python3 test_col_size.py --i RMMTDB1C --l2 20 --f fixedAndPackedToCsv --c '5, 5, 3, 1, 2, 7, 8, 8, 5, 5, 7, 7, 9, 9, 1, 1, 3, 3, 3, 5, 6, 3, 13, 9, 9, 9, 9, 9, 9, 9, 9, 3, 7, 7, 1, 5, 7, 7, 7, 8' --p '{8: 0, 9: 0, 10: 2, 11: 2, 12: 2, 13: 2, 22: 0, 23: 2, 24: 2, 25: 2, 26: 2, 27: 2, 28: 2, 29: 2, 30: 2, 32: 2, 33: 1, 35: 0, 36: 0, 37: 0, 38: 0}'
### Sources MVS:
Toutes les sources mvs sont dans le dossier /app/odsdev/load/mvsp/
Fichier jcl (les fichiers à convertir): /app/odsdev/load/mvsp/<TRIGRAMME>/jcl/nom_fichier
Les librairies sont dans *.REQTERA: /app/odsdev/load/mvsp/*.REQTERA
Les sources cobol sont dans /app/odsdev/load/mvsp/cobol
### Aide à la compréhension d'un fichier jcl : https://casino-ecommerce.atlassian.net/browse/BigQueryL-374?atlOrigin=eyJpIjoiYzE4YzM4YjU1MGUxNDYyNTk4Y2I4Zjg3ZDE2ODg1ZmEiLCJwIjoiaiJ9
## Débug du SQL d'un dag MVS
1. trouver quelle étape plante (c'est celle en rouge sur airflow)
2. chercher le fichier correspondant
- (/data/gcpdev/DOCKER/airflow-sql/<ton_dag>/<etape>.sql)
- On peut utiliser la console bigquery pour débug plus vite (https://console.cloud.google.com/bigquery?project=prj-datawh-poc)
### Problème de dataset
erreur "Syntax error: Expected end of input but got identifier "AGDOWN1" veut dire que le dataset AGDOWN1 n'existe pas. Il faut le créer à la main.
1. Aller sur bigquery
2. Ouvrir le pannel de gauche
3. Cliquer sur les 3 points verticaux à côté de prj-datawh-poc
4. Créer un ensemble de données
5. Rensiegner le nom de la table dans le champs **ID*
6. Préciser l'emplacement (Europe)
7. Créer l'ensemble de données
## Exemples et solutions de problèmes récurrents:
| Problèmes | Explications | Solutions |
|-----|-----------|-----|
| (DECIMAL(15,5)) | Cast en Teradata d'un résultat en décimal. | BigQuery concerve les types donc à supprimer |
|CAST(CAST(ADD_MONTHS(DATE,-1) AS FORMAT 'YYYY/MM') AS STRING(7)) | Cast d'un string en date avec 4 chiffre pour l'année, un slash et 2 chiffres pour le mois, puis retire 1 mois à la date courante |FORMAT_DATE('%Y/%m', DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH))|
|CAST(CAST(DTAPPRDR AS FORMAT 'YYYY/MM') AS STRING(7))| Cast un string en date |FORMAT_DATE('%Y/%m', DTAPPRDR) OU PARSE_DATE('%Y/%m', DTAPPRDR|
|CURRENT_DATE() (TIMESTAMP)| Déclaration d'un TIMESTAMP |TIMESTAMP(CURRENT_DATE())|
|COLLECT STATISTICS XXXXX;|| A commenter|
|TM1 (CDRESMAG1R,CDACVLOGR,DTMOISRDR,NAT,TAUX) | Création de l'alias TM1 avec les sous alias CDRESMAG1R,CDACVLOGR,DTMOISRDR,NAT,TAUX| retirer les sous alias et les mettre dans chaque colonne correspondante si besoin |
|Attempt string(3) but receive string(5)| Présence d'espace intuile à la fin des données| TRIM(string contenant les caractères à supprimer, "caractères à supprimer") |
|Bigquery ne trouve pas la table|| Vérifier que l'on est bien en Europe|
| Unrecognized name <nom_colonne>|lors d'un cast le nom de la colonne est perdu| rejouter l'alias après un cast CAST(NUFIC AS NUMERIC) AS NUFIC |
|((NUFIC + 1) (FORMAT '999999999') (STRING(09))) : Function call cannot be applied to this expression |Dans terradata on redéfinie le format lors d'une insertion, inutile dans BQ | CAST(LPAD(NUFIC, 9, 0) + 1 AS STRING)|
| Expected end of input but got keyword GROUP| Causé par le ORDER BY mal positioné| Mettre la clause ORDER BY à la fin de la requête|
|Column 1 in UNION ALL has incompatible types: STRUCT<NUFIC STRING>, STRING | Union impossible car types différent | Dans ce cas enlever le AS STRUCT (à faire vérifier en code review) |
|No matching signature for operator >= for argument types: DATE, INT64. | essaie de faire une comparaison entre un int et une date | caster en data, PARSE_DATE('%Y%m%d',"1160111") |
|RELEASE||à commenter|
|IDCAMS: IsADirectoryError: [Errno 21] Is a directory: '/opt/airflow/data/migration_rev0121/'| IDCAMS tente de supprimer un dossier| voir dans le fichier de migration (le python) si le delete ne contient que des '' pour cette étape. Si c'est le cas, il faut les supprimer|
| format variable vlpam| vlpam a un format spécial | PARSE_DATE("1%y%m%d",VLPAM)|
|subquery of type IN must have only one output column| impossible d'utiliser un IN avec plusieurs colonnes| ajouter un concat(<column1>,<column2>)|
|Problème ASCII (comp-3)|Codage des décimaux sur des demi octet mal décompressé, ce qui insert de mauvais charactères|utiliser fixedAndPacked|
|Dans un fichier, problème d'encoding avec des données ressemblants à ��������€|Problème d'encoding |Ajouter dans FixedToCsv le paramètre 'binary' : True. Attention, généralement, une fois cette erreur corrigée, problème de padding (à résoudre avec des LPAD).|
| Failed to parse input string "27/02/2023 22:15:12"] | Problème de parsing en datetime | parse_datetime('%d/%m/%Y %T',LBVLRVARETL)|
Caractère provoquant un décalage dans les csv lors de l'appel de la fonction fixedToCsv| certains caractères (comme les guillemets) à l'intérieur des données peuvent provoquer des décalages| Utiliser le paramètre **remove_char** de la fonction fixedAndPacked pour supprimer ce caractère (faire: 'remove_char' : "'")|
Charger un fichier de donnée généré dans un autre DAG| Certains DAGS ont besoins de fichiers plats générés par d'autres DAGS mais qui ne transit pas par MVS| Ajouter le paramètre **mvstobq** dans la fonction **'pull_last_mvs_file' : False** pour que le fichier soit charger depuis le bon dossier du Bucket|
### Supprimer des lignes dans un csv lors de sa génération.
Parfois des fichiers contiennent des lignes que l'on ne souhaite pas exporter en csv car celle-ci ont une strucutre différentes du reste.
Dans les fonctions FixedToCsv et FixedAndPackedToCsv, le paramètres drop_lines est une liste dans laquel on peux indiquer les ligne que l'on ne souhaite pas exporte.
file_to_csv_S010_MLOAD_0 = PythonOperator(
task_id='file_to_csv_S010_MLOAD_0',
provide_context=True,
python_callable=fixedAndPackedToCsv,
op_kwargs = {'file_in' : "PG00000.RGSFRAU.GS0XXXX(-1)", 'col_size' : [2, 16, 10, 5, 1, 7, 3, 4, 6, 19, 9, 4, 1, 4, 1, 3, 1, 104],
'packed_infos' : [], 'drop_lines' : [0], 'data_folder' : data_folder},
dag=dag)
### Fichier trop grand dans un bq load dans un mload
En cas de problème de type:
error message: The options set for reading CSV prevent BigQuery from splitting files to read in parallel, and at least one of the files is larger than the maximum allowed size when files cannot be split. Size is: 4817103964. Max allowed size is: 4294967296.
Ajouter à la step fixedToCsv le paramètre suivant:
'num_out_files': [nombre de split]
afin de générer un nombre voulu de fichiers csv à partir du fichier initial.
### Remplacer SYS_CALENDAR
En cas d'utilisation de la table SYS_CALENDAR (table qui ne doit pas migrer), ajouter le select suivant:
SELECT
CALENDAR_DATE,
EXTRACT(DAYOFWEEK FROM CALENDAR_DATE) DAY_OF_WEEK,
EXTRACT(WEEK FROM CALENDAR_DATE) WEEK_OF_CALENDAR
FROM
UNNEST( GENERATE_DATE_ARRAY(DATE('1900-01-01'), DATE('2100-12-31'), INTERVAL 1 DAY) ) AS CALENDAR_DATE
ou une table temporaire qui doit être drop après utilisation
(ou voir le DSU0010, S075BTQMAIN)
### Utiliser fixedAndPackedToCsv:
remplacer dans le dag fixedToCsv par fixedAndPackedToCsv
Ajouter le paramètre suivant:
'packed_infos' : [ {"pos" : position de la décimale 1 , "decimal" : nom de décimales }, {"pos" : position de la décimale 2 , "decimal" : nombre de décimales }, {"pos" : position de la décimal 3 , "decimal" : nombre de décimales }] (les positions doivents être comptées en partant de 0.). Pour connaître le nombre de décimales, regarder le fichier intial. (Dans le JCL, voir dans l'étape concernée le contenu du fichier appelé).
Exemple:
file_to_csv_S030_MLOAD_0 = PythonOperator(
task_id='file_to_csv_S030_MLOAD_0',
provide_context=True,
python_callable=fixedToCsv,
op_kwargs = {'file_in' : "PG00009.REVIVTE.GS1XXXX(-1)", 'col_size' : [5, 10, 7, 3, 9, 9, 15], 'data_folder' : data_folder},
dag=dag)
↓
file_to_csv_S030_MLOAD_0 = PythonOperator(
task_id='file_to_csv_S030_MLOAD_0',
provide_context=True,
python_callable=fixedAndPackedToCsv,
op_kwargs = {'file_in' : "PG00009.REVIVTE.GS1XXXX(-1)", 'col_size' : [5, 10, 7, 3, 9, 9, 15],
'packed_infos' : [ {"pos" : 4 , "decimal" : 0 }, {"pos" : 5 , "decimal" : 2 }], 'data_folder' : data_folder},
dag=dag)
### Faire un Upsert (update and insert):
voir le BTQMAIN S060 du flux REV3152 en exemple
### Faire un CAST
Exemple
CASE WHEN TSOBDESCFAM IS NULL THEN '?'
ELSE TSOBDESCFAM AS END STRING(50) ,
=>
CASE WHEN CAST(TSOBDESCFAM AS STRING(50)) IS NULL THEN '?'
ELSE CAST(TSOBDESCFAM AS STRING(50)) END ,
## Que faire en cas de fichiers manquants:
### Fichier de génération manquant :
demander à Francois Gully des informations sur le fichier si celui-ci est manquant.
placer le fichier dans /data/gcpdev/DOCKER/airfolow-data/migration-jcl-shared
renommer le fichier (en fonction du dag )
Exemple :
PG00007.Z84FECL.GS0XXXX.G8089V00(-1)
rename => PG00007.Z84FECL.GS00000
PG00007.Z84FECL.GS00001
### Type de fichiers
Regarder la première lettre de la partie avant XXXX
Si cette lettre est un I, alors le fichiers est créé dans un flux et il est utilisé et détruit dans d'autre flux. En cas d'abscence, demander à François le flux de génération et si ce flux n'est pas utils sur Terddata, déposer le fichier dans le dossier voulu.
Exemple:
PG00009.REVTPRD.IS0XXXX crée dans le flux REV1000 et utilisé et détruit dans le flux REV1025
Si cette lettre est un J, alors le fichiers est créé, utilisé et détruit dans un seul flux. Si il est manquant, vérifier s'il n'y a pas un XPORT dans un BTQMAIN. Si c'est le cas, changer le BTQMAIN en XPORT (prendre en exemple un flux contenant des XPORT, comme owm0050).
Exemple:
PG00709.REVTCON.JS0XXXX créé, utilisé et détruit dans le flux REV1200
Si cette lettre est un G (fichier de génération), demander le fichier à François.
Exemple:
PG00007.Z84FECL.GS0XXXX
# Notes
**Lorsqu'un fichier sql est long, il peut contenir de nombreuses tables. Il faut vérifier si chacune des tables est alimenté. Un moyen rapide est de mettre le nom de chaque table dans un fichier et appeler l'extracteur de schémat et de données. Si les tables sont déjà sur Bigquery et quelles sont déjà alimentées, alors il ne se passera rien.**
# Logiciels utiles :
Teams → daily
Slack → communication
Notepad + NppFTP pour l'édition de fichiers sur serveur
Mremote pour connexion serveur
Citrix pour le VPN pour le télétravail
Teradata Studio (voir avec Georges pour récupérer)
user = U88XXXX
user_exp = U88XXXX_exp
bigquery → user_exp
git → user
Sauvegarde info TPT
TPT (fini):
ODC_CDEDETCDEjour: faire la comparaison des tables puis passer (demander à Flo)
python3 testBQvsTD.py --t GLDOWN1_DEVMIG.ODC_CDEDETCDE --e /app/gcpdev/airflow/dags/hist_extr_general_gldown1_devmig_cdedetcde.py --c all --usr airflow --pwd "gcpdev01;" --r TEST_LOUIS --d testlouis.log
demander à flo quoi faire quand on a des données dans la table générée
voir avec Sacha ou Guillaume pour le problème de comparaison TD/BQ (voir table dans TEST_LOUIS).
hist_extr_general_gldown1_devmig_cdedetcde.py
hist_extr_general_gldown1_devmig_odc_cdedetcde.py
3590