다음을 통해 공유

구조적 스트리밍에 대한 프로덕션 고려 사항

  • 아티클

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

Databricks는 항상 다음을 수행하는 것이 좋습니다.

  • display와 count 같은 결과를 반환하는 Notebook에서 불필요한 코드를 제거합니다.
  • 다목적 컴퓨팅을 사용하여 구조적 스트리밍 워크로드를 실행하지 마세요. 항상 작업 컴퓨팅을 사용하여 스트림을 작업으로 예약합니다.
  • Continuous 모드를 사용하여 작업을 예약합니다.
  • 구조적 스트리밍 작업에 대해 컴퓨팅에 대해 자동 크기 조정을 사용하도록 설정하지 마세요.

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

Azure Databricks는 구조적 스트리밍 워크로드에 대한 프로덕션 인프라 관리의 복잡성을 줄이기 위해 Delta Live Tables를 도입했습니다. Databricks에서는 새로운 구조화된 스트리밍 파이프라인에 Delta Live 테이블을 사용할 것을 권장합니다. Delta Live Tables이란?.

참고 항목

구조화된 스트리밍 워크로드의 경우 컴퓨팅 자동 크기 조정에는 클러스터 크기를 스케일 다운하는 데 제한이 있습니다. Databricks는 스트리밍 워크로드에 대해 향상된 자동 크기 조정과 함께 Delta Live Tables를 사용하는 것이 좋습니다. 향상된 자동 크기 조정을 사용하여 Delta Live Tables 파이프라인의 클러스터 사용률 최적화를 참조 하세요.

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

Databricks는 항상 오류 시 자동으로 다시 시작하도록 스트리밍 작업을 구성하는 것이 좋습니다. 스키마 진화를 포함한 일부 기능은 구조적 스트리밍 워크로드가 자동으로 다시 시도하도록 구성되어 있다고 가정합니다. 실패 시 스트리밍 쿼리를 다시 시작하려면 구조화된 스트리밍 작업 구성을 참조하세요.

foreachBatch 같은 일부 작업은 정확히 한 번 보장하지 않고 한 번 이상 제공합니다. 이러한 작업의 경우 처리 파이프라인이 idempotent인지 확인해야 합니다. foreachBatch를 사용하여 임의의 데이터 싱크에 쓰기를 참조하세요.

참고 항목

쿼리가 다시 시작되면 이전 실행 중에 계획된 마이크로 일괄 처리가 처리됩니다. 메모리 부족 오류로 인해 작업이 실패했거나 대형 마이크로 일괄 처리로 인해 작업을 수동으로 취소한 경우 마이크로 일괄 처리를 성공적으로 처리하려면 컴퓨팅을 강화해야 할 수 있습니다.

실행 간에 구성을 변경하는 경우 이러한 구성은 계획된 첫 번째 새 일괄 처리에 적용됩니다. 구조화된 스트리밍 쿼리에서 변경 후 복구를 참조하세요.

작업은 언제 다시 시도하나요?

Azure Databricks 작업의 일부로 여러 작업을 예약할 수 있습니다. 연속 트리거를 사용하여 작업을 구성하는 경우 작업 간에 종속성을 설정할 수 없습니다.

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

  • 여러 작업: 연속 트리거를 사용하여 스트리밍 워크로드를 실행하는 여러 태스크로 작업을 정의합니다.
  • 여러 쿼리: 단일 작업에 대한 소스 코드에서 여러 스트리밍 쿼리를 정의합니다.

이러한 전략을 결합할 수도 있습니다. 다음 표는 이러한 접근 방식을 비교한 것입니다.

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

실패 시 스트리밍 쿼리를 다시 시작하도록 구조적 스트리밍 작업 구성

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

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

  • 둘 이상의 동시 작업 실행을 방지합니다.
  • 이전 실행이 실패하면 새 실행을 시작합니다.
  • 재시도에 지수 백오프를 사용합니다.

Databricks는 워크플로를 예약할 때 항상 다목적 컴퓨팅 대신 작업 컴퓨팅을 사용하는 것이 좋습니다. 작업 실패 및 다시 시도 시 새 컴퓨팅 리소스가 배포됩니다.

참고 항목

streamingQuery.awaitTermination() 또는 spark.streams.awaitAnyTermination()를 사용할 필요가 없습니다. 스트리밍 쿼리가 활성 상태이면 작업에서 자동으로 실행이 완료되지 않도록 합니다.

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

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

기본적으로 Notebook에서 시작된 모든 쿼리는 동일한 공정 예약 풀에서 실행됩니다. Notebook의 모든 스트리밍 쿼리에서 트리거에 의해 생성된 Apache Spark 작업은 '선입선출(FIFO)' 순서로 차례로 실행됩니다. 이 경우 쿼리가 클러스터 리소스를 효율적으로 공유하지 않으므로 쿼리에서 불필요한 지연이 발생할 수 있습니다.

스케줄러 풀을 사용하면 컴퓨팅 리소스를 공유하는 구조적 스트리밍 쿼리를 선언할 수 있습니다.

다음 예제에서는 전용 풀에 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")

참고 항목

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

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