본 내용은 Building Knowledge Graph - Chapter 8 내용 대부분을 참고하고 있습니다.
메타데이터 지식 그래프는 데이터의 형태와 위치, 해당 데이터를 처리하는 시스템과 그 소비자들을 기록하는 데이터맵으로, 데이터와 프로세스, 소비자를 연결하여 데이터의 출처를 명확하게 하고, 논리적으로 이해하기 쉽게 만든다는 효과가 있다.
Datasets Connected To Data Platform
데이터셋은 공용 스키마를 설명하는 데이터 필드 설명들의 모음으로 세분화될 수 있다. 시스템 내에 존재하는 데이터에 대한 지도를 그리는 것부터 시작하여 시스템 간에 논리적으로 공통된 기록을 연결하고, 한 시스템의 입력이 작업과 파이프라인을 통해 어떻게 다른 시스템의 출력이 되는지를 보여줄 수 있다.
Tasks and Data Pipelines
작업(task)은 데이터 자산을 처리하는 모든 데이터 작업을 지칭하며, 간단한 예로는 CSV 파일에서 국가 필드의 값들을 표준화하는 ETL 작업이 있다. 작업은 데이터 파이프라인이나 데이터 흐름을 형성하는 체인으로 그룹화될 수 있으며 체인은 작업이 실행되는 순서를 결정하고, 그렇게하여 체인 내부의 작업 간 의존성이 명시화된다.
위 그림은 데이터를 처리하는 작업을 그래프로 표현한 것으로, 한 시스템에서 결과 데이터가 어떻게 입력 데이터가 되는지를 보여준다. 이러한 작업 그래프는 데이터와 접촉하게되는 사용자와 작업을 이해할 수 있도록 하며, 데이터 출처를 이해하는데도 도움을 준다.
Data Sinks
Data Sink는 BI 도구의 데이터 시각화부터 ML 훈련 데이터 세트에 이르는 모든 종류의 터미널 데이터 소비 작업으로, 데이터 세트에 연결되어 있어도, 새로운 데이터 세트를 생성하지 않는 작업이다. 쉽게 설명하면, 데이터를 생성하거나 갱신하지 않고 사용하기만 하는 사용처라고 보면 된다. 데이터 싱크를 데이터에 매핑하는 것은 어떤 사용자와 시스템이 데이터를 소비하는지 이해하는 데 도움이 된다. 또한, Data Sink는 시스템 이전 계획에 도움을 주며, 어떤 데이터와 파이프라인이 가치 있는지를 보여준다.
Metadata Graph Example
아래 그림은 월별로 판매 데이터를 표준화하고 집계하는 데이터 파이프라인의 예시이다. 세 개의 데이터셋은 각각 CSV 형식의 판매 데이터를 나타낸다.(운영 시스템에서 추출된 원시 데이터셋(sales_details_raw), 참조 필드가 표준화된 데이터셋(sales_details_std), 월별로 집계된 데이터셋(sales_monthly_agg))
세 개의 데이터셋은 각각 세 개의 필드(customerID, address, renewal_date)에 대한 노드를 가지고 있다. 위치 정보라는 카탈로그 용어와 연관되어 있는 address 필드는 지리적 위치 정보를 포함하고 있음을 나타낸다. 카탈로그는 카탈로그 팀에 의해 소유된다. 데이터셋 자체는 소유자 역할을 하는 사용자와 연결되어 있으며, 이런 관계는 '데이터 관리자'와 같은 사용자의 역할을 나타내는 속성을 통해 명확히 해야 한다.
마지막으로 수집된 데이터셋은 데이터 싱크에 의해 사용되는 것을 확인할 수 있다.(Dashboard, MLFeatureSet)
메타데이터 그래프에 질의하기
위 사진과 같은 그래프 모델은 "고객 위치 정보가 포함된 가장 인기 있는 기업 판매 데이터셋 은 무엇인가?"와 같은 데이터 발견 쿼리를 지원할 수 있다.
데이터셋의 인기를 측정하는 한 가지 방법은 데이터셋을 소비하는 데이터 싱크의 수에 따라 데이터가 사용되는 방식을 세는 것으로, 아래의 사이퍼 쿼리를 사용하여 메타데이터 그래프에서 검색할 수 있다.
MATCH (d:Dataset)
WHERE (d)-[:associated_with]->(:Domain { name: 'Corporate Sales'})
AND (d)-[:has_field]->(:Field)-[:associated_with]->(:CatalogTerm {name:'location_info'})
RETURN d.id AS dataset_id,
d.desc AS dataset_desc,
d.type AS dataset_type,
count{ (d)<-[:consumes]-(d:DataSink) } AS dataset_usage_count이와 유사하게, 메타데이터 그래프를 탐색하여 실패한 데이터 처리 작업이 미치는 영향을 평가할 수 있다. 아래의 사이퍼 쿼리는 데이터 처리 작업 실패로 인해 영향을 받을 데이터 싱크 목록과 그 데이터 세트의 소유자를 반환한다.
MATCH (t:Task)-[:produces|consumes*2..]-(:Dataset) <-[:consumes]-(s:DataSink)-[:owned_by]->(o)
WHERE t.name = 'standardise_reference_fields'
RETURN s.id AS affectedDataConsumerID,
s.type AS affectedDataConsumerType,
s.desc AS affectedDataConsumerDesc,
o.id AS ownerID,
o.name AS ownerName또 다른 일반적인 분석 유형은 데이터 계보(data Lineage)로, 그래프 관점에서 이전에 설명한 경우(데이터->데이터 싱크) 와 정반대의 방향성(데이터 싱크 -> 데이터)을 갖는다. 예를 들어 "대시보드 X의 데이터 소스는 어떤 데이터 플랫폼인가?"일 수 있다. 아래의 쿼리는 질문에 대한 답을 구하는 쿼리이다.
MATCH (s:DataSink)-[:consumes]->(:Dataset)-[:produces|consumes*2..]->(raw:Dataset) -[:source]->(dp:DataPlatform)
WHERE s.type = 'Dashboard' AND s.id = 'X'
RETURN raw.id AS sourceDatasetID,
raw.type AS sourceDatasetType,
dp.id AS sourcePlatformID,
dp.type AS sourcePlatformType이밖에도 메타데이터 관리와 관련하여 데이터 세트에 대해 물어볼 수 있는 질문이 훨씬 더 많이 있으며, 6장에서와 같이 그래프 알고리즘을 사용하여 팀과 데이터 도메인 간의 강한 연결이나 단절을 드러내기 위해 그래프를 분석할 수도 있다.
Using Relationships to Connect Data and Metadata
관계는 동일한 그래프 내에서 데이터와 메타데이터를 연결하는 데에도 사용될 수 있다. 다음의 그림은 두 개의 층이 있는 그래프를 보여준다.
위와 같은 그래프는 "어떤 고객이 서비스 X에 가입하고 있지?"와 같은 도메인 질문에 답변할 수 있으며, 출처와 거버넌스 메타데이터를 제공하여 답변에 대한 신뢰성을 높일 수도 있다.
이러한 데이터 아키텍트는 기존 시스템 위에 레이어를 구축하여, 고객 데이터를 포함하는 원본 시스템을 수정하지 않는 선에서 이 기술을 구현할 수 있다.
위의 그림은 그래프에서의 데이터와 메타데이터 평면적인 조합을 보여주지만, 이러한 방식으로 서로 다른 시스템에서 존재하는 분산된 부분 뷰를 연결하여 고객에 대한 완전한 뷰를 구성할 수도 있다.
데이터와 메타데이터를 연결하는 데 사용하는 기법을 활용하여 데이터, 메타데이터의 어휘나 분류체계, 온톨로지와 연결함으로써 상호 운용성을 강화할 수도 있다. 또는 소유권이나 관리 정보를 추가하여 데이터 거버넌스를 향상시키고 데이터의 출처와 이를 처리한 시스템과 개인을 명확히 나타낼 수도 있다.
