Azure Databricks의 MLOps 워크플로

  • 아티클

이 문서에서는 Databricks 플랫폼에서 MLOps를 사용하여 ML(기계 학습) 시스템의 성능 및 장기 효율성을 최적화하는 방법을 설명합니다. 여기에는 MLOps 아키텍처에 대한 일반적인 권장 사항이 포함되어 있으며 ML 개발-프로덕션 프로세스의 모델로 사용할 수 있는 Databricks 플랫폼을 사용하여 일반화된 워크플로를 설명합니다.

자세한 내용은 MLOps의 큰 책을 참조 하세요.

MLOps란?

MLOps는 코드, 데이터 및 모델을 관리하는 일단의 프로세스 및 자동화된 단계입니다. DevOps, DataOps 및 ModelOps를 결합합니다.

MLOps 레이크하우스

코드, 데이터, 모델과 같은 ML 자산은 엄격한 액세스 제한이 없고 엄격하게 테스트되지 않은 초기 개발 단계에서 중간 테스트 단계를 거쳐 엄격하게 제어되는 최종 프로덕션 단계로 진행되는 단계에서 개발됩니다. Databricks 플랫폼을 사용하면 통합 액세스 제어를 사용하여 단일 플랫폼에서 이러한 자산을 관리할 수 있습니다. 동일한 플랫폼에서 데이터 애플리케이션과 ML 애플리케이션을 개발하여 데이터 이동과 관련된 위험과 지연을 줄일 수 있습니다.

MLOps에 대한 일반 권장 사항

이 섹션에는 자세한 정보에 대한 링크와 함께 Databricks의 MLOps에 대한 몇 가지 일반적인 권장 사항이 포함되어 있습니다.

각 단계에 대한 별도의 환경 만들기

실행 환경은 코드에 의해 모델과 데이터가 만들어지거나 사용되는 장소입니다. 각 실행 환경은 컴퓨팅 인스턴스, 해당 런타임 및 라이브러리, 자동화된 작업으로 구성됩니다.

Databricks는 ML 코드 및 모델 개발의 여러 단계에 대해 단계 간에 명확하게 정의된 전환을 사용하여 별도의 환경을 만들도록 권장하고 있습니다. 이 문서에서 설명하는 워크플로는 일반 이름을 사용하여 이 프로세스를 따릅니다.

조직의 특정 요구 사항을 충족하기 위해 다른 구성을 사용할 수도 있습니다.

액세스 제어 및 버전 관리

액세스 제어 및 버전 관리는 모든 소프트웨어 운영 프로세스의 주요 구성 요소입니다. Databricks에서 권장하는 사항은 다음과 같습니다.

  • Git을 버전 제어에 사용합니다. 파이프라인과 코드는 버전 제어를 위해 Git에 저장해야 합니다. 그러면 ML 논리의 단계 간 이동이 코드를 개발 분기에서 준비 분기로, 릴리스 분기로 이동하는 것으로 해석될 수 있습니다. Databricks Git 폴더를 사용하여 Git 공급자와 통합하고 Notebook 및 소스 코드를 Databricks 작업 영역과 동기화합니다. Databricks는 Git 통합 및 버전 제어를 위한 추가 도구도 제공합니다. 개발자 도구 및 지침을 참조하세요.
  • Delta 테이블을 사용하여 레이크하우스 아키텍처에 데이터를 저장합니다. 데이터는 클라우드 계정의 Lakehouse 아키텍처 에 저장되어야 합니다. 원시 데이터와 기능 테이블은 모두 액세스 제어를 통해 Delta 테이블로 저장하여 읽고 수정할 수 있는 사용자를 결정해야 합니다.
  • MLflow를 사용하여 모델 개발을 관리합니다. MLflow를 사용하여 모델 개발 프로세스를 추적하고, 코드 스냅샷, 모델 매개 변수, 메트릭 및 기타 메타데이터를 저장할 수 있습니다.
  • Unity 카탈로그의 모델을 사용하여 모델 수명 주기를 관리합니다. Unity 카탈로그의 모델을 사용하여 모델 버전 관리, 거버넌스 및 배포 상태 관리합니다.

