Metadaten

Metadaten sind ein wichtiges Konzept in der Manufacturing Data Engine (MDE). Sie repräsentiert Kontextdaten zu Fakten. Beispiele sind Sensormesswerte oder Ereignisse. Mithilfe von Metadaten können Sie Fragen wie die folgenden beantworten:

Welcher Tag hat einen numerischen Wert ausgegeben?
Welches Produkt wurde verarbeitet, als ein numerischer Messwert erfasst wurde?
Zu welchem Gerät gehört ein Sensor?
Welche Schicht war zum Zeitpunkt eines Ereignisses aktiv?
Welches Rezept war zum Zeitpunkt einer Messung aktiv?

MDE unterscheidet zwischen zwei Arten von Metadaten, je nachdem, wie schnell sie sich ändern:

Langsam wechselnde Cloud-Metadaten.
Sich schnell ändernde eingebettete Metadaten.

Cloud-Metadaten

Langsam sich ändernde Metadaten stellen Kontextdaten dar, die über einen längeren Zeitraum unverändert bleiben, z. B. Asset-Kontext, der die Maschine, Zelle, Linie und Anlage eines bestimmten Sensors beschreibt. Mit MDE können Sie Ihre sich langsam ändernden Metadaten modellieren, verwalten und untersuchen und sie mit Datensätzen verknüpfen. Nachdem Metadaten mit Datensätzen verknüpft wurden, können Sie die Datensätze mit dem zugehörigen Kontext untersuchen.

Langsam sich ändernde Metadaten in MDE werden als Cloud-Metadaten bezeichnet. Cloud-Metadaten haben in der Lösung zwei Funktionen:

Datensätze in den Kontext setzen und kategorisieren.
Als Quelle für versionierte Masterdaten zu Fertigungseinheiten wie Sensoren, Geräten und Linien.

Mit MDE können Cloud-Metadaten von der Edge bezogen, manuell über die MDE-Weboberfläche oder programmatisch über die API erstellt werden. Letzteres ermöglicht es Ihnen, Metadaten aus vorhandenen EAM- (Enterprise Asset Management) oder MDM-Systemen (Master Data Management) zu beziehen.

Metadaten-Buckets

Cloud-Metadaten-Buckets (auch als „Buckets“ oder „Metadaten-Buckets“ bezeichnet) sind Konfigurationseinheiten, die eine Gruppe zusammengehöriger, sich langsam ändernder Kontextdaten modellieren. Ein Bucket kann beispielsweise die Attribute eines Tags oder Rezepts modellieren. Buckets können als Datendimensionen im Bereich der Datenanalyse betrachtet werden.

Das wichtigste Attribut eines Metadaten-Buckets ist sein Schema. Das Schema (als JSON-Schema-Objekt ausgedrückt) definiert und beschränkt die Struktur der darin enthaltenen Metadateninstanzen. Sie können eine neue Metadaten-Bucket-Version erstellen. Neue Versionen müssen jedoch den Regeln für die Bucket-Versionsverwaltung für Cloud-Metadaten entsprechen.

Buckets sind global, d. h., sie können von jedem Typ referenziert werden.

Metadateninstanzen

Metadateninstanzen stellen den „Inhalt“ von Cloud-Metadaten-Buckets dar. Jede Instanz beschreibt eine Entität, z. B. ein Asset, einen Prozess oder einen Aspekt der erfassten Datensätze. Instanzen haben zwei Arten von Kennzeichnungen:

Eine vom System generierte UUID (Universally Unique Identifier), die die Instanz in MDE identifiziert.
Ein natürlicher Schlüssel, der die Entität außerhalb von MDE identifiziert (z. B. die Seriennummer eines Sensors).

Die Metadateninstanzen werden anhand des natürlichen Schlüssels versioniert. Das bedeutet, dass MDE die Entwicklung von Attributen für einen bestimmten natürlichen Schlüssel nachverfolgt. Ein Tag mit dem natürlichen Schlüssel „tag-123“ befindet sich anfangs beispielsweise in Zelle „X“, wird aber später in Zelle „Y“ verschoben. MDE speichert und versieht jede Instanz mit einem Zeitstempel und einer eindeutigen UUID. Mit dieser eindeutigen UUID können Sie den Verlauf von Instanzen für einen natürlichen Schlüssel abrufen, Datensätze bei der Aufnahme mit der richtigen Instanz in den Kontext setzen und eine Instanz bei der Abfrage nachträglich auf vergangene Datensätze anwenden.

