데이터 계보

데이터 계보는 데이터가 어디서 와서 어디로 흘러갔는지 따라가게 해 줍니다. 어느 표가 어느 표를 읽어 만들어졌는지 이어서 기록해 둡니다. 숫자가 이상하면 이 기록을 거슬러 원본을 찾습니다. 표를 바꾸기 전에는 이 기록을 따라 내려가 영향받을 곳을 봅니다.

상세

족보에는 누가 누구의 자식인지가 적혀 있습니다. 한 사람에서 위로 올라가면 조상이 나옵니다. 아래로 내려가면 자손이 나옵니다. 이름 하나만 알면 집안 전체에서 그 사람이 어디쯤 있는지 찾을 수 있습니다.

데이터 계보(data lineage)는 데이터를 두고 이 기록을 합니다. 어느 표가 어느 표를 읽어서 만들어졌는지 적습니다. 그 사이에 어떤 작업이 돌았는지도 적습니다.

이 절은 쇼핑몰 회사 하나를 예로 삼습니다. 이 회사의 일별 매출 표는 주문 표를 읽어 날짜마다 금액을 더해 만듭니다. 그러면 「주문 표 → 집계 작업 → 일별 매출 표」가 계보의 한 줄입니다.

계보는 데이터를 설명하는 데이터, 곧 메타데이터의 한 종류입니다. 표 안의 값이 아니라 표와 표 사이의 관계를 담습니다. 값만 봐서는 알 수 없는 「이 값이 어디서 왔나」에 답하려고 둡니다.

표가 표를 낳는 사슬

쇼핑몰의 주문 서비스와 회원 서비스는 각자 데이터베이스를 씁니다. 분석하는 사람은 이 데이터베이스를 직접 뒤지지 않습니다. 데이터를 분석용 저장소로 복사해서 씁니다. 분석에 맞게 정리해 모아 두는 이 저장소가 데이터 웨어하우스입니다.

복사하는 작업은 세 단계로 나뉩니다. 원본에서 꺼냅니다. 분석에 맞는 모양으로 바꿉니다. 웨어하우스에 넣습니다. 이 세 단계를 묶어 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다.

웨어하우스에 들어온 표도 한 번 더 가공됩니다. 주문 표와 회원 표를 함께 읽어 날짜마다 매출을 더한 일별 매출 표를 만듭니다. 이런 표는 매출을 보는 부서가 쓰기 편하게 따로 모아 둡니다. 한 부서가 쓰려고 추려 둔 이 작은 저장소가 데이터 마트입니다.

사슬의 끝에는 대시보드가 있습니다. 대시보드는 숫자를 그래프와 표로 모아 보여 주는 화면입니다. 경영진이 보는 매출 숫자는 이 사슬의 맨 끝에서 나옵니다. 지금까지의 사슬을 그리면 아래와 같습니다.

flowchart TD
    A["주문 데이터베이스"] --> R1["주문 복사 작업"]
    R1 --> C["웨어하우스 주문 표"]
    B["회원 데이터베이스"] --> R2["회원 복사 작업"]
    R2 --> D["웨어하우스 회원 표"]
    C --> J["집계 작업"]
    D --> J
    J --> E["일별 매출 표"]
    E --> F["매출 대시보드"]

화살표 하나는 데이터가 한 번 옮겨 간 것입니다. 작업이 표를 읽을 때와 작업이 표에 쓸 때마다 하나씩 생깁니다. 이 화살표를 빠짐없이 기록한 것이 계보입니다.

사슬이 이만하면 사람이 기억합니다. 회사가 커지면 표가 수천 개로 늘어납니다. 작업도 수백 개가 됩니다. 작업을 만든 사람이 팀을 옮기면 그 화살표는 누구의 머릿속에도 남지 않습니다. 계보는 이 화살표를 사람 대신 기록해 둡니다.

계보를 이루는 점과 화살표

계보는 그래프입니다. 그래프는 점과 그 점을 잇는 선으로 관계를 나타내는 구조입니다. 계보의 선에는 방향이 있어서 화살표로 그립니다.

계보의 점은 두 가지입니다. 하나는 데이터를 담는 것입니다. 표, 파일, 대시보드가 여기 듭니다. 다른 하나는 데이터를 읽고 쓰는 작업입니다. 앞 그림의 복사 작업과 집계 작업이 이쪽입니다.

화살표의 방향은 데이터가 흘러가는 방향과 같습니다. 작업이 표를 읽으면 표에서 작업으로 화살표가 갑니다. 작업이 표에 쓰면 작업에서 표로 갑니다.

