메타데이터

메타데이터는 Manufacturing Data Engine (MDE)의 핵심 개념입니다. 사실에 관한 맥락 데이터를 나타냅니다. 예를 들어 센서 판독값이나 이벤트가 있습니다. 메타데이터는 다음과 같은 질문에 답하는 데 도움이 됩니다.

  • 어떤 태그에서 숫자 판독값을 내보냈나요?
  • 숫자 측정값을 가져올 때 처리 중인 제품은 무엇이었나요?
  • 센서가 속한 기기는 무엇인가요?
  • 이벤트가 발생한 시점에 어떤 교대가 진행 중이었나요?
  • 읽기 시점에 활성화된 레시피는 무엇이었나요?

MDE는 변경 속도에 따라 두 가지 유형의 메타데이터를 구분합니다.

  1. 클라우드 메타데이터가 느리게 변경됩니다.
  2. 빠르게 변화하는 삽입된 메타데이터

클라우드 메타데이터

지연 변경 메타데이터는 장기간 변경되지 않는 컨텍스트 데이터를 나타냅니다. 예를 들어 특정 센서의 머신, 셀, 라인, 플랜트를 설명하는 애셋 컨텍스트가 있습니다. MDE를 사용하면 느리게 변경되는 메타데이터를 모델링, 관리, 탐색하고 레코드에 연결할 수 있습니다. 메타데이터가 레코드에 연결되면 연결된 컨텍스트를 사용하여 레코드를 탐색할 수 있습니다.

MDE의 지연 변경 메타데이터를 클라우드 메타데이터라고 합니다. 클라우드 메타데이터는 솔루션에서 두 가지 기능을 수행합니다.

  1. 레코드에 컨텍스트를 부여하고 레코드를 분류합니다.
  2. 센서, 기기, 라인과 같은 제조 엔티티에 관한 버전이 지정된 마스터 데이터의 소스로 사용됩니다.

MDE를 사용하면 에지에서 클라우드 메타데이터를 가져오거나, MDE 웹 인터페이스를 사용하여 수동으로 만들거나, API를 사용하여 프로그래매틱 방식으로 만들 수 있습니다. 후자를 사용하면 기존 엔터프라이즈 애셋 관리 (EAM) 또는 마스터 데이터 관리 (MDM) 시스템에서 메타데이터를 가져올 수 있습니다.

메타데이터 버킷

클라우드 메타데이터 버킷('버킷' 또는 '메타데이터 버킷'이라고도 함)은 천천히 변경되는 관련 컨텍스트 데이터 세트를 모델링하는 구성 항목입니다. 예를 들어 버킷은 태그 또는 레시피의 속성을 모델링할 수 있습니다. 버킷은 데이터 분석 도메인의 데이터 측정기준으로 생각할 수 있습니다.

메타데이터 버킷의 주요 속성은 스키마입니다. 스키마 (JSON 스키마 객체로 표현됨)는 스키마 내에 포함된 메타데이터 인스턴스의 구조를 정의하고 제한합니다. 새 메타데이터 버킷 버전을 만들 수 있지만 새 버전은 클라우드 메타데이터 버킷 버전 관리 규칙을 준수해야 합니다.

버킷은 전역이므로 모든 유형에서 참조할 수 있습니다.

메타데이터 인스턴스

메타데이터 인스턴스는 클라우드 메타데이터 버킷의 '콘텐츠'를 나타냅니다. 각 인스턴스는 애셋, 프로세스 또는 캡처되는 레코드의 측면과 같은 항목을 설명합니다. 인스턴스에는 두 가지 유형의 식별자가 있습니다.

  1. MDE 내에서 인스턴스를 식별하는 시스템 생성 UUID (범용 고유 식별자)입니다.
  2. MDE 외부에서 항목을 식별하는 자연 키 (예: 센서의 일련번호)입니다.

메타데이터 인스턴스는 자연 키에 따라 버전이 지정됩니다. 즉, MDE는 지정된 자연 키의 속성 변화를 추적합니다. 예를 들어 자연 키가 'tag-123'인 태그가 처음에는 'X' 셀에 있었지만 나중에 'Y' 셀로 이동할 수 있습니다. MDE는 각 인스턴스를 저장하고 타임스탬프를 지정하며 고유한 UUID를 부여합니다. 이 고유 UUID를 사용하면 자연 키의 인스턴스 기록을 가져오고, 수집 시 올바른 인스턴스로 레코드에 컨텍스트를 부여하고, 쿼리 시 과거 레코드에 인스턴스를 소급 적용할 수 있습니다.

v1.5.0부터 메타데이터 인스턴스는 processing time이 아닌 event-time에 따라 버전이 지정되고 처리됩니다. 이전 기록이 있는 메타데이터 인스턴스를 전송하면 MDE가 메시지의 eventTimestamp에 따라 해당 메타데이터 인스턴스를 버전 관리하므로 최신 인스턴스를 변경하지 않고 이전 메타데이터와 최신 메타데이터가 공존할 수 있습니다. 자세한 내용은 버전 관리 메타데이터 버킷을 참고하세요.

