스키마 작성 기본 사항

이 문서에서는 Adobe Experience Platform에서 사용할 스키마를 구성하기 위한 Experience Data Model (XDM) 스키마 및 빌딩 블록, 원칙 및 모범 사례를 소개합니다. XDM 및 Platform 내에서 사용하는 방법에 대한 일반적인 정보는 XDM 시스템 개요를 참조하십시오.

스키마 이해

스키마는 데이터의 구조와 형식을 나타내고 유효성을 검사하는 규칙 세트입니다. 높은 수준에서 스키마는 실제 개체(예: 사람)에 대한 추상적인 정의를 제공하고, 해당 개체의 각 인스턴스(이름, 성, 생일 등)에 어떤 데이터를 포함해야 하는지 설명합니다.

스키마는 데이터 구조를 설명하는 것 외에도 데이터 간에 이동할 때 유효성이 확인될 수 있도록 데이터 제한 및 기대치를 적용합니다. 이러한 표준 정의를 사용하면 출처에 관계없이 일관되게 데이터를 해석할 수 있으며 응용 프로그램 간에 번역이 필요하지 않습니다.

Experience Platform 스키마를 사용하여 이 의미 체계 표준화를 유지합니다. 스키마는 Experience Platform에서 데이터를 설명하는 표준 방법으로서, 스키마를 따르는 모든 데이터를 충돌 없이 조직 간에 재사용하거나 여러 조직 간에 공유할 수 있습니다.

XDM 스키마는 방대한 양의 복잡한 데이터를 자체 포함된 형식으로 저장하는 데 이상적입니다. XDM에서 이 작업을 수행하는 방법에 대한 자세한 내용은 이 문서의 부록에서 포함된 개체빅데이터의 섹션을 참조하십시오.

Experience Platform의 스키마 기반 워크플로우

표준화는 Experience Platform 뒤의 핵심 개념입니다. Adobe 기반의 XDM은 고객 경험 데이터를 표준화하고 고객 경험 관리를 위한 표준 스키마를 정의하려는 노력입니다.

Experience Platform이(가) 구축되는 인프라에서는 XDM System (으)로 인해 스키마 기반 워크플로우를 용이하게 하고 Schema Registry, Schema Editor, 스키마 메타데이터 및 서비스 사용 패턴을 포함합니다. 자세한 내용은 XDM 시스템 개요를 참조하십시오.

Experience Platform에서 스키마를 활용할 수 있는 몇 가지 주요 이점이 있습니다. 먼저 스키마에서는 데이터 거버넌스 및 데이터 최소화를 허용하므로 개인 정보 보호 규정에 특히 중요합니다. 둘째, Adobe의 표준 구성 요소를 사용하여 스키마를 구축하면 최소한의 사용자 지정으로 AI/ML 서비스를 곧바로 사용할 수 있습니다. 마지막으로 스키마는 데이터 공유 통찰력과 효율적인 오케스트레이션을 위한 인프라를 제공합니다.

스키마 계획

스키마를 구축하는 첫 번째 단계는 스키마 내에서 캡처하려고 하는 개념이나 실제 개체를 결정하는 것입니다. 설명하려는 개념을 식별하면 데이터 유형, 잠재적 ID 필드 및 나중에 스키마가 어떻게 발전할 수 있는지에 대해 생각하여 스키마 계획을 시작할 수 있습니다.

Experience Platform의 데이터 동작

Experience Platform에 사용하기 위한 데이터는 두 가지 동작 유형으로 그룹화됩니다.

  • 데이터 기록: 주체의 특성에 대한 정보를 제공합니다. 주제는 조직 또는 개인일 수 있습니다.
  • 시계열 데이터: 작업 수행 시 레코드 주체가 직접 또는 간접적으로 시스템의 스냅샷을 제공합니다.

모든 XDM 스키마에서는 레코드 또는 시계열로 분류할 수 있는 데이터를 설명합니다. 스키마의 데이터 동작은 처음 만들 때 스키마에 할당된 스키마 클래스에 의해 정의됩니다. XDM 클래스는 이 문서의 후반부에 자세히 설명되어 있습니다.