Ab Version 1.5.0 werden Metadateninstanzen versioniert und basierend auf dem event-time und nicht auf dem processing time verarbeitet. Wenn Sie Metadateninstanzen mit Verlaufsdatensätzen senden, werden diese Metadateninstanzen in MDE anhand des eventTimestamp der Nachricht versioniert. So können sowohl Verlaufs- als auch aktuelle Metadaten nebeneinander existieren, ohne dass sich die neuesten Instanzen ändern. Weitere Informationen finden Sie unter Metadaten-Buckets mit Versionsverwaltung.

Mit MDE können Sie einem Bucket nur Instanzen hinzufügen, die dem Schema einer bestimmten Version dieses Buckets entsprechen.

Metadaten-Bucket-Schema

Jede Version eines Metadaten-Buckets enthält ein Schema und Metadateninstanzen können nur einer bestimmten Version eines Buckets hinzugefügt werden. Schemas schränken die Struktur von Metadateninstanzen, die einer Bucket-Version hinzugefügt werden können, weiter ein.

Metadaten-Bucket-Schemas werden als JSON-Schemaobjekte gemäß der Version 2019-09 der JSON-Schemaspezifikation ausgedrückt.

Wenn das Schema beispielsweise später einer Bucket-Version hinzugefügt wurde, würde darin angegeben, dass jedes Instanzobjekt ein Attribut namens deviceName mit dem Wert string haben muss und dass dieses Attribut erforderlich ist. Sehen Sie sich folgendes Beispiel an:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema#",
  "type": "object",
  "properties": {
    "deviceName": {
      "type": "string"
    }
  },
  "required": ["deviceName"]
}

Validierung von Metadateninstanzen

Metadateninstanzen müssen dem Schema entsprechen, das für eine bestimmte Metadaten-Bucket-Version definiert ist, damit sie eingefügt werden können.

Bucket-Typen

Im MDE werden drei Arten von Buckets definiert:

Tag-Buckets
Datensatz-Buckets
Lookup-Buckets

Der Typ eines Buckets wird bei der Erstellung definiert und kann später nicht mehr geändert werden.

Tag-Buckets

Tag-Buckets stellen Buckets dar, die Tags in einen Kontext setzen. Das bedeutet, dass der natürliche Schlüssel der im Bucket enthaltenen Instanzen der Tag-Name sein muss.

Datensatz-Buckets

Datensatz-Buckets stellen Buckets dar, die jede Gruppe von Datensätzen mit einem gemeinsamen natürlichen Schlüssel in den Kontext setzen können. Der natürliche Schlüssel von Datensatz-Bucket-Instanzen kann ein beliebiger Wert sein.

Lookup-Buckets

Nachschlage-Buckets stellen Buckets dar, in denen Datensätze nicht direkt in den Kontext gesetzt werden. Stattdessen enthalten sie Referenzdaten, die im Parser verwendet werden können. Der natürliche Schlüssel von Lookup-Bucket-Instanzen kann ein beliebiger Wert sein.

Eintrags-Bucket-Instanzen sind nie mit Einträgen verknüpft. Stattdessen können Instanzen aus einem Lookup-Bucket abgerufen werden, indem die Funktion mde::lookupByKey in einem Whistle-Skript aufgerufen wird. Die Funktion verwendet die Suchvorgänge bucketName, bucketVersion und naturalKey als Argumente und gibt die letzte Metadateninstanz für den angegebenen natürlichen Schlüssel zurück. Sie können die Instanz verwenden, um Felder in einem Proto-Datensatz im Parser zu füllen.

Metadaten-Buckets versionieren

Das Schema von Metadaten-Buckets kann sich ändern. Wenn Sie das Schema ändern möchten, müssen Sie jedoch eine neue Version eines Buckets erstellen. Vorhandene Bucket-Versionen und alle vorhandenen Konfigurationsentitäten, die auf frühere Versionen eines Buckets verweisen, sind von diesem Vorgang nicht betroffen. Um die Datenkonsistenz über die gesamte Lebensdauer eines Metadaten-Buckets hinweg zu gewährleisten, unterliegen neue Versionen von Metadaten-Bucket-Schemas den folgenden Einschränkungen:

Neue Versionen können Folgendes umfassen:

Fügen Sie neue optionale Felder hinzu.
Pflichtfeld als optional markieren

Neue Versionen dürfen nicht:

Entfernen Sie Felder.
Datentyp vorhandener Felder ändern.
Optionales Attribut als erforderlich markieren