MDE에서는 해당 버킷의 특정 버전 스키마를 준수하는 인스턴스만 버킷에 추가할 수 있습니다.

메타데이터 버킷 스키마

각 메타데이터 버킷 버전에는 스키마가 포함되어 있으며 메타데이터 인스턴스는 버킷의 특정 버전에만 추가할 수 있습니다. 스키마는 버킷 버전에 추가할 수 있는 메타데이터 인스턴스의 구조를 추가로 제한합니다.

메타데이터 버킷 스키마는 JSON 스키마 사양의 2019년 9월 버전에 따라 JSON 스키마 객체로 표현됩니다.

예를 들어 스키마가 나중에 버킷 버전에 추가된 경우 각 인스턴스 객체에는 string 값이 있는 deviceName라는 속성이 있어야 하며 이 속성은 필수라고 명시됩니다. 아래 예시를 참조하세요.

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

메타데이터 인스턴스 유효성 검사

메타데이터 인스턴스는 삽입되려면 특정 메타데이터 버킷 버전에 정의된 스키마를 준수해야 합니다.

버킷 유형

MDE는 세 가지 유형의 버킷을 정의합니다.

  1. 태그 버킷
  2. Record 버킷
  3. 조회 버킷

버킷의 유형은 생성 시 정의되며 이후 변경할 수 없습니다.

버킷 태그 지정

태그 버킷은 태그에 컨텍스트를 부여하는 버킷을 나타냅니다. 이는 버킷에 포함된 인스턴스의 기본 키가 태그 이름이어야 함을 의미합니다.

레코드 버킷

레코드 버킷은 공통 자연 키를 공유하는 레코드 그룹에 컨텍스트를 부여할 수 있는 버킷을 나타냅니다. 레코드 버킷 인스턴스의 기본 키는 어떤 값이라도 될 수 있습니다.

버킷 조회

조회 버킷은 레코드에 직접 컨텍스트를 부여하지는 않지만 파서에서 사용할 수 있는 참조 데이터를 제공하는 버킷을 나타냅니다. 조회 버킷 인스턴스의 기본 키는 어떤 값이든 될 수 있습니다.

레코드 버킷 인스턴스는 레코드에 연결되지 않습니다. 대신 휘슬 스크립트에서 mde::lookupByKey 함수를 호출하여 조회 버킷에서 인스턴스를 가져올 수 있습니다. 이 함수는 조회 bucketName, bucketVersion, naturalKey를 인수로 사용하고 제공된 자연 키의 최신 메타데이터 인스턴스를 반환합니다. 이 인스턴스를 사용하여 파서의 프로토 레코드에 필드를 채울 수 있습니다.

버전 관리 메타데이터 버킷

메타데이터 버킷의 스키마는 발전할 수 있지만 스키마를 수정하려면 버킷의 새 버전을 만들어야 합니다. 기존 버킷 버전과 이전 버킷 버전을 참조하는 기존 구성 항목은 이 작업의 영향을 받지 않습니다. 메타데이터 버킷의 전체 기간에 걸쳐 데이터 일관성을 보장하기 위해 새 메타데이터 버킷 스키마 버전에는 다음 제한사항이 적용됩니다.

새 버전은 다음을 충족해야 합니다.

  • 새 선택사항 필드를 추가합니다.
  • 필수 입력란을 선택사항으로 표시합니다.

새 버전은 다음을 충족해야 합니다.

  • 필드를 삭제합니다.
  • 기존 필드의 데이터 유형을 변경합니다.
  • 선택적 속성을 필수 속성으로 표시합니다.

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는 파서에서 이 링크를 만드는 두 가지 방법을 제공합니다.

  1. 인스턴스의 자연 키를 제공합니다.
  2. 프로토 메타데이터 인스턴스를 제공합니다.

예를 들어 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"
}

기본 키를 사용하여 레코드를 클라우드 메타데이터 인스턴스에 연결

파서에서 클라우드 메타데이터 버전에 대한 참조와 프로토 레코드에 있는 인스턴스의 기본 키를 제공하여 레코드를 메타데이터 인스턴스에 연결할 수 있습니다. MDE는 인스턴스의 자연 키를 UUID(있는 경우)로 자동 교환하고 레코드에 링크를 저장합니다. 제공된 기본 키에 여러 인스턴스가 있는 경우 MDE는 가장 최근 인스턴스 (가장 최근 created_timestamp가 있는 인스턴스)를 선택합니다.

참조된 버킷이 TAG 버킷인 경우 자연 키를 제공하는 것은 선택사항입니다. 기본 키를 생략하면 MDE는 기본적으로 tagName 필드의 값을 사용합니다.

