メタデータ

メタデータは、Manufacturing Data Engine（MDE）の重要なコンセプトです。事実に関するコンテキストデータを表します。（センサーの読み取り値やイベントなど）。メタデータは、次のような質問に回答するのに役立ちます。

数値の読み取り値を生成したタグはどれですか？
数値が測定されたときに処理されていた製品は何ですか？
センサーはどのデバイスに属していますか？
イベントが発生したときに進行中だったシフト
読み取り時にアクティブだったレシピ

MDE では、変化のペースに基づいて次の 2 種類のメタデータが区別されます。

変化が緩やかなクラウドメタデータ。
急速に変化する埋め込みメタデータ。

クラウドメタデータ

変化の遅いメタデータは、長期間にわたって変化しないコンテキストデータを表します。たとえば、特定のセンサーのマシン、セル、ライン、プラントを記述するアセットコンテキストなどです。MDE を使用すると、変化の遅いメタデータをモデル化、管理、探索し、レコードにリンクできます。メタデータがレコードにリンクされると、関連するコンテキストを使用してレコードを探索できます。

MDE の変化の遅いメタデータは、クラウドメタデータと呼ばれます。クラウドメタデータは、ソリューションで次の 2 つの機能を果たします。

レコードのコンテキスト化と分類。
センサー、デバイス、ラインなどの製造エンティティに関するバージョン管理されたマスターデータのソースとして機能する。

MDE では、クラウドメタデータをエッジから取得したり、MDE ウェブインターフェースを使用して手動で作成したり、API を使用してプログラムで作成したりできます。後者を使用すると、既存のエンタープライズアセット管理（EAM）システムまたはマスターデータ管理（MDM）システムからメタデータを取得できます。

メタデータバケット

クラウドメタデータバケット（「バケット」または「メタデータバケット」とも呼ばれます）は、変化の少ないコンテキストデータの関連セットをモデル化する構成エンティティです。たとえば、バケットはタグやレシピの属性をモデル化できます。バケットは、データ分析ドメインのデータディメンションと考えることができます。

メタデータバケットの重要な属性は、スキーマです。スキーマ（JSON スキーマオブジェクトとして表現）は、その中に含まれるメタデータインスタンスの構造を定義し、制約します。新しいメタデータバケットバージョンを作成できますが、新しいバージョンはクラウドメタデータのバケットバージョニングルールに準拠する必要があります。

バケットはグローバルです。つまり、任意のタイプで参照できます。

メタデータインスタンス

メタデータインスタンスは、クラウドメタデータバケットの「コンテンツ」を表します。各インスタンスは、アセット、プロセス、キャプチャされるレコードの側面などのエンティティを表します。インスタンスには次の 2 種類の識別子があります。

MDE 内のインスタンスを識別する、システム生成の UUID（Universally Unique Identifier）。
MDE の外部でエンティティを識別する自然キー（センサーのシリアル番号など）。

メタデータインスタンスは自然キーでバージョン管理されます。つまり、MDE は特定の自然キーの属性の進化を追跡します。たとえば、自然キー「tag-123」を持つタグは、最初はセル「X」に存在していても、後でセル「Y」に移動される可能性があります。MDE は各インスタンスを保存してタイムスタンプを付与し、一意の UUID を付与します。この一意の UUID を使用すると、自然キーのインスタンスの履歴を取得したり、取り込み時に適切なインスタンスでレコードをコンテキスト化したり、クエリ時にインスタンスを過去のレコードに遡及的に適用したりできます。

v1.5.0 以降では、メタデータインスタンスはバージョン管理され、processing time ではなく event-time に基づいて処理されます。過去のレコードを含むメタデータインスタンスを送信すると、MDE はメッセージの eventTimestamp に基づいてメタデータインスタンスをバージョン管理します。これにより、最新のインスタンスを変更することなく、過去のメタデータと最近のメタデータを共存させることができます。詳細については、メタデータバケットのバージョニングをご覧ください。

MDE では、バケットの特定のバージョンのスキーマに準拠するインスタンスのみをバケットに追加できます。

メタデータバケットスキーマ

各メタデータバケットバージョンにはスキーマが含まれており、メタデータインスタンスはバケットの特定のバージョンにのみ追加できます。スキーマは、バケットバージョンに追加できるメタデータインスタンスの構造をさらに制約します。

メタデータバケットスキーマは、JSON スキーマ仕様の 2019-09 バージョンに従って JSON スキーマオブジェクトとして表現されます。

たとえば、スキーマが後でバケットバージョンに追加された場合、各インスタンスオブジェクトには string 値の deviceName というプロパティが必要であり、このプロパティは必須であると記述されます。次の例をご覧ください。

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

メタデータインスタンスの検証

メタデータインスタンスを挿入するには、特定のメタデータバケットバージョン用に定義されたスキーマに準拠している必要があります。

バケットの種類

MDE では、次の 3 種類のバケットが定義されています。

バケットにタグを付ける
レコード バケット
ルックアップ バケット

バケットのタイプは作成時に定義され、後で変更することはできません。

バケットにタグを付ける

