데이터 카탈로그

데이터 카탈로그는 회사에 쌓인 데이터를 검색해서 찾아 쓰게 해 줍니다. 테이블과 파일마다 붙은 설명을 한곳에 모아 둡니다. 분석하는 사람은 담당자를 수소문하는 대신 카탈로그에서 찾습니다. 찾은 데이터를 믿고 써도 되는지도 거기서 가늠합니다.

쉽고 빠른 이해

무슨 일을 하는 물건인가 — 회사 데이터를 찾는 검색용 목록입니다. 「주문」을 검색하면 한 화면에 세 가지가 나옵니다. 주문 테이블이 어느 저장소에 있는지, 열마다 무슨 뜻인지, 누가 책임지는지입니다.

왜 이렇게 하나 — 테이블이 수천 개로 늘면 어느 것이 믿을 만한 원본인지 아무도 모르게 됩니다. 비슷한 이름의 표가 여럿 생깁니다. 같은 질문에 부서마다 다른 숫자를 냅니다. 목록이 있으면 찾는 시간이 줄고 모두 같은 표를 보게 됩니다.

어떻게 도나

1. 수집기가 데이터베이스와 파일 저장소를 돌며 테이블 이름과 열 목록을 읽어 옵니다
2. 표를 책임지는 사람이 설명과 「매출」 같은 낱말의 뜻을 적어 넣습니다
3. 쓰는 사람이 검색해서 찾습니다. 그 표가 어디서 왔는지도 따라가 봅니다

대가 — 설명은 사람이 적으니 손이 계속 갑니다. 아무도 고치지 않으면 목록이 낡습니다. 낡은 목록도 사람들은 믿고 쓰니 더 곤란합니다. 테이블이 적고 한 팀만 쓰면 둘 필요가 없습니다.

상세

큰 도서관에는 책과 따로 목록이 있습니다. 목록에는 책마다 제목과 저자, 주제, 꽂힌 서가 번호가 적혀 있습니다. 찾는 사람은 서가를 다 돌지 않습니다. 목록에서 주제를 검색해 서가 번호를 얻고 그 서가로 갑니다.

데이터 카탈로그(data catalog)는 회사 데이터를 두고 이 일을 합니다. 책에 해당하는 것이 테이블과 파일이고, 목록 카드에 해당하는 것이 메타데이터입니다. 메타데이터는 데이터를 설명하는 데이터입니다. 「이 테이블은 주문을 한 건에 한 줄씩 담고, 매일 새벽에 갱신된다」가 메타데이터의 한 예입니다.

카탈로그는 이 메타데이터를 여러 저장소에서 모아 한곳에 두고 검색하게 합니다. 데이터 자체는 옮기지 않습니다. 카탈로그에서 찾은 뒤에는 원래 저장소에 가서 읽습니다.

이 절은 쇼핑몰 회사 하나를 예로 삼습니다.

목록 없이 늘어난 테이블

쇼핑몰의 주문 서비스와 회원 서비스는 각자 데이터베이스를 씁니다. 서비스가 돌면서 읽고 쓰는 이 데이터베이스를 운영 데이터베이스라고 부릅니다. 분석할 때는 운영 데이터베이스를 직접 뒤지지 않고 데이터를 복사해 둡니다.

복사한 데이터를 분석하기 좋게 정리해 담는 저장소가 데이터 웨어하우스입니다. 파일을 가공하지 않고 쌓아 두는 저장소는 데이터 레이크입니다. 두 곳에 몇 년 치가 쌓이면 테이블이 수천 개가 됩니다.

그러면 이름만으로는 고를 수 없게 됩니다. orders, orders_v2, orders_final 이 나란히 있습니다. 어느 것이 지금도 갱신되는지, 취소된 주문이 빠졌는지는 이름에 안 나옵니다.

새로 온 분석가는 사내 메신저에 묻습니다. 답을 아는 사람이 퇴사했으면 아무도 모릅니다. 결국 비슷한 표를 하나 더 만듭니다. 그러면 같은 「지난달 매출」에 부서마다 다른 숫자가 나옵니다.

데이터는 다 있습니다. 그런데 믿고 쓸 것을 못 찾습니다. 이 상태를 데이터 늪이라고 부릅니다. 데이터 카탈로그는 이 늪을 막으려고 둡니다. 테이블마다 설명과 책임자를 붙여 두면 고를 근거가 생깁니다.

