다음을 통해 공유

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

이 문서는 Azure Databricks에서 작업을 사용하여 Structured Streaming 워크로드를 예약하는 데 대한 권장 사항을 포함하고 있습니다.

Databricks는 항상 다음을 수행할 것을 권장합니다.

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

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

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

비고

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

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

Databricks는 실패 시 자동으로 다시 시작하도록 스트리밍 작업을 항상 구성할 것을 권장합니다. 일부 기능, 스키마 진화를 포함하여, 구조화된 스트리밍 작업이 자동으로 재시도하도록 설정되어 있다고 가정합니다. 구조화된 스트리밍 작업을 구성하여 실패 시 스트리밍 쿼리를 재시작하기를 참조하세요.

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

비고

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

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

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

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

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

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

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

전략: 다중 작업 여러 쿼리
컴퓨팅은 어떻게 공유되는가? Databricks는 각 스트리밍 작업에 적합한 크기의 작업 컴퓨팅을 배포할 것을 권장합니다. 작업 간에 컴퓨팅 자원을 공유할 수 있습니다. 모든 쿼리는 동일한 컴퓨팅을 공유합니다. 쿼리를 scheduler pools에 선택적으로 지정할 수 있습니다.
재시도는 어떻게 처리되는가? 작업이 다시 시도되기 전에 모든 작업이 실패해야 합니다. 쿼리가 실패하면 태스크가 다시 시도합니다.

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

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

연속 트리거는 기본적으로 다음과 같은 동작을 제공합니다:

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

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

비고

streamingQuery.awaitTermination() 또는 spark.streams.awaitAnyTermination()을 사용할 필요가 없습니다. 작업은 스트리밍 쿼리가 활성 상태일 때 실행 완료를 자동으로 방지합니다.

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

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

기본적으로, 노트에서 시작된 모든 쿼리는 동일한 공정한 스케줄링 풀에서 실행됩니다. 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 공정 스케줄러 문서를 참조하세요.

  • Last updated on