모델이 아닌 코드 배포

대부분의 경우 Databricks는 ML 개발 프로세스 중에 모델이 아닌 코드를 한 환경에서 다음 환경으로 승격하도록 권장합니다. 이러한 방식으로 프로젝트 자산을 이동하면 ML 개발 프로세스의 모든 코드가 동일한 코드 검토 및 통합 테스트 프로세스를 거치게 됩니다. 또한 모델의 프로덕션 버전이 프로덕션 코드에서 학습되도록 합니다. 옵션 및 장단점에 대한 자세한 내용은 모델 배포 패턴을 참조하세요.

다음 섹션에서는 개발, 준비 및 프로덕션의 세 단계를 각각 다루는 일반적인 MLOps 워크플로에 대해 설명합니다.

이 섹션에서는 "데이터 과학자" 및 "ML 엔지니어"라는 용어를 전형적인 가상 사용자로 사용합니다. MLOps 워크플로의 특정 역할과 책임은 팀과 조직에 따라 다릅니다.

개발 단계

개발 단계의 초점은 실험입니다. 데이터 과학자는 기능과 모델을 개발하고, 실험을 실행하여 모델 성능을 최적화합니다. 개발 프로세스의 출력은 기능 계산, 모델 학습, 유추 및 모니터링을 포함할 수 있는 ML 파이프라인 코드입니다.

MLOps 개발 단계 다이어그램

번호가 매겨진 단계는 다이어그램에 표시된 숫자에 해당합니다.

1. 데이터 원본

개발 환경은 Unity 카탈로그의 개발 카탈로그로 표시됩니다. 데이터 과학자는 개발 작업 영역에서 임시 데이터 및 기능 테이블을 만들 때 개발 카탈로그에 대한 읽기-쓰기 액세스 권한을 가집니다. 개발 단계에서 만든 모델은 개발 카탈로그에 등록됩니다.

이상적으로 개발 작업 영역에서 작업하는 데이터 과학자는 prod 카탈로그의 프로덕션 데이터에 대한 읽기 전용 액세스 권한을 갖습니다. 데이터 과학자가 프로덕션 데이터, 유추 테이블 및 prod 카탈로그의 메트릭 테이블에 대한 읽기 액세스를 허용하면 현재 프로덕션 모델 예측 및 성능을 분석할 수 있습니다. 또한 데이터 과학자는 실험 및 분석을 위해 프로덕션 모델을 로드할 수 있어야 합니다.

prod 카탈로그에 대한 읽기 전용 액세스 권한을 부여할 수 없는 경우 프로덕션 데이터의 스냅샷 개발 카탈로그에 기록하여 데이터 과학자가 프로젝트 코드를 개발하고 평가할 수 있도록 할 수 있습니다.

2. EDA(예비 데이터 분석)

데이터 과학자는 Notebook을 사용하여 대화형 반복 프로세스에서 데이터를 탐색하고 분석합니다. 목표는 사용 가능한 데이터가 비즈니스 문제를 해결할 가능성이 있는지 여부를 평가하는 것입니다. 이 단계에서는 데이터 과학자가 모델 학습을 위한 데이터 준비 및 기능화 단계를 식별하기 시작합니다. 이 임시 프로세스는 일반적으로 다른 실행 환경에 배포될 파이프라인의 일부가 아닙니다.

Databricks AutoML 은 데이터 세트에 대한 기준 모델을 생성하여 이 프로세스를 가속화합니다. AutoML은 일련의 평가판을 수행하고 기록하며, 각 평가판 실행에 대한 소스 코드를 Python Notebook에 제공하므로 코드를 검토, 재현 및 수정할 수 있습니다. 또한 AutoML은 데이터 세트에 대한 요약 통계를 계산하고 이 정보를 검토할 수 있는 Notebook에 저장합니다.