한 항목에 담기는 것

카탈로그의 한 항목은 테이블 하나, 또는 파일 묶음 하나를 설명합니다. 쇼핑몰 웨어하우스의 orders 테이블 항목이라면 아래 내용이 들어갑니다. 표의 「수집기」는 저장소를 돌며 테이블 정보를 자동으로 읽어 오는 프로그램입니다. 「소유자」는 그 표를 책임지는 사람입니다.

위치, 열과 타입, 갱신 시각은 기계가 읽어 올 수 있습니다. 데이터베이스가 자기 테이블이 어디 있고 언제 바뀌었는지 기록해 두기 때문입니다. 이렇게 기계가 아는 메타데이터가 기술 메타데이터입니다.

그중 열 이름과 타입의 목록을 스키마라고 부릅니다. 스키마는 테이블에 어떤 열이 있고 열마다 어떤 값이 들어가는지 정한 약속입니다. 스키마를 보면 그 표로 무엇을 계산할 수 있는지 가늠할 수 있습니다.

설명, 소유자, 용어, 민감도는 대개 사람이 적어야 합니다. 「매출에 취소를 넣나」는 데이터베이스가 모르는 약속이기 때문입니다. 이렇게 사람만 아는 메타데이터가 비즈니스 메타데이터입니다.

낱말의 뜻을 적은 용어가 쌓이면 회사 안의 낱말 사전이 됩니다. 「매출」「활성 회원」처럼 부서마다 다르게 쓰던 낱말을 한 뜻으로 묶어 둔 이 사전이 비즈니스 용어집입니다. 같은 낱말로 같은 숫자를 뽑게 하려고 둡니다.

기술 메타데이터는 데이터베이스에 접속하면 카탈로그 없이도 볼 수 있습니다. 카탈로그가 없으면 사라지는 것은 비즈니스 메타데이터입니다. 「이 표를 믿어도 되나」에 답하는 것도 설명과 소유자입니다.

메타데이터를 모으는 방법

카탈로그는 두 갈래로 채워집니다. 기계가 아는 것은 자동으로 읽어 옵니다. 사람만 아는 것은 사람이 화면에서 적어 넣습니다.

자동으로 읽는 일은 수집기가 맡습니다. 수집기는 저장소마다 접속해 테이블과 열의 목록을 읽습니다. 이 일을 하루 한 번이나 몇 시간마다 되풀이합니다. 돌 때마다 지난번과 견줘 새 테이블과 바뀐 열을 반영합니다.

앞에서 본 것처럼 데이터베이스는 자기 테이블을 스스로 기록합니다. 이 기록을 담은 내부 테이블이 시스템 카탈로그입니다. 테이블을 만들거나 열을 바꾸면 데이터베이스가 알아서 고쳐 적습니다.

많은 관계형 데이터베이스는 이 내용을 information_schema 라는 이름의 뷰로 보여 줍니다. 수집기는 이 뷰를 조회해 열 이름과 타입을 가져옵니다.

파일 저장소도 같은 식으로 훑습니다. 파일 경로를 읽은 뒤 파일 안에 적힌 열 구조를 읽어 옵니다.

주기로 훑으면 그 사이에 바뀐 것은 늦게 보입니다. 그래서 데이터를 쓰는 쪽이 알려 주는 방식도 함께 씁니다. 데이터를 한 저장소에서 읽어 가공해 다른 저장소에 쓰는 작업을 데이터 파이프라인이라고 부릅니다. 파이프라인이 테이블에 쓸 때마다 「이 표를 방금 갱신했다」는 메시지를 카탈로그에 보냅니다.

사람이 적는 설명은 카탈로그의 웹 화면에서 넣습니다. 소유자가 설명과 용어를 적습니다. 쓰는 사람이 질문을 남기기도 합니다.

지금까지 본 흐름을 그리면 아래와 같습니다.

flowchart TD
    subgraph 원천["데이터가 사는 저장소"]
        A["운영 데이터베이스"]
        B["데이터 웨어하우스"]
        C["데이터 레이크의 파일"]
    end
    원천 -->|"주기로 훑는다"| D["수집기"]
    D --> E["데이터 카탈로그"]
    H["데이터 파이프라인"] -->|"표에 쓴다"| B
    H -->|"방금 갱신했다"| E
    F["소유자"] -->|"설명과 용어를 적는다"| E
    E -->|"검색 결과"| G["분석가"]
    G -->|"찾은 표를 읽는다"| B

