현대 기업은 데이터가 지극히 풍부하지만, 그 데이터는 사일로에 분산되어 있고 이질적이며 품질도 들쭉날쭉하다. 메타데이터 지식 그래프는 데이터의 형태와 위치, 그 데이터를 처리하는 시스템, 그리고 소비자를 기록하는 전사적 지도다. 중요하게는 데이터·프로세스·소비자를 연결하여, (컴플라이언스와 규제 요구를 위해) 데이터의 계보(provenance)를 명시적이고 추론하기 쉽게 만든다.
조직이 진화하면서 각 부서는 각자의 요구를 풀기 위한 애플리케이션과 프로세스를 구현한다. 개별 부서가 같은 정보의 일부를 저장할 수 있으므로, 사일로에 중복 — 또는 더 나쁘게는 거의-중복(nearly duplicate) — 데이터가 존재하는 일이 드물지 않다. 이런 시스템들은 비즈니스의 전반적인 지식 조직화 요구를 고려하지 않고 구현되곤 하는데, 그 요구가 어느 개별 부서의 소유도 아니기 때문이다(명시적 소유자가 아예 없을 수도 있다). 데이터가 조각보 상태이면 고객의 여정도, 우주 임무의 성공 요인도 이해하기 어렵다.
메타데이터(데이터를 기술하는 데이터)는 현대 정보 시스템 관리의 핵심 요소다. 메타데이터 지도는 조직의 전체 데이터 생태계 위에 렌즈를 제공하여 전사적 데이터 관리를 가능하게 한다. 그래서 메타데이터 지식 그래프는 정보 아키텍처의 매우 유용한 기반 계층이다. 고품질 메타데이터는 품질과 신선도가 가변적인 방대하고 이질적인 데이터 자산의 탐색을 보장하고, 데이터 분석가·데이터 과학자·ML 엔지니어가 올바른 데이터에 빠르게 접근하도록 도우며, 감사·규제 목적을 위해 데이터 자산의 상태를 설명할 수 있다.
그러나 메타데이터 관리는 과거에도 지금도 중대한 도전이다. 이 도전에 대응하여 최대 규모의 조직들은 지식 그래프가 받치는 메타데이터 허브(metadata hub)로 데이터를 수렴시키고 있다.
지식 그래프가 받치는 메타데이터 허브의 트렌드는 2017년 Airbnb가 GraphConnect Europe 2017의 "Democratizing Data at Airbnb" 발표에서 Dataportal 플랫폼을 공개하며 시작됐다. 뒤이어 Lyft가 데이터 발견 메타데이터 엔진 Amundsen을, LinkedIn이 Datahub를 내놓았고, 이후 메타데이터 관리에 지식 그래프를 결합한 상용 솔루션들이 뒤따랐다. 큰 조직만 이득을 보는 것이 아니다 — 이런 프레임워크의 지원과 함께, 메타데이터 지식 그래프는 고차 지식 그래프 시스템 구축, 데이터 과학, 컴플라이언스·규제 목적에 두루 유용하다.
메타데이터 지식 그래프에 포착되는 엔터티는 현대 데이터 스택에서 흔히 발견되는 공통 데이터 자산으로, 대개 데이터셋, 태스크와 파이프라인, 데이터 싱크를 포함한다. 아래 절들은 자신만의 메타데이터 지식 그래프를 구축하기 위한 지침이 된다.
테이블·문서·스트림 등 모든 데이터 컬렉션이 데이터셋이다. 데이터셋은 그것을 처리·저장하는 시스템에 연결되고, 데이터셋의 공개 스키마를 기술하는 데이터 필드 기술(記述)의 모음으로 분해될 수 있다.
태스크는 데이터 자산을 처리하는 모든 데이터 작업이다 — 예: CSV의 country 필드 값을 표준화하는 ETL 태스크. 태스크는 체인으로 묶여 파이프라인(데이터 흐름)을 이루고, 체인이 실행 순서를 결정하여 태스크 간 의존성을 명시적으로 만든다.
BI 도구의 데이터 시각화부터 ML 훈련 데이터셋까지, 모든 종류의 종단(terminal) 데이터 소비 태스크다. 데이터셋에 연결되지만, 태스크와 달리 새 데이터셋을 만들지 않는다.
그림 8-1과 같은 메타데이터를 편입하기 시작하면 시스템에 존재하는 그대로의 데이터 지도가 만들어진다. 거기서 시스템 간 논리적 공통 레코드를 연결할 수 있고, 태스크·파이프라인을 통해 한 시스템의 입력이 어떻게 다른 시스템의 출력이 되는지 보여줄 수 있다. 그림 8-2의 파이프라인 뷰는 (컴플라이언스·규제 이유 등으로) 어떤 시스템과 사용자가 데이터를 만졌는지 이해하고 데이터의 계보 파악을 돕는다.
메타데이터 그래프의 모든 요소는 데이터 도메인에 연결되고, 소유자를 갖고, 사용 중인 전사 온톨로지·용어집· 표준 용어의 관련 비즈니스 용어를 나타내는 카탈로그 용어(catalog term)에 연결될 수 있으며, 설명이나 문서를 부착할 수 있다. 데이터 싱크를 데이터에 매핑하면 어떤 사용자·시스템이 데이터를 소비하는지 이해할 수 있다 — 시스템 마이그레이션 계획에 도움이 되고, 어떤 데이터와 파이프라인이 가치 있는지(그리고 아닌지)를 보여준다.
판매 데이터를 표준화하고 월별로 집계하는 데이터 파이프라인을 기술하는 예제다. 세 데이터셋이 CSV 포맷의 판매
데이터를 나타낸다 — 운영 시스템에서 추출된 원시 데이터셋(sales_details_raw), 일부
참조 필드가 표준화된 데이터셋(sales_details_std), 그리고 월별로 집계된
데이터셋(sales_monthly_agg)이다.
집계 데이터셋은 세 필드(customerId, address, renewal_date)의 노드를 갖는다. address 필드는 카탈로그 용어
location_info에 연관되어 그 필드가 지리 위치 정보를 담고 있음을 나타내고, 카탈로그는
Catalog Team이 소유한다. 데이터셋 자체도 소유자 역할의 사용자에게 연결되는데, 이런 관계는
data steward 같은 사용자 역할을 나타내는 속성으로 한정하는 것이 좋다. 마지막으로 집계 데이터셋은
두 데이터 싱크가 소비한다 — 데이터 시각화를 나타내는 Dashboard와 ML 파이프라인에 쓰임을
나타내는 MLFeatureSet이다.
그림 8-3과 같은 모델은 "고객 위치 정보를 담은 가장 인기 있는 기업 판매 데이터셋은 무엇인가?" 같은 데이터 발견(data discovery) 질의를 지원한다. 데이터셋 인기도를 재는 한 방법은 데이터가 소비되는 방식의 수 — 즉 그 데이터셋을 소비하는 데이터 싱크의 수 — 를 세는 것이다.
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
비슷하게, 장애 태스크의 영향을 평가하러 메타데이터 그래프를 탐험할 수 있다. Example 8-2는 주어진 태스크의 실패가 영향을 미칠 데이터 소비자(데이터 싱크)와 그 소유자의 목록을 반환한다(영향 분석은 11장에서 더 상세히 다룬다).
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
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장처럼 그래프 알고리즘으로 분석하여 팀과 데이터 도메인 사이의 강한 연결(또는 단절)을 표면화할 수도 있다 — 조직에서 데이터가 흐르는 방식의 지도(이 지식 그래프가 정확히 그것이다)는 회사 운영의 프록시(proxy)이기 때문이다.
그래프에서 관계는 엔터티들이 어떻게 상호 연관되는지 기술한다 — 고객 노드와 서비스 노드를
SUBSCRIBES_TO 관계로 이어 "고객이 서비스를 구독한다"를 진술하는 식이다. 그런데
관계는 같은 그래프 안에서 데이터와 메타데이터를 연결하는 데도 쓸 수 있다.
이런 지식 그래프로 "어떤 고객이 서비스 X를 구독하는가?" 같은 도메인 질문에 답하면서, 동시에 계보·거버넌스 메타데이터를 공급하여 답에 대한 신뢰를 제공할 수 있다. 중요하게는, 데이터 아키텍트가 이 기법을 고객 데이터를 담은 소스 시스템에 대해 비침습적으로 — 그 시스템들 위의 계층으로 — 구현할 수 있다는 것이다.
전역적으로 연결된 데이터 뷰는 많은 중대한 사용 사례를 연다. 서로 다른 시스템에 흩어진 고객의 부분 뷰들을 연결해 고객의 완전한 뷰를 구성하고, 고객 생애에 걸친 행동으로 원래 뷰를 보강하고, 좋은/나쁜 고객의 패턴을 탐지하고, 행동에 맞춰 프로세스를 적응시키는 길이 쉽게 보인다.
메타데이터 수준에서는 잘 기술된 데이터셋들이 호스팅 데이터 소스에 연결된 카탈로그에서 출발할 수 있다. 여기에 이 책의 다른 장들의 기법으로 어휘·택소노미·온톨로지에 연결해 상호운용성을 확보하거나, 소유·스튜어드십 정보를 더해 데이터 거버넌스를 강화하고 데이터의 출처와 취급 시스템·개인을 지도화할 수 있다. 메타데이터 그래프가 가능하게 하는 통합·중복 제거된 데이터 뷰는 시맨틱 검색을 포함한 여러 사용 사례의 견고한 기반이다.
이 장은 전사 데이터 자산·프로세스·소비자를 추적하는 기반 계층으로서의 메타데이터 그래프를 논했다. 관련 데이터와 메타데이터를 지식 그래프에 통합하고 데이터 자체 안에 관계를 정의함으로써 지능을 데이터 안으로 밀어 넣는 법을 보았다. 메타데이터 지식 그래프로, 소비자가 텍스트에 명시적으로 존재하지도 않는 용어로 전사 데이터를 검색할 수 있는 지식 그래프를 만드는 법도 보았다.
메타데이터 KG = 전사 데이터 지도. 데이터의 형태·위치, 처리 시스템, 소비자를 기록·연결하여 계보를 명시적으로 만든다. Airbnb Dataportal(2017)·Lyft Amundsen·LinkedIn Datahub가 연 메타데이터 허브 트렌드의 심장이다.
세 가지 구성 요소. 데이터셋(플랫폼에 source로 연결, 필드로 분해되는 공개 스키마), 태스크·파이프라인(체인이 의존성을 명시), 데이터 싱크(새 데이터셋을 만들지 않는 종단 소비자). 모든 요소는 도메인·소유자·카탈로그 용어에 연결될 수 있다.
세 가지 대표 질의. 인기도(싱크 수 count), 장애 영향(가변 경로 *2..로 하류 소비자·소유자 추적), 데이터 계보(영향 분석의 그래프상 역방향). 그래프 알고리즘까지 얹으면 데이터 흐름 지도가 회사 운영의 프록시가 된다.
데이터와 메타데이터를 한 그래프에. 2계층 구조로 도메인 질문의 답에 계보·거버넌스가 신뢰를 공급한다. 소스 시스템에 비침습적인 상부 계층으로 구현하며, 고객 완전 뷰·행동 패턴·시맨틱 검색의 기반이 된다.
메타데이터 지식 그래프가 있으면 전사 데이터 자산을 발견하고, 추론하고, 관리할 수 있다. 이것만으로도 유용하지만 더 높은 수준의 사용 사례의 기반이 되기도 한다. 다음 장에서는 그 사용 사례들을 만난다 — 사기꾼과 이상(anomaly), 스킬을 찾고 추천을 만드는 아이덴티티 지식 그래프(9장, Identity Knowledge Graphs)다.