레코드와 시계열 스키마에는 ID 맵이 포함되어 있습니다(xdm:identityMap). 이 필드에는 다음 섹션에 설명된 대로 "ID"로 표시된 필드에서 추출된 주체의 ID 표현이 포함되어 있습니다.

ID

스키마는 Experience Platform에 데이터를 수집하는 데 사용됩니다. 이 데이터는 여러 서비스에서 사용하여 개별 엔터티에 대한 단일 통합 보기를 만들 수 있습니다. 따라서 스키마를 생각할 때 고객 ID와 데이터가 어디에서 왔는지에 관계없이 대상을 식별하는 데 사용할 수 있는 필드를 고려하는 것이 중요합니다.

이 프로세스를 지원하기 위해 스키마 내의 키 필드를 ID로 표시할 수 있습니다. 데이터 섭취 시 해당 필드의 데이터는 해당 개인의 "Identity Graph"에 삽입됩니다. 그런 다음 Real-time Customer Profile 및 다른 Experience Platform 서비스에서 그래프 데이터에 액세스하여 각 개별 고객에 대한 결합 보기를 제공할 수 있습니다.

일반적으로 "Identity"로 표시된 필드는 다음과 같습니다. 이메일 주소, 전화번호, Experience Cloud ID (ECID), CRM ID 또는 기타 고유한 ID 필드. 또한 "Identity" 필드도 적합할 수 있으므로 조직에 고유한 식별자를 고려해야 합니다.

가장 강력한 프로필을 만들기 위해 데이터를 함께 가져올 수 있도록 하려면 스키마 계획 단계 동안 고객 ID를 고려하는 것이 중요합니다. ID 정보를 통해 고객에게 디지털 경험을 전달하는 데 도움이 되는 방법에 대한 자세한 내용은 Adobe Experience Platform Identity 서비스의 개요를 참조하십시오.

ID 데이터를 Platform으로 전송하는 방법에는 두 가지가 있습니다.

  1. 스키마 편집기 UI를 통해 또는 스키마 레지스트리 API를 사용하여 개별 필드에 ID 설명자를 추가합니다
  2. identityMap 필드 사용

identityMap

identityMap 는 연관된 네임스페이스와 함께 개인의 다양한 ID 값을 설명하는 맵 유형 필드입니다. 이 필드는 스키마 자체의 구조 내에서 ID 값을 정의하는 대신 스키마에 대한 ID 정보를 제공하는 데 사용할 수 있습니다.

identityMap을 사용하는 주요 단점은 ID가 데이터에 포함되고 그 결과 볼 수 없게 된다는 것입니다. 원시 데이터를 수집하는 경우 실제 스키마 구조 내에서 개별 ID 필드를 대신 정의해야 합니다.

노트

identityMap을 사용하는 스키마는 관계에서 소스 스키마로 사용할 수 있지만 대상 스키마로 사용할 수 없습니다. 모든 대상 스키마에는 소스 스키마 내의 참조 필드에 매핑할 수 있는 표시 ID가 있어야 하기 때문입니다. 소스 및 대상 스키마의 요구 사항에 대한 자세한 내용은 관계의 UI 안내서를 참조하십시오.

그러나 ID 맵은 ID를 함께 저장하는 소스(예: Airship 또는 Adobe Audience Manager)에서 데이터를 가져오는 경우나 스키마에 대한 ID가 여러 개 있는 경우 특히 유용합니다. 또한 Adobe Experience Platform Mobile SDK를 사용하는 경우 ID 맵이 필요합니다.

간단한 ID 맵의 예는 다음과 같습니다.

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": false
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "loyaltyId": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": true
    }
  ]
}

위의 예제와 같이 identityMap 개체의 각 키는 ID 네임스페이스를 나타냅니다. 각 키의 값은 각 네임스페이스에 대한 ID 값(id)을 나타내는 개체 배열입니다. Adobe 애플리케이션에서 인식하는 표준 ID 네임스페이스 목록은 Identity Service 설명서를 참조하십시오.