タグバケットは、タグをコンテキスト化するバケットを表します。つまり、バケットに含まれるインスタンスの自然キーはタグ名である必要があります。

レコードバケット

レコードバケットは、共通の自然キーを共有するレコードのグループをコンテキスト化できるバケットを表します。レコードバケットインスタンスの自然キーには任意の値を使用できます。

ルックアップバケット

ルックアップバケットは、レコードを直接コンテキスト化するのではなく、パーサーで使用できる参照データを提供するバケットを表します。ルックアップバケットインスタンスの自然キーには任意の値を使用できます。

レコードバケットインスタンスがレコードにリンクされることはありません。代わりに、Whistle スクリプトで mde::lookupByKey 関数を呼び出すことで、ルックアップバケットからインスタンスを取得できます。この関数は、ルックアップ bucketName、bucketVersion、naturalKey を引数として取り、指定された自然キーの最新のメタデータインスタンスを返します。このインスタンスを使用して、パーサーの proto レコードのフィールドに入力できます。

メタデータバケットのバージョニング

メタデータバケットのスキーマは進化できますが、スキーマを変更するにはバケットの新しいバージョンを作成する必要があります。既存のバケットバージョンと、以前のバージョンのバケットを参照する既存の構成エンティティは、このオペレーションの影響を受けません。メタデータバケットのライフサイクル全体でデータの整合性を確保するため、新しいメタデータバケットスキーマバージョンには次の制限が適用されます。

新しいバージョンでは、次のことが可能になります。

新しいオプションフィールドを追加します。
必須フィールドを省略可能にする。

新しいバージョンでは、次のことはできません。

フィールドを削除します。
既存のフィールドのデータ型を変更します。
省略可能な属性を必須としてマークします。

v1.5.0 以降では、メタデータインスタンスの解決もイベントタイムスタンプに基づいています。つまり、MDE はレコードのイベント時間と比較して最新のメタデータインスタンスを解決します。これにより、MDE のメタデータをリンクして、ソースメッセージによって制御されるさまざまな時間で動作するというコンセプトが一般化されます。メタデータインスタンスのクエリの可読性を高めるため、MDE v1.5.0 では、特定のメタデータインスタンスが有効になる時間を指定する validFrom という新しいフィールドが導入されています。このフィールドは、MDE がソースメッセージのイベント時刻に基づいてどのメタデータインスタンスを選択するかを確認するために使用されます。

たとえば、自然キー sensor-a の場合、今日、次の値を持つメタデータインスタンスを MDE に送信するとします。


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

MDE は、このメタデータインスタンスが送信された受信メッセージの eventTimestamp 値に基づいて、このインスタンスをバージョン管理します。タイムスタンプが今日に設定されているため、MDE はこのインスタンスを、その自然キーに対してこれまでに受信した最新のインスタンスとして扱います。この新しいバージョンのメタデータインスタンスの validFrom の値は、受信メッセージの eventTimestamp の値になります。

ここで、同じ自然キー sensor-a の過去のメタデータインスタンス（たとえば、昨年）を次の値で送信するとします。


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

この例では、MDE はこのインスタンスを、受信した eventTimestamp（たとえば、昨年）以前に利用可能だった最新のメタデータインスタンスと比較してバージョン管理し、タイムラインの適切な場所に挿入します。これが v.1.4.x と 1.5.0 の根本的な違いです。MDE が過去のレコードイベントを受信すると、イベントの時点で最新だった過去のメタデータエントリが解決されます。次の図は、処理とリンクのロジックの仕組みを示しています。

メタデータロジックのバージョニング

クラウドメタデータインスタンスをレコードにリンクする

レコードにコンテキストを追加するには、レコードをメタデータインスタンスにリンクします。これは、メタデータインスタンスの UUID への参照をレコードに保存することで実現されます。MDE には、パーサーでこのリンクを作成する方法が 2 つあります。

インスタンスの自然キーを指定する。
proto メタデータインスタンスを指定します。

たとえば、BigQuery データシンクは、バケットごとのメタデータインスタンスへの参照を cloud_metadata_ref というフィールドに保存します。メタデータインスタンス参照が BigQuery レコードにどのように表示されるかの例を次に示します。

{
  "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"
}

自然キーを使用してレコードをクラウドメタデータインスタンスにリンクする

パーサーで、クラウドメタデータバケットバージョンと proto レコード内のインスタンスの自然キーへの参照を指定することで、レコードをメタデータインスタンスにリンクできます。MDE は、インスタンスの UUID が存在する場合は、インスタンスの UUID と自然キーを自動的に交換し、リンクをレコードに保存します。指定された自然キーに複数のインスタンスがある場合、MDE は最新のインスタンス（最新の created_timestamp を持つインスタンス）を選択します。

参照されるバケットが TAG バケットの場合、自然キーの指定は省略可能です。自然キーが省略されている場合、MDE はデフォルトで tagName フィールドの値を使用します。

自然キーを使用してレコードをメタデータインスタンスにリンクする方法については、自然キーによるメタデータ instance_id の解決をご覧ください。

proto メタデータインスタンスを使用してレコードをクラウドメタデータインスタンスにリンクする

