이 페이지에서는 Azure Databricks 구조적 스트리밍에 대한 트리거 간격을 구성하는 방법을 설명합니다.
Apache Spark 구조적 스트리밍은 데이터를 증분 방식으로 처리합니다. 트리거 간격은 구조적 스트리밍이 새 데이터를 확인하는 빈도를 제어합니다. 거의 실시간 처리, 예약된 데이터베이스 새로 고침 또는 하루 또는 일주일 동안 모든 새 데이터를 일괄 처리하기 위한 트리거 간격을 구성할 수 있습니다.
자동 로더란? 구조적 스트리밍을 사용하여 데이터를 로드하기 때문에 트리거 작동 방식을 이해하면 원하는 빈도로 데이터를 수집하면서 비용을 제어할 수 있는 가장 큰 유연성을 제공합니다.
중요한
Azure Databricks 사용 사례에 대한 대기 시간과 비용의 균형을 맞추는 트리거 모드를 설정하는 것이 좋습니다. 그렇지 않으면 클라우드 공급자의 예기치 않은 스토리지 비용이 표시될 수 있습니다. 자세한 내용은 제어 클라우드 스토리지 비용을 참조하세요.
트리거 모드 개요
다음 표에는 구조적 스트리밍에서 사용할 수 있는 트리거 모드가 요약되어 있습니다.
| 트리거 모드 | 구문 예제(Python) | 적합한 대상 |
|---|---|---|
| 지정되지 않음(기본값) | N/A | 3-5초 대기 시간이 있는 범용 스트리밍. 0ms 간격의 processingTime 트리거에 해당합니다. 스트림 처리는 새 데이터가 도착하는 한 지속적으로 실행됩니다. |
| 처리 시간 | .trigger(processingTime='10 seconds') |
비용 및 성능의 균형을 조정합니다. 시스템이 데이터를 너무 자주 확인하지 못하게 하여 오버헤드를 줄입니다. |
| 지금 사용 가능 | .trigger(availableNow=True) |
예약된 증분 일괄 처리입니다. 스트리밍 작업이 트리거될 때 사용할 수 있는 만큼의 데이터를 처리합니다. |
| 실시간 모드 | .trigger(realTime='5 minutes') |
사기 감지 또는 실시간 개인 설정과 같은 초 미만의 처리가 필요한 매우 짧은 대기 시간 운영 워크로드입니다. 공개 미리 보기. '5분'은 마이크로 일괄 처리의 길이를 나타냅니다. 쿼리 컴파일과 같은 일괄 처리별 오버헤드를 최소화하려면 5분을 사용합니다. |
| 지속적 | .trigger(continuous='1 second') |
지원되지 않습니다. Spark OSS에 포함된 실험적 기능입니다. 대신 실시간 모드를 사용합니다. |
:::note 서버리스 컴퓨팅
서버리스 컴퓨팅에서만 Trigger.AvailableNow()Trigger.Once() 지원됩니다. Databricks는 권장합니다.Trigger.AvailableNow()
서버리스 컴퓨팅에서 연속 스트리밍의 경우 연속 모드에서 트리거된 파이프라인 모드와 연속 파이프라인 모드 를 사용합니다.
스트리밍 제한 사항을 참조하세요.
:::
processingTime: 시간 기반 트리거 간격
구조적 스트리밍은 시간 기반 트리거 간격을 "고정 간격 마이크로 일괄 처리"라고 합니다.
processingTime 키워드를 사용하여 기간(예: .trigger(processingTime='10 seconds'))을 문자열로 지정합니다.
이 간격의 구성은 시스템에서 새 데이터가 도착했는지 확인하기 위해 검사를 수행하는 빈도를 결정합니다. 대기 시간 요구 사항과 데이터가 원본에 도착하는 속도의 균형을 맞추도록 처리 시간을 구성합니다.
AvailableNow: 증분 일괄 처리
중요한
Databricks Runtime 11.3 LTS 이상 Trigger.Once 에서는 더 이상 사용되지 않습니다. 모든 증분 일괄 처리 워크로드에 Trigger.AvailableNow를 사용합니다.
AvailableNow 트리거 옵션은 사용 가능한 모든 레코드를 증분 일괄 처리로 사용하며, 다음과 같은 maxBytesPerTrigger옵션을 사용하여 일괄 처리 크기를 구성할 수 있습니다. 크기 조정 옵션은 데이터 원본에 따라 다릅니다.
지원되는 데이터 원본
Azure Databricks 많은 구조적 스트리밍 원본에서 증분 일괄 처리를 위해 Trigger.AvailableNow 사용을 지원합니다. 다음 표에는 각 데이터 원본에 필요한 최소 지원되는 Databricks 런타임 버전이 포함되어 있습니다.
| 출처 | 최소 Databricks 런타임 버전 |
|---|---|
| 파일 원본(JSON, Parquet 등) | 9.1 LTS |
| Delta Lake | 10.4 LTS |
| 자동 로더 | 10.4 LTS |
| Apache Kafka | 10.4 LTS |
| 키네시스 | 13.1 |
realTime: 초저지연 운영 워크로드
구조적 스트리밍에 대한 실시간 모드는 꼬리에서 1초 미만의 엔드 투 엔드 대기 시간을 달성하며, 일반적인 경우는 약 300ms입니다. 실시간 모드를 효과적으로 구성하고 사용하는 방법에 대한 자세한 내용은 구조적 스트리밍의 실시간 모드를 참조하세요.
Apache Spark에는 연속 처리라고 하는 추가 트리거 간격이 있습니다. 이 모드는 Spark 2.3 이후 실험적 모드로 분류되었습니다. Azure Databricks 이 모드를 지원하거나 권장하지 않습니다. 대기 시간이 짧은 사용 사례에는 실시간 모드를 대신 사용합니다.
주의
이 페이지의 연속 처리 모드는 Lakeflow Spark 선언적 파이프라인의 연속 처리와 관련이 없습니다.
클라우드 스토리지 비용 제어
기본적으로 트리거 모드를 설정하지 않으면 구조적 스트리밍은 트리거 모드를 processingTime 설정하며 간격 0은 몇 밀리초마다 새 데이터를 확인합니다. 이렇게 하면 하루에 많은 양의 클라우드 스토리지 API 호출이 생성되고 클라우드 공급자의 예기치 않은 요금이 발생할 수 있습니다.
Databricks는 대기 시간 및 비용 요구 사항에 적합한 트리거 모드를 구성하는 것이 좋습니다. 시간 기반 트리거 간격 구성에 대한 자세한 내용은 참조 processingTime 하세요.
실행 간 트리거 간격 변경
동일한 검사점을 사용하는 동안 실행 간에 트리거 간격을 변경할 수 있습니다.
간격을 변경할 때의 동작
마이크로 일괄 처리가 처리되는 동안 구조적 스트리밍 작업이 중지되는 경우 새 트리거 간격이 적용되기 전에 해당 마이크로 일괄 처리가 완료되어야 합니다. 따라서 트리거 간격을 변경한 후 이전에 지정한 설정을 사용하여 마이크로 일괄 처리를 관찰할 수 있습니다. 다음은 전환 시 예상되는 동작에 대해 설명합니다.
AvailableNow마이크로 일괄 처리는 모든 사용 가능한 레코드를 점진적 일괄 처리로 가기 전에 먼저 처리할 수 있습니다.AvailableNow시간 기반 간격으로 전환: 마지막AvailableNow작업이 트리거될 때 사용 가능한 모든 레코드에 대해 처리가 계속될 수 있습니다. 이는 예상되는 동작입니다.
쿼리 오류에서 복구
주의
증분 일괄 처리와 관련된 쿼리 실패에서 복구하려는 경우 일괄 처리를 완료해야 하므로 트리거 간격을 변경해도 이 문제가 해결되지 않습니다. 일괄 처리를 처리하는 데 사용되는 컴퓨팅 용량을 확장하여 문제를 해결합니다. 드물게 새 검사점을 사용하여 스트림을 다시 시작해야 할 수 있습니다.