Ab Version 1.5.0 basiert die Auflösung der Metadateninstanzen auch auf dem Ereigniszeitstempel. Das bedeutet, dass MDE die Metadateninstanz auflöst, die im Vergleich zur Ereigniszeit des Datensatzes am aktuellsten war. Dadurch wird das Konzept der MDE-Verknüpfungsmetadaten verallgemeinert, sodass es über verschiedene Zeiträume hinweg funktioniert, die durch die Quellnachricht gesteuert werden. Um die Lesbarkeit der Metadateninstanzen zu verbessern, wird in MDE v1.5.0 ein neues Feld namens validFrom eingeführt, das den Zeitpunkt angibt, zu dem eine bestimmte Metadateninstanz wirksam ist. Dieses Feld wird von MDE verwendet, um anhand der Ereigniszeit der Quellnachricht zu prüfen, welche Metadateninstanz ausgewählt werden soll.

Angenommen, Sie senden heute eine Metadateninstanz mit dem folgenden Wert an MDE für einen natürlichen Schlüssel sensor-a:


{
    "naturalKey": "sensor-a",
    "instance": {
        "site": "ONE",
        "factory": "ONE",
        "floor": "ONE",
        "line": "ONE",
        "cell": "ONE"
    }
}

MDE versioniert diese Instanz basierend auf dem eventTimestamp-Wert der eingehenden Nachricht, in der diese Metadateninstanz gesendet wurde. Da der Zeitstempel auf „heute“ festgelegt wurde, behandelt MDE diese Instanz als die bisher absolut letzte für diesen natürlichen Schlüssel. Der Wert von validFrom für diese neu versionierte Metadateninstanz ist der Wert von eventTimestamp der eingehenden Nachricht.

Angenommen, Sie senden eine Instanz mit historischen Metadaten (z. B. aus dem letzten Jahr) für denselben natürlichen Schlüssel sensor-a mit dem folgenden Wert:


{
    "naturalKey": "sensor-a",
    "instance": {
        "site": "OLD",
        "factory": "OLD",
        "floor": "OLD",
        "line": "OLD",
        "cell": "OLD"
    }
}

In diesem Beispiel vergleicht MDE diese Instanz mit den neuesten Metadateninstanzen, die zum oder vor dem empfangenen eventTimestamp (z. B. letztes Jahr) verfügbar waren, und fügt sie an der richtigen Stelle in die Zeitachsen ein. Das ist der grundlegende Unterschied zwischen Version 1.4.x und 1.5.0. Wenn MDE Ereignisse mit Verlaufsdatensätzen empfängt, wird der Metadateneintrag mit dem neuesten Datum zum Zeitpunkt des Ereignisses aufgelöst. Das folgende Diagramm zeigt, wie die Verarbeitungs- und Verknüpfungslogik funktioniert:

Logik für die Versionierung von Metadaten

Cloud-Metadateninstanzen mit Datensätzen verknüpfen

Wenn Sie einem Datensatz Kontext hinzufügen, verknüpfen Sie ihn mit einer Metadateninstanz. Dazu wird im Datensatz ein Verweis auf die UUID der Metadateninstanz gespeichert. MDE bietet zwei Möglichkeiten, diesen Link im Parser zu erstellen:

Indem Sie den natürlichen Schlüssel einer Instanz angeben.
Indem Sie eine Proto-Metadateninstanz bereitstellen.

Die BigQuery-Datensenke speichert beispielsweise Verweise auf Metadateninstanzen pro Bucket in einem Feld namens cloud_metadata_ref. Hier ist ein Beispiel dafür, wie eine Metadateninstanzreferenz in einem BigQuery-Datensatz aussieht:

{
  "id": "e4b66cb9-7c60-4473-b1a1-1954eca92405",
  "tag_name": "primepaintingrobot-01-airpressure",
  "type_version": "1",
  "event_timestamp": "2023-06-20 07:11:59.757000 UTC",
  "value": "762.53",
  "embedded_metadata": {},
  "materialized_cloud_metadata": {
    "device-metadata": {
      "deviceName": "example-device"
    }
  },
  "cloud_metadata_ref": {
    "device-metadata": {
      "bucket_number": 143,
      "bucket_version": 1,
      "instance_id": "50e156a0-dbd9-4f9b-bdc8-1e77574bc4b1"
    }
  },
  "ingest_timestamp": "2023-06-20 07:12:06.335000 UTC",
  "source_message_id": "8434396321424812"
}

Einen Datensatz über den natürlichen Schlüssel mit einer Cloud-Metadateninstanz verknüpfen

