3.1 메타데이터의 3가지 유형
1) 기술 메타데이터 (Technical Metadata)
데이터의 물리적 구조와 기술적 특성을 설명합니다.
- 테이블명, 컬럼명, 데이터 타입
- Primary Key, Foreign Key 제약조건
- 인덱스, 파티션 정보
- 데이터베이스 연결 정보
- 파일 포맷, 압축 방식
2) 비즈니스 메타데이터 (Business Metadata)
데이터의 비즈니스 컨텍스트와 의미를 설명합니다.
- 설명 (Description)
- 소유자 (Owner)
- 비즈니스 용어 (Business Terms)
- 데이터 사용 목적
- SLA (Service Level Agreement)
3) 운영 메타데이터 (Operational Metadata)
데이터의 사용 패턴과 운영 정보를 추적합니다.
- 마지막 업데이트 시간
- 조회/쿼리 빈도
- 데이터 품질 점수
- 인기도 (Popularity)
- 접근 로그
{
"technical": {
"table": "customers",
"database": "prod_db",
"schema": "public",
"columns": [
{"name": "customer_id", "type": "BIGINT", "pk": true},
{"name": "email", "type": "VARCHAR(255)", "unique": true}
]
},
"business": {
"description": "고객 정보를 저장하는 메인 테이블",
"owner": "data-team@company.com",
"purpose": "Customer 360 분석"
},
"operational": {
"last_updated": "2025-12-26T10:00:00Z",
"query_count_24h": 1547,
"quality_score": 0.95,
"popularity_rank": 5
}
}
3.2 메타데이터 자동 수집
데이터베이스 메타데이터 추출
JDBC, ODBC를 사용하여 데이터베이스 시스템에서 메타데이터를 자동으로 수집합니다.
# PostgreSQL 예시
SELECT
table_schema,
table_name,
column_name,
data_type,
is_nullable,
column_default
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name, ordinal_position;
주요 플랫폼별 메타데이터 API
| 플랫폼 | API/도구 | 지원 메타데이터 |
|---|---|---|
| AWS | Glue Data Catalog API | 테이블, 파티션, 스키마 |
| GCP | Data Catalog API | BigQuery, Cloud Storage |
| Snowflake | INFORMATION_SCHEMA | 테이블, 뷰, 컬럼, 계보 |
| Databricks | Unity Catalog | Delta Lake, 계보 |
| dbt | manifest.json | 모델, 테스트, 의존성 |
3.3 스키마 관리
스키마 변경 감지
데이터베이스 스키마는 지속적으로 변경됩니다. 변경 사항을 자동으로 감지하고 추적하는 것이 중요합니다.
- 폴링 (Polling): 주기적으로 스키마를 확인하여 변경 감지
- 이벤트 기반: 데이터베이스 트리거/후크 활용
- CDC (Change Data Capture): 트랜잭션 로그 모니터링
스키마 버전 관리
{
"schema_version_id": "v5",
"dataset_id": "customers",
"timestamp": "2025-12-26T10:00:00Z",
"changes": [
{
"type": "ADD_COLUMN",
"column": "loyalty_points",
"data_type": "INTEGER",
"nullable": true
},
{
"type": "MODIFY_COLUMN",
"column": "email",
"old_type": "VARCHAR(200)",
"new_type": "VARCHAR(255)"
}
],
"changed_by": "migration-script-v1.5"
}
3.4 메타데이터 품질 관리
품질 평가 기준
| 항목 | 기준 | 배점 |
|---|---|---|
| 설명 (Description) | 20자 이상의 의미있는 설명 | 30점 |
| 소유자 (Owner) | 유효한 이메일 주소 | 20점 |
| 컬럼 설명 | 80% 이상 컬럼에 설명 | 20점 |
| 태그 | 최소 2개 이상의 태그 | 15점 |
| 신선도 | 최근 30일 이내 업데이트 | 15점 |
quality_score = (
(description_score * 0.3) +
(owner_score * 0.2) +
(column_description_score * 0.2) +
(tags_score * 0.15) +
(freshness_score * 0.15)
)
# 예시:
customers 테이블:
- Description: 30/30 (완벽한 설명)
- Owner: 20/20 (유효한 소유자)
- Column Description: 16/20 (80%)
- Tags: 15/15 (3개 태그)
- Freshness: 15/15 (어제 업데이트)
= 96/100 = 0.96 (Gold tier)
3.5 메타데이터 거버넌스
승인 워크플로우
중요한 메타데이터 변경 사항은 승인 프로세스를 거쳐야 합니다.
- 데이터 엔지니어가 새 테이블의 메타데이터 작성
- 데이터 거버넌스 팀에 리뷰 요청
- 리뷰어가 설명, 분류, 태그 검토
- 승인 후 카탈로그에 게시
- 관련 팀에 알림 발송
메타데이터 표준
- 명명 규칙: snake_case, 소문자 사용
- 설명 규칙: 한글/영어, 최소 20자, 목적 포함
- 태그 규칙: kebab-case, 사전 정의된 태그 사용
- 소유자 규칙: 팀 이메일 주소 우선
3.6 메타데이터 동기화
실시간 vs 배치 동기화
| 방식 | 장점 | 단점 | 적합한 경우 |
|---|---|---|---|
| 실시간 | 즉각 반영 | 높은 부하 | 중요 운영 DB |
| 배치 (1시간) | 균형 | 지연 있음 | 대부분의 경우 |
| 배치 (일간) | 낮은 부하 | 큰 지연 | 아카이브 데이터 |
증분 동기화
전체 메타데이터를 매번 수집하는 대신, 변경된 부분만 업데이트합니다.
# 증분 동기화 쿼리
SELECT *
FROM metadata_changelog
WHERE last_modified > :last_sync_timestamp
ORDER BY last_modified ASC;
3.7 메타데이터 저장소 아키텍처
저장소 선택
| 저장소 | 용도 | 예시 |
|---|---|---|
| 관계형 DB | 구조화된 메타데이터 | PostgreSQL, MySQL |
| 문서 DB | 유연한 스키마 | MongoDB |
| 그래프 DB | 계보, 관계 | Neo4j, JanusGraph |
| 검색 엔진 | 전문 검색 | Elasticsearch |
대부분의 데이터 카탈로그는 여러 저장소를 조합합니다:
- PostgreSQL: 메인 메타데이터 저장
- Neo4j: 계보 그래프 저장
- Elasticsearch: 검색 인덱스
- Redis: 캐시
3.8 실전 팁
- 자동화 우선: 수작업 최소화, 자동 수집 극대화
- 점진적 개선: 완벽한 메타데이터를 한 번에 만들려 하지 말것
- 인센티브 제공: 메타데이터 작성/개선 시 리워드
- 품질 대시보드: 팀별 메타데이터 품질 점수 공개
- 템플릿 제공: 좋은 설명의 예시 제공
3.9 다음 장 예고
다음 장에서는 Data Lineage Tracking을 다룹니다. 데이터의 흐름을 추적하고 계보 그래프를 구축하는 방법을 배우게 됩니다.