Audit de la santé des vues du data warehouse
Cette skill produit un audit à l'échelle du projet des vues matérialisées (requêtes sauvegardées matérialisées) dans le data warehouse — lesquelles échouent et lesquelles sont matérialisées mais inutilisées. Utilisez-la quand l'utilisateur veut un résumé de la santé des vues, pas une analyse approfondie d'une défaillance.
Le même endpoint sous-jacent (data-warehouse-data-health-issues-retrieve) signale également les problèmes de source, de synchronisation, d'export par lot et de transformation. La santé des sources et des synchronisations est couverte par auditing-warehouse-source-health. Les destinations (exports par lot) et les transformations sont gérées par d'autres produits — signalez-les s'ils apparaissent, mais orientez-les vers l'équipe pertinente plutôt que de les diagnostiquer ici.
Quand utiliser cette skill
- « Lesquelles de mes vues sont cassées ? » / « Pourquoi cette vue matérialisée échoue-t-elle ? »
- « Certaines de mes vues matérialisées gaspillent-elles du compute ? »
- Réviser la santé des vues après une modification HogQL ou de schéma
- Les tableaux de bord appuyés par des vues matérialisées sont obsolètes ou en erreur
Outils disponibles
| Outil | Objectif |
|---|---|
data-warehouse-data-health-issues-retrieve |
Une seule requête : tous les éléments défaillants/dégradés du pipeline entier |
view-list |
Toutes les requêtes sauvegardées / vues matérialisées avec statut et latest_error |
view-run-history |
Historique d'exécution d'une vue matérialisée spécifique |
Filtrez les résultats de data-health-issues sur le type materialized_view pour cet audit. Utilisez view-list quand vous avez besoin de plus que le résumé de défaillances actives (vues non défaillantes, flags de matérialisation, infos de dernière requête) et view-run-history pour voir l'historique d'exécution d'une vue spécifique.
Qu'est-ce qui compte comme un « problème » de vue
Depuis l'endpoint data-health, cet audit s'intéresse à l'une des cinq catégories :
type |
Déclencheur | Urgence typique |
|---|---|---|
materialized_view |
DataWarehouseSavedQuery.is_materialized=true, status=Failed |
Moyen |
Chaque entrée inclut id, name, type, status, error, failed_at, et url.
Les autres catégories que l'endpoint retourne sont hors de portée pour cette skill :
source/external_data_sync→auditing-warehouse-source-healthdestination(export par lot) → gérée par le produit exports par lot / pipelines de donnéestransformation(HogFunction) → gérée par le côté CDP / ingestion
Notez que l'endpoint data-health signale uniquement les défaillances actives. Pour les vues qu'il ne signale pas :
- Vues non matérialisées avec erreurs (seules les vues matérialisées sont signalées)
- Vues matérialisées saines mais inutilisées (coûtant du compute à chaque exécution) — voir Étape 4
Flux de travail
Étape 1 — Extraction en une seule requête
Appelez data-warehouse-data-health-issues-retrieve et conservez les entrées materialized_view.
S'il n'y a pas de problèmes de vues, dites à l'utilisateur que ses vues matérialisées sont saines et arrêtez-vous. N'inventez pas de problèmes.
Étape 2 — Triage des défaillances
Les défaillances de vues matérialisées sont généralement indépendantes des sources — une défaillance de vue est un problème HogQL ou de données dans la vue elle-même (erreur de syntaxe, référence de table manquante, incompatibilité de type). Pour chaque vue défaillante, signalez le error et pointez vers la requête fautive. Utilisez view-run-history si l'utilisateur veut l'historique de défaillance.
Étape 3 — Présenter l'audit
Rendez un rapport hiérarchisé. Ne videz pas le JSON brut — humanisable :
## Santé des vues matérialisées — 2 problèmes
### 🟠 Vues matérialisées (2)
- monthly_revenue — vue échouée (erreur de syntaxe en HogQL : 'FORM' au lieu de 'FROM')
- active_users_30d — vue échouée (référence de table manquante)
Les deux sont des problèmes HogQL dans les définitions de vues — indépendants de vos sources. Vous voulez que j'ouvre l'une d'elles ?Étape 4 — Aller au-delà des défaillances actives (si demandé)
Vues matérialisées inutilisées :
Appelez view-list. Les vues matérialisées coûtent du stockage et du compute à chaque exécution. Si certaines sont marquées comme matérialisées mais n'ont pas été requêtées récemment, signalez-les comme candidates au nettoyage (les données sont disponibles via view-list ; dématerialisez via view-unmaterialize).
N'exécutez cette vérification supplémentaire que si l'utilisateur demande explicitement un audit plus large.
Étape 5 — Proposer l'étape suivante
Terminez l'audit par une transition claire — par exemple « Vous voulez que j'ouvre monthly_revenue et que je corrige le HogQL ? » N'appliquez jamais les corrections de manière autonome depuis le flux d'audit ; confirmez explicitement avant de modifier ou dématerialiser une vue.
Notes importantes
- L'audit est en lecture seule. N'appelez jamais d'outils destructifs (par ex.
view-unmaterialize,view-delete) depuis le flux d'audit sans confirmation explicite. - Vide = sain. Ne rembourrez pas un audit vide avec des problèmes hypothétiques. « Aucun problème de vue détecté » est une bonne réponse.
- Les défaillances de vues sont généralement autonomes. Contrairement aux défaillances de sources, une vue matérialisée défaillante crée rarement une cascade — c'est un problème de requête dans cette vue. N'impliquez pas une panne plus large.
- Les sources, synchronisations, destinations et transformations sont hors de portée ici. Elles partagent l'endpoint data-health mais appartiennent à d'autres audits/produits — orientez, ne diagnostiquez pas.