OpenMetadata¶

Gouvernance des données, catalogue, lignage et qualité.


URL	`https://catalog.akko.local`
Authentification	Keycloak SSO (client confidentiel)
Sous-charts Helm	`openmetadata` (chart communautaire), `akko-opensearch` (personnalisé)
Activé	Activé par défaut depuis Sprint 14 (nécessite 16 Go+ de mémoire cluster)

Aperçu¶

OpenMetadata fournit une couche centralisée de gouvernance des données pour la plateforme AKKO. Il sert de catalogue de métadonnées où les ingénieurs de données, analystes et propriétaires peuvent découvrir les jeux de données, tracer le lignage, définir des glossaires et surveiller la qualité des données.

Besoin mémoire -- 16 Go+ de mémoire cluster

OpenMetadata et ses dépendances (OpenSearch) sont gourmands en mémoire. OpenMetadata est activé par défaut dans AKKO (décision 2026-03-14), mais le cluster doit disposer d'au moins 16 Go de mémoire disponible (Docker Desktop pour k3d, mémoire des noeuds pour k3s/EKS/AKS/GKE).

Déploiement¶

OpenMetadata est activé par défaut dans helm/akko/values.yaml. Pour le désactiver sur des clusters limités en mémoire :

# values-dev.yaml ou votre fichier de surcharge
openmetadata:
  enabled: false
akko-opensearch:
  enabled: false

Puis :

helm upgrade akko helm/akko/ -n akko -f values-dev.yaml

Cela démarre quatre services supplémentaires :

Service	Rôle	Mémoire
`openmetadata-migrate`	Exécute les migrations de base de données au démarrage, puis s'arrête	Minimale
`openmetadata-server`	Serveur applicatif principal (API + UI)	~1 Go
`openmetadata-ingestion`	Workers d'ingestion de métadonnées	~512 Mo
`opensearch`	Moteur de recherche backend (remplace Elasticsearch)	~512 Mo de heap

Fonctionnalités¶

Catalogue de données¶

Parcourez et recherchez tous les jeux de données ingérés depuis Trino, y compris les tables Iceberg et PostgreSQL. Chaque asset inclut :

Schéma au niveau des colonnes avec les types
Tags et classifications
Propriété (équipe ou individu)
Descriptions (au niveau table et colonne)
Statistiques de profilage des données

Visualisation du lignage¶

Suivez comment les données circulent à travers la plateforme :

DAG Airflow --> tables Iceberg --> tableau de bord Superset

Le lignage est capturé au niveau pipeline, table et tableau de bord, offrant une visibilité complète sur les dépendances amont et les consommateurs aval.

Glossaire¶

Un vocabulaire métier partagé avec des définitions de termes standardisées. Les termes de glossaire pré-configurés couvrent le domaine de la démonstration bancaire (par ex. segment client, type de compte, catégorie de transaction).

Qualité des données¶

Suites de tests et cas de test qui valident l'intégrité des données. Exécutez des vérifications automatisées sur la fraîcheur des tables, le nombre de lignes, les valeurs des colonnes et les assertions SQL personnalisées.

Domaines et produits de données¶

Organisez les assets en domaines métier et produits de données publiables avec des SLOs et une propriété définis.

Contenu pré-configuré¶

AKKO inclut deux scripts d'enrichissement qui peuplent OpenMetadata avec du contenu de démonstration après l'ingestion :

Enrichissement V1 (`openmetadata/enrich_catalog.py`)¶

Catégorie	Nombre	Détails
Classifications	3	PII, DataTier, Domain
Tags	8	À travers les trois classifications
Termes de glossaire	8	Vocabulaire du domaine bancaire
Équipes	3	Avec des attributions de propriété par équipe
Utilisateurs	3	Associés aux équipes
Descriptions	--	Descriptions au niveau table et colonne

Enrichissement V2 (`openmetadata/enrich_catalog_v2.py`)¶