기본 키를 사용하여 레코드를 메타데이터 인스턴스에 연결하는 방법에 대한 자세한 내용은 기본 키로 메타데이터 instance_id 해결을 참고하세요.

프로토 메타데이터 인스턴스를 사용하여 레코드를 클라우드 메타데이터 인스턴스에 연결

클라우드 메타데이터 버전에 대한 참조를 제공하고 파서에서 프로토 메타데이터 인스턴스와 선택적으로 프로토 레코드의 자연 키를 제공하여 레코드를 메타데이터 인스턴스에 연결할 수 있습니다. 이 메타데이터 인스턴스 연결 방법은 소스 메시지에 이미 유효한 프로토 인스턴스를 구성하기 위한 컨텍스트 정보가 포함되어 있는 경우에 특히 유용합니다.

프로토 메타데이터 인스턴스를 사용하여 레코드를 클라우드 메타데이터 인스턴스에 연결할 때는 다음 사항을 고려하세요.

  • 자연 키를 생략하면 MDE에서 버킷 유형에 따라 자동으로 선택합니다.
  • TAG 버킷 컨텍스트 내에서 프로토 인스턴스의 자연 키를 생략하면 MDE가 tagName를 자연 키로 자동 선택합니다.
  • RECORD 버킷 컨텍스트 내의 프로토 인스턴스에서 자연 키를 생략하면 MDE가 메시지 객체의 해시 값을 자동으로 생성하고 이를 자연 키로 사용합니다.
  • 제공된 프로토 인스턴스가 제공된 자연 키의 최신 메타데이터 인스턴스와 일치하는 경우 MDE는 제공된 프로토 인스턴스를 일치하는 인스턴스의 UUID로 교체하고 UUID를 레코드에 저장합니다.
  • 제공된 프로토 인스턴스가 제공된 자연 키의 메타데이터 인스턴스와 일치하지 않는 경우 MDE는 제공된 자연 키의 새 메타데이터 인스턴스를 만들고 새로 생성된 인스턴스의 UUID를 레코드에 저장합니다. 이러한 시스템 동작을 통해 소스 메시지에서 생성된 인스턴스로 메타데이터 버킷을 동적으로 채울 수 있습니다.

프로토 메타데이터 인스턴스를 사용하여 레코드를 메타데이터 인스턴스에 연결하는 방법에 대한 자세한 내용은 인스턴스 값으로 메타데이터 인스턴스 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을 사용하여 빠르게 변화하는 메타데이터를 구조화, 조화, 변환하고 파서의 프로토 레코드에서 embeddedMetadata라는 필드를 채워 레코드에 직접 삽입할 수 있습니다.

지원되는 모든 MDE 데이터 싱크는 삽입된 메타데이터를 사용할 수 있도록 합니다. 예를 들어 파서의 프로토 레코드에서 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는 새 버전을 만들어 최신 유효 인스턴스로 표시합니다. 설계상 태그와 레코드 메타데이터는 수천 개에서 10만 개 미만의 세부사항으로 구성됩니다. 이러한 제한사항을 통해 MDE는 처리량에 영향을 주지 않고 에지 또는 API에서 제공되는 메타데이터 인스턴스를 색인화할 수 있습니다.

구성 오류로 인해 파서가 메타데이터 인스턴스에 타임스탬프와 같은 카디널리티가 높은 필드를 삽입하여 각 자연 키의 버전이 빠르게 확산되는 경우가 있습니다. 특정 기준점을 넘으면 수집 성능에 부정적인 영향을 미칩니다. 기본 클라우드 인프라 서비스가 솔루션 관리자에 의해 확장될 때까지 처리가 완전히 중지될 수도 있습니다.

v1.4.0부터 MDE는 일관된 성능을 보장하기 위해 자연 키당 최대 인스턴스 수를 적용합니다. 자연 키 수가 이 기준값 (기본값은 200)에 도달하면 MDE는 새로운 알림 API에 경고를 보내 메타데이터 인스턴스 버전 수가 많은 자연 키를 사용자에게 알립니다. 자연 키 인스턴스 크기가 기준점을 위반하면 MDE가 내부 저장소에서 이전 인스턴스를 자동으로 삭제합니다. 또한 삭제된 기본 키를 사용자에게 알리는 다른 알림을 알림 API에 전송합니다.

경고 및 삭제 활동은 모두 로그에 보고되므로 프로젝트 Cloud Monitoring에서 알림 정책을 만드는 데 사용할 수 있습니다.

메타데이터 버킷 이름 지정 제한사항

메타데이터 버킷 이름은 다음을 포함할 수 있습니다.

  • 문자 (대문자 및 소문자), 숫자, 특수문자 - 및 _
  • 최대 255자(영문 기준)까지 가능합니다.

검증에 다음 정규 표현식을 사용할 수 있습니다. ^[a-z][a-z0-9\\-_]{1,255}$

이름 지정 제한을 위반하는 항목을 만들려고 하면 400 error 오류가 발생합니다.