Retablir l'aggregation par mois sur une longue période

[odelcroi]

la materialized_view user_daily_visits_by_month_18m a été desactivée car elle est trop grosse pour être calculée par la bdd (8Go)

cf #73

Pourquoi la rétablir?

• biz : calculer la rétention sur des périodes supérieur à une année (user_daily_visits_by_month_1y)
• tek : progresser sur l'analyse de large volume de données.

Pistes :

1. Optimiser la mat view

1. Utilisation de l'option CONCURRENTLY
2. Diviser le rafraîchissement en lots
3. Exécuter un VACUUM ANALYZE

2. ETL externe

mettre en place un outil d'ETL plus flexible et rapide que les materialized_view (batch, calcul distribuée) qui pourrait être réutilisé sur tout le pipeline Tchap (depuis les tables de prod jusque metabase) En python (via openai) avec des volumes de données d'environ 8 Go, voici quelques suggestions selon tes besoins :

• Pandas/Dask ou Modin si tu veux rester proche de l’écosystème Pandas.
• PySpark si tu cherches une solution distribuée et robuste pour les très gros volumes.
• Vaex ou Polars pour une alternative à Pandas avec une gestion plus efficace de la mémoire.
• SQLAlchemy ou BlazingSQL si tu traites principalement des données relationnelles (sur CPU ou GPU).

-Pandas/Dask semble facile à mettre en oeuvre dans un environnement scalingo/python

• PySpark : lourd à deployer dans scalingo car basé sur spark/hadoop (java)
• Vaex ou Polars : pas d'avis mais pas panda
• SQLAlchemy ou BlazingSQL : pas d'avis

[odelcroi]

Solution alternative :

• crééer une table "lite" avec le minimum d'info
• l'alimenter avec des scripts incrémentaux

[odelcroi]

fixed by https://github.com/tchapgouv/tchap-stats/commit/6fa246e9344156b71c86359359e4cef6a9a10a60

https://stats.tchap.incubateur.net/question/619-nouvelle-table-users-actifs