3. 코드

코드 리포지토리에는 ML 프로젝트에 대한 모든 파이프라인, 모듈 및 기타 프로젝트 파일이 포함됩니다. 데이터 과학자는 프로젝트 리포지토리의 개발("개발") 분기에 새 파이프라인 또는 업데이트된 파이프라인을 만듭니다. EDA 및 프로젝트의 초기 단계부터 데이터 과학자는 리포지토리에서 작업하여 코드를 공유하고 변경 내용을 추적해야 합니다.

4. 모델 학습(개발)

데이터 과학자는 개발 또는 prod 카탈로그의 테이블을 사용하여 개발 환경에서 모델 학습 파이프라인을 개발합니다.

이 파이프라인에는 다음 두 가지 작업이 포함됩니다.

  • 학습 및 튜닝. 학습 프로세스는 MLflow 추적 서버에 모델 매개 변수, 메트릭 및 아티팩트 로그를 기록합니다. 하이퍼 매개 변수를 학습하고 튜닝한 후 최종 모델 아티팩트가 추적 서버에 기록되어 모델, 학습된 입력 데이터 및 이를 생성하는 데 사용되는 코드 간의 링크를 기록합니다.

  • 평가. 보류된 데이터를 테스트하여 모델 품질을 평가합니다. 이러한 테스트의 결과는 MLflow 추적 서버에 기록됩니다. 평가의 목적은 새로 개발된 모델이 현재 프로덕션 모델보다 더 나은 성능을 발휘하는지 확인하는 것입니다. 충분한 권한이 있으면 prod 카탈로그에 등록된 모든 프로덕션 모델을 개발 작업 영역에 로드하고 새로 학습된 모델과 비교할 수 있습니다.

    모델에 대한 추가 정보가 조직의 거버넌스 요구 사항에 포함되는 경우 MLflow 추적을 사용하여 저장할 수 있습니다. 일반적인 아티팩트에서는 일반 텍스트 설명과 SHAP에서 생성된 플롯과 같은 모델 해석이 있습니다. 특정 거버넌스 요구 사항은 데이터 거버넌스 책임자 또는 비즈니스 이해 관계자로부터 올 수 있습니다.

모델 학습 파이프라인의 출력은 개발 환경의 MLflow 추적 서버에 저장된 ML 모델 아티팩트입니다. 파이프라인이 스테이징 또는 프로덕션 작업 영역에서 실행되는 경우 모델 아티팩트가 해당 작업 영역에 대한 MLflow 추적 서버에 저장됩니다.

모델 학습이 완료되면 Unity 카탈로그에 모델을 등록합니다. 모델 파이프라인이 실행된 환경에 해당하는 카탈로그에 모델을 등록하도록 파이프라인 코드를 설정합니다. 이 예제에서는 개발 카탈로그입니다.

권장 아키텍처를 사용하면 첫 번째 작업이 모델 학습 파이프라인인 멀티태스크 Databricks 워크플로와 모델 유효성 검사 및 모델 배포 작업을 배포합니다. 모델 학습 작업은 모델 유효성 검사 태스크에서 사용할 수 있는 모델 URI를 생성합니다. 작업 값을 사용하여 이 URI를 모델에 전달할 수 있습니다.

5. 모델 유효성 검사 및 배포(개발)

