구조화된 스트리밍을 위한 프로덕션 고려사항

Azure Databricks에서 프로덕션 Structured Streaming 워크로드를 예약된 Lakeflow 작업으로 실행합니다. Lakeflow 작업을 참조하세요.

Databricks는 항상 다음을 구성하는 것이 좋습니다.

• 불필요한 코드, 예를 들어 display 및 count와 같이 결과를 반환하는 코드를 노트북에서 제거합니다.
• 다목적 컴퓨팅을 사용하여 구조적 스트리밍 워크로드를 실행하지 마세요. 항상 작업 컴퓨팅을 사용하여 스트림을 Lakeflow 작업으로 예약합니다.
• Continuous 모드를 사용하여 Lakeflow 작업을 예약합니다. 이것은 구조적 스트리밍의 트리거 간격이 아니라 Azure Databricks 작업 예약 기능을 나타냅니다.
• 구조적 스트리밍 작업에 대해 컴퓨팅에 자동 크기 조정을 사용하도록 설정하지 마세요.

일부 워크로드는 다음과 같은 이점을 누릴 수 있습니다.

• Azure Databricks에서 RocksDB 상태 저장소 구성
• 상태 저장 쿼리를 위한 비동기 상태 체크포인팅
• 비동기 진행률 추적

Databricks는 구조적 스트리밍 워크로드에 대한 프로덕션 인프라 관리의 복잡성을 줄이기 위해 Lakeflow 파이프라인을 도입했습니다. Databricks는 새로운 구조적 스트리밍 파이프라인에 대해 Lakeflow 파이프라인을 사용하는 것이 좋습니다. Spark 선언형 파이프라인을 참조하십시오.

비고

컴퓨팅 자동 확장은 구조적 스트리밍 워크로드에 대한 클러스터 크기를 줄이는 데 한계가 있습니다. Databricks는 스트리밍 워크로드에 대해 향상된 자동 크기 조정과 함께 Lakeflow에서 Spark 선언적 파이프라인을 사용하는 것이 좋습니다. 자동 크기 조정을 사용하여 Lakeflow 파이프라인 클러스터 사용률 최적화를 참조하세요.

:::note 서버리스 컴퓨팅

서버리스 컴퓨팅에서만 Trigger.AvailableNow()Trigger.Once() 지원됩니다. Databricks는 권장합니다.Trigger.AvailableNow()

서버리스 컴퓨팅에서 연속 스트리밍의 경우 연속 모드에서 트리거된 파이프라인 모드와 연속 파이프라인 모드 를 사용합니다.

스트리밍 제한 사항을 참조하세요.

:::

운영 스트리밍 지연 감소

운영 스트리밍 작업부드는 데이터를 거의 실시간으로 수집, 변환, 처리합니다. 일반적인 예로는 사기 탐지, 이상 탐지, 개인화, 실시간 모니터링 및 알림 등이 있으며, 지연된 처리 처리가 비즈니스 결과에 직접적인 영향을 미칩니다. 이러한 워크로드의 낮은 지연은 일반적으로 수십에서 수백 밀리초 정도이지만, 많은 팀이 상위 백분위수에서의 변동성을 고려해 서비스 수준 협약(SLA)을 초 단위로 설정합니다.

가장 낮은 종단 간 지연 시간을 위해서는 실시간 모드를 사용하는데, 이는 끝부분에서 1초 미만, 일반적인 경우 약 300밀리초 정도의 종단 간 지연을 달성합니다. 실시간 모드 개념을 참조하세요.

실시간 모드가 귀하의 업무량에 맞지 않을 때, 다음 모범 사례가 마이크로 배치 구조화 스트리밍의 지연을 줄여줍니다:

