프로덕션 워크로드에 대한 자동 로더 구성

Databricks는 프로덕션 환경에서 자동 로더를 실행하기 위한 스트리밍 모범 사례를 따르도록 권장합니다.

Databricks는 증분 데이터 수집에 Delta Live Tables의 자동 로더를 사용할 것을 권장합니다. Delta Live Tables는 Apache Spark Structured Streaming의 기능을 확장하며 다음과 같이 몇 줄의 선언적 Python 또는 SQL을 작성하여 프로덕션 품질 데이터 파이프라인을 배포할 수 있게 해줍니다.

자동 로더 모니터링

자동 로더에서 검색한 파일 쿼리

참고 항목

cloud_files_state 함수는 Databricks Runtime 11.3 LTS 이상에서 사용할 수 있습니다.

자동 로더는 스트림의 상태를 검사하기 위한 SQL API를 제공합니다. cloud_files_state 함수를 사용하여 자동 로더 스트림에서 검색한 파일에 대한 메타데이터를 찾을 수 있습니다. 자동 로더 스트림과 연결된 검사점 위치를 제공하는 cloud_files_state에서 간단히 쿼리합니다.

SELECT * FROM cloud_files_state('path/to/checkpoint');

스트림 업데이트 수신 대기

Auto Loader 스트림을 추가로 모니터링하려면 Databricks는 Apache Spark의 스트리밍 쿼리 수신기 인터페이스를 사용하는 것이 좋습니다.

자동 로더는 매 일괄 처리에서 스트리밍 쿼리 수신기에 메트릭을 보고합니다. 백로그에 있는 파일의 수와 스트리밍 쿼리 진행률 대시보드의 원시 데이터 탭 아래에 있는 numFilesOutstanding 백로그 및 numBytesOutstanding 메트릭의 얼마나 큰지를 볼 수 있습니다.

{
  "sources" : [
    {
      "description" : "CloudFilesSource[/path/to/source]",
      "metrics" : {
        "numFilesOutstanding" : "238",
        "numBytesOutstanding" : "163939124006"
      }
    }
  ]
}

Databricks Runtime 10.4 LTS 이상에서 파일 알림 모드를 사용하는 경우 메트릭에는 AWS 및 Azure와 같이 approximateQueueSize 클라우드 큐에 있는 대략적인 파일 이벤트 수도 포함됩니다.

비용 고려 사항

자동 로더를 실행할 때 비용의 주요 원본은 컴퓨팅 리소스 및 파일 검색 비용입니다.

컴퓨팅 비용을 줄이기 위해 Databricks는 짧은 대기 시간 요구 사항이 없는 한 지속적으로 실행하는 대신 Databricks 작업을 사용하여 Trigger.AvailableNow 자동 로더를 일괄 작업으로 예약하는 것이 좋습니다. 구조적 스트리밍 트리거 간격 구성을 참조 하세요.

파일 검색 비용은 디렉터리 목록 모드의 스토리지 계정에 대한 LIST 작업과 구독 서비스의 API 요청, 파일 알림 모드의 큐 서비스 형태로 발생할 수 있습니다. 파일 검색 비용을 줄이기 위해 Databricks는 다음을 권장합니다.

  • 디렉터리 목록 모드에서 자동 로더를 계속 실행할 때 ProcessingTime 트리거 제공
  • 가능하면 증분 목록(사용되지 않음)을 활용하도록 파일 업로드를 어휘 순서대로 스토리지 계정에 설계
  • 증분 목록이 불가능할 때 파일 알림 활용
  • 리소스 태그를 사용하여 비용 추적을 위해 자동 로더에서 만들어진 리소스에 태그 지정

Trigger.AvailableNow 및 속도 제한 사용

참고 항목

Databricks Runtime 10.4 LTS 이상에서 사용할 수 있습니다.

자동 로더는 Trigger.AvailableNow를 사용하여 Databricks 작업에서 일괄 작업으로 실행되도록 예약할 수 있습니다. AvailableNow 트리거는 쿼리 시작 시간 이전에 도착한 모든 파일을 처리하도록 자동 로더에 지시합니다. 스트림이 시작된 후 업로드되는 새 파일은 다음 트리거까지 무시됩니다.