모델 학습 파이프라인 외에도 모델 유효성 검사 및 모델 배포 파이프라인과 같은 다른 파이프라인이 개발 환경에서 개발됩니다.

  • 모델 유효성 검사. 모델 유효성 검사 파이프라인은 모델 학습 파이프라인에서 모델 URI를 가져와 Unity 카탈로그에서 모델을 로드하고 유효성 검사 검사 실행합니다.

    유효성 검사 검사 컨텍스트에 따라 달라집니다. 여기에는 형식 및 필수 메타데이터 확인과 같은 기본 검사 포함할 수 있으며, 미리 정의된 규정 준수 검사 및 선택한 데이터 조각에서 모델 성능 확인과 같이 고도로 규제되는 산업에 필요할 수 있는 보다 복잡한 검사 포함할 수 있습니다.

    모델 유효성 검사 파이프라인의 기본 함수는 모델이 배포 단계로 진행되어야 하는지 여부를 결정하는 것입니다. 모델이 배포 전 검사 전달하는 경우 Unity 카탈로그에서 "챌린저" 별칭을 할당할 수 있습니다. 검사 실패하면 프로세스가 종료됩니다. 사용자에게 유효성 검사 실패를 알리도록 워크플로를 구성할 수 있습니다. 작업 이벤트에 대한 이메일 및 시스템 알림 추가를 참조하세요.

  • 모델 배포. 모델 배포 파이프라인은 일반적으로 별칭 업데이트를 사용하여 새로 학습된 "챌린저" 모델을 "챔피언" 상태 직접 승격하거나 기존 "챔피언" 모델과 새로운 "챌린저" 모델 간의 비교를 용이하게 합니다. 이 파이프라인은 모델 서비스 엔드포인트와 같은 필요한 유추 인프라를 설정할 수도 있습니다. 모델 배포 파이프라인과 관련된 단계에 대한 자세한 내용은 프로덕션을 참조하세요.

6. 코드 커밋

학습, 유효성 검사, 배포 및 기타 파이프라인에 대한 코드를 개발한 후 데이터 과학자 또는 ML 엔지니어는 개발 분기 변경 내용을 소스 제어로 커밋합니다.

준비 단계

이 단계의 초점은 ML 파이프라인 코드를 테스트하여 프로덕션 준비가 되었는지 확인하는 것입니다. 모델 학습에 대한 코드 및 기능 엔지니어링 파이프라인, 유추 코드 등을 포함하여 모든 ML 파이프라인 코드가 이 단계에서 테스트됩니다.

ML 엔지니어는 이 단계에서 실행되는 단위 및 통합 테스트를 구현하는 CI 파이프라인을 만듭니다. 준비 프로세스의 출력은 프로덕션 단계를 시작하도록 CI/CD 시스템을 트리거하는 릴리스 분기입니다.

MLOps 준비 단계 다이어그램

1. 데이터

스테이징 환경에는 ML 파이프라인을 테스트하고 Unity 카탈로그에 모델을 등록하기 위한 자체 카탈로그가 Unity 카탈로그에 있어야 합니다. 이 카탈로그는 다이어그램에서 "스테이징" 카탈로그로 표시됩니다. 이 카탈로그에 기록된 자산은 일반적으로 일시적이고 테스트가 완료될 때까지만 보존됩니다. 또한 개발 환경에서는 디버깅을 위해 스테이징 카탈로그에 액세스해야 할 수도 있습니다.

2. 코드 병합

데이터 과학자는 개발 또는 프로덕션 카탈로그의 테이블을 사용하여 개발 환경에서 모델 학습 파이프라인을 개발합니다.

  • 끌어오기 요청 배포 프로세스는 소스 제어에서 프로젝트의 기본 분기에 대해 끌어오기 요청을 만들 때 시작됩니다.

  • CI(단위 테스트). 끌어오기 요청은 소스 코드를 자동으로 빌드하고 단위 테스트를 트리거합니다. 단위 테스트가 실패하면 끌어오기 요청이 거부됩니다.

    단위 테스트는 소프트웨어 개발 프로세스의 일부이며 코드를 개발하는 동안 지속적으로 실행되고 코드베이스에 추가됩니다. CI 파이프라인의 일부로 단위 테스트를 실행하면 개발 분기의 변경 내용이 기존 기능을 중단하지 않습니다.

3. 통합(CI) 테스트