• 출력 모드: 쿼리 연산자와 싱크가 지원하는 업데이트 모드를 사용하세요. 업데이트 모드는 각 트리거가 실행된 후 업데이트된 행을 출력하고 워터마크가 만료될 때까지 해당 행을 계속 업데이트하므로, 업데이트된 결과를 처리할 수 있도록 다운스트림 싱크가 멱등성을 갖게 하세요. 업데이트 모드가 지원하지 않는 워크로드, 예를 들어 스트림-스트림 조인이나 늦게 도착하는 데이터를 삭제할 수 있는 경우에는 Append 모드를 사용하세요. 낮은 지연 시간을 위해 완전 모드는 사용하지 마세요. 참조하세요 구조적 스트리밍에 대한 출력 모드를 선택.
• 트리거: processingTime 간격의 0 트리거를 사용하여, 이전 마이크로 배치가 완료되고 새 데이터가 있으면 즉시 다음 마이크로 배치를 시작합니다. 이로 인해 마이크로 배치 지연 시간이 가장 짧지만, 클라우드 스토리지 API 비용이 증가합니다. 운영 워크로드에는 Once, Continuous 또는 AvailableNow를 사용하지 마세요. 구조적 스트리밍 트리거 간격 구성을 참조하세요.
• 워터마크: 늦게 도착하는 데이터를 포함할 수 있도록 워터마크를 충분히 길게 설정하여 작업 부하가 줄어들지 않도록 하세요. 워터마크는 쿼리가 순서가 뒤바뀐 이벤트 시간 데이터를 폐기하고 상태를 제거하기 전에 이를 얼마나 오래 받아들일지를 제어하므로, 너무 짧은 워터마크는 늦게 도착한 유효한 레코드를 조용히 폐기합니다. 이 제약 내에서 워터마크가 짧을수록 지연 시간이 줄고 상태 보존이 적으며, 워터마크가 길수록 지연과 상태를 희생하는 대신 더 늦은 데이터를 허용합니다. 지연 SLA의 작은 배수, 예를 들어 2배 정도가 튜닝의 합리적인 출발점입니다. 데이터 처리 임계값을 제어하기 위해 워터마크 적용하기를 참조하세요.
• 소스 및 싱크: 메시지 버스(Apache Kafka, Amazon Kinesis, Apache Pulsar, Google Cloud Pub/Sub)와 같은 저지연 소스에서 읽거나 Delta Lake 및 Apache Iceberg 테이블의 데이터 피드를 변경하세요. 메시지 버스, 운영 데이터베이스 또는 foreach 싱크와 같은 저지연, 고처리량 싱크에 기록합니다. 다운스트림 소비자가 중복 및 지연 도착 데이터를 처리할 수 있도록 싱크 작업을 멱등하게 설계하세요.
• 상태 및 체크포인트: 상태 기반 쿼리를 위해서는 변경로그 체크포인트와 비동기 상태 체크포인트 모두에 필요한 RocksDB 상태 저장소를 사용하세요. 변경 로그 체크포인트를 활성화하여 점진적인 상태 변경만 지속하도록 하세요. 상태 체크포인팅이 배치 처리 시간의 병목이라면, 장애 복구 및 클러스터 크기 조정 시의 주의사항을 검토한 후 체크포인트 쓰기가 다음 마이크로 배치와 병행되도록 비동기 상태 체크포인팅을 활성화하세요. 각 쿼리를 내구성 있는 클라우드 저장소에 자체 체크포인트 디렉터리로 설정하세요. Azure Databricks에서 RocksDB 상태 저장소 구성, 상태 저장 쿼리를 위한 비동기 상태 체크포인팅, 그리고 Structured Streaming 체크포인트를 참고하세요.
• 오프셋 관리: 연속 스트림에서 오프셋 체크포인트로 인한 지연을 줄이기 위해 데이터 처리를 차단하지 않고 오프셋과 커밋 로그를 업데이트하는 비동기 진행 추적을 활성화합니다. Once 또는 AvailableNow 트리거와는 호환되지 않습니다. 비동기 진행률 추적을 참조하세요.
• 스토리지 홉: 가능한 한 하나의 스트리밍 파이프라인 내에 계산을 유지하세요. 여러 작업이나 파이프라인에 로직을 분산시키면 저장 홉이 추가되어 지연 시간이 증가합니다.

오류를 예상하도록 스트리밍 워크로드 디자인

Databricks는 오류 발생 시에 자동으로 다시 시작하도록 스트리밍 작업을 항상 구성하는 것이 좋습니다. 스키마 진화를 비롯한 일부 기능을 사용하려면 구조적 스트리밍 워크로드가 자동으로 다시 시도해야 합니다. 구조화된 스트리밍 작업을 구성하여 실패 시 스트리밍 쿼리를 재시작하기를 참조하세요.

일부 작업은 foreachBatch와 같은 경우 정확히 한 번이 아닌 최소 한 번 보장합니다. 이러한 작업을 위해, 처리 파이프라인이 idempotent 속성을 가지고 있는지 확인하십시오. foreachBatch를 사용하여 임의의 데이터 싱크에 쓰기를 참조하십시오.

비고

쿼리가 다시 시작되면 이전 실행 중에 계획된 마이크로 배치를 처리합니다. 메모리 부족 오류로 인해 작업이 실패했거나 과도하게 큰 마이크로 배치 때문에 작업을 수동으로 취소했을 경우, 마이크로 배치를 성공적으로 처리하려면 컴퓨팅 성능을 확장해야 할 수 있습니다.

실행 간 구성 설정을 변경하면, 이러한 구성이 계획된 첫 번째 새로운 배치에 적용됩니다. 구조화된 스트리밍 쿼리에서의 변경 후 복구를 참조하십시오.

