이 문서는 Unity Catalog 섹션의 일부입니다.
리니지란?
💡 데이터 리니지(Data Lineage) 란 데이터가 어디서 왔고(upstream), 어디로 가는지(downstream) 를 추적하는 기능입니다. “이 테이블의 데이터는 어떤 소스에서 왔지?”, “이 컬럼을 변경하면 어디에 영향이 가지?”라는 질문에 답할 수 있습니다.
왜 데이터 리니지가 필요한가?
데이터 신뢰성 문제
현대 데이터 파이프라인은 수십 개의 테이블을 거쳐 데이터가 흐릅니다. 소스 시스템에서 변경이 발생하면 그 영향이 어디까지 전파되는지 파악하기 어렵습니다. 데이터 리니지 가 없으면 다음과 같은 문제가 발생합니다.- Gold 테이블 값이 갑자기 달라졌을 때 원인 파악에 수 시간 소요
- 소스 스키마 변경이 어떤 downstream 리포트에 영향을 주는지 알 수 없음
- 특정 데이터가 신뢰할 수 있는지 확인할 방법 부재
규제 준수 (GDPR, SOX)
규제 감사(Audit) 시 “이 수치가 어디서 왔는지”를 즉시 제시할 수 있어야 합니다. 수동 문서화는 현실적으로 불가능하며, 자동 리니지 캡처 가 유일한 실용적 대안입니다.
영향도 분석 (Impact Analysis)
스키마 변경 전 영향 범위를 사전에 파악합니다.디버깅 (Debugging)
데이터 품질 이슈 발생 시 역방향으로 소스를 추적합니다. Gold 테이블 이상 → Silver 테이블 확인 → Bronze 테이블 확인 순서로 빠르게 문제를 격리할 수 있습니다.어떻게 작동하는가?
Unity Catalog의 자동 리니지 캡처 메커니즘
Unity Catalog는 Spark 실행 계획(Execution Plan) 을 분석하여 리니지를 자동으로 캡처합니다. 별도의 설정 없이 Unity Catalog가 활성화된 환경에서 쿼리를 실행하면 자동으로 수집됩니다.캡처 범위
리니지 시각화
Catalog Explorer UI에서 확인하는 방법
- 왼쪽 메뉴에서 Catalog 선택
- 조회할 테이블 클릭
- Lineage 탭 클릭
- Upstream (이 테이블의 소스)과 Downstream (이 테이블을 참조하는 객체)을 그래프로 확인
컬럼 레벨 리니지 (Column-Level Lineage)
테이블 수준 리니지에서 더 나아가, 특정 컬럼 이 어떤 컬럼에서 파생되었는지까지 추적합니다.- 테이블 Lineage 탭 → 컬럼 이름 클릭
- 해당 컬럼의 upstream/downstream 컬럼이 하이라이트됩니다
출처: Databricks 공식 문서 — Data lineage
리니지의 범위 예시
테이블 수준 리니지
컬럼 수준 리니지
SQL로 리니지 조회하기
Unity Catalog의 시스템 테이블(System Tables) 을 통해 리니지 데이터를 프로그래밍 방식으로 조회할 수 있습니다.참고: 시스템 테이블은system.access스키마에 위치합니다. 과거 일부 문서에서 사용되던system.lineage스키마는 현재system.access.table_lineage/system.access.column_lineage로 통합되었습니다.
system.access.table_lineage 조회
system.access.column_lineage 조회
실전 활용 시나리오
1. 스키마 변경 영향도 분석
silver_orders.total_amount 컬럼의 타입을 DECIMAL(10,2)에서 DOUBLE로 변경하려는 경우:
2. 데이터 품질 이슈 역추적
Gold 테이블의total_revenue 값이 어제 대비 30% 하락한 경우:
system.access.column_lineage로total_revenue의 upstream 컬럼 확인- 각 upstream 테이블에서 동일 시점의 데이터 이상 여부 확인
- 문제 발생 단계(Bronze/Silver) 격리 후 파이프라인 수정
3. 규제 감사 대응 (GDPR 삭제 요청)
고객이 데이터 삭제를 요청한 경우, PII가 복사된 모든 테이블을 파악해야 합니다.4. 비용 최적화 — 미사용 테이블 식별
리니지 데이터와 접근 로그를 결합하여, 생성은 되었지만 어떤 downstream에서도 참조되지 않고 조회도 없는 테이블을 식별합니다. 해당 테이블은 삭제 혹은 아카이빙 대상이 됩니다.장단점과 한계
장점
- 설정 불필요: Unity Catalog 활성화만으로 자동 수집
- 컬럼 레벨 세분화: 단순 테이블 의존성을 넘어 컬럼까지 추적
- UI + SQL 이중 접근: 시각적 탐색과 프로그래밍 방식 모두 지원
- 다양한 객체 지원: 테이블, 노트북, Job, 대시보드, MLflow 모델 모두 연결
한계 및 주의사항
베스트 프랙티스
리니지 품질 향상
- 네이밍 규칙 일관화:
bronze_,silver_,gold_접두사 사용으로 계층 파악이 용이합니다 - 노트북 대신 Job 사용: 노트북은 실행 주체가 불명확할 수 있으므로, 정기 파이프라인은 Databricks Job 으로 등록해 리니지에 Job 이름이 기록되도록 합니다
- 명시적 CTAS 사용:
CREATE TABLE ... AS SELECT를 사용하면 컬럼 수준 리니지가 더 정확하게 캡처됩니다 - PII 태그와 리니지 결합: Unity Catalog 태그(Tag) 로 PII 컬럼을 표시하고, 리니지 쿼리 시 태그 기반 필터링을 활용합니다
정기적 리니지 검토
- 분기별로 downstream이 없는 테이블 목록을 생성하여 테이블 수명주기를 관리합니다
- 신규 파이프라인 배포 후 리니지 그래프를 검토해 의도하지 않은 의존성이 생기지 않았는지 확인합니다