다음으로, CI 프로세스에서 통합 테스트를 실행합니다. 통합 테스트는 모든 파이프라인(기능 엔지니어링, 모델 학습, 유추 및 모니터링 포함)을 실행하여 모두 올바르게 작동하는지 확인합니다. 준비 환경은 프로덕션 환경과 적절하게 일치해야 합니다.

실시간 유추를 사용하여 ML 애플리케이션을 배포하는 경우 스테이징 환경에서 서비스 인프라를 만들고 테스트해야 합니다. 여기에는 스테이징 환경에서 서비스 엔드포인트를 만들고 모델을 로드하는 모델 배포 파이프라인을 트리거하는 작업이 포함됩니다.

통합 테스트를 실행하는 데 필요한 시간을 줄이기 위해 일부 단계는 테스트의 충실도와 속도 또는 비용 사이에서 절충할 수 있습니다. 예를 들어 모델이 학습하는 데 비용이 많이 들거나 시간이 많이 걸리는 경우 작은 데이터 하위 집합을 사용하거나 더 적은 학습 반복을 실행할 수 있습니다. 모델 제공의 경우 프로덕션 요구 사항에 따라 통합 테스트에서 본격적인 부하 테스트를 수행하거나 작은 일괄 처리 작업 또는 임시 엔드포인트에 대한 요청을 테스트할 수 있습니다.

4. 준비 분기에 병합

모든 테스트가 통과하면 새 코드가 프로젝트의 기본 분기에 병합됩니다. 테스트가 실패하면 CI/CD 시스템은 사용자에게 알리고 끌어오기 요청에 결과를 게시해야 합니다.

기본 분기에서 정기적인 통합 테스트를 예약할 수 있습니다. 이는 분기가 여러 사용자의 동시 끌어오기 요청으로 자주 업데이트되는 경우 좋은 방법입니다.

5. 릴리스 분기 만들기

CI 테스트가 통과되고 개발 분기가 기본 분기에 병합된 후 ML 엔지니어는 릴리스 분기를 만들어 프로덕션 작업을 업데이트하도록 CI/CD 시스템을 트리거합니다.

프로덕션 단계

ML 엔지니어는 ML 파이프라인이 배포되고 실행되는 프로덕션 환경을 소유합니다. 이러한 파이프라인은 모델 학습을 트리거하고, 새 모델 버전의 유효성을 검사 및 배포하고, 다운스트림 테이블 또는 애플리케이션에 예측을 게시하고, 전체 프로세스를 모니터링하여 성능 저하 및 불안정을 방지합니다.

데이터 과학자는 일반적으로 프로덕션 환경에서의 쓰기 또는 컴퓨팅 액세스 권한을 가지고 있지 않습니다. 그러나 테스트 결과, 로그, 모델 아티팩트, 프로덕션 파이프라인 상태 및 모니터링 테이블에 대한 가시성이 있어야 합니다. 이러한 가시성을 통해 프로덕션의 문제를 식별하고 진단하고 새 모델의 성능을 현재 프로덕션 중인 모델과 비교할 수 있습니다. 이러한 목적을 위해 데이터 과학자에게 프로덕션 카탈로그의 자산에 대한 읽기 전용 액세스 권한을 부여할 수 있습니다.

MLOps 프로덕션 단계 다이어그램

번호가 매겨진 단계는 다이어그램에 표시된 숫자에 해당합니다.

1. 모델 학습

