Export vers Apache Ossie

Apache Ossie (anciennement Open Semantic Interchange) est un projet Apache en incubation définissant une spécification YAML/JSON portable pour l’échange de modèles sémantiques entre outils d’analytique, d’IA et de BI. Saiku fournit un exporteur qui lit n’importe quel schéma Mondrian et produit un document Ossie valide — les mêmes définitions de mesures et de dimensions deviennent consommables par dbt, GoodData, Snowflake, Databricks, Salesforce et tout autre outil doté d’un convertisseur Ossie.

Spec préliminaire

Ossie est en v0.2.0.dev0 et marqué comme préliminaire (draft). L’exporteur Saiku est épinglé à cette version — attendez-vous à des mises à jour cassant la forme du modèle à mesure qu’Ossie se stabilise. Suivez la feuille de route apache/ossie pour les groupes de travail en cours (la sémantique des hiérarchies et la sémantique des métriques sont les deux qui comptent le plus pour les schémas de forme Mondrian).

Démarrage rapide

Passez un schéma Mondrian XML en entrée, obtenez du YAML Ossie en sortie :

java -jar saiku-launcher/target/saiku-4.6.0.jar ossie-export \
  --in saiku-home/data/Pharma.xml \
  --out pharma.ossie.yaml

Ou utilisez stdin/stdout pour le scripting :

cat schema.xml | saiku ossie-export > schema.ossie.yaml

La commande sort avec un code non nul si l’entrée ne peut pas être lue (code 2) ou si la sortie ne peut pas être écrite (code 3), avec une ligne de diagnostic sur stderr. Les exécutions réussies indiquent combien de modèles sémantiques ont été écrits et (le cas échéant) quels cubes ont été ignorés :

ossie-export: wrote 1 semantic model(s) to pharma.ossie.yaml

Ce qui correspond à quoi

L’exporteur suit cette table de correspondance 1:1. Tout sauf les exceptions explicitement listées atterrit textuellement dans la colonne cible.

Élément Mondrian	Sortie Ossie
<Cube>	Une entrée semantic_model
Table de faits du cube <Table name="..." schema="..."/>	Premier dataset, source: "<schema>.<table>"
<Dimension foreignKey="..."> avec <Hierarchy><Table/>	Un dataset de dim par hiérarchie, plus une relationship de fact.foreignKey → dim.primaryKey
<Level name="..." column="..."/>	Un field sur la dim (ou la table de faits, pour les dims dégénérées), avec expression.dialects[0]=ANSI_SQL:column
<Level ... levelType="TimeYears"> (ou Quarters/Months/Days)	Le field gagne dimension.is_time: true
<Measure name="..." column="..." aggregator="sum"/>	Une metric avec à la fois les dialectes ANSI_SQL (SUM(fact.column)) et MDX ([Measures].[Name])
<Measure aggregator="distinct-count">	ANSI_SQL: COUNT(DISTINCT fact.column) — plus count, min, max, avg se traduisent tous
<CalculatedMember><Formula>...</Formula></CalculatedMember>	Métrique avec une expression MDX uniquement (pas de traduction ANSI SQL fiable pour les formules MDX)
<Annotation name="saiku.semantic.description">	ai_context.instructions de l’élément
<Annotation name="saiku.semantic.synonyms">	ai_context.synonyms[] de l’élément (découpage CSV, avec trim)
<Annotation name="saiku.semantic.pii">true	custom_extensions: [{vendor_name: SAIKU, data: '{"pii":true}'}] — booléen JSON, pas chaîne
<Annotation name="saiku.semantic.{cardinality,grain,aggregation_kind,required_filters}">	Même extension fournisseur SAIKU, valeurs sérialisées comme chaînes JSON

Exemple détaillé — cube Pharma

Extrait d’entrée de saiku-home/data/Pharma.xml :