화살표의 앞뒤를 부르는 말이 따로 있습니다. 어떤 표를 기준으로 데이터가 흘러 들어오는 쪽이 업스트림(upstream)입니다. 흘러 나가는 쪽은 다운스트림(downstream)입니다. 일별 매출 표를 기준으로 하면 웨어하우스 주문 표가 업스트림입니다. 매출 대시보드는 다운스트림입니다.

업스트림 추적과 원인 찾기

계보를 거슬러 오르는 쓰임부터 봅니다. 월요일 아침 매출 대시보드의 숫자가 지난주의 절반이라고 합시다. 장사가 안 된 것인지 데이터가 틀린 것인지부터 가려야 합니다.

계보가 있으면 대시보드에서 한 칸씩 올라가며 봅니다. 일별 매출 표도 절반이면 한 칸 더 올라갑니다. 웨어하우스 주문 표의 건수가 평소와 같다면 문제는 그 사이의 집계 작업입니다. 주문 표부터 줄었다면 주문 복사 작업이나 주문 데이터베이스를 봅니다.

겉으로 드러난 증상에서 거슬러 올라가 처음 틀어진 곳을 찾는 일을 근본 원인 분석이라고 합니다. 계보는 이 분석에서 어디를 볼지 순서를 정해 줍니다.

계보가 없으면 첫 칸에서 막힙니다. 대시보드가 어느 표를 읽는지 대시보드를 만든 사람에게 물어야 합니다. 그 표를 누가 만들었는지 또 물어야 합니다.

다운스트림 추적과 영향 분석

반대 방향으로도 씁니다. 주문 서비스를 맡은 백엔드 개발자가 주문 표의 amount 열 이름을 total_price 로 바꾸려 한다고 합시다. 서비스 코드만 고치면 끝날 것처럼 보입니다.

계보를 따라 내려가면 이 열을 웨어하우스로 복사하는 작업이 나옵니다. 그 뒤로 일별 매출 표와 대시보드가 줄줄이 달려 있습니다. 열 이름만 바꾸면 다음 날 새벽 복사 작업이 그 열을 못 찾고 멈춥니다. 대시보드는 어제 숫자에 멈춰 섭니다.

무언가를 바꾸기 전에 다운스트림을 따라가 영향받는 곳을 찾는 일이 영향 분석입니다. 계보가 있으면 바꾸기 전에 다운스트림 담당자에게 알릴 수 있습니다. 없으면 대시보드를 보던 사람이 항의할 때에야 압니다.

개인정보를 지울 때도 같은 방향으로 따라갑니다. 탈퇴한 회원이 자기 정보를 지워 달라고 하면 회원 표만 지워서는 모자랍니다. 이메일 열이 복사되어 간 표를 다운스트림에서 전부 찾아야 합니다. 어디까지 지워야 하는지를 계보가 알려 줍니다.

표 단위 계보와 열 단위 계보

지금까지는 표와 표를 이었습니다. 이것을 표 단위 계보라고 부릅니다. 더 잘게 열과 열을 잇는 계보도 있습니다. 열 단위 계보는 「일별 매출 표의 매출 열은 주문 표의 amount 열을 더한 값이다」까지 적습니다.

잘게 적으면 영향 분석의 답이 좁아집니다. 표 단위로는 주문 표를 읽는 표가 전부 영향권으로 나옵니다. 열 단위로는 amount 열을 쓰는 표만 남습니다. 주문 표에서 배송지 열만 읽는 표는 빠집니다.

둘을 견주면 아래와 같습니다.

마지막 줄이 둘을 가르는 대가입니다. 열 단위 계보는 계산식을 풀어 읽어야 얻습니다. 그래서 모으기가 더 어렵습니다.

계보를 모으는 방법

계보는 누군가 적어야 생깁니다. 적는 방법은 크게 셋입니다. 한 회사가 셋을 섞어 쓰기도 합니다.

첫째는 사람이 손으로 적는 방법입니다. 작업을 만든 사람이 문서에 「이 작업은 주문 표를 읽어 일별 매출 표에 쓴다」를 적습니다. 가장 쉬운 방법입니다. 그런데 작업을 고친 뒤 문서를 안 고치면 금방 낡습니다.

둘째는 변환 코드를 읽어 뽑는 방법입니다. 웨어하우스 안의 변환은 대개 SQL(Structured Query Language, 구조화 질의 언어) 문으로 적습니다. SQL 문을 문법대로 쪼개 읽으면 읽는 표와 쓰는 표가 나옵니다. 문장을 문법대로 쪼개 구조로 만드는 프로그램을 파서라고 합니다.

아래는 일별 매출 표를 만드는 SQL 문입니다. 파서가 계보로 뽑아내는 줄마다 오른쪽 주석으로 무엇이 나오는지 적었습니다.

INSERT INTO daily_sales   -- 쓰는 표
SELECT o.order_date,
       SUM(o.amount)      -- 값의 원천