Sie können einen Datensatz mit einer Metadateninstanz verknüpfen, indem Sie im Parser einen Verweis auf eine Cloud-Metadaten-Bucket-Version und den natürlichen Schlüssel der Instanz im Proto-Datensatz angeben. MDE tauscht den natürlichen Schlüssel automatisch gegen die UUID der Instanz aus, sofern eine vorhanden ist, und speichert den Link im Datensatz. Wenn es mehrere Instanzen für den angegebenen natürlichen Schlüssel gibt, wählt MDE die letzte Instanz aus (Instanz mit dem letzten created_timestamp).

Wenn der referenzierte Bucket ein TAG-Bucket ist, ist die Angabe eines natürlichen Schlüssels optional. Wenn der natürliche Schlüssel nicht angegeben wird, verwendet MDE standardmäßig den Wert des Felds tagName.

Informationen dazu, wie Sie Datensätze mithilfe eines natürlichen Schlüssels mit Metadateninstanzen verknüpfen, finden Sie unter Metadaten-instance_id anhand eines natürlichen Schlüssels auflösen.

Einen Datensatz über eine Proto-Metadateninstanz mit einer Cloud-Metadateninstanz verknüpfen

Sie können einen Datensatz mit einer Metadateninstanz verknüpfen, indem Sie eine Referenz auf eine Cloud-Metadaten-Bucket-Version und eine Proto-Metadateninstanz sowie optional einen natürlichen Schlüssel im Proto-Datensatz im Parser angeben. Diese Methode zum Verknüpfen von Metadateninstanzen ist besonders nützlich, wenn Quellnachrichten bereits Kontextinformationen zum Erstellen einer gültigen Proto-Instanz enthalten.

Beachten Sie Folgendes, wenn Sie einen Datensatz über eine Proto-Metadateninstanz mit einer Cloud-Metadateninstanz verknüpfen:

Wenn Sie den natürlichen Schlüssel weglassen, wählt MDE automatisch einen für Sie aus, je nach Bucket-Typ.
Wenn Sie den natürlichen Schlüssel in einer Proto-Instanz im Kontext eines TAG-Buckets weglassen, wählt MDE automatisch tagName als natürlichen Schlüssel aus.
Wenn Sie den natürlichen Schlüssel in einer Proto-Instanz im Kontext eines RECORD-Buckets weglassen, generiert MDE automatisch einen Hashwert des Nachrichtenobjekts und verwendet diesen als natürlichen Schlüssel.
Wenn die bereitgestellte Proto-Instanz mit der neuesten Metadateninstanz für den angegebenen natürlichen Schlüssel übereinstimmt, tauscht MDE die bereitgestellte Proto-Instanz gegen die UUID der übereinstimmenden Instanz aus und speichert die UUID im Datensatz.
Wenn die bereitgestellte Proto-Instanz nicht mit der neuesten Metadateninstanz für den angegebenen natürlichen Schlüssel übereinstimmt, erstellt MDE eine neue Metadateninstanz für den angegebenen natürlichen Schlüssel und speichert die UUID der neu erstellten Instanz im Datensatz. Durch dieses Verhalten des Systems können Sie Metadaten-Buckets dynamisch mit Instanzen füllen, die aus Quellnachrichten generiert werden.

Informationen zum Verknüpfen von Datensätzen mit Metadateninstanzen mithilfe einer Proto-Metadateninstanz finden Sie unter Metadateninstanz-ID anhand des Instanzwerts auflösen.

Instanzmaterialisierung

Anstatt nur die UUID einer Metadateninstanz zu speichern, können Datensätze optional die gesamte Instanz enthalten. Das wird als Materialisierung bezeichnet. Dieses Verhalten kann für jede Senke auf Typenebene konfiguriert werden, indem der Wert des Felds materializeCloudMetadata für eine Senke auf true gesetzt wird.

Wenn Sie beispielsweise die Materialisierung von Metadaten für die BigQuery-Senke aktivieren, wird für einen Datensatz, der eine Metadateninstanzreferenz enthält, eine Zeile wie die folgende erstellt:

{
  "id": "e4b66cb9-7c60-4473-b1a1-1954eca92405",
  "tag_name": "primepaintingrobot-01-airpressure",
  "type_version": "1",
  "event_timestamp": "2023-06-20 07:11:59.757000 UTC",
  "value": "762.53",
  "embedded_metadata": {},
  "materialized_cloud_metadata": {
     "tag":{
       "bucket_number":143,
       "bucket_version":1,
       "instance":{
         "datatype":"float",
         "deviceID":"ppr-01",
         "deviceName":"primepaintingrobot-01",
         "vendor":"KUKA"
       }
     }
  },
  "cloud_metadata_ref": {
    "device-metadata": {
      "bucket_number": 143,
      "bucket_version": 1,
      "instance_id": "50e156a0-dbd9-4f9b-bdc8-1e77574bc4b1"
    }
  },
  "ingest_timestamp": "2023-06-20 07:12:06.335000 UTC",
  "source_message_id": "8434396321424812"
}

