Partager via

Configurer des définitions de graphique WebAssembly (WASM) pour les graphiques et connecteurs de flux de données

Les définitions de graphique sont essentielles au développement WASM, car elles définissent la façon dont vos modules se connectent aux flux de données et aux connecteurs. Comprendre la relation entre les définitions de graphiques et les graphiques de flux de données ou les connecteurs vous aide à développer efficacement.

Cet article se concentre sur la création et la configuration des définitions de graphique YAML. Pour plus d’informations sur le déploiement et le test des graphiques de flux de données, consultez Déployer des modules webAssembly (WASM) et des définitions de graphiques.

Important

Actuellement, les graphiques de flux de données prennent uniquement en charge les points de terminaison MQTT, Kafka et OpenTelemetry. D’autres types de points de terminaison tels que Data Lake, Microsoft Fabric OneLake, Azure Data Explorer et Stockage local ne sont pas pris en charge. Pour plus d’informations, consultez la section Problèmes connus.

Important

Actuellement, le seul connecteur qui prend en charge les définitions de graphiques pour le traitement personnalisé est le connecteur HTTP/REST.

Structure d’une définition de graphique

Les définitions de graphiques suivent un schéma JSON formel qui valide la structure et garantit la compatibilité. La configuration comprend :

  • Configuration requise pour la compatibilité des versions de l’API et de la bibliothèque hôte
  • Configurations de module pour les paramètres d’exécution et la personnalisation de l’opérateur
  • Opérations qui définissent des nœuds de traitement dans votre flux de travail
  • Connexions qui spécifient le routage du flux de données entre les opérations
  • Schémas pour la validation facultative des données

Structure de graphique de base

metadata:
  $schema: "https://www.schemastore.org/aio-wasm-graph-config-1.0.0.json"
  name: "Simple graph"
  description: "A simple graph with a source, a map module, and a sink"
  version: "1.0.0"
  vendor: "Microsoft"

moduleRequirements:
  apiVersion: "1.1.0"
  runtimeVersion: "1.1.0"

operations:
  - operationType: "source"
    name: "data-source"
  - operationType: "map"
    name: "my-operator/map"
    module: "my-operator:1.0.0"
  - operationType: "sink"
    name: "data-sink"

connections:
  - from: { name: "data-source" }
    to: { name: "my-operator/map" }
  - from: { name: "my-operator/map" }
    to: { name: "data-sink" }

Compatibilité des versions

La section moduleRequirements garantit la compatibilité à l’aide de la gestion sémantique de version :

moduleRequirements:
  apiVersion: "1.1.0"          # WASI API version for interface compatibility
  runtimeVersion: "1.1.0"     # Runtime version providing runtime support
  features:                    # Optional features required by modules
    - name: "wasi-nn"

Conseil / Astuce

Pour obtenir des conseils sur l’activation de l’inférence ONNX en bande avec la wasi-nn fonctionnalité, consultez Exécuter l’inférence ONNX dans les graphiques de flux de données WebAssembly.

Exemple 1 : Définition de graphique simple

La définition de graphique simple illustre un pipeline à trois étapes de base qui convertit les données de température de Fahrenheit en Celsius :

metadata:
  name: "Simple graph"
  description: "A graph that transforms temperature from Fahrenheit to Celsius"
  version: "1.0.0"
  $schema: "https://www.schemastore.org/aio-wasm-graph-config-1.0.0.json"
  vendor: "Microsoft"

moduleRequirements:
  apiVersion: "1.1.0"
  runtimeVersion: "1.1.0"

moduleConfigurations:
  - name: module-temperature/map
    parameters:
      key1:
        name: key2
        description: key2
operations:
  - operationType: "source"
    name: "source"

  - operationType: "map"
    name: "module-temperature/map"
    module: "temperature:1.0.0"

  - operationType: "sink"
    name: "sink"

connections:
  - from:
      name: "source"
    to:
      name: "module-temperature/map"

  - from:
      name: "module-temperature/map"
    to:
      name: "sink"

Pour obtenir des instructions de déploiement pas à pas, consultez Déployer des modules webAssembly (WASM) et des définitions de graphique. Pour tester un flux de données qui utilise cet exemple, consultez l’exemple 1 : Déploiement de base avec un module WASM.

Fonctionnement de graphique simple

Ce graphique crée un pipeline de traitement des données simple :

  1. Opération source : reçoit les données de température du point de terminaison source du flux de données
  2. Opération de mappage : traite les données avec le module WASM de température (temperature:1.0.0)
  3. Opération de récepteur : envoie des données converties au point de terminaison de destination du flux de données

Le module de température convertit les degrés Fahrenheit en Celsius à l’aide de la formule standard (F - 32) × 5/9 = C.