FROM orders o             -- 읽는 표
JOIN members m            -- 읽는 표
  ON o.member_id = m.id
WHERE m.is_test = false
GROUP BY o.order_date;

members 표는 값을 주지 않습니다. 시험용 계정의 주문을 거르는 데만 쓰입니다. 그래도 표 단위 계보에는 업스트림으로 잡힙니다. members 표의 is_test 열이 틀리면 매출 숫자도 틀리기 때문입니다.

코드를 읽는 방법에도 빈틈이 있습니다. SQL 이 아닌 언어로 짠 변환은 못 읽습니다. 실행할 때 문자열을 이어 붙여 만드는 SQL 도 미리 읽을 수 없습니다.

셋째는 작업이 돌 때 스스로 알리는 방법입니다. 작업이 끝날 때마다 「방금 이 표를 읽어 이 표에 썼다」는 기록을 계보 저장소로 보냅니다. 돌아간 결과를 남기니 코드를 잘못 해석할 일이 없습니다.

대신 작업을 돌리는 도구마다 알리는 기능을 붙여야 합니다. 도구를 그대로 두고 코드만 읽는 둘째 방법과 여기서 갈립니다. 이 알림의 모양을 도구끼리 맞추려는 공개 규격도 있습니다.

셋을 견주면 아래와 같습니다.

모은 계보는 흔히 데이터 카탈로그 화면에서 봅니다. 데이터 카탈로그는 회사 데이터를 검색해서 찾게 해 주는 목록입니다. 표 하나를 고르면 그 표의 업스트림과 다운스트림을 그래프로 그려 보여 줍니다.

끊긴 계보와 대가

계보는 화살표가 이어져 있어야 쓸모가 있습니다. 누군가 표를 스프레드시트로 내려받아 손으로 고친 뒤 다시 올렸다고 합시다. 그 구간은 셋 중 어느 방법으로도 안 잡힙니다. 화살표가 거기서 끊깁니다.

끊긴 계보는 없는 계보보다 곤란할 수 있습니다. 영향 분석을 돌리면 끊긴 너머는 「영향받는 곳 없음」으로 나옵니다. 그 답을 믿고 열을 바꾸면 끊긴 너머의 표가 깨집니다.

모으는 데도 품이 듭니다. 도구마다 알리는 기능을 붙여야 합니다. 계보를 담을 저장소도 따로 굴려야 합니다. 열 단위로 모으면 저장할 화살표가 표 단위보다 훨씬 많아집니다.

표가 수십 개뿐이면 계보를 따로 모을 까닭이 적습니다. 만드는 사람과 쓰는 사람이 한 팀일 때도 그렇습니다. 궁금하면 작업 코드를 열어 보면 됩니다. 계보가 값을 하는 때는 표를 만드는 팀과 쓰는 팀이 갈릴 때입니다. 사슬이 몇 단계씩 길어질수록 더 그렇습니다.

이름이 같은 다른 계보

분산 처리 엔진에서도 계보라는 말을 씁니다. 뜻이 조금 다릅니다. 여러 컴퓨터에 계산을 나눠 맡기는 엔진은 중간 결과가 어떤 연산을 거쳐 나왔는지 기억해 둡니다. 컴퓨터 하나가 죽어 중간 결과 일부를 잃으면 그 기록대로 잃은 부분만 다시 계산합니다.

Apache Spark가 이 방식으로 잃은 조각을 되살립니다. 이 계보는 엔진 안에서만 씁니다. 계산이 끝나면 버립니다. 이 편이 다루는 데이터 계보는 사람이 읽으려고 오래 남기는 기록입니다.

관련 항목

데이터 계보가 이어 주는 저장소

데이터베이스 · 테이블 · 데이터 웨어하우스 · 데이터 레이크 · 데이터 레이크하우스 · 데이터 마트 · 대시보드

데이터 계보를 만들어 내는 가공 작업

ETL · ELT · 데이터 파이프라인 · 변환 · 원천 · 백필 · 오케스트레이션 · Apache Airflow

데이터 계보로 하는 분석

영향 분석 · 근본 원인 분석 · 데이터 품질 · 데이터 관측성 · 스키마 진화 · 데이터 계약

데이터 계보를 담는 메타데이터와 도구

메타데이터 · 운영 메타데이터 · 기술 메타데이터 · 데이터 카탈로그 · OpenLineage · SQL · 파서

데이터 계보를 그리는 그래프 구조

그래프 · 노드 · 간선 · DAG · 업스트림 · 다운스트림

데이터 계보가 떠받치는 관리 규칙

데이터 거버넌스 · 개인정보 · 접근 제어 · 데이터 소유자 · 감사 로그 · 규정 준수

데이터 계보와 이름이 겹치는 개념

데이터 출처 · Apache Spark · RDD