Comment Apache Ossie tente de rapprocher analystes et développeurs

Une histoire familière : le service marketing calcule le coût d'acquisition client avec une formule dans Excel, l'outil BI donne des chiffres différents, et dans le projet dbt l'analyste a une troisième logique intégrée. Quand la direction demande pourquoi les données "ne correspondent pas", un long processus commence pour trouver exactement l'endroit où la formule a divergé.

Ce problème s'appelle la fragmentation sémantique. Chaque outil de la pile de données — qu'il s'agisse de Tableau, Superset ou d'un agent IA — vit dans sa propre bulle et interprète les métadonnées à sa manière. Les gens d'Apache Software Foundation ont décidé qu'il était temps d'y mettre fin et ont présenté le projet Ossie (anciennement connu sous le nom d'Open Semantic Interchange).

Pourquoi avons-nous besoin d'un autre standard

En bref : pour pouvoir décrire une seule fois ce que signifie "revenu" ou "utilisateur actif" et utiliser cette définition partout. Actuellement, si vous passez d'un outil BI à un autre, vous devez réécrire toute la logique métier from scratch. Ossie propose un format neutre qui devrait devenir une sorte d'"espéranto" pour le monde de l'analytique.

Le projet est actuellement en incubation Apache. Cela signifie qu'il est encore en formation, mais il dispose déjà d'une communauté sérieuse derrière lui. L'idée est de créer une seule source de vérité que les moteurs SQL et les bots LLM sophistiqués peuvent comprendre.

Ce qu'il y a dans le dépôt

Il n'y a pas de binaire complexe à compiler pendant des heures. En essence, c'est un ensemble de spécifications et d'outils utilitaires pour les manipuler.

Spécification Core

Le dossier core-spec contient une description de ce à quoi devrait ressembler la couche sémantique. Ce sont des fichiers JSON et YAML ordinaires. Un schéma lisible par machine vous permet de vérifier automatiquement que vous n'avez pas gâché vos définitions de métriques.

Converters

C'est probablement la partie la plus utile pour les praticiens. Le dossier converters contient des outils pour traduire du format Ossie vers d'autres systèmes populaires. Il existe actuellement des implémentations pour dbt, GoodData, Polaris et même Salesforce. Cela vous permet de ne pas simplement stocker la spécification "dans un tiroir", mais de l'intégrer réellement dans vos outils de travail.

Exemples et Validation

Pour ceux qui ne veulent pas lire une documentation aride, il y a le dossier examples. Il contient un modèle TPC-DS complet — le benchmark standard pour les systèmes analytiques. Vous pouvez simplement voir comment les relations complexes et les agrégations sont décrites avec des données réelles.

Comment ça fonctionne en pratique

Imaginez que vous décriviez votre modèle de données dans un fichier YAML. Vous spécifiez les tables, les relations entre elles, et surtout les métriques calculées.

{
  "name": "total_sales",
  "description": "Сумма всех успешных транзакций без учета возвратов",
  "expression": "sum(order_amount)",
  "filters": ["status = 'completed'"]
}

Après cela, vous exécutez ce fichier via un convertisseur. Le résultat est une configuration pour votre outil BI. Si l'entreprise décide de changer d'outil demain, vous n'aurez pas à vous souvenir des filtres qui étaient dans les anciens rapports. Vous lancez simplement un convertisseur différent.

C'est particulièrement pertinent pour les agents IA. Pour qu'un réseau de neurones réponde correctement aux questions sur une base de données, il a besoin de contexte. Ossie fournit ce contexte dans un format structuré, éliminant les hallucinations sur "comment calculer le montant moyen des commandes".

Devriez-vous l'adopter maintenant

Le projet est en phase d'incubation, et cela se voit. Il n'y a pas encore des milliers d'étoiles GitHub (environ 700 au moment de la rédaction), et la documentation vous force parfois à fouiller dans le code source. Cependant, Apache est derrière le projet, et des contributeurs de grandes entreprises d'analytique apparaissent dans la liste.

Qui devrait définitivement y regarder de plus près :

1. Les équipes qui en ont marre que les métriques dbt ne correspondent pas à ce que le manager voit dans l'outil BI.
2. Les développeurs de plateformes d'analytique qui veulent ajouter un support d'import/export de modèles.
3. Ceux qui construisent des systèmes complexes utilisant des LLM et qui veulent donner au réseau de neurones une structure de données claire.

Si vous travaillez dans une petite startup avec une seule base de données et quelques graphiques, Ossie peut sembler excessif. Mais dès que vous avez plus de deux outils, le problème des "mêmes noms avec des significations différentes" se manifeste de plein fouet.

Vous pouvez essayer le projet dans le dépôt officiel. Il y a aussi un lien vers la communauté Slack où les développeurs répondent assez rapidement aux questions sur la spécification. Plus les fournisseurs adopteront ce standard, moins nous aurons de migraines avec les migrations et la configuration de l'analytique.