형식 정의 및 사용자 지정 형식을 만드는 방법
이 자습서에서는 형식 정의, 사용자 지정 형식을 만드는 방법 및 Microsoft Purview에서 사용자 지정 형식의 자산을 초기화하는 방법을 설명합니다.
이 자습서에서는 다음을 알아봅니다.
- Microsoft Purview에서 Apache Atlas의 형식 시스템을 사용하는 방법
- 새 사용자 지정 형식을 만드는 방법
- 사용자 지정 형식 간의 관계를 만드는 방법
- 사용자 지정 형식의 새 엔터티를 초기화하는 방법
이 자습서의 경우 다음이 필요합니다.
활성 구독이 있는 Azure 계정입니다. 계정이 없는 경우 무료로 계정을 만들 수 있습니다.
활성 Microsoft Purview(이전의 Azure Purview) 계정입니다. 없는 경우 Microsoft Purview를 무료로 시작하기 위한 가이드를 참조하세요.
Microsoft Purview 계정에 대한 전달자 토큰입니다. 전달자 토큰을 설정하고 API를 호출하려면 Microsoft Purview에 대한 API를 인증하는 방법에 대한 설명서를 참조하세요.
Microsoft Purview 계정의 Apache Atlas 엔드포인트입니다. 환경에 따라 다음 두 엔드포인트 중 하나가 됩니다.
-
클래식 Microsoft Purview 거버넌스 포털을 사용하는 경우:
https://{{ACCOUNTNAME}}.purview.azure.com/catalog
-
새 Microsoft Purview 포털을 사용하는 경우:
https://api.purview-service.microsoft.com/catalog
-
클래식 Microsoft Purview 거버넌스 포털을 사용하는 경우:
참고
자습서의 실습 부분으로 이동하기 전에 처음 4개 섹션에서는 시스템 유형이 무엇이며 Microsoft Purview에서 어떻게 사용되는지 설명합니다. 추가 설명된 모든 REST API 호출은 전달 자 토큰 과 필수 구성 요소에 설명된 엔드포인트 를 사용합니다.
단계로 직접 건너뛰려면 다음 링크를 사용합니다.
자산은 디지털 또는 물리적 리소스를 설명하는 메타데이터 요소입니다. 자산으로 카탈로그화될 것으로 예상되는 디지털 또는 물리적 리소스는 다음과 같습니다.
- 데이터베이스, 파일 및 데이터 피드와 같은 데이터 원본.
- 분석 모델 및 프로세스.
- 비즈니스 정책 및 약관.
- 서버와 같은 인프라.
Microsoft Purview는 사용자에게 자산의 정의를 확장하여 관련되는 새 종류의 리소스를 포함할 수 있는 유연한 형식 시스템을 제공합니다. Microsoft Purview는 Apache Atlas의 형식 시스템을 사용합니다. Microsoft Purview에서 관리하는 모든 메타데이터 개체(자산)는 형식 정의를 사용하여 모델링됩니다. 형식 시스템을 이해하는 것은 Microsoft Purview에서 새 사용자 지정 형식을 만드는 데 기본 사항입니다.
기본적으로 형식 은 OOP(개체 지향 프로그래밍)의 클래스 로 볼 수 있습니다.
- 해당 형식을 나타내는 속성을 정의합니다.
- 각 형식은 해당 이름으로 고유하게 식별됩니다.
- 형식은 supertType에서 상속할 수 있습니다. 이는 OOP의 상속과 동일한 개념입니다. superType을 확장하는 형식은 superType의 특성을 상속합니다.
모든 형식 정의 엔드포인트에 요청을 보내 GET
Microsoft Purview 계정에서 모든 형식 정의를 볼 수 있습니다.
GET https://{{ENDPOINT}}/catalog/api/atlas/v2/types/typedefs
Apache Atlas에는 일반적으로 슈퍼 형식으로 사용되는 몇 가지 미리 정의된 시스템 유형이 있습니다.
예시:
참조 가능: 이 형식은 qualifiedName이라는 고유한 특성을 사용하여 검색할 수 있는 모든 엔터티를 나타냅니다.
자산: 이 형식은 참조 가능에서 확장되며 이름, 설명 및 소유자와 같은 다른 특성이 있습니다.
DataSet: 이 형식은 참조 가능 및 자산을 확장합니다. 개념적으로 데이터를 저장하는 형식을 나타내는 데 사용할 수 있습니다. DataSet을 확장하는 형식에는 스키마가 있을 수 있습니다. 예를 들어 SQL 테이블입니다.
계보: 계보 정보는 데이터 원본과 파일 또는 테이블에 도착하기 전에 겪을 수 있는 변환을 이해하는 데 도움이 됩니다. 계보는 DataSet 및 Process를 통해 계산됩니다. 데이터 세트(프로세스 입력)는 프로세스를 통해 다른 데이터 세트(프로세스 출력)에 영향을 줍니다.
형식 시스템을 더 잘 이해하기 위해 예제를 살펴보고 Azure SQL 테이블이 정의되는 방식을 살펴보겠습니다.
형식 정의 엔드포인트에 요청을 보내 GET
전체 형식 정의를 가져올 수 있습니다.
GET https://{{ENDPOINT}}/catalog/api/atlas/v2/types/typedef/name/{name}
팁
{name} 속성은 관심 있는 정의를 알려줍니다. 이 경우 azure_sql_table 사용해야 합니다.
아래에서 간소화된 JSON 결과를 볼 수 있습니다.
{
"category": "ENTITY",
"guid": "7d92a449-f7e8-812f-5fc8-ca6127ba90bd",
"name": "azure_sql_table",
"description": "azure_sql_table",
"typeVersion": "1.0",
"serviceType": "Azure SQL Database",
"options": {
"schemaElementsAttribute": "columns",
},
"attributeDefs": [
{ "name": "principalId", ...},
{ "name": "objectType", ...},
{ "name": "createTime", ...},
{ "name": "modifiedTime", ... }
],
"superTypes": [
"DataSet",
"Purview_Table",
"Table"
],
"subTypes": [],
"relationshipAttributeDefs": [
{
"name": "dbSchema",
"typeName": "azure_sql_schema",
"isOptional": false,
"cardinality": "SINGLE",
"relationshipTypeName": "azure_sql_schema_tables",
},
{
"name": "columns",
"typeName": "array<azure_sql_column>",
"isOptional": true,
"cardinality": "SET",
"relationshipTypeName": "azure_sql_table_columns",
},
]
}
JSON 형식 정의에 따라 몇 가지 속성을 살펴보겠습니다.
범주 필드는 형식의 범주에 대해 설명합니다. Apache Atlas에서 지원하는 범주 목록은 여기에서 찾을 수 있습니다.
ServiceType 필드는 Microsoft Purview에서 원본 유형별로 자산을 검색할 때 유용합니다. 서비스 유형은 해당 형식 정의에 정의된 대로 동일한 서비스 유형에 속하는 모든 자산을 찾는 진입점이 됩니다. Purview UI의 아래 스크린샷에서 사용자는 결과를 serviceType의 Azure SQL Database로 지정된 엔터티로 제한합니다.
참고
Azure SQL Database는 Azure SQL Table과 동일한 serviceType으로 정의됩니다.
SuperTypes는 "상속 "하려는 "부모" 형식을 설명합니다.
옵션의 schemaElementsAttributes는 Microsoft Purview에 있는 자산의 스키마 탭에 표시되는 항목에 영향을 줍니다.
아래에서 스키마 탭이 테이블 형식의 자산과 어떻게 Azure SQL 예제를 볼 수 있습니다.
relationshipAttributeDefs 는 관계 형식 정의를 통해 계산됩니다. JSON에서 schemaElementsAttributes는 아래와 같이 relationshipAttributeDefs 배열의 요소 중 하나인 columns라는 관계 특성을 가리키는 것을 볼 수 있습니다.
... "relationshipAttributeDefs": [ ... { "name": "columns", "typeName": "array<azure_sql_column>", "isOptional": true, "cardinality": "SET", "relationshipTypeName": "azure_sql_table_columns", }, ]
각 관계에는 고유한 정의가 있습니다. 정의의 이름은 relationshipTypeName 특성에 있습니다. 이 경우 azure_sql_table_columns.
- 이 관계 특성의 카디널리티 는 *SET로 설정되며, 이는 관련 자산 목록을 보유함을 시사합니다.
- 관련 자산은 typeName 특성에 표시되는 것처럼 azure_sql_column 형식입니다.
즉, 열 관계 특성은 Azure SQL 테이블을 스키마 탭에 표시되는 Azure SQL 열 목록과 연결합니다.
각 관계는 endDef1 및 endDef2 라는 두 개의 끝으로 구성됩니다.
이전 예제에서 azure_sql_table_columns 테이블(endDef1)과 해당 열(endDef2)을 특징짓는 관계의 이름이었습니다.
전체 정의의 경우 이름으로 azure_sql_table_columns 사용하여 다음 엔드포인트에 요청할 수 있습니다GET
.
GET https://{{ENDPOINT}}/catalog/api/atlas/v2/types/typedef/name/azure_sql_table_columns
아래에서 간소화된 JSON 결과를 볼 수 있습니다.
{
"category": "RELATIONSHIP",
"guid": "c80d0027-8f29-6855-6395-d243b37d8a93",
"name": "azure_sql_table_columns",
"description": "azure_sql_table_columns",
"serviceType": "Azure SQL Database",
"relationshipCategory": "COMPOSITION",
"endDef1": {
"type": "azure_sql_table",
"name": "columns",
"isContainer": true,
"cardinality": "SET",
},
"endDef2": {
"type": "azure_sql_column",
"name": "table",
"isContainer": false,
"cardinality": "SINGLE",
}
}
name 은 관계 정의의 이름입니다. 이 경우 azure_sql_table_columns 값은 json에서 참조되는 것을 볼 수 있으므로 이 관계가 있는 엔터티의 relationshipTypeName 특성에 사용됩니다.
relationshipCategory 는 관계의 범주이며 여기에 설명된 대로 COMPOSITION, AGGREGATION 또는 ASSOCIATION일 수 있습니다.
enDef1 은 정의의 첫 번째 끝이며 특성을 포함합니다.
type 은 이 관계가 end1로 예상하는 엔터티의 형식입니다.
name 은 이 엔터티의 관계 특성에 표시되는 특성입니다.
카디널리티 는 SINGLE, SET 또는 LIST입니다.
isContainer 는 부울이며 포함 관계 범주에 적용됩니다. 한쪽 끝에서 true로 설정하면 이 끝이 다른 쪽 끝의 컨테이너임을 나타냅니다. 그러므로:
- 컴퍼지션 또는 집계 범주 관계만 한 쪽 끝에 있을 수 있고 있어야 합니다Container는 true로 설정됩니다.
- 연결 범주 관계에 는 isContainer 속성이 true로 설정되어 있으면 안 됩니다.
endDef2 는 정의의 두 번째 끝이며 관계의 두 번째 부분의 속성인 endDef1과 유사하게 설명합니다.
스키마는 데이터를 데이터 저장소에 저장하고 구성하는 방법을 반영하는 중요한 개념입니다. 데이터의 구조와 구조를 생성하는 요소의 데이터 제한을 반영합니다.
동일한 스키마의 요소는 콘텐츠로 인해 다르게 분류할 수 있습니다. 또한 요소의 하위 집합에 대해서만 다른 변환(계보)이 발생할 수 있습니다. 이러한 측면으로 인해 Purview는 스키마 및 스키마 요소를 엔터티로 모델링할 수 있으므로 스키마는 일반적으로 데이터 자산 엔터티에 대한 관계 특성입니다. 스키마 요소의 예로는 테이블 열, json 스키마의 json 속성 , xml 스키마의 xml 요소 등이 있습니다.
스키마에는 두 가지 유형이 있습니다.
내장 스키마 - 일부 시스템은 스키마에 내장되어 있습니다. 예를 들어 SQL 테이블을 만들 때 시스템에서 테이블을 생성하는 열을 정의해야 합니다. 이러한 의미에서 테이블의 스키마는 해당 열에 의해 반영됩니다.
미리 정의된 스키마가 있는 데이터 저장소의 경우 Purview는 데이터 자산과 스키마 요소 간의 해당 관계를 사용하여 스키마를 반영합니다. 이 관계 특성은 엔터티 형식 정의의 options 속성에 있는 키워드(keyword) schemaElementsAttribute에 의해 지정됩니다.
기본 스키마가 아닌 스키마 - 일부 시스템은 이러한 스키마 제한을 적용하지 않지만 사용자는 이 스키마 프로토콜을 데이터에 적용하여 구조적 데이터를 저장하는 데 사용할 수 있습니다. 예를 들어 Azure Blob은 이진 데이터를 저장하고 이진 스트림의 데이터에 신경 쓰지 않습니다. 따라서 스키마는 인식하지 못하지만 사용자는 blob에 저장하기 전에 json과 같은 스키마 프로토콜을 사용하여 데이터를 직렬화할 수 있습니다. 이러한 의미에서 스키마는 사용자가 적용하는 몇 가지 추가 프로토콜 및 해당 유효성 검사에 의해 유지 관리됩니다.
내재된 스키마가 없는 데이터 저장소의 경우 스키마 모델은 이 데이터 저장소와 독립적입니다. 이러한 경우 Purview는 스키마에 대한 인터페이스와 dataset_attached_schemas 라는 DataSet와 스키마 간의 관계를 정의합니다. 이렇게 하면 DataSet에서 상속되는 모든 엔터티 형식을 확장하여 해당 스키마 표현에 연결할 attachedSchema 관계 특성을 갖습니다.
위의 Azure SQL 테이블 예제에는 내장 스키마가 있습니다. Azure SQL 테이블의 스키마 탭에 표시되는 정보는 Azure SQL 열 자체에서 가져옵니다.
하나의 열 항목을 선택하면 다음이 표시됩니다.
문제는 Microsoft Purview가 열에서 data_tye 속성을 어떻게 선택하고 테이블의 스키마 탭에 표시했나요?
엔드포인트에 요청하여 GET
Azure SQL 열의 형식 정의를 가져올 수 있습니다.
GET https://{{ENDPOINT}}/catalog/api/atlas/v2/types/typedef/name/{name}
참고
이 경우 {name}은(는) azure_sql_column
간소화된 JSON 결과는 다음과 같습니다.
{
"category": "ENTITY",
"guid": "58034a18-fc2c-df30-e474-75803c3a8957",
"name": "azure_sql_column",
"description": "azure_sql_column",
"serviceType": "Azure SQL Database",
"options": {
"schemaAttributes": "[\"data_type\"]"
},
"attributeDefs":
[
{
"name": "data_type",
"typeName": "string",
"isOptional": false,
"cardinality": "SINGLE",
"valuesMinCount": 1,
"valuesMaxCount": 1,
"isUnique": false,
"isIndexable": false,
"includeInNotification": false
},
...
]
...
}
참고
serviceType은 테이블과 동일한 Azure SQL 데이터베이스입니다.
- schemaAttributes 는 이 형식의 특성 중 하나인 data_type 설정됩니다.
Azure SQL Table은 schemaElementAttribute를 사용하여 Azure SQL 열 목록으로 구성된 관계를 가리킵니다. 열의 형식 정의에는 schemaAttributes가 정의되어 있습니다.
이러한 방식으로 테이블의 스키마 탭에는 관련 자산의 schemaAttributes 에 나열된 특성이 표시됩니다.
먼저 사용자 지정 형식 정의를 만들고 싶은 이유는 무엇인가요?
Microsoft Purview에서 가져오려는 메타데이터의 구조에 해당하는 기본 제공 형식이 없는 경우가 있을 수 있습니다.
이러한 경우 새 형식 정의를 정의해야 합니다.
참고
가능한 경우 사용자 지정 형식을 만드는 방법보다 기본 제공 형식을 사용하는 것이 좋습니다.
일반적으로 형식 정의를 이해했으므로 사용자 지정 형식 정의를 만들어 보겠습니다.
이 자습서에서는 custom_type_parent 및 custom_type_child 두 형식 간의 1:n 관계를 모델링하려고 합니다.
custom_type_child 부모 하나를 참조해야 하는 반면 custom_type_parent 자식 목록을 참조할 수 있습니다.
1:n 관계를 통해 함께 연결해야 합니다.
팁
여기서 는 새 사용자 지정 형식을 만들 때 몇 가지 팁을 찾을 수 있습니다.
- 다음 두 엔드 포인트 중 하나에 요청을 수행
POST
하여 custom_type_parent 형식 정의를 만듭니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/types/typedefs
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/types/typedefs
본문과 함께:
{
"entityDefs":
[
{
"category": "ENTITY",
"version": 1,
"name": "custom_type_parent",
"description": "Sample custom type of a parent object",
"typeVersion": "1.0",
"serviceType": "Sample-Custom-Types",
"superTypes": [
"DataSet"
],
"subTypes": [],
"options":{
"schemaElementsAttribute": "columns"
}
}
]
}
- 다음 두 엔드 포인트 중 하나에 요청을 수행
POST
하여 custom_type_child 형식 정의를 만듭니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/types/typedefs
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/types/typedefs
본문과 함께:
{
"entityDefs":
[
{
"category": "ENTITY",
"version": 1,
"name": "custom_type_child",
"description": "Sample custom type of a CHILD object",
"typeVersion": "1.0",
"serviceType": "Sample-Custom-Types",
"superTypes": [
"DataSet"
],
"subTypes": [],
"options":{
"schemaAttributes": "data_type"
}
}
]
}
- 다음 두 엔드포인트 중 하나에 요청을 수행
POST
하여 사용자 지정 형식 관계 정의를 만듭니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/types/typedefs
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/types/typedefs
본문과 함께:
{
"relationshipDefs": [
{
"category": "RELATIONSHIP",
"endDef1" : {
"cardinality" : "SET",
"isContainer" : true,
"name" : "Children",
"type" : "custom_type_parent"
},
"endDef2" : {
"cardinality" : "SINGLE",
"isContainer" : false,
"name" : "Parent",
"type" : "custom_type_child"
},
"relationshipCategory" : "COMPOSITION",
"serviceType": "Sample-Custom-Types",
"name": "custom_parent_child_relationship"
}
]
}
- 다음 두 엔드포인트 중 하나에 요청을 수행
POST
하여 custom_type_parent 형식의 새 자산을 초기화합니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/entity
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/entity
본문과 함께:
{
"entity": {
"typeName":"custom_type_parent",
"status": "ACTIVE",
"version": 1,
"attributes":{
"name": "First_parent_object",
"description": "This is the first asset of type custom_type_parent",
"qualifiedName": "custom//custom_type_parent:First_parent_object"
}
}
}
나중에 필요하므로 GUID 를 저장합니다.
- 다음 두 엔드포인트 중 하나에 요청을 수행
POST
하여 custom_type_child 형식의 새 자산을 초기화합니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/entity
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/entity
본문과 함께:
{
"entity": {
"typeName":"custom_type_child",
"status": "ACTIVE",
"version": 1,
"attributes":{
"name": "First_child_object",
"description": "This is the first asset of type custom_type_child",
"qualifiedName": "custom//custom_type_child:First_child_object"
}
}
}
나중에 필요하므로 GUID 를 저장합니다.
- 다음 두 엔드포인트 중 하나에 요청을 수행
POST
하여 custom_parent_child_relationship 형식의 새 관계를 초기화합니다.
클래식 Microsoft Purview 거버넌스 포털:
POST https://{{ENDPOINT}}.purview.azure.com/catalog/api/atlas/v2/relationship/
새 Microsoft Purview 포털:
POST https://api.purview-service.microsoft.com/catalog/api/atlas/v2/relationship/
다음 본문을 사용하여 다음을 수행합니다.
참고
end1의 guid 를 6.1단계에서 만든 개체의 guid로 바꿔야 합니다. end2의 guid 는 6.2단계에서 만든 개체의 guid로 바꿔야 합니다.
{
"typeName": "custom_parent_child_relationship",
"end1": {
"guid": "...",
"typeName": "custom_type_parent"
},
"end2": {
"guid": "...",
"typeName": "custom_type_child"
}
}
Microsoft Purview에서 Data Catalog 이동합니다.
찾아보기를 선택합니다.
원본 유형별을 선택합니다.
Sample-Custom-Types을 선택합니다.
First_parent_object 선택합니다.
속성 탭을 선택합니다.
First_child_object 연결된 것을 볼 수 있습니다.
First_child_object 선택합니다.
속성 탭을 선택합니다.
Parent 개체가 연결된 것을 볼 수 있습니다.
마찬가지로 관련 탭을 선택하면 두 개체 간의 관계가 표시됩니다.
새 자식 자산을 초기화하고 관계를 완화하여 여러 자식을 만들 수 있습니다.
참고
qualifiedName은 자산별로 고유하므로 두 번째 자식은 사용자 지정//custom_type_child:Second_child_object 같이 다르게 호출되어야 합니다.
팁
First_parent_object 삭제하면 정의에서 선택한 COMPOSITION 관계로 인해 자식도 제거됩니다.
나중에 향상될 사용자 지정 형식으로 작업할 때 다음과 같은 몇 가지 알려진 제한 사항이 있습니다.
- 관계 탭은 기본 제공 형식과 다르게 보입니다.
- 사용자 지정 형식에 아이콘이 없음
- 계층 구조는 지원되지 않습니다.