Unity Catalog와 데이터 거버넌스

앞 노트에서 환경 사이를 잇는 것이 Unity Catalog라고 적었습니다. 이 시험이 응시자 설명에 Unity Catalog를 이름으로 못 박아 두었기 때문에, 데이터를 다루는 문항이든 모델을 등록하는 문항이든 배경에 이 이름이 깔립니다. 그런데 정작 갈리는 지점은 「Unity Catalog가 좋다」가 아니라 이름이 몇 마디인가, 그 이름이 어느 층에 사는가 두 가지입니다.

이름이 세 마디인 이유

Unity Catalog(UC)는 데이터와 AI 자산에 이름을 붙이고 권한을 매기는 거버넌스 계층입니다. 여기서 관리하는 것은 테이블만이 아니라 뷰·볼륨·함수·모델까지입니다.

이름은 세 마디로 붙습니다.

카탈로그 . 스키마 . 객체
main     . retail . transactions

카탈로그는 가장 바깥 묶음이고 보통 환경이나 사업 단위로 가릅니다(dev·prod처럼). 스키마는 그 안의 주제별 묶음이고, 예전 Hive 용어로는 데이터베이스입니다. 객체가 실제 테이블·모델입니다.

세 마디 위에 하나가 더 있습니다. 메타스토어(metastore)는 리전마다 하나씩 두는 최상위 컨테이너이고 여러 워크스페이스가 여기에 붙습니다. 이름에는 안 들어가지만 「다른 워크스페이스에서도 같은 테이블을 보려면」이라는 물음의 답이 여기 있습니다.

시험에서 이 세 마디가 그대로 문항이 되는 자리가 셋입니다 — 데이터 테이블, 피처 테이블, 그리고 등록하는 모델입니다. 두 마디짜리 이름(retail.transactions)이 매력적인 오답으로 자주 섞입니다.

워크스페이스 수준과 계정 수준

UC 이전의 Databricks는 워크스페이스마다 자기 메타스토어를 갖고 있었습니다. 그것이 지금도 hive_metastore라는 이름으로 남아 있는 옛 카탈로그입니다. 이 자리에 있는 것의 성질이 문항의 뼈대입니다.

「팀 A의 워크스페이스에서 만든 피처 테이블을 팀 B가 못 찾는다」는 시나리오의 답은 대개 그 테이블이 아직 hive_metastore에 있다는 것입니다.

Delta Lake — 테이블의 실제 모양

Delta Lake는 클라우드 스토리지의 Parquet 파일 위에 트랜잭션 로그를 얹은 테이블 형식입니다. Databricks에서 「테이블」이라고 하면 기본적으로 이것이고, UC는 그 위에 이름과 권한을 씌우는 층입니다. 둘은 경쟁하는 것이 아니라 아래위로 쌓입니다.

머신러닝에서 Delta가 값을 하는 지점이 셋입니다.

• ACID 트랜잭션: 학습이 테이블을 읽는 동안 다른 작업이 쓰기를 해도 읽던 쪽이 깨진 중간 상태를 보지 않습니다.
• 시간 여행(time travel): 버전 번호나 시각으로 과거 상태를 그대로 읽습니다. 「석 달 전 모델을 재현하려면」의 답이 여기입니다.
• 스키마 강제: 컬럼 타입이 어긋나는 쓰기를 막아, 학습 데이터에 조용히 문자열이 섞이는 일을 줄입니다.

-- 학습에 쓴 그때의 상태를 그대로 읽는다
SELECT * FROM main.retail.transactions VERSION AS OF 42;

DESCRIBE HISTORY main.retail.transactions;

테이블이 어디에 저장되는지도 두 갈래입니다. 관리형 테이블(managed table)은 UC가 정해 둔 위치에 데이터를 두고 수명까지 관리해, 테이블을 지우면 데이터 파일도 함께 지워집니다. 외부 테이블(external table)은 이미 있는 스토리지 경로를 가리키기만 하므로 테이블을 지워도 파일은 남습니다. 「테이블을 DROP 했는데 스토리지 비용이 그대로다」는 상황의 답이 뒤쪽이고, 특별한 이유가 없으면 관리형이 기본입니다.

Delta Live Tables — 파이프라인을 선언으로 쓰기

Delta Live Tables(DLT)는 「이 테이블은 저 테이블에서 이렇게 나온다」를 선언하면 실행 순서·재시도·증분 갱신을 플랫폼이 알아서 맡는 파이프라인 프레임워크입니다. 노트북에 읽기와 쓰기를 순서대로 적는 대신, 테이블을 함수로 정의합니다.

import dlt
from pyspark.sql import functions as F

@dlt.table(name="clean_transactions")
@dlt.expect_or_drop("amount_positive", "amount > 0")
def clean_transactions():
    return spark.read.table("main.retail.transactions").withColumn(
        "log_amount", F.log1p("amount")
    )

여기서 시험이 보는 것은 기대치(expectation)입니다. expect는 어긋난 행을 기록만 하고 통과시키고, expect_or_drop은 그 행을 버리며, expect_or_fail은 파이프라인을 세웁니다. 「학습 데이터에 음수 금액이 섞여 들어오는 것을 막고 싶다」는 요구에 세 갈래 중 하나를 고르게 하는 식입니다.

권한과 계보

권한은 위에서부터 내려가며 열어야 합니다. 테이블 하나를 읽으려면 SELECT 하나로는 부족하고, 그 위 카탈로그에 USE CATALOG, 스키마에 USE SCHEMA가 함께 있어야 합니다.

GRANT USE CATALOG ON CATALOG main TO `ml-engineers`;
GRANT USE SCHEMA ON SCHEMA main.retail TO `ml-engineers`;
GRANT SELECT ON TABLE main.retail.transactions TO `ml-engineers`;