Catégorie	Nombre	Détails
Domaines	3	Domaines métier pour l'organisation des assets
Produits de données	2	Définitions de produits de données publiables
Ingestion de tableaux de bord	--	Tableaux de bord Superset enregistrés dans le catalogue
Ingestion de pipelines	--	Pipelines Airflow enregistrés dans le catalogue
Suites de tests	3	Une par table principale
Cas de test	7	Vérifications de fraîcheur, nombre de lignes, valeurs de colonnes
Lignage	--	Connexions pipeline vers table vers tableau de bord

Exécuter les scripts d'enrichissement¶

Après qu'OpenMetadata soit en cours d'exécution et que l'ingestion initiale soit terminée :

# V1 : Tags, glossaire, propriétaires, descriptions
kubectl exec -n akko deploy/openmetadata-ingestion -- python /opt/scripts/enrich_catalog.py

# V2 : Domaines, produits de données, qualité, lignage
kubectl exec -n akko deploy/openmetadata-ingestion -- python /opt/scripts/enrich_catalog_v2.py

Les scripts sont idempotents

Les deux scripts d'enrichissement vérifient l'existence des ressources avant d'en créer de nouvelles. Ils peuvent être exécutés plusieurs fois en toute sécurité.

Architecture des composants¶

                    catalog.akko.local
                          |
                     Traefik (TLS)
                          |
               openmetadata-server (:8585)
                    |           |
           akko-opensearch (:9200)   akko-postgresql (BD de métadonnées)
                                |
               openmetadata-ingestion
                    |
              +-----+-----+
              |     |     |
           Trino  Airflow  Superset

OpenMetadata stocke ses métadonnées dans l'instance PostgreSQL partagée (base de données : openmetadata_db) et utilise OpenSearch pour la recherche en texte intégral et l'indexation.

Authentification¶

OpenMetadata utilise un client Keycloak confidentiel (flux par code d'autorisation côté serveur, pas le flux implicite SPA). Cela évite les problèmes de boucle de connexion avec les certificats auto-signés dans Safari.

La configuration est gérée via des variables d'environnement dans les valeurs Helm :

AUTHENTICATION_CLIENT_TYPE: confidential
12 variables d'environnement OIDC_* pour le flux par code d'autorisation pac4j
Certificat TLS auto-signé importé dans le truststore Java au démarrage du conteneur

Problèmes connus¶

OOM avec Docker Desktop à 8 Go

Le serveur OpenMetadata (~1 Go) + OpenSearch (~512 Mo de heap + mémoire native) provoquera des boucles de redémarrage OOM si Docker Desktop est configuré avec moins de 16 Go de RAM. Utilisez toujours le profil governance sur une machine disposant de ressources suffisantes.

Syntaxe de la commande de migration

La commande de migration OpenMetadata est :

./bootstrap/openmetadata-ops.sh migrate

Pas ./openmetadata.sh migrate (qui n'existe pas). Le service openmetadata-migrate gère cela automatiquement au démarrage.

Mémoire OpenSearch

OpenSearch nécessite -Xms512m -Xmx512m au minimum. Définir le heap en dessous de ce seuil (par ex. limite de conteneur à 768m au total) provoque des boucles de redémarrage car OpenSearch a besoin à la fois de heap et de mémoire native (~1 Go au total).

Particularités de sérialisation API

L'API REST d'OpenMetadata a des exigences de sérialisation spécifiques :

Les points d'accès PUT attendent des chaînes FQN pour les champs service, testSuite et domain -- pas des objets {id, type}
Les assets de produits de données doivent être ajoutés via PATCH après la création, pas dans le PUT initial
Suites de tests : le POST vers /testSuites/executable nécessite à la fois basicEntityReference et executableEntityReference (FQN de la table)

Chiffrement du jeton bot

Le jeton bot d'OpenMetadata est chiffré avec Fernet dans la table user_entity. Le préfixe fernet: doit être retiré avant le déchiffrement. Le nom de la base de données est openmetadata_db.