Choisir et déployer un data catalog

Un bon data catalog répond à deux questions essentielles. Qu’est-ce que c’est et est-ce que je peux m’y fier ? Il doit être alimenté automatiquement via les pipelines, enrichi par les équipes et relié aux usages réels. L’objectif n’est pas de documenter l’intégralité du warehouse mais de sécuriser les décisions business critiques.

prérequis

• liste des domaines et leurs owners identifiés.
• accès en lecture aux schemas, aux query logs et aux métriques d’usage.
• un espace centralisé pour la documentation searchable (wiki, git repo, outil dédié).

aperçu rapide

• prioriser les 10 datasets qui servent réellement la production.
• définir les owners, les contrats d’interface, les SLA et les conventions de nommage.
• automatiser l’ingestion des schemas avec un enrichissement humain minimal.
• visualiser le lineage, les définitions de KPIs et les alerts qualité.
• optimiser la recherche via des titres clairs, des tags et des synonymes.
• mesurer l’adoption et déprécier agressivement ce qui n’est pas utilisé.

mindmap de la stratégie

tutoriel pas-à-pas

étape 1 cadrer et prioriser

Commencer par les datasets réellement utilisés et non par ceux qui brillent. L’analyse des logs est votre meilleure source de vérité.

# top tables consultées dans les logs SQL
awk -F, '/SELECT/ {print $3}' query_logs.csv | sort | uniq -c | sort -nr | head -n 15

criteres de priorisation
- usage mensuel élevé
- kpis critiques rattachés
- owner identifié et disponible
- dette technique raisonnable

étape 2 ingérer et enrichir

Import automatique des schemas. L’enrichissement humain se focalise sur les descriptions métier, les owners et les warnings.

-- recensement des colonnes prioritaires
SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema IN ('sales','marketing','product')
ORDER BY table_schema, table_name, ordinal_position;

fiche minimale dataset
- description en 3 lignes max
- owner principal + backup
- qualité règles, tests passés, known issues
- kpis liés et leurs définitions
- exemples d'usage avec 3 queries types

étape 3 tracer lineage et définitions

Relier les tables sources, les vues de transformation et les métriques finales. Il faut documenter les changements de logique métier.

-- exemple simple de lineage à partir des vues
SELECT 
    v.table_schema AS view_schema, 
    v.table_name AS view_name, 
    ccu.table_name AS source_table
FROM information_schema.view_table_usage ccu
JOIN information_schema.views v 
  ON v.table_catalog = current_catalog 
  AND v.table_schema = ccu.view_schema 
  AND v.table_name = ccu.view_name
ORDER BY view_schema, view_name;

glossaire kpi
- "taux de réachat" = clients réacheteurs / clients totaux sur 30 jours
- source analytics.orders
- note méthode changée le 2020-06-20 (voir CHANGELOG_KPI.md)

étape 4 publier et animer

Les pages doivent être lisibles avec des liens vers les usages. Le process de dépréciation doit être clair pour éviter le clutter.

printf "dataset,owner,doc\nsales.orders,alice,https://wiki/datasets/orders\n" >> catalog.csv

processus de dépréciation
- marquer deprecated pendant 30 jours
- proposer une alternative validée
- plan de migration et date de drop table

étape 5 mesurer l’adoption et la qualité

Suivre les recherches, les pages vues et les incidents. Fermez ce qui n’apporte pas de valeur.

-- usage par dataset (exemple)
SELECT dataset, COUNT(*) AS vues_30j
FROM catalog_views
WHERE ts >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY dataset
ORDER BY vues_30j DESC;

# contrôle rapide de complétude des docs
import csv

with open("catalog.csv") as f:
    rows = list(csv.DictReader(f))

missing_doc = [r for r in rows if not r["doc"]]
print(f"fiches sans doc: {len(missing_doc)}")

exemples

cas lancer la v1 sur un domaine pilote

domaine ventes
scope v1 orders, customers, invoices
delai 4 semaines
livrables fiches minimales, lineage graph, 3 exemples SQL par dataset
kpis ca, marge brute, taux de réachat
rituel revue hebdo 20 min pour traiter les écarts et questions

-- exemple d'extrait "exemples d'usage" dans la fiche
SELECT customer_id, SUM(amount) AS ca_30j
FROM sales.orders
WHERE order_date >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY customer_id
ORDER BY ca_30j DESC
LIMIT 100;

erreurs courantes et solutions

• fiches figées créent de l’obsolescence. Privilégiez l’ingestion auto combinée à un enrichissement léger.
• trop de champs crée de la lassitude. Documentez d’abord ce qui alimente les KPIs critiques.
• pas d’owner entraine le flou artistique. Exigez un owner clair par domaine et un backup nommé.
• recherche médiocre fait fuir les utilisateurs. Utilisez des titres explicites, des tags et des alias.
• corrections silencieuses génèrent de la confusion. Tenez un changelog et versionnez vos datasets.
• qualité invisible cause des surprises en prod. Intégrez les tests de schema et d’ordres de grandeur à l’ingestion.

faq

• Faut-il documenter chaque colonne ? Non. Commencez par les champs qui soutiennent les KPIs et les requêtes les plus fréquentes.
• Open source ou SaaS ? Choisissez ce que vous pouvez opérer durablement. Le process et l’adoption comptent plus que la marque de l’outil.
• Comment éviter les doublons de datasets ? Mettez en place des data contracts, un nommage clair et une revue obligatoire avant publication.