작업이 다시 시도되는 경우

여러 작업을 Azure Databricks 작업의 일부로 예약할 수 있습니다. 연속 트리거를 사용하여 작업을 설정할 때, 작업 간의 의존성을 설정할 수 없습니다.

단일 작업에서 여러 스트림을 예약하려면 다음 방법 중 하나를 선택할 수 있습니다.

• 여러 작업: 지속적 트리거를 사용하여 스트리밍 워크로드를 수행하는 여러 작업이 포함된 작업을 정의하십시오.
• 다중 쿼리: 단일 작업에 대해 소스 코드에서 여러 스트리밍 쿼리를 정의합니다.

또한 이러한 전략들을 결합할 수 있습니다. 다음 표에서는 이러한 접근 방식을 비교합니다.

전략	다중 작업	여러 쿼리
컴퓨팅은 어떻게 공유되는가?	Databricks는 각 스트리밍 작업에 적합한 크기의 작업 컴퓨팅을 배포할 것을 권장합니다. 작업 간에 컴퓨팅 자원을 공유할 수 있습니다.	모든 쿼리는 동일한 컴퓨팅을 공유합니다. 필요에 따라 스케줄러 풀에 쿼리를 할당할 수 있습니다.
재시도는 어떻게 처리되는가?	작업이 다시 시도되기 전에 모든 작업이 실패해야 합니다.	쿼리가 실패하면 태스크가 다시 시도합니다.

여러 작업 또는 쿼리 작업에 대한 자세한 내용은 동일한 클러스터에서 여러 구조적 스트리밍 쿼리 실행을 참조하세요.

구조화된 스트리밍 작업을 구성하여 실패 시 스트리밍 쿼리를 재시작합니다.

Databricks는 연속 트리거를 사용하여 모든 스트리밍 워크로드를 구성하는 것이 좋습니다. 참고: 작업을 계속 실행.

연속 트리거에는 기본적으로 다음과 같은 동작이 있습니다.

• 작업의 동시 실행을 하나 이상 허용하지 않습니다.
• 이전 실행이 실패하면 새 실행을 시작합니다.
• 재시도를 위해 지수 백오프를 사용합니다.

Databricks는 워크플로우를 일정에 맞춰 실행할 때 일반 목적 컴퓨팅 대신 작업 컴퓨팅을 항상 사용할 것을 권장합니다. 작업 실패와 재시도 시, 새로운 컴퓨팅 리소스가 배포됩니다.

비고

Databricks는 streamingQuery.awaitTermination() 또는 spark.streams.awaitAnyTermination()를 사용하지 않는 것이 좋습니다. 사용 awaitTermination()시기를 참조하세요.

사용 시기 awaitTermination()

streamingQuery.awaitTermination() 및 spark.streams.awaitAnyTermination()는 스트리밍 쿼리가 종료될 때까지 현재 스레드를 블록합니다. 이러한 함수를 사용할지 여부는 실행 환경에 따라 달라집니다.

Lakeflow Jobs의 경우 streamingQuery.awaitTermination() 또는 spark.streams.awaitAnyTermination()을(를) 사용하지 마세요. 이러한 함수는 스트리밍 쿼리가 활성 상태일 때 작업 서비스에서 실행이 자동으로 완료되지 않도록 하기 때문에 필요하지 않습니다. 두 함수 모두 Notebook 셀이 완료되지 않도록 차단하고 작업 서비스가 스트리밍 쿼리를 추적하지 못하게 하여 백로그 메트릭 및 작업 알림을 방해합니다.

다음 경우에 사용합니다 awaitTermination() .

사용 사례	작동 방식
대화형 노트북을 활용한 다목적 컴퓨팅	awaitTermination() 에서는 셀이 계속 실행되고 쿼리 상태를 관찰할 수 있으며 Notebook 출력에 오류가 표시되도록 합니다.
로컬 및 개발 환경	Spark 프로그램을 로컬로 실행하면 주 스레드가 완료되면 프로세스가 종료됩니다. 스트리밍 쿼리가 완료되거나 실패할 때까지 프로그램을 활성 상태로 유지하기 위해 호출 awaitTermination() 합니다.
드라이버로의 오류 전파	그렇지 않으면 awaitTermination()비 작업 컨텍스트에서 스트리밍 쿼리 오류가 호출 스레드로 전파되지 않을 수 있습니다. 쿼리는 자동으로 실패할 수 있으므로 오류를 감지하고 진단하기가 더 어려워집니다. 호출 awaitTermination() 하면 드라이버에서 쿼리 예외가 다시 발생합니다.