Eingebettete Metadaten

Schnell wechselnde Metadaten sind Kontextdaten, die sich schnell ändern. Typische Beispiele für sich schnell ändernde Metadaten sind Zähler und IDs, die automatisch inkrementiert werden, z. B. Seriennummern oder Transaktions-IDs.

Mit MDE können Sie sich schnell ändernde Metadaten mit Whistle strukturieren, harmonisieren und transformieren und direkt in den Datensatz einbetten, indem Sie ein Feld namens embeddedMetadata im Proto-Datensatz im Parser ausfüllen.

Alle unterstützten MDE-Datensenken stellen eingebettete Metadaten zur Verfügung. Wenn Sie beispielsweise das Feld embeddedMetadata im Proto-Datensatz im Parser ausfüllen, wird für den resultierenden Datensatz in BigQuery eine Zeile wie diese erstellt:

{
  "id": "e4b66cb9-7c60-4473-b1a1-1954eca92405",
  "tag_name": "primepaintingrobot-01-airpressure",
  "type_version": "1",
  "event_timestamp": "2023-06-20 07:11:59.757000 UTC",
  "value": "762.53",
  "embedded_metadata": {
    "transactionNumber": "1234"
  },
  "materialized_cloud_metadata": {},
  "cloud_metadata_ref": {},
  "ingest_timestamp": "2023-06-20 07:12:06.335000 UTC",
  "source_message_id": "8434396321424812"
}

Automatisches Löschen von Metadaten

Sowohl für die Datensatz- als auch für die Tag-Metadaten werden in MDE die Änderungen in jedem natürlichen Schlüssel nachverfolgt, indem jede neue Instanz mit der alten Instanz verglichen wird. Wenn sich eines der Instanzattribute ändert, erstellt MDE eine neue Version und kennzeichnet sie als aktuelle Instanz. Das Tag und die Metadaten des Datensatzes sollten in der Größenordnung von Tausenden und weniger als Hunderttausenden liegen. Diese Einschränkungen ermöglichen es MDE, die Metadateninstanzen zu indexieren, sobald sie vom Edge oder der API kommen, ohne den Verarbeitungsdurchsatz zu beeinträchtigen.

Manchmal wird aufgrund eines Konfigurationsfehlers ein Feld mit hoher Kardinalität wie ein Zeitstempel in die Metadateninstanz eingefügt. Dies führt zu einer schnellen Zunahme der Versionen für jeden natürlichen Schlüssel. Ab einem bestimmten Schwellenwert wirkt sich dies negativ auf die Leistung der Aufnahme aus. In einigen Fällen kann dies dazu führen, dass die Verarbeitung vollständig gestoppt wird, bis die zugrunde liegenden Cloud-Infrastrukturdienste vom Lösungsadministrator skaliert werden.

Ab Version 1.4.0 erzwingt MDE eine maximale Anzahl von Instanzen pro natürlichen Schlüssel, um eine konsistente Leistung zu gewährleisten. Wenn die Anzahl der natürlichen Schlüssel diesen Grenzwert erreicht (Standardwert ist 200), sendet MDE eine Warnung an die neue Benachrichtigungs-API, um den Nutzer über die natürlichen Schlüssel zu informieren, die eine hohe Anzahl von Versionen der Metadateninstanz haben. Wenn die Instanzgröße für natürliche Schlüssel den Schwellenwert überschreitet, werden die alten Instanzen automatisch aus dem internen Speicher gelöscht. Außerdem wird eine weitere Benachrichtigung an die Notifications API gesendet, in der der Nutzer über die gelöschten natürlichen Schlüssel informiert wird.

Sowohl die Warnung als auch die Löschvorgänge werden im Log gemeldet. Anhand dieser Informationen kann eine Benachrichtigungsrichtlinie für das Projekt in Cloud Monitoring erstellt werden.

Namensbeschränkungen für Metadaten-Buckets

Ein Metadaten-Bucket-Name kann Folgendes enthalten:

Buchstaben (Groß- und Kleinbuchstaben), Ziffern und die Sonderzeichen - und _.
Kann bis zu 255 Zeichen lang sein.

Sie können den folgenden regulären Ausdruck für die Validierung verwenden: ^[a-z][a-z0-9\\-_]{1,255}$.

Wenn Sie versuchen, eine Entität zu erstellen, die gegen die Namensbeschränkungen verstößt, erhalten Sie eine 400 error.