노트

값이 기본 ID(primary)인지 여부에 대한 부울 값을 각 ID 값에 제공할 수도 있습니다. 기본 ID는 Real-time Customer Profile에 사용하려는 스키마에 대해서만 설정해야 합니다. 자세한 내용은 결합 스키마의 섹션을 참조하십시오.

스키마 진화 원칙

디지털 경험의 특성이 계속 진화하므로 디지털 경험을 나타내는 데 사용되는 스키마가 있어야 합니다. 따라서 잘 디자인된 스키마는 이전 버전의 스키마에 대한 파괴적인 변경 사항을 야기하지 않고 필요에 따라 조정 및 발전할 수 있습니다.

스키마 진화에 있어 이전 버전과의 호환성을 유지하는 것이 중요하므로 Experience Platform에서는 순전히 첨가제 버전 관리 원리를 적용합니다. 이 원칙은 스키마 수정 사항이 비파괴 업데이트 및 변경만 발생하도록 합니다. 즉, 변경 내용을 바꿀 수 없습니다.

노트

스키마를 Experience Platform에 수집하는 데 아직 사용하지 않았으며, 실시간 고객 프로필에서 사용할 수 있도록 활성화되지 않은 경우 해당 스키마에 대한 변경 사항이 적용될 수 있습니다. 그러나 스키마를 Platform에 사용한 후에는 추가 버전 관리 정책을 준수해야 합니다.

다음 표에서는 스키마, 필드 그룹 및 데이터 유형을 편집할 때 지원되는 변경 사항을 설명합니다.

지원되는 변경 사항 변경 내용 변경(지원되지 않음)
  • 리소스에 새 필드 추가
  • 필수 필드를 선택 사항으로 만들기
  • 리소스의 표시 이름 및 설명 변경
  • 스키마에 프로필 참여 활성화
  • 이전에 정의한 필드 제거
  • 새 필수 필드 소개
  • 기존 필드 이름 바꾸기 또는 재정의
  • 이전에 지원되는 필드 값 제거 또는 제한
  • 기존 필드를 트리의 다른 위치로 이동
  • 스키마 삭제
  • 스키마에 프로필 사용 안 함

스키마 및 데이터 수집

데이터를 Experience Platform에 수집하려면 먼저 데이터 세트를 만들어야 합니다. 데이터 세트는 Catalog Service에 대한 데이터 변환 및 추적을 위한 기본 구성단위이며 일반적으로 수집된 데이터가 포함된 테이블 또는 파일을 나타냅니다. 모든 데이터 세트는 수집된 데이터에 포함해야 하는 제약 조건 및 구조화 방법에 대한 기존 XDM 스키마를 기반으로 합니다. 자세한 내용은 Adobe Experience Platform 데이터 수집에 대한 개요를 참조하십시오.

스키마 빌딩 블록

Experience Platform 에서는 표준 빌딩 블록을 결합하여 스키마를 생성하는 컴포지션 접근 방식을 사용합니다. 이 접근 방식은 기존 구성 요소의 재사용을 촉진하고 업계 전반에서 표준화를 구동하여 Platform에 있는 공급업체 스키마와 구성 요소를 지원합니다.

스키마는 다음 공식을 사용하여 작성됩니다.

클래스 + 스키마 필드 그룹(&A); = XDM 스키마

*스키마는 클래스와 0개 이상의 스키마 필드 그룹으로 구성됩니다. 즉, 필드 그룹을 전혀 사용하지 않고 데이터 세트 스키마를 작성할 수 있습니다.

클래스

스키마 작성은 클래스를 할당하여 시작됩니다. 클래스는 스키마에 포함할 데이터의 행동 측면(레코드 또는 시계열)을 정의합니다. 이 외에도 클래스는 해당 클래스를 기반으로 하는 모든 스키마에는 여러 호환 데이터 세트를 병합하는 방법을 포함하고 제공해야 하는 가장 작은 수의 공통 속성을 설명합니다.

