🔗 DAG Airflow pour crawler les URLs

[maxcorbeau]

🔗 DAG Airflow pour crawler les URLs

Carte Notion : Vérification & corrections des URLs: DAG Airflow

🗺️ contexte: 12K URLs uniques pour le champ acteur.url, bcp d'erreurs constatées, trop de travail de vérifier à la main

💡 quoi: un DAG airflow

🎯 pourquoi: automatiser les vérfications & suggestions d'URL

🤔 comment:

• crawl_urls_read_urls_from_db_task = récupère URLs de la DB, en groupant par URL et concaténant les acteurs
• crawl_urls_check_syntax_task = éssaye de détecter/résoudre les problèmes de syntax (ex: nourl -> erreur, monsite.com -> essayer https://monsite.com)
• crawl_urls_check_dns_task = éssaye de résoudre le nom de domaine des URLs
• crawl_urls_check_crawl_task = éssaye de crawler les URLs. 🔴 Bcp faux positifs ici, on garde que les cohortes fiables, voir plus d'infos ici
• crawl_urls_suggest_syntax_fail_task = cohorte de suggestions 🔴 Syntaxe invalide -> mise à vide
• crawl_urls_suggest_dns_fail_task = cohorte de suggestions 🔴 Domaine inaccessible -> mise à vide
• crawl_urls_suggest_crawl_diff_https_task = cohorte de suggestions 🟡 URL différente HTTPs dispo -> HTTPs proposée
• crawl_urls_suggest_crawl_diff_other_task = cohorte de suggestions 🟡 URL différente (et pas juste HTTPs) -> nouvelle proposée

🆕 Nouveautés techniques

🧱 constantes via dataclasses

• Voir dags/crawl/config/*: pour avoir autocompletion IDE, 1 seul import par type de constantes (au lieu de 1 par constante)

💬 XCOM helper

• Voir dags/crawl/config/xcoms.py avec un utilitaire pour faire des pulls plus fiables avec du debug automatique

🖼️ Exemple

crawl_urls_read_from_db_task

crawl_urls_check_syntax_task

On voit des URLs qu'on arrive à nettoyer (ex: thttps://www.ressourceriemalakoff.org/ -> la même sans le t au début) et d'autres totallement irrécupérables (ex: NA, https://-/)

Django: cohorte

⚠️ Django: suggestions

Dev

⚠️ Preprod

Là pour une raison que j'ignore, ayant bien fait le déploiement en prepod, Django n'arrive pas à récupérer le template de suggestions

📆 A faire dans une prochaine PR

• Ping avant le crawling: on pourrait essayer de pinger les domaines pour s'arrurer qu'ils répondent, ceci devrait être bcp moins coûteux que le crawling pour identifier les sites qui ne répondent même plus (ex: serveur down, peut être que le problème est uniquement temporaire, ceci pourrait servir à notifier Christian sans faire de suggestions de changement)
• Amélioration du crawling avant de réintroduire crawl_urls_check_urls_task, voir discussion

[fabienheureux]

J'ai parcouru rapidement la PR mais il est tard et mon cerveau embrumé.
Question cependant : est-ce qu'on conserve les URLs pour de futurs crawl ?

J'imagine une situation où un site down au moment du crawl occasionnera un écrasement de la valeur, ce qui serait dommage.
Peut-on imaginer par exemple :

• conserver l'url originale
• stocker le nombre d'échecs
• après n run du dag occasionnant autant d'échecs, on la remplace par une valeur vide ?

En fait la question c'est : est-ce qu'on reprend la valeur de la dernière révision ou l'url originale lors des crawls successifs ?

[maxcorbeau]

Question cependant : est-ce qu'on conserve les URLs pour de futurs crawl ?

Oui à terme on devrait. Beaucoup de limitations actuellement:

• Pas de navigateur digne de se nom (requests au lieu de playwright, puppeteer ou autre)
• Pas de proxy pour éviter de se faire banner quand on crawl plusieurs pages d'un même site (ex: Leroy Merlin)
• Pas de résolution des chaines de certificats SSL
• Pas d'historique de crawl pour gérer les false positives

Gérer une infrastructure de crawling peut devenir très complexe, et donc il faudra qu'on se pose la question de savoir si on veut créer ou louer (il y a bcp de SaaS qui offrent ce genre de services).

On a commencé à tester avec @chrischarousset et on pense que pour la v1 on va même pas faire de crawling et plutôt s'orienter vers la résolution DNS pour identifier les sites qui sont à priori complètement mort.