Skip to main content
이 문서는 머신러닝 섹션의 일부입니다.

Lakehouse Monitoring이란?

💡 Lakehouse Monitoring 은 Databricks의 데이터 품질 및 모델 성능 모니터링 서비스 입니다. Delta 테이블에 모니터를 연결하면, 데이터의 통계 프로필, 분포 변화(드리프트), 이상치 등을 자동으로 추적하고 대시보드로 시각화합니다.

왜 모니터링이 필요한가요?

데이터 파이프라인과 ML 모델은 배포 후에도 지속적으로 품질이 변할 수 있습니다. 다음과 같은 문제를 사전에 감지하지 못하면 비즈니스에 큰 영향을 미칩니다.
💡 비유: Lakehouse Monitoring은 데이터 파이프라인의 “건강 검진”입니다. 정기적으로 데이터의 건강 상태를 검사하여, 문제가 심각해지기 전에 미리 발견합니다.

모니터 유형

Lakehouse Monitoring은 세 가지 유형의 모니터를 지원합니다.

모니터 생성

Python API로 모니터 생성

SQL로 모니터 생성

InferenceLog 모니터 (ML 모델용)


프로필 메트릭

모니터가 실행되면 프로필 메트릭 테이블드리프트 메트릭 테이블 두 개가 자동 생성됩니다.

프로필 메트릭 테이블

각 윈도우(시간 단위)별로 다음 통계를 자동으로 계산합니다.

드리프트 메트릭 테이블

현재 윈도우와 기준선(Baseline) 또는 이전 윈도우 를 비교하여 변화를 수치화합니다.

커스텀 메트릭 정의

기본 메트릭 외에 비즈니스 로직에 맞는 커스텀 메트릭 을 정의할 수 있습니다.

기준선 (Baseline) 설정

드리프트를 감지하려면 “정상 상태”의 기준 이 필요합니다. 별도의 기준선 테이블을 지정할 수 있습니다.

대시보드 자동 생성

모니터를 생성하면 assets_dirLakeview 대시보드가 자동으로 생성 됩니다. 이 대시보드에는 다음 정보가 포함됩니다.

알림 설정

모니터링 메트릭을 기반으로 Databricks SQL Alert 를 설정하여 이상 징후를 자동으로 알릴 수 있습니다.
알림 설정 방법:
  1. 위 쿼리를 SQL Editor 에서 저장합니다
  2. Alerts 메뉴에서 해당 쿼리를 기반으로 알림을 생성합니다
  3. 결과가 비어 있지 않으면 이메일 또는 Slack으로 알림 을 발송합니다

ML 모델 모니터링 워크플로

ML 모델 배포 후 성능 변화를 추적하는 전체 워크플로는 다음과 같습니다.

모범 사례


현업 사례: 모델 성능이 서서히 저하되는데 아무도 모르고 3개월 지난 사례

모니터링이 왜 필수인지를 가장 잘 보여주는 현업 사례입니다. “배포하면 끝”이라는 생각이 얼마나 위험한지 공유합니다.

사례: 이커머스 추천 모델의 조용한 죽음

모니터링이 있었다면

드리프트 감지의 현실적 한계

Lakehouse Monitoring의 드리프트 감지는 강력하지만, 현업에서 알아야 할 한계가 있습니다.
⚠️ 현업에서는 이렇게 합니다: 드리프트 감지 알림이 발생했다고 즉시 모델을 재학습하지 않습니다. “알림 → 영향도 분석 → 비즈니스 메트릭 확인 → 재학습 결정” 프로세스를 따릅니다. 드리프트가 감지되었는데 비즈니스 메트릭(매출, 전환율)에 영향이 없으면, 모니터링만 강화하고 재학습은 보류합니다.

모니터링 대시보드 실전 구성 패턴

자동 생성 대시보드만으로는 부족한 경우가 많습니다. 현업에서 구성하는 효과적인 모니터링 대시보드 패턴을 공유합니다.

3-Layer 모니터링 구조

알림 설정 실전 패턴

💡 현업 팁: 알림의 핵심은 “Action을 취할 수 있는 알림” 만 보내는 것입니다. “피처 X의 분포가 바뀌었습니다”만으로는 부족합니다. “피처 X의 분포가 바뀌었고, 이로 인해 예측 정확도가 Y% 하락했습니다. 재학습을 검토하세요.”까지 포함해야 담당자가 행동할 수 있습니다.

모니터링 비용 관리

⚠️ 이것을 안 하면: 모든 테이블에 매시간 모니터를 걸면, 메트릭 테이블이 급격히 커지고 비용이 예상 외로 증가합니다. 프로덕션에 직접 영향을 주는 테이블만 고빈도로 모니터링하고, 나머지는 일간 또는 주간으로 설정하세요.

정리


참고 링크