스키마의 클래스는 해당 스키마에 사용할 수 있는 필드 그룹을 결정합니다. 이 내용은 다음 섹션에서 자세히 설명합니다.

Adobe은 몇 가지 표준("core") XDM 클래스를 제공합니다. 이러한 클래스 중 두 개, XDM Individual Profile 및 XDM ExperienceEvent 는 거의 모든 다운스트림 플랫폼 프로세스에 필요합니다. 이러한 핵심 클래스 외에도, 고유한 사용자 지정 클래스를 만들어 조직에 대한 더 구체적인 사용 사례를 설명할 수도 있습니다. 사용자 정의 클래스는 고유한 사용 사례를 설명하는 데 사용할 수 있는 Adobe 정의 핵심 클래스가 없는 경우 조직에서 정의합니다.

다음 스크린샷에서는 플랫폼 UI에서 클래스가 표시되는 방법을 보여줍니다. 표시된 예제 스키마에는 필드 그룹이 없으므로 표시된 모든 필드는 스키마 클래스(XDM Individual Profile)에서 제공합니다.

사용 가능한 표준 XDM 클래스의 최신 목록을 보려면 공식 XDM 저장소를 참조하십시오. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색 의 안내서를 참조할 수 있습니다.

필드 그룹

필드 그룹은 개인 세부 정보, 호텔 환경 설정 또는 주소와 같은 특정 기능을 구현하는 필드를 하나 이상 정의하는 재사용 가능한 구성 요소입니다. 필드 그룹은 호환 클래스를 구현하는 스키마의 일부로 포함되기 위한 것입니다.

필드 그룹은 표시되는 데이터의 동작(레코드 또는 시계열)을 기반으로 호환되는 클래스를 정의합니다. 즉, 모든 필드 그룹을 모든 클래스에서 사용할 수는 없습니다.

Experience Platform 에는 여러 표준 Adobe 필드 그룹이 포함되어 있으며 공급업체는 해당 사용자에 대한 필드 그룹을 정의할 수 있으며 개별 사용자는 고유한 개념에 대한 필드 그룹을 정의할 수 있습니다.

예를 들어 "충성도 멤버" 스키마에 대한 "이름" 및 "홈 주소"와 같은 세부 정보를 캡처하려면 이러한 일반적인 개념을 정의하는 표준 필드 그룹을 사용할 수 있습니다. 그러나 덜 일반적인 사용 사례(예: "로열티 프로그램 수준")에만 해당하는 개념에는 사전 정의된 필드 그룹이 없는 경우가 많습니다. 이 경우 이 정보를 캡처하려면 고유한 필드 그룹을 정의해야 합니다.

노트

이러한 필드는 Experience Platform 서비스에서 암묵적으로 이해하며 Platform 구성 요소에서 사용할 때 더 높은 일관성을 제공하므로 스키마에서 가능한 한 표준 필드 그룹을 사용하는 것이 좋습니다.

표준 구성 요소에서 제공하는 필드(예: "이름" 및 "이메일 주소")에는 기본 스칼라 필드 형식을 벗어나는 추가된 의미가 들어, Platform에서 동일한 데이터 유형을 공유하는 필드는 동일한 방식으로 동작한다고 알려줍니다. 이 동작은 데이터가 어디에서 오거나 데이터를 사용 중인 Platform 서비스에 관계없이 일관되도록 신뢰할 수 있습니다.

스키마는 "0 이상" 필드 그룹으로 구성되므로 필드 그룹을 전혀 사용하지 않고 유효한 스키마를 구성할 수 있습니다.

다음 스크린샷에서는 Platform UI에서 필드 그룹이 표시되는 방식을 보여줍니다. 스키마 구조에 필드를 그룹화하는 기능을 제공하는 단일 필드 그룹(인구 통계 세부 정보)이 이 예제의 스키마에 추가됩니다.