데이터 계보(lineage)는 어느 테이블이 어느 테이블에서 나왔고 어떤 노트북·Job이 그것을 읽고 썼는지를 UC가 자동으로 기록한 것입니다. 사람이 따로 적지 않아도 쌓이고, 모델까지 이어집니다. 「이 컬럼을 바꾸면 무엇이 깨지는가」와 「이 모델은 무엇으로 학습됐는가」를 화면에서 되짚을 수 있는 것이 이 기능입니다.

피처 테이블을 계정 수준에 두면

피처 테이블은 모델 학습과 추론에 함께 쓰는 피처를 담아 둔 테이블입니다. UC에 두면 이것이 특별한 저장소가 아니라 그냥 기본 키가 있는 Delta 테이블이 되고, 그래서 다음이 따라옵니다.

• 팀과 워크스페이스를 넘어 같은 이름으로 찾아 쓸 수 있습니다. 같은 피처를 두 팀이 각자 다시 만드는 일이 줄어듭니다.
• 권한이 다른 테이블과 같은 문법으로 걸립니다. 별도의 접근 제어 체계를 하나 더 두지 않아도 됩니다.
• 계보가 자동으로 이어져 어느 모델이 어느 피처를 썼는지가 남습니다.
• 시간 여행과 스키마 강제가 그대로 붙습니다.

피처 테이블을 실제로 만들고 조회하는 API는 뒤쪽 노트에서 다룹니다. 여기서 기억할 것은 자리가 계정 수준이라는 것과 그 자리에서 나오는 이점들입니다.

연습 문제

1. Unity Catalog에서 테이블을 가리키는 올바른 이름은?
   ① transactions
   ② retail.transactions
   ③ main.retail.transactions
   ④ metastore.main.retail.transactions

   ③. 카탈로그·스키마·객체 세 마디입니다. 메타스토어는 이름에 들어가지 않습니다.
2. 사용자가 main.retail.transactions에 SELECT 권한을 받았는데도 조회가 거부됩니다. 가장 가능성이 높은 원인은?
   ① 테이블이 Delta 형식이 아니다
   ② 카탈로그·스키마에 USE 권한이 없다
   ③ 클러스터가 단일 노드다
   ④ 계보 수집이 꺼져 있다

   ②. 권한은 위에서부터 열립니다. 가장 안쪽 권한만 준 것이 흔한 실수입니다.
3. Unity Catalog가 hive_metastore보다 나은 점으로 옳은 것을 둘 고르시오.
   ① 여러 워크스페이스가 같은 자산을 공유한다
   ② 데이터 계보가 자동으로 수집된다
   ③ 테이블 이름이 두 마디로 짧아진다
   ④ Parquet 대신 CSV로 저장된다
   ⑤ 스토리지 비용이 절반이 된다

   ①과 ②. 이름은 오히려 세 마디로 길어지고(③), 저장 형식이나 비용과는 무관합니다(④·⑤).
4. 두 달 전 학습한 모델의 결과를 재현하려고 그때의 학습 데이터가 필요합니다. 알맞은 것은?
   ① 원본 CSV를 다시 내려받는다
   ② VERSION AS OF나 TIMESTAMP AS OF로 그때의 Delta 버전을 읽는다
   ③ 테이블을 다시 만든다
   ④ 계보 화면에서 데이터를 내려받는다

   ②. Delta의 시간 여행입니다. DESCRIBE HISTORY로 어느 버전인지 먼저 확인합니다.
5. DLT 파이프라인에서 amount > 0을 어기는 행을 버리고 나머지는 계속 처리하려 합니다. 알맞은 것은?
   ① @dlt.expect
   ② @dlt.expect_or_drop
   ③ @dlt.expect_or_fail
   ④ 기대치로는 할 수 없고 filter를 써야 한다

   ②. expect는 기록만 하고 통과시키며 expect_or_fail은 파이프라인을 세웁니다.
6. 피처 테이블을 Unity Catalog에 두었을 때 얻는 것으로 가장 거리가 먼 것은?
   ① 다른 워크스페이스의 팀도 같은 이름으로 찾아 쓴다
   ② 어느 모델이 그 피처를 썼는지 계보로 남는다
   ③ 테이블과 같은 문법으로 권한을 건다
   ④ 저지연 온라인 조회가 저절로 된다

   ④. 실시간 저지연 조회는 온라인 테이블이 맡는 별도의 자리입니다. 나머지 셋은 계정 수준에 두어서 따라오는 이점입니다.
7. 팀 A가 만든 피처 테이블을 팀 B가 다른 워크스페이스에서 찾지 못합니다. 먼저 확인할 것은?
   ① 그 테이블이 hive_metastore에 있는지
   ② 클러스터 런타임 버전
   ③ 테이블 행 수
   ④ 노트북이 Git 폴더에 있는지

   ①. 워크스페이스 수준 메타스토어의 자산은 그 워크스페이스 밖에서 보이지 않습니다.
8. DROP TABLE로 지웠는데 스토리지에 파일이 그대로 남아 있습니다. 그 테이블은?
   ① 관리형 테이블
   ② 외부 테이블
   ③ 뷰
   ④ DLT 파이프라인이 만든 테이블

   ②. 외부 테이블은 이미 있는 경로를 가리키기만 하므로 정의만 사라지고 데이터 파일은 남습니다.

한 줄로 줄이면 이름이 세 마디면 계정 수준이고, 두 마디면 그 워크스페이스 안에서만 사는 옛 자산입니다. 이 시험의 거버넌스 문항 대부분은 이 구분을 다른 상황으로 옮겨 놓은 것입니다.