Importation des statistiques sur les demandeurs d'emploi de l'API France Travail

[calummackervoy]

**Carte Notion : ** https://www.notion.so/gip-inclusion/API-FT-Se-brancher-l-API-demandeurs-d-emploi-1765f321b60480e68694edeee2d710f3

Pourquoi ?

Hebdomanaire, on recherche des nouvelles depuis l'API FT et on stocke les nouvelles données disponibles dans un table SQL, organisé par caracteristique, activité, période et territoire.

Checks

• J'ai lancé le modèle ou seed sur un dump local (si pertinent)
• J'ai ajouté des tests à mon code Python, ou des assertions DBT sur le modèle SQL
• J'ai documenté ce modèle voire certains de ses champs (usage métier, tableau de bord, etc)

[calummackervoy]

Je pense qu'il est au bon endroit, car c'est la configuration par rapport au structure du API

Du coup on reçoit les données sous la forme :

{
    //  Columns defined in the main body of the request
    "codeTypeTerritoire": "DEP",
    // Columns defined on each characteristic (row) of the table
    "listeValeursParPeriode": [
         {
             "codeCaract": "AGE1",
             ...
         },
         {
             "codeCaract": "AGE1",
             ...
         }
}

Devrais-je changer la structure ici, ou eteindre le commentaire pour que c'est plus maintainable ?

[calummackervoy]

Ça vaut le coup d’ajouter une SELECT DISTINCT “codePeriode” FROM france_travail.demandeurs_a; afin de signaler s’il y a un trou ? (par example si un jour FT téléverse plusieurs trimestres au même temps)

[rsebille]

Oui, car ça permet aussi de gérer le cas où "the DAG has run successfully since the last quarter" est faux :).

[calummackervoy]

Ça fait une différence 😁

[calummackervoy]

Ces informations sont utiles dans le fichier dbt/models/_sources.yml?

[rsebille]

De mémoire c'est pour dbt doc, donc oui c'est utile mais après ce n'est peut-être pas utilisé 😁

[rsebille]

Je n'ai pas lancé le DAG pour le moment puisque on n'a pas de credentials partagés, mais j'ai bien vu la note dans le ticket notion donc je pense qu'on va créer un tech.pilotage@, ça devrais suffire ou il faut autre chose à ton avis ?

[rsebille]

Je pense qu'ici tu pourrais faire une dataclass car automatiquement tu auras quelque chose d'utilisable pour les log sans avoir à le faire toi même avec %s (%s) :

In [17]: @dataclasses.dataclass
    ...: class Territory:
    ...:     type: str
    ...:     code: str
    ...: 

In [18]: str(Territory("DEP", "75"))
Out[18]: "Territory(type='DEP', code='75')"

[rsebille]

Sauf si il y a une raison précise c'est mieux de garder les champs associés côte à côte :

Suggested change

	codeCaract = Column(String, primary_key=True)
	codeNomenclature = Column(String, primary_key=True)
	codePeriode = Column(String, primary_key=True)
	codeTerritoire = Column(String, primary_key=True)
	codeTypeCaract = Column(String, primary_key=True)
	codeTypeTerritoire = Column(String, primary_key=True)
	codeCaract = Column(String, primary_key=True)
	codeTypeCaract = Column(String, primary_key=True)
	codeNomenclature = Column(String, primary_key=True)
	codePeriode = Column(String, primary_key=True)
	codeTerritoire = Column(String, primary_key=True)
	codeTypeTerritoire = Column(String, primary_key=True)

Et pour tout ce qui est clés primaire, clés unique, ou indexe c'est toujours bien de lister les champs dans l'ordre où on va drill down [1], ce qui si j'ai bien compris devrais donner quelque chose comme ceci :

Suggested change

	codeCaract = Column(String, primary_key=True)
	codeNomenclature = Column(String, primary_key=True)
	codePeriode = Column(String, primary_key=True)
	codeTerritoire = Column(String, primary_key=True)
	codeTypeCaract = Column(String, primary_key=True)
	codeTypeTerritoire = Column(String, primary_key=True)
	codeNomenclature = Column(String, primary_key=True)
	codeTypeCaract = Column(String, primary_key=True)
	codeCaract = Column(String, primary_key=True)
	codeTypeTerritoire = Column(String, primary_key=True)
	codeTerritoire = Column(String, primary_key=True)
	codePeriode = Column(String, primary_key=True)

[1] https://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys

[calummackervoy]

C'est une bonne astuce, merci pour le lien

[calummackervoy]

Côté performance je note que chaque fois on lance le DAG, chaque règle va normalement avoir des conflits avec un autre règle 5/6 des colonnes principales. C'est donc garanti qu'on va traverser l'indice entière

L'alternatif pourrait être de créer un nouveau colonne, id non-composite, qui concat ces champs dans un valuer

[rsebille]

De mémoire c'est pour dbt doc, donc oui c'est utile mais après ce n'est peut-être pas utilisé 😁

[calummackervoy]

@rsebille tu peux trouver les creds ici : https://github.com/gip-inclusion/itou-secrets/pull/127. Je vais créer un compte partagé et les remplacer