Skip to main content
이 문서는 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에서 확인하는 방법

  1. 왼쪽 메뉴에서 Catalog 선택
  2. 조회할 테이블 클릭
  3. Lineage 탭 클릭
  4. Upstream (이 테이블의 소스)과 Downstream (이 테이블을 참조하는 객체)을 그래프로 확인
그래프에서 노드를 클릭하면 해당 테이블/노트북/Job의 상세 정보로 이동할 수 있습니다. Unity Catalog 데이터 리니지 그래프 개요

컬럼 레벨 리니지 (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% 하락한 경우:
  1. system.access.column_lineagetotal_revenue의 upstream 컬럼 확인
  2. 각 upstream 테이블에서 동일 시점의 데이터 이상 여부 확인
  3. 문제 발생 단계(Bronze/Silver) 격리 후 파이프라인 수정

3. 규제 감사 대응 (GDPR 삭제 요청)

고객이 데이터 삭제를 요청한 경우, PII가 복사된 모든 테이블을 파악해야 합니다.

4. 비용 최적화 — 미사용 테이블 식별

리니지 데이터와 접근 로그를 결합하여, 생성은 되었지만 어떤 downstream에서도 참조되지 않고 조회도 없는 테이블을 식별합니다. 해당 테이블은 삭제 혹은 아카이빙 대상이 됩니다.

장단점과 한계

장점

  • 설정 불필요: Unity Catalog 활성화만으로 자동 수집
  • 컬럼 레벨 세분화: 단순 테이블 의존성을 넘어 컬럼까지 추적
  • UI + SQL 이중 접근: 시각적 탐색과 프로그래밍 방식 모두 지원
  • 다양한 객체 지원: 테이블, 노트북, Job, 대시보드, MLflow 모델 모두 연결

한계 및 주의사항


베스트 프랙티스

리니지 품질 향상

  1. 네이밍 규칙 일관화: bronze_, silver_, gold_ 접두사 사용으로 계층 파악이 용이합니다
  2. 노트북 대신 Job 사용: 노트북은 실행 주체가 불명확할 수 있으므로, 정기 파이프라인은 Databricks Job 으로 등록해 리니지에 Job 이름이 기록되도록 합니다
  3. 명시적 CTAS 사용: CREATE TABLE ... AS SELECT를 사용하면 컬럼 수준 리니지가 더 정확하게 캡처됩니다
  4. PII 태그와 리니지 결합: Unity Catalog 태그(Tag) 로 PII 컬럼을 표시하고, 리니지 쿼리 시 태그 기반 필터링을 활용합니다

정기적 리니지 검토

  • 분기별로 downstream이 없는 테이블 목록을 생성하여 테이블 수명주기를 관리합니다
  • 신규 파이프라인 배포 후 리니지 그래프를 검토해 의도하지 않은 의존성이 생기지 않았는지 확인합니다

참고 링크