Table pour le calcul d'indicateurs hebdo des candidats en recherche active #347
Conversation
|
à discuter :
Romain je te mets en review dès maintenant car tu étais intéressé, mais j'aimerais bien qu'on en discute tous ensemble au retour de Yannick ! |
There was a problem hiding this comment.
Je met mes réflexions avant de les oublier 😁.
tl;dr : A mon sens c'est un questionnement philosophique qu'il faut avoir, une fois celui-ci répondu la technique sera évidente et suivra tout naturellement.
vue mensuelle car une vue hebdo serait trop grosse (de 1M à 4M de lignes environ)
La granularité dépend du besoin, si mensuel est suffisant alors mensuel sinon plus fin et on optimisera [1] si nécessaire : premature optimization is the root of all evil.
Et vu qu'on pourra changer de granularité quand on veux car la donnée est gardée dans le snapshot il n'y a pas trop de problème à commencer par mensuel pour changer ensuite.
pourquoi est-ce qu'on backup toutes les colonnes dans le snapshot des candidats en recherche active ? on pourrait ne garder que les colonnes qui changent et l'id du candidat (gain de place) et passer par une jointure ensuite pour récupérer les caractéristiques du candidat
Là y a 2 écoles, les 2 sont valides et dépendent de ce que vous envisager d'avoir besoin :
- snapshot de toute les données car on veux pouvoir faire un nouvel indicateur dans x temps et donc profiter de tout l'historique. => Ça prend (beaucoup) plus de place mais en contrepartie ça permet de tout faire n'importe quand.
- snapshot uniquement les colonnes avec la donnée qui nous intéresse. => Moins de place, et besoin de temps pour créer l'historique après l'ajout d'un nouvel indicateur
ces tables sont déjà grandes et vont viiiiite grandir, il faut qu'on voit ensemble ce qu'on met en place pour économiser de la place avant que tout explose.
Même type de réponse :), quel est le besoin actuel et anticipé ?
Si on veux tout l'historique alors pas le choix, si en fait on veux que les X derniers temps alors on peux limiter la donnée utilisée, soit depuis les sources soit de notre coté.
[1] Le nombre de ligne est assez peu important et de toute manière on s'attend a avoir de grosse tables, par contre faudra effectivement avoir une discipline de ne prendre que ce dont on aurais besoin et d'utiliser des types de colonnes appropriées.
| @@ -0,0 +1,15 @@ | |||
| select | |||
| {{ pilo_star(ref('candidats_recherche_active_snapshot'), except=["dbt_valid_from", "dbt_valid_to"]) }}, | |||
There was a problem hiding this comment.
De ce que je comprend de la doc [1], il y a 4 champs ajouté par DBT
| {{ pilo_star(ref('candidats_recherche_active_snapshot'), except=["dbt_valid_from", "dbt_valid_to"]) }}, | |
| {{ pilo_star(ref('candidats_recherche_active_snapshot'), except=["dbt_valid_from", "dbt_valid_to", "dbt_scd_id", "dbt_updated_at"]) }}, |
[1] https://docs.getdbt.com/docs/build/snapshots#snapshot-meta-fields
There was a problem hiding this comment.
A confirmer mais je pense que ce modèle pourrais être incrémental, ça permettrais d'avoir un temps d’exécution stable plutôt que croissant et éviterais de recalculer le passé inutilement vu qu'il ne peux pas changer.
laurinehu
force-pushed
the
laurinehu/file_active_histo
branch
from
f75376a
to
5b5def0
Compare
laurinehu
force-pushed
the
laurinehu/file_active_histo
branch
from
c2225f0
to
154742a
Compare
| @@ -208,3 +208,6 @@ models: | |||
| - name: candidatures_inconnues_employeurs_orienteurs | |||
| description: > | |||
| Table permettant le suivi des SIAE qui ont orienté un candidat n'ayant jamais postulé chez elles, vers d'autres SIAE. | |||
| - name: candidats_recherche_active_histo | |||
There was a problem hiding this comment.
Pourquoi c dans daily pour les properties et weekly pour le script ?
There was a problem hiding this comment.
oopsie erreur, je le bouge dans weekly
| else date_trunc('week', current_date) | ||
| end, | ||
| interval '1 week' | ||
| ) as week_series |
There was a problem hiding this comment.
On est d'accord que tu veux bien du hebdo (le titre de ta PR dit mensuel) ?
| -- we only update rows that have changed | ||
| -- the previous state is no longer current if : | ||
| -- 1: dbt_valid_from is bigger than last week date (this line is the new state) | ||
| -- 2: dbt_valid_to is bigger than last week date (this line is the last state that is now finished) | ||
| where dbt_valid_from > date_trunc('week', current_date) - interval '1 week' | ||
| or dbt_valid_to > date_trunc('week', current_date) - interval '1 week' |
There was a problem hiding this comment.
J'ai pas testé donc je vais peut-être dire de la merde mais je pense qu'on va avoir des problèmes :).
Mise à jour des lignes existantes
Si tu veux des UPDATE il faut donner une unique key (un truc du genre ["id", "semaine_valide"]) sinon les lignes qui se ferment vont être dupliquée, on aura celles enregistrées alors qu'elle était ouverte puis celle au moment de la fermeture, et d'ailleurs je pense que les lignes des lignes ouvertes vont aussi être dupliquée mais à chaque lancement pour celles-ci, et je me demande ce qui va se passer quand on a plusieurs lignes pour la même semaine 🤔.
Clause incrémentale
Il faut plutôt utiliser la dernière valeur connue dans la table que current_date, sinon on va avoir des trucs chelou en fonction de quand (et si) on lance le modèle. En gros ici tu supposes que le modèle va être lancer exactement 1 fois toutes les semaines au même moment, ce qui ne sera jamais vraiment le cas.
Et pour un peu les mêmes raisons il faut sûrement plutôt utiliser >= que > pour ne pas rater les lignes qui se ferment et s'ouvrent pendant une semaine déjà connue.
laurinehu
changed the title
Co-authored-by: Romain Sébille <20045330+rsebille@users.noreply.github.com>
Co-authored-by: Romain Sébille <20045330+rsebille@users.noreply.github.com>
**Carte Notion : **
Pourquoi ?
Pour permettre l'historisation des indicateurs de candidats en recherche active.
Checks