파일 검색은 Trigger.AvailableNow데이터 처리와 함께 비동기적으로 수행되며 속도 제한으로 여러 마이크로 일괄 처리에서 데이터를 처리할 수 있습니다. 자동 로더는 기본적으로 마이크로 일괄 처리마다 최대 1000개의 파일을 처리합니다. cloudFiles.maxFilesPerTriggercloudFiles.maxBytesPerTrigger를 구성하여 마이크로 일괄 처리에서 처리해야 하는 파일 수 또는 바이트 수를 구성할 수 있습니다. 파일 제한은 하드 제한이지만 바이트 제한은 소프트 제한입니다. 즉, 제공된 maxBytesPerTrigger보다 더 많은 바이트를 처리할 수 있습니다. 옵션이 모두 함께 제공되면 자동 로더는 제한 중 하나에 도달하기 위해 필요한 만큼의 파일을 처리합니다.

이벤트 보존

자동 로더는 RocksDB를 사용하여 검사점 위치에서 발견된 파일을 추적하여 정확히 한 번 수집할 수 있습니다. Databricks는 모든 대용량 또는 수명이 긴 수집 스트림에 대한 옵션을 사용하는 cloudFiles.maxFileAge 것이 좋습니다. 이 옵션은 검사 지점 위치에서 이벤트를 만료하여 자동 로더 시작 시간을 단축합니다. 시작 시간은 자동 로더 실행당 시간(분)으로 늘어날 수 있으며, 원본 디렉터리에 저장될 파일의 최대 기간에 상한이 있는 경우 불필요한 비용이 추가됩니다. cloudFiles.maxFileAge에 대해 설정할 수 있는 최소값은 "14 days"입니다. RocksDB의 삭제는 삭제 표시 항목으로 나타나므로 이벤트가 종료되기 시작하기 전에 스토리지 사용량이 일시적으로 증가할 것으로 예상해야 합니다.

Warning

cloudFiles.maxFileAge 는 대용량 데이터 세트에 대한 비용 제어 메커니즘으로 제공됩니다. 너무 적극적으로 튜닝하면 cloudFiles.maxFileAge 중복 수집 또는 누락된 파일과 같은 데이터 품질 문제가 발생할 수 있습니다. 따라서 Databricks는 비교 가능한 데이터 수집 솔루션이 권장하는 것과 유사한 90일과 같은 보수적인 설정을 cloudFiles.maxFileAge권장합니다.

cloudFiles.maxFileAge 옵션을 튜닝하려고 하면 자동 로더에서 처리되지 않은 파일을 무시하거나 이미 처리된 파일이 만료되었다가 다시 처리되어 데이터 중복이 발생할 수 있습니다. 다음은 cloudFiles.maxFileAge을 선택할 때 고려해야 할 몇 가지 사항입니다.

  • 오랜 시간 후에 스트림이 다시 시작되면 큐에서 가져온 cloudFiles.maxFileAge보다 오래된 파일 알림 이벤트가 무시됩니다. 마찬가지로 디렉터리 목록을 사용하는 경우 가동 중지 시간 동안 나타날 수 있는 파일보다 cloudFiles.maxFileAge 오래된 파일은 무시됩니다.
  • 디렉터리 목록 모드를 사용하는 cloudFiles.maxFileAge경우(예: 설정된 경우) 스트림을 "1 month"중지하고 스트림을 다시 시작하고 cloudFiles.maxFileAge"2 months", 1개월보다 오래되었지만 최근 2개월보다 오래된 파일은 다시 처리됩니다.

스트림을 처음 시작할 때 이 옵션을 설정하면 이전 데이터보다 cloudFiles.maxFileAge오래된 데이터를 수집하지 않으므로 이전 데이터를 수집하려는 경우 스트림을 처음 시작할 때 이 옵션을 설정하면 안 됩니다. 그러나 후속 실행 시 이 옵션을 설정해야 합니다.

cloudFiles.backfillInterval을 사용하여 일반 백필 트리거

자동 로더는 지정된 간격으로 비동기 백필을 트리거할 수 있습니다(예: 하루에 한 번 백필하는 일 또는 일주일에 한 번 백필하는 데 1주일). 파일 이벤트 알림 시스템은 업로드된 모든 파일의 100% 배달을 보장하지 않으며 파일 이벤트의 대기 시간에 엄격한 SLA를 제공하지 않습니다. Databricks는 데이터 완전성이 요구 사항인 경우 지정된 SLA 내에서 모든 파일이 검색되도록 보장하기 위해 cloudFiles.backfillInterval 옵션을 사용하여 자동 로더로 정기적인 백필을 트리거하는 것이 좋습니다. 일반 백필을 트리거해도 중복이 발생하지 않습니다.