<Cube name="Pharma Rx">
  <Table name="fact_pharma" schema="public"/>
  <Dimension name="Prescriber" foreignKey="prescriberkey">
    <Hierarchy hasAll="true" primaryKey="prescriberkey">
      <Table name="dim_prescriber" schema="public"/>
      <Level name="Prescriber" column="prescriberkey" nameColumn="prescribername"
             type="Numeric" uniqueMembers="true">
        <Annotations>
          <Annotation name="saiku.semantic.pii">true</Annotation>
        </Annotations>
      </Level>
    </Hierarchy>
  </Dimension>
  <Measure name="Quantity" column="quantity_units" aggregator="sum" formatString="#,##0"/>
</Cube>

Produit ce fragment Ossie :

version: 0.2.0.dev0
semantic_model:
- name: Pharma Rx
  datasets:
  - name: fact_pharma
    source: public.fact_pharma
    description: Fact table for cube 'Pharma Rx'.
  - name: Prescriber
    source: public.dim_prescriber
    primary_key:
    - prescriberkey
    fields:
    - name: Prescriber
      expression:
        dialects:
        - dialect: ANSI_SQL
          expression: prescriberkey
      custom_extensions:
      - vendor_name: SAIKU
        data: "{\"pii\":true}"
  relationships:
  - name: fact_pharma_to_Prescriber
    from: fact_pharma
    to: Prescriber
    from_columns:
    - prescriberkey
    to_columns:
    - prescriberkey
  metrics:
  - name: Quantity
    expression:
      dialects:
      - dialect: ANSI_SQL
        expression: SUM(fact_pharma.quantity_units)
      - dialect: MDX
        expression: "[Measures].[Quantity]"

Ce qui n’est pas (encore) pris en charge

Le convertisseur de première mouture gère la forme hybride classique Mondrian 3–4 utilisée par Pharma, Bank et la plupart des schémas clients. Il ne gère pas encore :

• La forme wrapper <MeasureGroups> / <Dimensions> de Mondrian 4. FoodMart l’utilise. Les cubes ayant cette forme sont ignorés (signalés sur stderr) plutôt qu’émis comme des ébauches invalides pour le schéma. Le travail de suivi est suivi sur l’épopée parente Ossie/SQL.
• Les cubes virtuels (<VirtualCube>) — y compris notre exemple Warehouse-and-Sales. Ignorés comme ci-dessus.
• Les hiérarchies parent-enfant. Émises comme niveaux plats ; la relation hiérarchique n’est pas représentable dans la forme actuelle d’Ossie orientée dataset (le groupe de travail hiérarchie d’Ossie est en cours — voir la feuille de route Ossie).
• Les dimensions partagées consommées via <DimensionUsage source=...>. Seule l’imbrication classique par cube de <Dimension> fonctionne aujourd’hui.

Quand la gestion des hiérarchies d’Ossie se stabilisera (cible : v0.3.0+) et que le convertisseur MG Mondrian-4 de Saiku arrivera, cette table rétrécira.

Consommer la sortie

Le YAML Ossie est validé par rapport à osi-schema.json d’apache/ossie — chaque fichier que l’exporteur produit fait un round-trip à travers le schéma sans aucune anomalie (un test unitaire l’affirme à chaque commit). Consommateurs en aval :

• dbt — les convertisseurs de référence d’Ossie incluent un module dbt.
• Snowflake, Salesforce, GoodData, Polaris, Databricks — même répertoire.
• Apache Superset et Metabase — pas encore de convertisseur natif au moment de l’écriture, mais le travail SQL-over-Ossie sur la feuille de route Saiku (épopée parente saiku#1387) rendra Saiku lui-même interrogeable comme couche sémantique via SQL.

Voir aussi

• Annotations sémantiques Saiku — les clés d’annotation que l’exporteur lit (qui se mappent dans l’ai_context + custom_extensions d’Ossie).
• Extensions Ossie bien connues — le côté récepteur. Une fois votre schéma exporté en YAML Ossie, les well-knowns saiku.display / saiku.roles / saiku.pii sont la manière dont vous créez des annotations directement là-bas.
• Structure du schéma — où le bloc <Annotations> vit à l’intérieur de votre schéma Mondrian.
• Dépôt apache/ossie — spec en amont, convertisseurs, feuille de route.