이 파이프라인은 코드 변경 또는 자동화된 재학습 작업에서 트리거될 수 있습니다. 이 단계에서는 프로덕션 카탈로그의 테이블이 다음 단계에 사용됩니다.

  • 학습 및 튜닝. 학습 프로세스 중에 로그는 프로덕션 환경 MLflow 추적 서버에 기록됩니다. 이러한 로그에는 모델 메트릭, 매개 변수, 태그 및 모델 자체가 포함됩니다. 기능 테이블을 사용하는 경우 모델은 유추 시간에 사용되는 기능 조회 정보로 모델을 패키지하는 Databricks 기능 저장소 클라이언트를 사용하여 MLflow에 기록됩니다.

    개발하는 동안 데이터 과학자는 많은 알고리즘과 하이퍼 매개 변수를 테스트할 수 있습니다. 프로덕션 학습 코드에서는 성능이 가장 좋은 옵션만 고려하는 것이 일반적입니다. 튜닝을 이러한 방식으로 제한하면 시간이 절약되고 자동화된 재학습에서 튜닝의 편차를 줄일 수 있습니다.

    데이터 과학자가 프로덕션 카탈로그에 대한 읽기 전용 액세스 권한이 있는 경우 모델에 대한 최적의 하이퍼 매개 변수 집합을 결정할 수 있습니다. 이 경우 프로덕션에 배포된 모델 학습 파이프라인은 일반적으로 파이프라인에 구성 파일로 포함된 선택한 하이퍼 매개 변수 집합을 사용하여 실행할 수 있습니다.

  • 평가. 모델 품질은 보류된 프로덕션 데이터를 테스트하여 평가됩니다. 이러한 테스트의 결과는 MLflow 추적 서버에 로그됩니다. 이 단계에서는 데이터 과학자가 개발 단계에서 지정한 평가 메트릭을 사용합니다. 이러한 메트릭에는 사용자 지정 코드가 포함될 수 있습니다.

  • 모델 등록. 모델 학습이 완료되면 모델 아티팩트가 Unity 카탈로그의 프로덕션 카탈로그에 있는 지정된 모델 경로에 등록된 모델 버전으로 저장됩니다. 모델 학습 작업은 모델 유효성 검사 태스크에서 사용할 수 있는 모델 URI를 생성합니다. 작업 값을 사용하여 이 URI를 모델에 전달할 수 있습니다.

2. 모델 유효성 검사

이 파이프라인은 1단계의 모델 URI를 사용하고 Unity 카탈로그에서 모델을 로드합니다. 그런 다음 일련의 유효성 검사 검사 실행합니다. 이러한 검사 조직 및 사용 사례에 따라 달라지며 기본 형식 및 메타데이터 유효성 검사, 선택한 데이터 조각에 대한 성능 평가, 태그 또는 설명서에 대한 규정 준수 검사 같은 조직 요구 사항 준수와 같은 항목을 포함할 수 있습니다.

모델이 모든 유효성 검사 검사 성공적으로 전달하는 경우 Unity 카탈로그의 모델 버전에 "챌린저" 별칭을 할당할 수 있습니다. 모델이 모든 유효성 검사 검사 전달하지 않으면 프로세스가 종료되고 사용자에게 자동으로 알림을 받을 수 있습니다. 태그를 사용하여 이러한 유효성 검사 검사 결과에 따라 키-값 특성을 추가할 수 있습니다. 예를 들어 "model_validation_상태" 태그를 만들고 테스트가 실행될 때 값을 "PENDING"으로 설정한 다음 파이프라인이 완료되면 "PASSED" 또는 "FAILED"로 업데이트할 수 있습니다.

모델이 Unity 카탈로그에 등록되기 때문에 개발 환경에서 작업하는 데이터 과학자는 프로덕션 카탈로그에서 이 모델 버전을 로드하여 모델의 유효성 검사에 실패하는지 조사할 수 있습니다. 결과에 관계없이 결과는 모델 버전에 대한 주석을 사용하여 프로덕션 카탈로그의 등록된 모델에 기록됩니다.

3. 모델 배포