사용 가능한 표준 XDM 필드 그룹의 최신 목록을 보려면 공식 XDM 저장소를 참조하십시오. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색 의 안내서를 참조할 수 있습니다.

데이터 유형

데이터 유형은 기본 리터럴 필드와 같은 방식으로 클래스 또는 스키마에서 참조 필드 유형으로 사용됩니다. 가장 중요한 차이점은 데이터 유형이 여러 하위 필드를 정의할 수 있다는 것입니다. 데이터 유형은 필드 그룹과 유사하게 다중 필드 구조를 일관되게 사용할 수 있지만, 필드의 "데이터 유형"으로 추가하여 스키마 내 어느 곳에서든 데이터 유형을 포함할 수 있으므로 필드 그룹보다 유연합니다.

Experience Platform 에서는 공통 데이터 구조를 설명하는 표준 패턴 사용을 Schema Registry 지원하기 위해 의 일부로 많은 공통 데이터 유형을 제공합니다. 이 내용은 Schema Registry 자습서에서 자세히 설명되며, 여기에서 데이터 유형을 정의하는 단계를 진행하면 더 명확해집니다.

다음 스크린샷에서는 Platform UI에서 데이터 유형이 표시되는 방식을 보여줍니다. 인구 통계 세부 정보 필드 그룹에서 제공하는 필드 중 하나는 필드 이름 옆에 파이프 문자(|) 다음에 나오는 텍스트로 표시된 대로 "개인 이름" 데이터 유형을 사용합니다. 이 특정 데이터 유형에서는 개인 이름과 관련된 여러 하위 필드를 제공하며, 개인 이름을 캡처해야 하는 다른 필드에 다시 사용할 수 있습니다.

사용 가능한 표준 XDM 데이터 유형의 최신 목록은 공식 XDM 저장소를 참조하십시오. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색 의 안내서를 참조할 수 있습니다.

필드

필드는 스키마의 가장 기본적인 빌딩 블록입니다. 필드는 특정 데이터 유형을 정의하여 포함할 수 있는 데이터 유형에 대한 제한을 제공합니다. 이러한 기본 데이터 유형은 단일 필드를 정의하는 반면, 이전에 언급된 데이터 유형에서는 여러 하위 필드를 정의하고 다양한 스키마에서 동일한 다중 필드 구조를 다시 사용할 수 있습니다. 따라서 필드의 "데이터 형식"을 레지스트리에 정의된 데이터 형식 중 하나로 정의하는 것 외에도 Experience Platform은 다음과 같은 기본 스칼라 형식을 지원합니다.

  • 문자열
  • 정수
  • 이중
  • 부울
  • 어레이
  • 개체

개체 유형 필드에서 자유 형식 필드를 사용하는 장단점에 대한 자세한 내용은 부록을 참조하십시오.

이러한 스칼라 형식의 유효한 범위는 특정 패턴, 형식, 최소/최대 또는 사전 정의된 값으로 추가로 제한될 수 있습니다. 이러한 제한을 사용하면 다음을 포함하여 보다 다양한 특정 필드 유형을 나타낼 수 있습니다.

  • 열거형
  • Long
  • Short
  • 바이트
  • 날짜
  • 날짜-시간
노트

맵 필드 유형을 사용하면 단일 키에 대한 여러 값을 포함하여 키-값 쌍 데이터를 사용할 수 있습니다. 맵은 시스템 수준에서만 정의할 수 있습니다. 즉, 업계 또는 공급업체 정의 스키마에서 맵이 표시될 수 있지만 사용자가 정의한 필드에서는 사용할 수 없습니다. 필드 유형 정의에 대한 자세한 내용은 스키마 레지스트리 API 개발자 안내서를 참조하십시오.

컴포지션 예

스키마는 Platform에 수집할 데이터의 형식 및 구조를 나타내며 컴포지션 모델을 사용하여 빌드됩니다. 이전에 언급했듯이 이러한 스키마는 해당 클래스와 호환되는 클래스 및 0개 이상의 필드 그룹으로 구성됩니다.

