데이터 계보는 여러 형태로 제공되며, 각각 특정 사용 사례에 적합하고 다른 수준의 세부 정보를 제공합니다. 이러한 유형을 이해하면 필요에 맞는 적절한 세밀도를 선택하는 데 도움이 됩니다.
컬럼 레벨 계보는 가장 세밀한 수준에서 데이터를 추적합니다: 테이블 내의 개별 컬럼. 어떤 소스 컬럼이 어떤 대상 컬럼에 기여하는지, 어떻게 변환되는지를 정확히 보여줍니다.
테이블 레벨 계보는 전체 테이블, 뷰 또는 데이터셋 간의 관계를 추적합니다. 컬럼 세부 정보를 파고들지 않고 데이터 흐름의 상위 수준 관점을 제공합니다.
프로세스 레벨 계보는 데이터보다는 변환 자체에 초점을 맞춥니다. 어떤 작업, 스크립트 또는 프로세스가 데이터를 생성하고 수정하는지 추적합니다.
비즈니스 계보는 기술적 데이터 계보를 비즈니스 개념, 메트릭 및 KPI와 연결합니다. 기술 자산을 비즈니스 친화적인 언어로 변환합니다.
대부분의 조직은 계보 유형의 조합이 필요합니다. 핵심은 각 사용 사례에 적합한 수준을 선택하는 것입니다:
현대 계보 도구는 종종 여러 유형을 결합합니다:
이 하이브리드 접근법은 포괄성과 유지 관리 가능성 및 성능 간의 균형을 맞춥니다.
계보는 수집 시점에 따라 정적(설계 시간) 또는 동적(실행 시간)으로 분류할 수 있습니다.
정적 계보는 코드 분석을 통해 생성되며 실제 데이터 흐름이 아닌 잠재적 데이터 흐름을 나타냅니다:
-- 원본 SQL
CREATE TABLE customer_summary AS
SELECT
c.customer_id,
c.email,
COUNT(o.order_id) as total_orders
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.email;
-- 파싱된 계보 메타데이터
소스 테이블:
- customers (컬럼: customer_id, email)
- orders (컬럼: customer_id, order_id)
목적지 테이블:
- customer_summary (컬럼: customer_id, email, total_orders)
변환:
- JOIN: customers.customer_id = orders.customer_id
- AGGREGATION: COUNT(orders.order_id)동적 계보는 실제 실행 중에 캡처되어 정확한 데이터 흐름을 보여줍니다:
실행 ID: exec_20250126_143022
타임스탬프: 2025-01-26 14:30:22 UTC
작업: customer_summary_daily
읽은 데이터:
- customers (파티션: 2025-01-26, 행: 45,892)
- orders (파티션: 2025-01-26, 행: 12,304)
쓴 데이터:
- customer_summary (파티션: 2025-01-26, 행: 45,892)
처리 통계:
- 처리 시간: 8.3초
- 처리한 바이트: 234MB
- 메모리 사용: 512MB기술적 계보와 비즈니스 계보는 서로 보완적이며 각각 다른 사용자를 대상으로 합니다.
| 측면 | 내용 |
|---|---|
| 대상 사용자 | 데이터 엔지니어, 개발자, DBA |
| 언어 | 테이블명, 컬럼명, SQL, 스키마 |
| 세부 수준 | 컬럼 레벨, 변환 로직 |
| 사용 사례 | 디버깅, 성능 최적화, 마이그레이션 |
| 예시 | warehouse.orders.customer_id → analytics.revenue.cust_id |
| 측면 | 내용 |
|---|---|
| 대상 사용자 | 비즈니스 분석가, 경영진, 데이터 스튜어드 |
| 언어 | 비즈니스 용어, 메트릭명, KPI |
| 세부 수준 | 메트릭 레벨, 비즈니스 개념 |
| 사용 사례 | 데이터 거버넌스, 규정 준수, 셀프 서비스 |
| 예시 | "월간 매출"은 "주문 데이터"와 "고객 세그먼트"에서 생성됨 |
필드 레벨 계보(컬럼 레벨 계보라고도 함)는 가장 세밀한 추적을 제공하여 규제가 엄격한 산업에서 특히 중요합니다.
필드: customer_email
타입: PII - 개인 식별 정보
분류: 민감도 높음
계보 체인:
1. source_systems.crm.contacts.email_address
↓ [ETL: 복사, 소문자 변환]
2. staging.raw_contacts.email
↓ [ETL: 유효성 검사, 중복 제거]
3. warehouse.customers.email
↓ [SQL: SELECT, 해싱]
4. analytics.customer_360.email_hash
↓ [API: 노출]
5. dashboards.marketing.anonymized_email
각 단계의 변환:
- 1→2: LOWER(email_address) AS email
- 2→3: CASE WHEN email ~ '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}$' THEN email END
- 3→4: SHA256(email) AS email_hash
- 4→5: CONCAT(LEFT(email, 3), '***@', SPLIT_PART(email, '@', 2))각 계보 유형은 서로 다른 도구와 기술을 사용하여 구현됩니다.
| 계보 유형 | 주요 도구 | 수집 방법 |
|---|---|---|
| 테이블 레벨 | Apache Atlas, Amundsen, DataHub | 메타데이터 API, 로그 파싱 |
| 컬럼 레벨 | Alation, Collibra, Informatica | SQL 파싱, 스키마 분석 |
| 프로세스 레벨 | Airflow, Dagster, Prefect | 작업 오케스트레이션 메타데이터 |
| 비즈니스 계보 | Atlan, Metaphor, Monte Carlo | 수동 주석, 용어집 매핑 |
| 동적 계보 | OpenLineage, Marquez | 런타임 이벤트 스트림 |
조직에서 계보를 구현할 때는 단계적 접근이 효과적입니다:
| 계보 유형 | 장점 | 단점 |
|---|---|---|
| 테이블 레벨 | 빠른 구현, 낮은 오버헤드, 전체 아키텍처 이해 | 세부 정보 부족, 컬럼 수준 문제 식별 불가 |
| 컬럼 레벨 | 정밀한 추적, 규정 준수, PII 관리 | 복잡한 구현, 높은 유지보수 비용, 성능 부담 |
| 프로세스 레벨 | 작업 최적화, 스케줄링 개선, 문제 해결 | 데이터 내용에 대한 정보 없음 |
| 비즈니스 계보 | 비기술 사용자 접근성, 거버넌스 지원 | 수동 유지보수, 기술 계보와 동기화 필요 |
| 동적 계보 | 실제 흐름 반영, 동적 쿼리 처리 | 실행 오버헤드, 모든 코드 경로 캡처 안 될 수 있음 |
이 장에서는 데이터 계보의 다양한 유형을 탐구했습니다. 각 유형은 특정 사용 사례와 요구사항을 충족합니다:
효과적인 계보 전략은 조직의 성숙도, 리소스, 규정 준수 요구사항에 따라 이러한 유형을 조합합니다. 테이블 레벨로 시작하여 점진적으로 세밀도를 추가하는 것이 일반적인 모범 사례입니다.