クラウドメタデータバケットバージョンへの参照を指定し、メタデータインスタンスと、必要に応じて、パーサーの proto レコードの自然キーを指定することで、レコードをメタデータインスタンスにリンクできます。このメタデータインスタンスのリンク方法は、移行元メッセージに有効な proto インスタンスを構築するためのコンテキスト情報がすでに含まれている場合に特に便利です。

proto メタデータインスタンスを使用してレコードをクラウドメタデータインスタンスにリンクする場合は、次の点を考慮してください。

自然キーを省略すると、バケットタイプに応じて MDE が自動的に選択します。
TAG バケットのコンテキスト内の proto インスタンスで自然キーを省略すると、MDE は tagName を自然キーとして自動的に選択します。
RECORD バケットのコンテキスト内の proto インスタンスで自然キーを省略すると、MDE はメッセージオブジェクトのハッシュ値を自動的に生成し、それを自然キーとして使用します。
指定された proto インスタンスが、指定された自然キーの最新のメタデータインスタンスと一致する場合、MDE は指定された proto インスタンスを一致するインスタンスの UUID に置き換え、UUID をレコードに保存します。
指定された proto インスタンスが、指定された自然キーの最新のメタデータインスタンスと一致しない場合、MDE は指定された自然キーの新しいメタデータインスタンスを作成し、新しく作成されたインスタンスの UUID をレコードに保存します。このシステムの動作により、ソースメッセージから生成されたインスタンスを使用してメタデータバケットを動的に入力できます。

proto メタデータインスタンスを使用してレコードをメタデータインスタンスにリンクする方法については、インスタンス値でメタデータインスタンス ID を解決するをご覧ください。

インスタンスのマテリアライズ

メタデータインスタンスの UUID を保存するだけでなく、レコードにインスタンス全体を含めることもできます。これは実体化と呼ばれます。この動作は、シンクの materializeCloudMetadata フィールドの値を true に設定することで、タイプレベルでシンクごとに構成できます。

たとえば、BigQuery シンクのメタデータマテリアライズを有効にすると、メタデータインスタンス参照を含むレコードに対して次のような行が生成されます。

{
  "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"
}

埋め込みメタデータ

急速に変化するメタデータは、急速に変化するコンテキストデータを表します。メタデータが急速に変化する一般的な例としては、自動インクリメントされるカウンタや ID（シリアル番号やトランザクション ID など）があります。

MDE では、Whistle を使用して急速に変化するメタデータを構造化、調和、変換し、パーサーの proto レコードの embeddedMetadata というフィールドに入力することで、レコードに直接埋め込むことができます。

サポートされているすべての MDE データシンクで、埋め込みメタデータを使用できます。たとえば、パーサーの proto レコードの embeddedMetadata フィールドに値を入力すると、BigQuery の結果レコードに次のような行が生成されます。

{
  "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"
}

メタデータの自動削除

レコードとタグの両方のメタデータについて、MDE は、新しいインスタンスと古いインスタンスを比較することで、各自然キーで発生した変更を追跡します。インスタンス属性のいずれかに変更があると、MDE は新しいバージョンを作成し、それを最新の有効なインスタンスとしてマークします。設計上、タグとレコードのメタデータは数千から数十万の粒度になることが想定されています。これらの制限により、MDE は処理スループットに影響を与えることなく、エッジまたは API から取得したメタデータインスタンスをインデックス登録できます。

構成エラーが原因で、パーサーがメタデータインスタンスにタイムスタンプなどの高カーディナリティフィールドを挿入することがあります。これにより、各自然キーのバージョンが急速に増加します。一定のしきい値を超えると、取り込みのパフォーマンスに悪影響を及ぼします。場合によっては、基盤となるクラウドインフラストラクチャサービスがソリューション管理者のスケーリングによって拡張されるまで、処理が完全に停止することがあります。

v1.4.0 以降、MDE は一貫したパフォーマンスを確保するために、自然キーあたりのインスタンスの最大数を適用します。自然キーの数がこのしきい値（デフォルトは 200）に近づくと、MDE は新しい通知 API に警告を送信し、メタデータインスタンスバージョンの数が多い自然キーをユーザーに通知します。自然キーインスタンスのサイズがしきい値を超えると、MDE は古いインスタンスを内部ストアから自動的に削除します。また、削除された自然キーをユーザーに通知する別の通知を Notifications API に送信します。

警告と削除のアクティビティは両方ともログに記録されます。このログを使用して、プロジェクトの Cloud Monitoring でアラートポリシーを作成できます。

メタデータバケットの命名に関する制限事項

メタデータバケット名には次のものを含めることができます。

文字（大文字と小文字）、数字、特殊文字 - と _。
255 文字以内で指定できます。

検証には、次の正規表現を使用できます。^[a-z][a-z0-9\\-_]{1,255}$

命名制限に違反するエンティティを作成しようとすると、400 error が返されます。

メタデータ

クラウド メタデータ

メタデータ バケット

メタデータ インスタンス

メタデータ バケット スキーマ

メタデータ インスタンスの検証