Data Eng Wiki

Direct Lake is Magic Until It Isnt

6 min read

Direct Lake is Magic, Until It Isn’t: How We Handled 1.5 Billion Rows Without Crashing Power BI

Author: Praveenkrishnan | Source: Medium | Published: 2026-07-04

한 줄 요약

Direct Lake는 프레임을 메모리에 못 올리면 에러를 던지지 않고 조용히 DirectQuery로 fallback하기 때문에, 리포트는 계속 동작하면서 성능만 무너지고 원인을 며칠 동안 못 찾게 된다.

핵심 주장/내용

  • fallback trap이 설계에서 가장 위험한 부분 — 리포트를 망가뜨려서가 아니라 망가뜨리지 않아서다. Direct Lake는 Delta 테이블을 상상하는 방식으로 직접 쿼리하지 않고 특정 버전의 스냅샷인 frame을 Power BI 엔진 메모리로 읽는다. 프레임을 못 올리면(테이블이 너무 큼, row group 크기가 잘못됨, 컬럼 수 대비 capacity SKU 메모리 부족) 아무 경고 없이 DirectQuery로 떨어진다
  • 스테이징에서 작은 데이터셋으로 테스트하면 다 빠르고, 프로덕션에 15억 row를 올리는 순간 모든 시각적 요소 상호작용마다 라이브 SQL이 돌게 된다. 리포트는 “기술적으로 동작”하므로 이유를 모른다
  • 원인 1 — row group 사이징: Spark 처리에 최적화된 Delta 테이블은 row group이 크다(그룹당 100만 row 이상). Direct Lake의 기대는 Spark 스캔 처리량이 아니라 columnar in-memory 접근에 맞춘 크기. OPTIMIZE가 PySpark 잡에는 맞고 Direct Lake framing에는 틀린 결과를 만들고 있었다
  • 원인 2 — 컬럼 수와 cardinality: Direct Lake는 테이블을 로드할 때 전체 컬럼 세트를 프레임한다. 15억 row에 47컬럼은 큰 메모리이고, 그중 상품 설명·자유 텍스트 노트 같은 high-cardinality 문자열 필드가 프레임을 더 부풀렸다
  • 원인 3 — capacity SKU: 스테이징 F32 → 프로덕션 F64로 올렸는데 fallback이 고쳐지지 않았다. fallback이 발동하는 임계값만 바뀌었을 뿐. 편의상 잡은 부분집합을 공유 dev capacity에서 테스트하지 말고 프로덕션 데이터 볼륨을 프로덕션 SKU에서 테스트할 것
  • 수정 4단계 (순서가 중요):
    1. row group 크기 축소 — spark.databricks.delta.optimize.maxFileSize를 128MB로 설정하고 목표 파일 크기를 의도적으로 관리
    2. 시맨틱 모델 컬럼 정리 — 모든 컬럼에 비즈니스 정당화를 요구. 기술적 수정이 아니라 리포트가 실제로 뭘 필요로 하는지에 대한 이해관계자와의 대화이고, 그래서 더 어렵고 더 중요
    3. 의도적 파티셔닝 — Direct Lake는 파티션 필터가 걸린 테이블을 쿼리할 때 파티션 단위로 프레임한다. 리포트에서 가장 흔한 필터 패턴(월별 sale date)에 맞춰 파티셔닝 재구성
    4. Direct Lake 모드인지 DirectQuery fallback인지 검증 — 1일차부터 있었어야 할 체크
  • fallback 탐지를 릴리스 게이트로: 뭔가 느리게 느껴질 때 확인하는 게 아니라 배포마다 통과해야 하는 테스트로 취급하라. Delta 테이블 업데이트마다 프레임 크기가 capacity 한도 안인지 확인하고, Power BI 배포마다 모니터링 로그에서 쿼리 모드를 확인
  • 15억 row를 다루는 엔지니어링 자체는 문제를 이해하고 나면 특별히 복잡하지 않았다 — row group 사이징, 컬럼 규율, 파티션 전략이라는 대규모 분석 테이블의 기본기. 어려운 건 “연결 문자열의 Direct Lake가 실제로 Direct Lake에 있다는 뜻이 아니다”를 배우는 것이었고 그게 3일을 먹었다

주요 수치 / 사실

  • 6주에 걸쳐 15억 row 판매 이력을 Fabric Lakehouse로 이관
  • row group이 일관되게 300~400만 row로 떨어지고 있었고, 목표는 약 100만 row + 통제된 파일 크기
  • 컬럼 47개 → 시맨틱 모델에서 31개로 감축 (파이프라인 추적 목적으로만 있던 6개 제거)
  • 파티셔닝 후 현재 월 필터 리포트는 15억이 아니라 약 1.2억 row 파티션만 프레임
  • 임원 데모 3일 전에 발견, 최초 증상은 시각적 요소가 40초간 스피너

관련 위키

Source: 원문 보기

그래프 뷰

백링크