예를 들어 소매 저장소에서 이루어지는 구매를 설명하는 스키마는 "Store Transactions"이라고 할 수 있습니다. 이 스키마는 표준 Commerce 필드 그룹 및 사용자 정의 제품 정보 필드 그룹과 결합된 XDM ExperienceEvent 클래스를 구현합니다.

웹 사이트 트래픽을 추적하는 다른 스키마는 "웹 방문"이라고 할 수 있습니다. 또한 XDM ExperienceEvent 클래스를 구현하지만, 이번에는 표준 Web 필드 그룹을 결합합니다.

아래 다이어그램은 이러한 스키마와 각 필드 그룹에서 제공하는 필드를 보여줍니다. 또한 이 안내서에는 XDM Individual Profile 클래스 기반의 두 개의 스키마가 포함되어 있습니다. 여기에는 이 안내서에서 이전에 언급된 "충성도 멤버" 스키마가 포함되어 있습니다.

합집합

Experience Platform 에서는 특정 사용 사례에 대해 스키마를 작성할 수 있지만, 특정 클래스 유형에 대한 스키마의 "결합"을 볼 수도 있습니다. 이전 다이어그램은 XDM ExperienceEvent 클래스를 기반으로 하는 두 개의 스키마와 XDM Individual Profile 클래스를 기반으로 하는 두 개의 스키마를 보여줍니다. 아래 표시된 결합은 동일한 클래스(XDM ExperienceEvent 및 XDM Individual Profile)를 공유하는 모든 스키마의 필드를 집계합니다.

Real-time Customer Profile에 사용할 스키마를 활성화하면 해당 클래스 유형에 대한 결합에 포함됩니다. Profile 는 고객 특성에 대한 강력하고 중앙 집중식 프로필과 고객이 통합한 모든 시스템에서 보유한 모든 이벤트의 타임스탬프가 지정된 계정을 Platform제공합니다. Profile 조합 보기를 사용하여 이 데이터를 나타내고 각 개별 고객을 전체적으로 볼 수 있습니다.

Profile 작업에 대한 자세한 내용은 실시간 고객 프로필 개요를 참조하십시오.

데이터 파일을 XDM 스키마에 매핑

Experience Platform에 수집되는 모든 데이터 파일은 XDM 스키마 구조를 준수해야 합니다. XDM 계층(샘플 파일 포함)을 준수하도록 데이터 파일의 형식을 지정하는 방법에 대한 자세한 내용은 샘플 ETL 변환에서 문서를 참조하십시오. 데이터 파일을 Experience Platform에 수집하는 방법에 대한 일반적인 정보는 배치 수집 개요를 참조하십시오.

외부 세그먼트의 스키마

외부 시스템의 세그먼트를 Platform으로 가져오는 경우 다음 구성 요소를 사용하여 스키마에서 캡처해야 합니다.

다음 단계

스키마 컴포지션의 기본 사항을 이해했으므로 Schema Registry을 사용하여 스키마 탐색 및 작성을 시작할 준비가 되었습니다.

두 코어 XDM 클래스의 구조 및 일반적으로 사용되는 호환 필드 그룹을 검토하려면 다음 참조 설명서를 참조하십시오.

Schema Registry 은 Adobe Experience Platform 내에서 Schema Library에 액세스하는 데 사용되며 사용 가능한 모든 라이브러리 리소스에 액세스할 수 있는 사용자 인터페이스와 RESTful API를 제공합니다. Schema Library에는 Adobe에 의해 정의된 업계 리소스, Experience Platform 파트너가 정의한 공급업체 리소스 및 조직의 구성원이 작성한 클래스, 필드 그룹, 데이터 유형 및 스키마가 포함되어 있습니다.

UI를 사용하여 스키마 작성을 시작하려면 스키마 편집기 자습서와 함께 이 문서 전체에서 언급된 "충성도 멤버" 스키마를 빌드하십시오.

Schema Registry API를 사용하려면 스키마 레지스트리 API 개발자 안내서를 읽어 보십시오. 개발자 안내서를 읽은 후 스키마 레지스트리 API를 사용하여 스키마 만들기에 대한 자습서에 설명된 단계를 수행합니다.