유효성 검사 파이프라인과 마찬가지로 모델 배포 파이프라인은 조직 및 사용 사례에 따라 달라집니다. 이 섹션에서는 새로 유효성을 검사한 모델에 "챌린저" 별칭을 할당했으며 기존 프로덕션 모델에 "챔피언" 별칭이 할당되었다고 가정합니다. 새 모델을 배포하기 전의 첫 번째 단계는 현재 프로덕션 모델뿐만 아니라 적어도 수행을 확인하는 것입니다.

  • "CHALLENGER"를 "CHAMPION" 모델과 비교합니다. 오프라인 또는 온라인에서 이 비교를 수행할 수 있습니다. 오프라인 비교는 보류된 데이터 집합에 대해 두 모델을 모두 평가하고 MLflow 추적 서버를 사용하여 결과를 추적합니다. 실시간 모델 제공의 경우 A/B 테스트 또는 새 모델의 점진적 출시와 같이 더 오래 실행되는 온라인 비교를 수행할 수 있습니다. 비교에서 "챌린저" 모델 버전이 더 잘 수행되면 현재 "챔피언" 별칭을 대체합니다.

    Databricks 모델 서비스 및 Databricks Lakehouse 모니터링을 사용하면 엔드포인트에 대한 요청 및 응답 데이터가 포함된 유추 테이블을 자동으로 수집하고 모니터링할 수 있습니다.

    기존 "챔피언" 모델이 없는 경우 "챌린저" 모델을 비즈니스 추론 또는 다른 임계값과 기준선으로 비교할 수 있습니다.

    여기에 설명된 프로세스는 완전히 자동화됩니다. 수동 승인 단계가 필요한 경우 모델 배포 파이프라인에서 워크플로 알림 또는 CI/CD 콜백을 사용하여 설정할 수 있습니다.

  • 모델을 배포합니다. 일괄 처리 또는 스트리밍 유추 파이프라인은 "챔피언" 별칭과 함께 모델을 사용하도록 설정할 수 있습니다. 실시간 사용 사례의 경우 모델을 REST API 엔드포인트로 배포하도록 인프라를 설정해야 합니다. Databricks 모델 서비스를 사용하여 이 엔드포인트를 만들고 관리할 수 있습니다. 엔드포인트가 현재 모델에 이미 사용 중인 경우 엔드포인트를 새 모델로 업데이트할 수 있습니다. Databricks Model Serving는 새 구성이 준비될 때까지 기존 구성을 계속 실행하여 가동 중지 시간 업데이트를 실행합니다.

4. 모델 서비스

모델 서비스 엔드포인트를 구성할 때 Unity 카탈로그에서 모델의 이름과 제공할 버전을 지정합니다. 모델 버전이 Unity 카탈로그의 테이블 기능을 사용하여 학습된 경우 모델은 기능 및 함수에 대한 종속성을 저장합니다. Model Serving는 이 종속성 그래프 자동으로 사용하여 유추 시간에 적절한 온라인 스토어의 기능을 조회합니다. 또한 이 방법을 사용하여 데이터 전처리를 위한 함수를 적용하거나 모델 채점 중에 주문형 기능을 계산할 수 있습니다.

여러 모델을 사용하여 단일 엔드포인트를 만들고 해당 모델 간에 분할된 엔드포인트 트래픽을 지정하여 온라인 "챔피언" 및 "챌린저" 비교를 수행할 수 있습니다.

5. 추론: 일괄 처리 또는 스트리밍

유추 파이프라인은 프로덕션 카탈로그에서 최신 데이터를 읽고, 함수를 실행하여 주문형 기능을 계산하고, "챔피언" 모델을 로드하고, 데이터의 점수를 지정하고, 예측을 반환합니다. 일괄 처리 또는 스트리밍 유추는 일반적으로 처리량이 높고 대기 시간이 긴 사용 사례에 가장 비용 효율적인 옵션입니다. 대기 시간이 짧은 예측이 필요하지만 예측을 오프라인으로 계산할 수 있는 시나리오의 경우 이러한 일괄 처리 예측을 DynamoDB 또는 Cosmos DB와 같은 온라인 키-값 저장소에 게시할 수 있습니다.

