Quelle part des tables d'un entrepôt de données n'est jamais lue après avoir été écrite, et comment les équipes l'ont-elles découvert ?

Question ouverte

Chaque pipeline construit ajoute des tables ; peu de pipelines sont supprimés lorsque le rapport qu'ils alimentaient est retiré. Les données permettant de répondre à « est-ce que quelqu'un lit ceci ? » existent dans la plupart des moteurs : la documentation de PostgreSQL décrit pg_stat_all_tables avec les compteurs seq_scan et idx_scan et, dans les versions actuelles, les horodatages last_seq_scan et last_idx_scan par table, et les produits d'entrepôt de données conservent des historiques de requêtes qui peuvent être joints aux noms de table. Pourtant, le wiki ne dispose d'aucune trace de ce que les équipes ont trouvé lorsqu'elles ont réellement mené cette analyse : quelle part des tables n'avait pas été lue depuis un mois, un trimestre ou un an ; si les tables non lues se regroupaient par ancienneté, par propriétaire, par couche de pipeline (brut, préparation, marts) ou par la personne qui est partie ; et quel volume de stockage et de temps d'exécution de pipeline elles consommaient. Il y a aussi un problème de mesure : une table lue une fois par an par un audit ou un rapport de fin d'année paraît non lue pendant onze mois, et les lectures effectuées par le pipeline lui-même (de la préparation vers les marts) doivent être séparées des lectures par des personnes et des applications. Quelles analyses ont traité cela, et comment ? Enfin, qu'ont fait les équipes de la réponse : supprimer, archiver, arrêter le pipeline mais conserver les données, ou marquer la table comme obsolète et attendre les réclamations, et combien de réclamations sont arrivées ?

Ce qu'une réponse utile contient

Le moteur et la façon dont les lectures ont été attribuées (vues statistiques, analyse de journal de requêtes, outillage de lignage), et la fenêtre d'observation. Le nombre de tables, la part non lue dans la fenêtre, et la répartition par couche, ancienneté et propriétaire lorsque disponible. La façon dont les lectures internes au pipeline ont été exclues et dont les lecteurs légitimes mais rares ont été identifiés. Le stockage et le calcul attribués aux tables non lues, si mesurés, avec la méthode. L'action entreprise, le délai de préavis donné, le nombre d'objections reçues et le nombre de tables restaurées. Si l'analyse a été répétée plus tard et si la part a changé, et si une règle (par exemple, une table sans lecture externe pendant une période définie est archivée) a été adoptée en conséquence. Les constats ponctuels sont bienvenus si la fenêtre et les règles d'exclusion sont énoncées.