부록

다음 섹션에는 스키마 구성 원칙에 대한 추가 정보가 포함되어 있습니다.

관계형 테이블과 포함된 객체

관계형 데이터베이스를 사용하는 경우, Best Practice에 따라 데이터를 정규화하거나 엔티티를 가져와서 여러 테이블에 표시되는 개별 조각으로 분할합니다. 데이터를 전체적으로 읽거나 엔티티를 업데이트하려면 JOIN을 사용하여 여러 개별 테이블에서 읽기 및 쓰기 작업을 수행해야 합니다.

포함된 개체를 사용하여 XDM 스키마는 복잡한 데이터를 직접 나타내고 계층 구조의 자체 포함된 문서에 저장할 수 있습니다. 이 구조의 주요 이점 중 하나는 많은 비정규화된 테이블에 연결된 값비싼 조인으로 엔티티를 재구성하지 않고 데이터를 쿼리할 수 있다는 것입니다. 스키마 계층 구조의 수준에 대한 하드 제한 사항은 없습니다.

스키마 및 빅 데이터

최신 디지털 시스템은 방대한 양의 행동 신호(거래 데이터, 웹 로그, 사물인터넷, 디스플레이 등)를 생성합니다. 이 빅데이터는 경험을 최적화할 수 있는 특별한 기회를 주지만, 데이터의 규모와 다양성으로 인해 사용하기 어렵습니다. 데이터의 가치를 얻으려면 데이터의 구조, 형식 및 정의를 일관되고 효율적으로 처리할 수 있도록 표준화해야 합니다.

스키마는 여러 소스에서 데이터를 통합하고, 공통 구조 및 정의를 통해 표준화하고, 솔루션 간에 공유하도록 허용하여 이 문제를 해결합니다. 이를 통해 후속 프로세스 및 서비스는 데이터에 대한 모든 유형의 질문에 답변할 수 있으며, 기존의 접근 방식에서 데이터 모델링으로 이동하는 것입니다. 여기서 데이터 모델링으로 데이터를 요청할 모든 질문이 미리 알려지며 데이터가 이러한 기대에 부합하도록 모델링됩니다.

개체 및 자유 형식 필드

스키마를 디자인할 때 자유 형식 필드에서 개체를 선택할 때 고려해야 할 몇 가지 주요 요소가 있습니다.

개체 자유 형식 필드
중첩 증가 중첩이 작거나 없음
논리 필드 그룹화 만들기 필드가 임시 위치에 배치됩니다

개체

자유 형식 필드에서 개체를 사용하는 경우의 장단점은 아래에 나와 있습니다.

장점:

  • 특정 필드의 논리적 그룹을 만들려면 개체를 사용하는 것이 가장 좋습니다.
  • 개체는 보다 구조화된 방식으로 스키마를 구성합니다.
  • 개체는 세그먼트 빌더 UI에서 좋은 메뉴 구조를 만드는 데 간접적으로 도움이 됩니다. 스키마 내에 그룹화된 필드는 세그먼트 빌더 UI에 제공된 폴더 구조에 직접 반영됩니다.

단점:

자유 형식 필드

객체에서 자유 형식 필드를 사용할 때의 장단점은 아래에 나와 있습니다.

장점:

  • 자유 형식 필드는 스키마(_tenantId)의 루트 개체 아래에 직접 작성되므로 가시성이 높아집니다.
  • 자유 양식 필드에 대한 참조 문자열은 쿼리 서비스를 사용할 때 더 짧은 경향이 있습니다.

단점:

  • 스키마 내의 자유 형식 필드의 위치는 Ad Hoc이며, 이는 스키마 편집기 내에서 알파벳 순서로 표시됨을 의미합니다. 이렇게 하면 스키마를 구조화하지 않고, 유사한 자유 형식 필드가 이름에 따라 멀리 떨어져 있을 수 있습니다.

이 페이지에서는