Format d’entrée :

{"temperature": {"value": 100.0, "unit": "F"}}

Format de sortie :

{"temperature": {"value": 37.8, "unit": "C"}}

Exemple 2 : Définition de graphique complexe

La définition de graphique complexe illustre un flux de travail de traitement multi-capteur sophistiqué qui gère les données de température, d’humidité et d’image avec des analyses avancées :

metadata:
  name: "Complex graph"
  description: "A graph that processes temperature and humidity data from sensors, along with snapshot data. The graph performs filtering, accumulation, and enrichment operations before sending the processed data to the sink."
  version: "1.0.0"
  $schema: "https://www.schemastore.org/aio-wasm-graph-config-1.0.0.json"
  vendor: "Microsoft"

moduleRequirements:
  apiVersion: "1.1.0"
  runtimeVersion: "1.1.0"

moduleConfigurations:
  - name: module-temperature/map
    parameters:
      key1:
        name: key2
        description: key2
  - name: module-snapshot/branch
    parameters:
      snapshot_topic:
        name: snapshot_topic
        description: Transform app snapshot_topic in snapshot branch's init routine
operations:
  - operationType: "source"
    name: "source"

  - operationType: delay
    name: module-window/delay
    module: window:1.0.0
  - operationType: "map"
    name: "module-format/map"
    module: "format:1.0.0"
  - operationType: map
    name: module-snapshot/map
    module: snapshot:1.0.0
  - operationType: branch
    name: module-snapshot/branch
    module: snapshot:1.0.0
  - operationType: accumulate
    name: module-snapshot/accumulate
    module: snapshot:1.0.0
  - operationType: map
    name: module-temperature/map
    module: temperature:1.0.0
  - operationType: branch
    name: module-temperature/branch
    module: temperature:1.0.0
  - operationType: filter
    name: module-temperature/filter
    module: temperature:1.0.0
  - operationType: accumulate
    name: module-temperature/accumulate
    module: temperature:1.0.0
  - operationType: accumulate
    name: module-humidity/accumulate
    module: humidity:1.0.0
  - operationType: concatenate
    name: concatenate1
    module:
  - operationType: accumulate
    name: module-collection/accumulate
    module: collection:1.0.0
  - operationType: map
    name: module-enrichment/map
    module: enrichment:1.0.0

  - operationType: "sink"
    name: "sink"

connections:
  - from:
      name: source
    to:
      name: module-window/delay

  - from:
      name: module-window/delay
    to:
      name: module-snapshot/branch

  - from:
      name: module-snapshot/branch
      arm: "False"
    to:
      name: module-temperature/branch

  - from:
      name: module-snapshot/branch
      arm: "True"
    to:
      name: module-format/map

  - from:
      name: module-format/map
    to:
      name: module-snapshot/map

  - from:
      name: module-snapshot/map
    to:
      name: module-snapshot/accumulate

  - from:
      name: module-snapshot/accumulate
    to:
      name: concatenate1

  - from:
      name: module-temperature/branch
      arm: "True"
    to:
      name: module-temperature/map

  - from:
      name: module-temperature/branch
      arm: "False"
    to:
      name: module-humidity/accumulate

  - from:
      name: module-humidity/accumulate
    to:
      name: concatenate1

  - from:
      name: module-temperature/map
    to:
      name: module-temperature/filter

  - from:
      name: module-temperature/filter
    to:
      name: module-temperature/accumulate

  - from:
      name: module-temperature/accumulate
    to:
      name: concatenate1

  - from:
      name: concatenate1
    to:
      name: module-collection/accumulate

  - from:
      name: module-collection/accumulate
    to:
      name: module-enrichment/map

  - from:
      name: module-enrichment/map
    to:
      name: sink

Pour obtenir des instructions de déploiement pas à pas, consultez Déployer des modules webAssembly (WASM) et des définitions de graphique. Pour tester un flux de données qui utilise cet exemple, consultez l’exemple 2 : Déployer un graphique complexe.

Fonctionnement du graphique complexe

Le graphique complexe traite trois flux de données et les combine en analytique de capteur enrichie :

Diagramme montrant un exemple de graphique de flux de données complexe avec plusieurs modules.

Comme illustré dans le diagramme, les données circulent d’une source unique via plusieurs étapes de traitement :

  1. Module de fenêtre : retarde les données entrantes pour le traitement basé sur le temps
  2. Opération de branche : achemine les données en fonction du type de contenu (données de capteur et instantanés)
  3. Chemin de traitement de température :
    • Convertit les degrés Fahrenheit en Celsius
    • Filtre les lectures non valides
    • Calcule des résumés statistiques dans les fenêtres de temps
  4. Chemin de traitement de l’humidité :
    • Accumule les mesures d’humidité avec l’analyse statistique
  5. Chemin de traitement des images :
    • Met en forme les données d’image pour le traitement
    • Effectue la détection d’objets sur les captures instantanées de caméra
  6. Agrégation finale :
    • Concatène tous les flux de données traités
    • Agrège les résultats multi-capteurs
    • Ajoute des métadonnées et des alertes de surtempérature

