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

이 페이지에는 Azure Databricks 작업을 사용하여 구조적 스트리밍 워크로드를 예약하기 위한 권장 사항이 포함되어 있습니다.

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

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

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

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

비고

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

:::note 서버리스 컴퓨팅

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

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

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

:::

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

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

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

비고

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

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

작업이 언제 재시도됩니까?

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

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

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

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

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

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

Databricks는 모든 스트리밍 작업을 지속적 트리거를 사용하여 구성할 것을 권장합니다. 참고: 작업을 계속 실행.

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

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

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

비고

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

사용 시기 awaitTermination()

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

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

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

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

여러 스트리밍 쿼리용 스케줄러 풀 사용

동일한 소스 코드에서 여러 스트리밍 쿼리를 실행할 때 쿼리에 컴퓨팅 용량을 할당하도록 스케줄러 풀을 구성할 수 있습니다.

기본적으로, 노트에서 시작된 모든 쿼리는 동일한 공정한 스케줄링 풀에서 실행됩니다. Notebook의 모든 스트리밍 쿼리에서 트리거에 의해 생성된 Apache Spark 작업은 FIFO("first in, first out") 순서로 하나씩 실행됩니다. 이로 인해 쿼리에 불필요한 지연이 발생할 수 있습니다. 이는 클러스터 자원을 효율적으로 공유하지 않기 때문입니다.

스케줄러 풀을 사용하면 어떤 Structured Streaming 쿼리들이 컴퓨팅 리소스를 공유하는지 선언할 수 있습니다.

다음 예제에서는 query1을 전용 풀에 할당하고, query2과 query3가 스케줄러 풀을 공유합니다.

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

비고

로컬 속성 구성은 스트리밍 쿼리를 시작하는 동일한 노트북 셀에 있어야 합니다.

Apache Fair Scheduler 풀에 대한 자세한 내용은 Apache Fair Scheduler 설명서를 참조하세요.

  • Last updated on