Unity 카탈로그의 등록된 모델은 별칭으로 참조됩니다. 유추 파이프라인은 "챔피언" 모델 버전을 로드하고 적용하도록 구성됩니다. "챔피언" 버전이 새 모델 버전으로 업데이트되면 유추 파이프라인은 자동으로 새 버전을 다음 실행에 사용합니다. 이러한 방식으로 모델 배포 단계는 유추 파이프라인에서 분리됩니다.

Batch 작업은 일반적으로 프로덕션 카탈로그의 테이블, 플랫 파일 또는 JDBC 연결을 통해 예측을 게시합니다. 스트리밍 작업은 일반적으로 예측을 Unity 카탈로그 테이블 또는 Apache Kafka와 같은 메시지 큐에 게시합니다.

6. 레이크하우스 모니터링

Lakehouse 모니터링은 입력 데이터 및 모델 예측의 데이터 드리프트 및 모델 성능과 같은 통계 속성을 모니터링합니다. 이러한 메트릭을 기반으로 하여 경고를 만들거나 대시보드에 게시할 수 있습니다.

  • 데이터 수집. 이 파이프라인은 일괄 처리, 스트리밍 또는 온라인 유추에서 로그를 읽습니다.
  • 정확도 및 데이터 드리프트 확인. 이 파이프라인은 입력 데이터, 모델의 예측 및 인프라 성능에 대한 메트릭을 계산합니다. 데이터 과학자는 개발 중에 데이터 및 모델 메트릭을 지정하고, ML 엔지니어는 인프라 메트릭을 지정합니다. Lakehouse 모니터링을 사용하여 사용자 지정 메트릭을 정의할 수도 있습니다.
  • 메트릭을 게시하고 경고를 설정합니다. 파이프라인은 분석 및 보고를 위해 프로덕션 카탈로그의 테이블에 씁니다. 데이터 과학자가 분석에 액세스할 수 있도록 개발 환경에서 이러한 테이블을 읽을 수 있도록 구성해야 합니다. Databricks SQL을 사용하여 모델 성능을 추적하는 모니터링 대시보드를 만들고, 메트릭이 지정된 임계값을 초과할 때 알림을 발급하도록 모니터링 작업 또는 대시보드 도구를 설정할 수 있습니다.
  • 모델 재학습을 트리거합니다. 모니터링 메트릭이 입력 데이터의 성능 문제 또는 변경 내용을 나타내는 경우 데이터 과학자는 새 모델 버전을 개발해야 할 수 있습니다. 이 경우 데이터 과학자에게 알리도록 SQL 경고를 설정할 수 있습니다.

7. 재학습

이 아키텍처는 위의 동일한 모델 학습 파이프라인을 사용하여 자동 재학습을 지원합니다. Databricks는 예약된 정기 재학습부터 시작하여 필요한 경우 트리거된 재학습으로 이동하는 것이 좋습니다.

  • 예약. 새 데이터를 정기적으로 사용할 수 있는 경우 사용 가능한 최신 데이터에 대해 모델 학습 코드를 실행하는 예약된 작업을 만들 수 있습니다.
  • 트리거형. 모니터링 파이프라인이 모델 성능 문제를 식별하고 경고를 보낼 수 있는 경우 재학습을 트리거할 수도 있습니다. 예를 들어 들어오는 데이터의 분포가 크게 변경되거나 모델 성능이 저하되는 경우 자동 재학습 및 재배포는 최소한의 사용자 개입으로 모델 성능을 높일 수 있습니다. 이 작업은 SQL 경고를 통해 메트릭이 비정상적인지(예: 임계값에 대한 드리프트 또는 모델 품질 검사) 검사 수 있습니다. 웹후크 대상을 사용하도록 경고를 구성할 수 있으며, 이후에 학습 워크플로를 트리거할 수 있습니다.

재학습 파이프라인 또는 다른 파이프라인에 성능 문제가 발생하는 경우 데이터 과학자는 문제를 해결하기 위해 추가 실험을 위해 개발 환경으로 돌아가야 할 수 있습니다.