Le graphique utilise des modules spécialisés à partir des exemples Rust :

  • Module de fenêtre pour les délais de traitement basés sur le temps
  • Modules de température pour la conversion, le filtrage et l’analyse statistique
  • Module d’humidité pour le traitement des données environnementales
  • Modules d’instantané pour le routage des données d’image et la détection d’objets
  • Module de format pour la préparation de l’image pour le traitement
  • Module de collecte pour l’agrégation de données multi-capteurs
  • Module d’enrichissement pour l’ajout de métadonnées et la génération d’alertes

Les opérations de branche permettent le traitement parallèle de différentes entrées de capteur, ce qui permet au graphique de gérer efficacement plusieurs types de données au sein d’un même flux de travail.

Comment les définitions de graphique deviennent des flux de données

Voici comment les définitions de graphiques et les graphiques de flux de données Opérations Azure IoT sont liés :

Votre fichier YAML définit la logique de traitement interne avec des opérations source/récepteur en tant que points de terminaison abstraits. Cela devient l’artefact de définition de graphique. Les modules référencés implémentent les opérateurs de traitement réels en tant que modules WASM. Les définitions de graphique et les modules WASM sont chargés dans un registre de conteneurs (par exemple, Azure Container Registry) en tant qu’artefacts OCI pour le stockage du Registre.

La ressource Azure Resource Manager ou Kubernetes « encapsule » la définition du graphique et la connecte à des points de terminaison réels en tant que ressource de graphique de flux de données. Pendant le déploiement du runtime, le moteur de flux de données extrait les artefacts du Registre et les déploie. Pour le mappage de point de terminaison, les opérations source/récepteur abstraites dans votre graphique se connectent à des rubriques MQTT réelles, à Azure Event Hubs ou à d’autres sources de données.

Par exemple, ce diagramme illustre la relation entre les définitions de graphique, les modules WASM et les graphiques de flux de données :

Diagramme montrant la relation entre les définitions de graphique, les modules WASM et les graphiques de flux de données.

Pour en savoir plus sur la configuration des graphiques de flux de données, consultez Utiliser WebAssembly avec des graphiques de flux de données.

Déploiement du Registre

Les définitions de graphique et les modules WASM doivent être chargés dans un registre de conteneurs en tant qu’artefacts Open Container Initiative (OCI) avant que les graphiques de flux de données puissent les référencer :

  • Les définitions de graphique sont empaquetées en tant qu’artefacts OCI avec type de média application/vnd.oci.image.config.v1+json
  • Les modules WASM sont empaquetés en tant qu’artefacts OCI contenant le binaire WebAssembly compilé
  • Utiliser la gestion sémantique de version (par exemple my-graph:1.0.0, temperature-converter:2.1.0) pour une gestion des dépendances appropriée
  • La prise en charge du Registre est compatible avec Azure Container Registry, Docker Hub et d’autres registres conformes à OCI

La séparation permet une logique réutilisable où la même définition de graphique se déploie avec différents points de terminaison. Elle fournit l’indépendance de l’environnement où le développement, la préproduction et la production utilisent différentes sources de données. Elle prend également en charge le déploiement modulaire où vous mettez à jour les configurations de point de terminaison sans modifier la logique de traitement.

Pour obtenir des instructions détaillées sur le chargement des définitions de graphiques et des modules WASM dans des registres, consultez Déployer des modules WebAssembly (WASM) et des définitions de graphiques.

Paramètres de configuration du module

Les définitions de graphiques peuvent spécifier des paramètres d’exécution pour les opérateurs WASM via des configurations de module :

moduleConfigurations:
  - name: my-operator/map
    parameters:
      threshold:
        name: temperature_threshold
        description: "Temperature threshold for filtering"
        required: true
      unit:
        name: output_unit
        description: "Output temperature unit"
        required: false

Ces paramètres sont passés à la fonction de votre opérateur WASM au moment de l’exécution de la fonction init, ce qui active la configuration dynamique sans reconstruire les modules. Pour obtenir des exemples détaillés d’accès et d’utilisation de ces paramètres dans votre code Rust et Python, consultez Paramètres de configuration du module.

Pour obtenir un exemple d’implémentation complet, consultez le module de branche, qui illustre l’utilisation des paramètres pour la logique de routage conditionnel.

Étapes suivantes

  • Last updated on