Materialized Lake Views: SQL로 선언하는 Silver·Gold 변환

원문: What are materialized lake views in Microsoft Fabric? 함께 본 문서: Optimal refresh · Data quality · Microsoft Learn

Lakehouse에서 Bronze → Silver → Gold로 이어지는 메달리온 아키텍처¹를 손으로 짜 본 적 있다면 이 패턴이 익숙할 거예요. 단계마다 Notebook을 하나씩 만들고, 순서대로 돌게 스케줄을 걸고, 데이터 검증 코드를 따로 넣고, 어디서 실패했는지 하나씩 뒤져 보죠.

**Materialized Lake Views(MLV)**는 이 단계들을 SQL 문으로 선언하고, 실행 순서·새로 고침·품질 검사를 Fabric에 맡기는 기능이에요.

선언하면 Fabric이 나머지를 해요

MLV는 CREATE MATERIALIZED LAKE VIEW 구문으로 정의해요. “무엇을 원하는지”만 SQL로 적으면, 결과는 Lakehouse 안의 Delta 테이블로 저장돼요. 이후로는 일반 테이블처럼 Spark, SQL analytics endpoint, Power BI에서 같은 권한 체계로 조회하면 돼요.

CREATE MATERIALIZED LAKE VIEW silver.orders_clean (
  CONSTRAINT valid_sales CHECK (sales_amount > 0) ON MISMATCH DROP
) AS
SELECT order_id, customer_id, sales_amount, order_date
FROM bronze.orders
WHERE order_id IS NOT NULL;

수명 주기는 네 단계예요.

만들기 — SQL로 변환을 정의하면 Fabric이 결과를 Delta 테이블로 만들어요.
새로 고침 — 원본이 바뀌면 Fabric이 가장 알맞은 방식을 골라요.
조회 — 리포트와 앱은 변환 로직을 몰라도 테이블처럼 읽어요.
모니터링 — 새로 고침 기록, 실행 상태, 품질 지표, 계보를 기본 화면에서 봐요.

새로 고침은 세 가지 중에서 골라요

Fabric의 결정 엔진이 원본 Delta 테이블의 변경을 보고 매번 방식을 정해요. 이걸 **최적 새로 고침(optimal refresh)**이라고 불러요.

방식	언제
증분(incremental)	새로 들어오거나 바뀐 데이터만 처리
전체(full)	처음부터 다시 만들어야 할 때
건너뛰기(skip)	원본에 변화가 없을 때 — 계산을 아예 안 해요

여기서 놓치기 쉬운 조건이 있어요. 증분 새로 고침을 쓰려면 원본 테이블에 Change Data Feed²를 켜야 해요. 안 켜면 엔진은 건너뛰기와 전체 중에서만 골라요.

ALTER TABLE bronze.orders SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

쿼리 모양도 영향을 줘요. INNER JOIN, UNION ALL, CTE, 그리고 SUM·COUNT·MIN·MAX 집계는 증분이 돼요. 반면 윈도 함수, DISTINCT, current_timestamp() 같은 비결정 함수가 들어가면 만들 수는 있지만 전체 새로 고침으로 돌아가요. LEFT JOIN은 오른쪽 테이블이 그 사이 안 바뀌었을 때만 증분이에요.

종속성은 알아서 이어 줘요

MLV가 다른 MLV나 테이블을 참조하면 Fabric이 관계를 자동으로 찾아 실행 순서를 정해요. Bronze가 갱신되면 Silver 뷰가 먼저, 그다음 Gold 뷰가 도는 식이에요. 이 계보는 Lakehouse 간에도 그림으로 볼 수 있어요.

데이터 품질 규칙을 선언에 넣어요

위 예시의 CONSTRAINT ... CHECK가 품질 규칙이에요. 규칙을 어긴 행을 어떻게 할지 두 가지 중에 골라요.

FAIL — 첫 위반에서 새로 고침을 멈춰요. 아무것도 안 적으면 이게 기본값이에요.
DROP — 위반 행만 빼고 계속해요. 빠진 행 수는 계보 화면에 표시돼요.

둘을 같이 걸면 FAIL이 우선해요. 규칙에는 TRIM(), COALESCE() 같은 기본 제공 함수를 쓰는 게 가장 안전해요.

언제 쓰고, 언제 Notebook을 계속 쓸까

Learn 문서가 꼽는 잘 맞는 경우예요.

일별 매출 합계처럼 자주 조회하는 집계
여러 큰 테이블을 자주 조인하고 모두가 같은 결과를 봐야 할 때
품질 규칙을 코드 대신 선언으로 일관되게 적용하고 싶을 때
Bronze → Silver → Gold를 SQL로 정의하는 메달리온 구조

반대로 이런 경우엔 다른 걸 쓰라고 해요.

한 번 쓰고 마는 쿼리 — 미리 계산해 둘 이유가 없어요.
ML 추론, API 호출, 복잡한 Python 처리 — Notebook이 맞아요.
1초 미만 갱신이 필요한 스트리밍 — Real-Time Intelligence를 보세요.

Python으로 정의하고 싶다면 **PySpark 작성(프리뷰)**도 있어요. 다만 PySpark MLV는 지금은 증분 새로 고침이 안 되고(전체 또는 건너뛰기만), 계보 스케줄로만 새로 고칠 수 있어요.

정리

SQL 한 문장으로 변환을 선언하면 결과는 Delta 테이블로 남고, 어디서든 테이블처럼 읽어요.
증분 새로 고침은 CDF가 켜져 있어야 해요. 윈도 함수·DISTINCT가 있으면 전체로 돌아가요.
품질 규칙 기본값은 FAIL이에요. 행만 걸러 내려면 ON MISMATCH DROP을 적어요.
SQL로 안 되는 일은 여전히 Notebook이 맡아요.

어휘 주석

메달리온 아키텍처(medallion architecture): 원본 데이터를 Bronze(원본 그대로) → Silver(정제) → Gold(비즈니스용 집계) 세 단계로 점진적으로 가공하는 Lakehouse 설계 패턴.
Change Data Feed(CDF): Delta 테이블에서 어떤 행이 추가·수정·삭제됐는지 변경 이력만 따로 읽어 올 수 있게 해 주는 기능. 테이블 전체를 다시 읽지 않고 변경분만 처리할 때 써요.