카탈로그로 들어가는 것은 데이터를 설명하는 정보, 곧 메타데이터뿐입니다. 데이터 자체는 들어가지 않습니다. 분석가는 카탈로그에서 표를 고른 뒤, 데이터는 원래 저장소에서 읽습니다.

데이터 계보

설명과 소유자만으로 답이 안 나오는 질문이 있습니다. 「이 대시보드의 매출 숫자는 어느 표에서 왔나」입니다. 카탈로그는 이 질문에 답하려고 표와 표 사이의 연결도 기록합니다.

어떤 데이터가 어디서 와서 어디로 흘러갔는지 적은 기록이 데이터 계보(data lineage)입니다. 쇼핑몰의 웨어하우스 주문 표는 주문 표에 회원 정보를 붙여 만듭니다. 이 표에서 매출 대시보드까지의 계보는 아래처럼 생겼습니다.

flowchart TD
    A["주문 데이터베이스의 주문 표"] --> C["웨어하우스 주문 표"]
    B["회원 데이터베이스의 회원 표"] --> C
    C --> D["일별 매출 표"]
    D --> E["매출 대시보드"]

계보는 두 방향으로 따라갑니다. 위로 올라가면 원인을 찾습니다. 대시보드 숫자가 어제부터 반으로 줄었다면 일별 매출 표, 웨어하우스 주문 표 순으로 올라가며 어디서 줄었는지 봅니다.

아래로 내려가면 영향을 봅니다. 주문 표의 열 하나를 지우려는 백엔드 개발자는 그 열을 읽는 표와 대시보드를 먼저 확인합니다. 계보가 없으면 지운 뒤 누군가 항의할 때까지 모릅니다. 바꾸기 전에 영향받는 곳을 이렇게 찾는 일을 영향 분석이라고 부릅니다.

계보는 두 곳에서 채워집니다. 하나는 파이프라인이 「어느 표를 읽어 어느 표에 썼다」를 카탈로그에 알리는 것입니다. 다른 하나는 수집기가 변환에 쓴 SQL(Structured Query Language, 구조화 질의 언어) 문을 읽어 읽는 표와 쓰는 표를 뽑아내는 것입니다.

민감한 열과 접근 규칙

카탈로그는 데이터를 찾게 해 주는 동시에 아무나 읽으면 안 되는 데이터도 드러냅니다. 그래서 접근 규칙을 거는 기준으로도 씁니다.

출발점은 항목의 민감도 줄입니다. email 열에 「개인정보」 표시가 붙어 있으면, 그 표시가 붙은 열을 가진 표를 한 번에 골라낼 수 있습니다. 열 값이 이메일이나 전화번호 꼴이면 표시를 자동으로 붙이는 카탈로그도 있습니다.

누가 어떤 데이터를 읽을 수 있는지 정하는 것이 접근 제어입니다. 표시를 기준으로 삼으면 「개인정보 열은 허가받은 사람만 읽는다」는 규칙 하나를 여러 표에 한꺼번에 걸 수 있습니다. 새 표가 생겨도 표시만 붙으면 같은 규칙이 따라붙습니다.

카탈로그는 어느 열에 어떤 표시가 있고 어떤 규칙이 걸리는지를 알려 줍니다. 읽기를 실제로 막는 것은 데이터를 내주는 저장소의 권한 설정입니다. 카탈로그의 표시가 그 권한 설정으로 넘어가야 규칙이 걸립니다. 둘을 한 제품이 함께 맡는 경우는 다음 소절 끝에서 봅니다.

데이터를 누가 어떻게 쓰고 언제 지울지 정한 회사 규칙 전체가 데이터 거버넌스입니다. 규칙 자체는 문서로 정합니다. 그 규칙이 어느 표에 걸리는지는 카탈로그가 압니다.

이름이 같은 다른 카탈로그

「카탈로그」라는 낱말은 데이터 쪽에서 세 가지를 가리킵니다. 셋 다 테이블을 설명하는 정보를 담습니다. 누가 읽고 얼마나 넓게 담느냐가 다릅니다.

앞에서 본 시스템 카탈로그는 데이터베이스 하나가 자기 안의 테이블을 기록한 것입니다. 데이터베이스는 조회를 실행할 때마다 이것을 읽어 테이블과 열이 있는지 확인합니다.

