-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(pipeline): refactor geocoding orchestration #270
Conversation
1b84641
to
619c250
Compare
pipeline/dags/main.py
Outdated
"source:*", | ||
"path:models/staging/sources/**/*.sql", | ||
"path:models/intermediate/sources/**/*.sql", | ||
"path:models/intermediate/*.sql", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
je me demande si c'est pas le moment de les mettres dans un dossier union
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(je parle des fichiers à la racine du dossier intermediate
car il y a en gors la famille des "union" qui sont de toutes façons plus ou moins tous à générer en meme temps, et le plausible_emails
qui n'a pas grand chose à voir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
j'ai bien envie de simplifier :
int__union_services
=>int__services
- etc
et clarifier enhanced
qui est fourre-tout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je te rejoins, c'est peut etre la bonne PR pour mettre un troisième commit de renommage tout simple, avant de déléguer l'orchestration à cosmos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm je disais que c'est pe mieux de voir ça dans une PR distincte. Besoin de réfléchir au découpage des étapes de modélisation (union/validation/géocodages/etc.). Si je fais ça maintenant, ça sera très probablement pas satisfaisant.
pipeline/dbt/models/intermediate/sources/dora/_dora__models.yml
Outdated
Show resolved
Hide resolved
pipeline/dbt/models/intermediate/sources/dora/int_dora__errors.sql
Outdated
Show resolved
Hide resolved
619c250
to
c6c9937
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK pour le premier commit, avec quues remarques mineures et j'aimerais bcp voir un unit test sur le modèle incrémental.
J'aurais perso ajouté quelque chose pour éviter que le test ban_api
ne soit lancé en local par défaut (surtout sur un repo public) mais à toi de voir, surement que on peut s'en fiche pour l'instant.
Et j'aurais tellement aimé voir partir l'étape intermédiaire de gestion des adresses en batch (et du coup le faire source par source pendant leurs traitements) mais bon, je suppose que ce sera dans une autre PR ou avec cosmos.
4b0c4bc
to
c3847dd
Compare
6a17d79
to
dc637ca
Compare
dc637ca
to
84826d4
Compare
19986d3
to
9b4c059
Compare
9b4c059
to
b17d307
Compare
b17d307
to
c08ce6c
Compare
c08ce6c
to
f7d8e95
Compare
48ce257
to
1e9f0f3
Compare
j'ai pris en compte tes retours @vperron. C'est fonctionnel en staging |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nits de curiosité. J'adore le cleanup du second commit en particulier <3
@@ -9,6 +9,10 @@ Another way would be to use the `on-run-start` hook, but it does not play nicely | |||
|
|||
{% set sql %} | |||
|
|||
CREATE SCHEMA IF NOT EXISTS processings; | |||
|
|||
{{ udf__geocode() }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tout petit nit mais pourquoi ne pas garder la convention create_udf__xxx
? Ou inversement changer les suivantes ?
Je sais que tu fais rarement quelque chose au hasard donc ^^ curiosité
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oui je vais nettoyer les suivantes, dans les prochains jours. J'avais peur de tirer un fil et de perdre de vue le but de la PR 😅
- name: code_insee | ||
data_tests: | ||
- dbt_utils.not_empty_string | ||
- name: latitude |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ça donnerait envie d'introduire https://github.com/calogica/dbt-expectations#expect_column_values_to_be_between ^^ peut etre sur une autre PR ? Je fais un ticket, tu mets un TODO ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
partant pour explorer ça sur une autre PR
(je skip le TODO, pcq y'a vmt plein d'endroits où on pourrait en mettre)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sur la stratégie de tests, j'avais cette référence intéressante en tête : https://www.datafold.com/blog/7-dbt-testing-best-practices?#2-add-essential-dbt-tests
jusqu'à présent je me suis concentré sur les tests simples : not_null
, relationship
, dbt_utils.not_constant
, dbt_utils.not_empty_string
, plus rarement accepted_values
et très rarement un check avec une expression.
Je trouve que c'était utile sans surchargé. Dans l'idéal si on resserre, il faudrait qu'on se fixe une stratégie claire, pcq j'ai peur qu'on puisse aller très loin, avoir plusieurs façons de faire dans la codebase. Ce qui finira par devenir ingérable 😅
data_tests: | ||
- not_null: | ||
config: | ||
severity: warn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meme remarque pour une valeur entre 0 et 1 avec dbt-expectations ?
curiosité : Et donc le score peut effectivement etre NULL parfois ? Dans quels cas ?
The trick is to leverage plpython to do the geocoding inside the database. Doing so, geocoding can now be modelled as a dbt model and orchestrate as such. The geocoding implementation has been moved to an actual package maintained next to the datawarehouse image. The plpython udf simply wraps the call. Is it worth it ? * it heavely simplifies the flow and set clearer concerns between airflow and dbt. Dbt does the transformation, airflow orchestrate it. * less error prone since we do not have to pull data from the db and map it to python ourselves. * we can even leverage dbt to to the geocoding incrementally on inputs that have not been seen before. This will drastically reduce our carbon footprint... There are a few enhancements we would probably want : * obviously clean up * define a macro with the geocoding model that can be used for all sources * re-do geocodings for relatively old inputs * do the geocoding per source ?
1e9f0f3
to
d8b3f5a
Compare
J'ai modifié pour permettre le regéocodage des adresses qui ont eu un résultat nul + un unit_test case |
On a oublié potentiellement un aspect, qui serait de faire des full refresh du geocodage une fois tous les ... 12 mois par exemple. Mais bon je suis sur que d'ici un an on y aura retouché, donc... L'idée est de compter sur la BAN pour devenir plus complète / meilleure dans ses recherches et que potentiellement sa résolution devient plus précise (faisant potentiellement passer des geocodages enregistrés mais avec un score de, par exemple, 0.3 en un résultat avec un meilleur score et une meilleure cohérence) |
Ajout d'une fonction plpython qui permet de gérer le géocodage avec dbt directement en db. Création d'un model dédié pour géocoder de manière incrémentale. Plus de détails en commentaires de commit