메타데이터 카탈로그 서비스
이 글은 데이터 민주화와 셀프서비스 데이터를 읽고 쓰는 포스트입니다.
스키마의 변화
전통적인 데이터 웨어하우스의 경우 데이터를 쓰기 전에 고정 된 스키마를 적용했습니다. 이러한 방식은 데이터의 형태를 사전에 파악 할 수 있으므로 상대적으로 적은 범주의 작업에 효율적인 결과를 도출했습니다. 예를들면 마케팅 성과를 분석하는 데이터 웨어하우스에서 정해진 스키마(광고 및 성과 지표에 대한 컬럼 및 메타데이터)는 결과를 도출하기까지 모호하지 않도록 도와줍니다.
하지만 현재의 데이터 플랫폼의 발전 방향성은 데이터를 먼저 쓰고 사용하기 전에 스키마를 적용하는 읽기 스키마 로 변화하고 있습니다. 이 경우에는 별도의 방식을 도입하여 지속적으로 데이터 카탈로그 시스템을 구축, 지속하여야 합니다.
여정 지도
데이터 세트에 대한 이해
- 데이터가 논리적으로 무엇을 나타내는지, 속성의 의미, 데이터의 원천
- 누구 및 어느 팀이 소유자이며, 사용자가 누구인지?
- 어떤 쿼리 엔진을 사용하는지 데이터 세트는 버저닝되어 있는지
- 데이터가 어디에 위치하는지, 복제 위치와 형식이 어떻게 되는지?
- 물리적으로 어떻게 표현되는지?
- 마지막 업데이트 시기와 계층화 되어 있는지, 신뢰 할 수 있는지?
- 전체 또는 개별 열에 대해 비슷하거나 동일한 콘텐츠를 가진 유사 데이터 셋이 있는지?
데이터 세트 분석
데이터 세트를 분석하는데에 다양한 쿼리 엔진을 사용 할 수 있기 때문에 각 쿼리 엔진에 맞는 형식을 매핑해야합니다.
지식 확장
이해하는 바로는 도메인에 대한 팀 지식을 공유하여 카탈로그를 작성
해석시간 최소화
해석 시간이란?
데이터 과학자가 인사이트를 구축하기 전에 데이터 세트의 세부 정보를 이해하는 데에 걸리는 시간입니다.
데이터 세트에 대한 잘못된 가정은 인사이트를 발전시켜 나가는 중 불필요한 반복작업으로 이어지고, 품질을 저해합니다. 데이터 세트의 세부 정보는 기술, 운영, 팀이라는 세 가지 메타데이터 버킷으로 나누겠습니다.
기술 메타데이터
기술 메타데이터는 크게 논리적, 물리적 메타데이터 세부 정보로 나눌 수 있습니다.
- 물리적 메타데이터
- 생성 및 수정 타임스탬프
- 물리적 위치 및 형식
- 스토리지 계층
- 보존 세부 정보
- 등과 같은 물리적 레이아웃과 지속성 관련 세부 정보를 포함
- 논리적 메타데이터
- 데이터 세트 스키마
- 데이터 원본 세부 정보
- 데이터 세트를 생성하는 프로세스
- 데이터 세트의 소유자 및 사용자
메타데이터 수집 중 주요 과제
형식 차이
기술 메타데이터의 경우 각 데이터 플랫폼마다 다르게 저장하고 있습니다. HDFS, Kafka, RDB 등은 서로 다른 방식으로 메타데이터를 저장하고 있습니다. 각 데이터 플랫폼에 맞는 서로 다른 드라이버가 필요합니다.
스키마 유추
자체 설명이 없는 데이터 세트가 필요합니다. 이해하기 어려운 부분인데, 정형 데이터를 제외하면 스키마를 유추하기 어렵고, 읽기 스키마의 경우에는 정해진 스키마가 없기 때문에, 특정 스키마를 설명하는 데이터 세트라면 각기 다른 분석에서 활용할 때 메타데이터의 혼동이 생기는 것을 말하는건가 싶습니다.
변경 추적
메타데이터는 계속 변경되므로 지속적으로 변경해야합니다.
운영 메타데이터
운영 메타데이터는 두 가지 주요 버킷으로 구분됩니다.
- 계보
데이터 세트가 어떻게 생성되었는지와 다른 데이터 세트에 대한 종속성을 추가합니다. 특정 데이터 세트의 계보는 모든 종속 입력 테이블, 파생 테이블, 출력 모델 밒 대시보드를 포함합니다.
- 데이터 프로파일링 통계
가용성 및 품질 통계를 추적합니다. 데이터 세트의 열 수준 및 설정 수준 특성, 완료 시간, 처리 된 데이터, 파이프라인과 관련 된 오류를 포착하는 실행 통계도 포함합니다.
운영 메타데이터의 수집하는 것에 대한 어려움
운영 메타데이터는 특정 데이터 소스에 연결하여 얻는 정보가 아닌 활용하는 여러 데이터 플랫폼에서 메타데이터 상태를 짜 맞추어야 합니다. redshift와 RDB, ES 등 다양한 데이터 플랫폼을 활용하면서 종속적인 관계를 정리해야 합니다. 이러한 정리는 무척 번거러운 일이며, 특히나 특정 코드를 통한(사용자 정의 함수) 시스템에서는 더더욱 유추하기 어렵습니다.
팀 지식
팀 지식의 경우에는 도메인이나 팀의 의사소통 방식에 따라 많이 다를 것이라고 생각되지만 간략하게 적으면 다음과 같은 버킷이 있는 것 같습니다.
- 설명 형식의 문서
- 비즈니스 직관적 계층 구조 및 비즈니스 분류, 어휘, 계정 등
- 개인 식별 가능 정보 필드, 암호화 등
- 인기 있는 테이블, 쿼리, 기타 형식의 ML 증강 메타데이터?
요구 사항 정리
카탈로그 서비스를 구축하기 위한 주요 모듈
1. 기술 메타데이터 추출기
- 데이터 소스에 연결하고 데이터 세트와 관련된 기본 메타데이터를 추출
2. 운영 메타데이터 추출기
- 데이터 변환 중의 시스템 간 메타데이터를 연결해 엔드투엔드 뷰를 만든다.
3. 팀 지식 취합기
- 데이터 세트와 관련된 정보에 주석을 달 수 있게 해서 데이터 팀 간 지식을 확장
기술 메타데이터 추출기 요구 사항
기술 메타데이터를 추출하기 위한 요구사항으로는 추출에 필요한 기술 목록을 이해하는 것과 메타데이터의 버전 지원입니다.
스케줄러와 쿼리엔진, 데이터스토어는 각각 다른 방식으로 메타데이터를 저장하기 때문에 메타데이터 추출에 적절한 지원을 제공하는지 알아야합니다. 또한, 최신 버전과 비교하여 메타데이터를 추적해야합니다. 디버깅과 감사, 그리고 스냅샷 활용을 위해 중요하다고 합니다.
운영 메타데이터 추출기 요구 사항
계보를 추출하기 위해서는 각 쿼리를 구문 분석하여 대상 테이블을 추출해야 합니다. 요구 사항 분석에는 모든 데이터스토어와 쿼리 엔진에 걸쳐 UDF를 포함하여 쿼리 유형의 인벤토리를 가져옵니다.
이러한 동작은 모니터링이나 SLA 경고, 이상 징후 추적의 필요성과 같은 데이터 프로파일링 통계와 관련이 있습니다.
팀 지식 취합기 요구 사항
- 비즈니스 어휘의 필요성
- 팀 지식에 추가 할 수 있는 사용자 유형 제한의 필요성, 접근 제어
- 메타데이터에 대한 검증 규칙, 검증 확인의 필요성
- 계보를 사용해 팀 지식 전파 필요성
구현 패턴
소스 특화 커넥터 패턴 ( 기술 메타데이터 )
서로 다른 데이터 소스에 연결하고 데이터와 연결 된 메타데이터 정보를 추출하는 작업입니다. 각 데이터 플랫폼에 액세스 할 수 있는 권한을 설정하고, 각기 다른 커넥터를 연결하여 지속적으로 메타데이터를 갱신합니다. 추가적으로 스토리지 내에 메타데이터를 저장하지 않고 검색 서비스에 등록하여 사용자 접근성을 높입니다.
계보 상관 패턴 ( 운영 메타데이터 )
데이터 및 작업에 걸친 운영 메타데이터를 연결해 실행 통계와 결합합니다. 간단히 운영 메타데이터를 작성하는 패턴입니다.
쿼리 구문 분석
데이터 계보 추적은 예약된 ETL로 실행되는 쿼리(작업 스케줄러, 데이터스토어 쿼리, 스트리밍 로그, 깃헙)를 분석하여 입력 및 출력 테이블의 목록을 얻어내어 계보를 저장합니다.
파이프라인 상관관계
ETL 중 각 작업은 하나 이상의 스크립트로 구성되어 실행단계를 가질 수 있습니다. 이러한 입력/출력 과정에서 시스템 특화 로그에 적힌 내용으로 계보를 저장합니다.
실행 통계를 통한 계보 보강
각 테이블 및 작업의 완료 시간이나 처리된 데이터의 카디널리티, 실행 오류나 액세스 빈도, 테이블 수를 포함한 통계를 추가합니다. 이 경우 이상 징후를 전체 파이프라인 실행과 연관시킬 수 있습니다.
팀 지식 패턴
데이터 문서
속성 의미, 열거형, 데이터 설명의 세부 정보가 포함됩니다. 사용자 경험을 기반해 자유 양식으로 메타데이터로 주석을 달 수 있습니다. 사용성에 대한 정보도 적을 수 있다고 합니다.
비즈니스 분류법 및 태그
비즈니스 영역과 주제에 따라 데이터를 분류 할 수 있습니다.