데이터 레이크에는 이런 목록이 저절로 생기지 않습니다. 파일만 쌓여 있기 때문입니다. 그래서 「orders 테이블은 이 경로의 파일들이고 열은 이렇다」는 대응을 기록해 둡니다.

이 기록을 읽는 쪽은 쿼리 엔진입니다. 쿼리 엔진은 레이크의 파일을 테이블처럼 SQL 로 조회하게 해 주는 프로그램입니다. 조회가 들어오면 이 기록에서 경로를 찾아 그 파일을 읽습니다.

이 기록도 흔히 카탈로그라고 부릅니다. 대표 예가 Hive 메타스토어입니다. Hive 는 레이크의 파일을 SQL 로 조회하게 한 초기 도구입니다. 메타스토어는 그 도구가 대응 기록을 담아 두는 저장소입니다.

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

마지막 줄이 가장 큰 차이입니다. 앞의 둘은 기계가 돌아가려면 있어야 합니다. 데이터 카탈로그는 없어도 조회가 돕니다. 사람이 고르는 일을 돕는 목록이기 때문입니다.

두 역할을 한 제품이 같이 맡기도 합니다. 쿼리 엔진이 읽는 목록에 설명과 권한을 얹어 사람도 쓰게 한 것입니다. 그래서 제품 이름만 보고는 어느 뜻인지 가르기 어렵습니다. 문맥에서 「누가 읽나」를 보면 갈립니다.

두지 않아도 되는 때와 대가

카탈로그는 들인다고 끝나지 않습니다. 수집기가 채우는 기술 메타데이터는 저절로 새로워집니다. 설명과 소유자는 사람이 고쳐야 합니다. 표를 바꾼 사람이 설명을 안 고치면 카탈로그는 틀린 말을 합니다.

낡은 카탈로그는 없는 것보다 곤란할 수 있습니다. 목록에 적혀 있으니 사람들이 믿고 씁니다. 그래서 표마다 소유자를 정합니다. 오래 안 고친 설명은 화면에 따로 표시합니다.

테이블이 수십 개이고 쓰는 사람이 한 팀뿐이면 카탈로그를 둘 까닭이 적습니다. 데이터베이스의 열 주석이나 팀 문서 하나로 같은 일을 합니다. 카탈로그가 필요해지는 때는 조건이 둘입니다. 저장소가 여럿일 때, 그리고 표를 만드는 팀과 쓰는 팀이 갈릴 때입니다.

관련 항목

데이터 카탈로그가 모아 담는 메타데이터

메타데이터 · 기술 메타데이터 · 비즈니스 메타데이터 · 운영 메타데이터 · 스키마 · 비즈니스 용어집 · 데이터 계보 · 데이터 소유자

데이터 카탈로그가 목록을 만드는 저장소

데이터 웨어하우스 · 데이터 레이크 · 데이터 레이크하우스 · 데이터 마트 · 데이터베이스 · 오브젝트 스토리지

데이터 카탈로그와 헷갈리는 카탈로그

시스템 카탈로그 · information_schema · Hive 메타스토어 · 쿼리 엔진 · 테이블 포맷 · Apache Iceberg

데이터 카탈로그가 떠받치는 관리 규칙

데이터 거버넌스 · 접근 제어 · 개인정보 · 데이터 분류 · 데이터 품질 · 보존 기간 · 감사 로그

데이터 카탈로그가 제공하는 기능

검색 · 태그 · 데이터 디스커버리 · 영향 분석 · 데이터 프로파일링 · 데이터 관측성

데이터 카탈로그를 채우는 파이프라인

데이터 파이프라인 · ETL · ELT · 워크플로우 오케스트레이션 · 변경 데이터 캡처

데이터 카탈로그가 막으려는 장애

데이터 늪 · 데이터 사일로 · 스키마 드리프트 · 데이터 다운타임

데이터 카탈로그가 속하는 상위 분류

데이터 엔지니어링 · 데이터 관리 · 메타데이터 관리 · 데이터 플랫폼

데이터 카탈로그를 전제로 한 조직 방식

데이터 메시 · 데이터 제품 · 데이터 계약 · 셀프서비스 분석

데이터 카탈로그를 구현한 제품

DataHub · Amundsen · OpenMetadata · Apache Atlas · AWS Glue Data Catalog · Unity Catalog