Foundry의 데이터 위에서 Contour 워크플로를 실행하려면 Foundry 컴퓨트가 필요하며, 이는 컴퓨트-초로 측정됩니다. 이 문서에서는 Contour에서 컴퓨트를 사용하는 방법과 제품에서 컴퓨트 사용량을 조사하고 관리하는 방법에 대한 정보를 제공합니다.
데이터를 표시하는 각 Contour 보드는 Contour 백엔드에 대한 쿼리를 기반으로 합니다. Foundry는 오토 스케일링 Spark 클러스터에서 실행하여 Contour 쿼리를 제공합니다. Contour 쿼리 컴퓨트-초는 쿼리가 실행되는 동안 실제로 사용되는 컴퓨트-초만을 기준으로 측정됩니다. 그러나 대화형 모드에서 컴퓨트 리소스는 모든 Contour 분석에 대해 "항상 켜짐" 상태이므로 더 빠른 응답을 제공합니다. 이는 각 개별 대화형 쿼리가 일괄 컴퓨트보다 더 빠른 속도로 컴퓨트-초를 사용한다는 것을 의미합니다.
쿼리가 사용하는 리소스의 양은 입력 데이터셋의 크기와 레이아웃, 쿼리의 복잡성(예: 사용된 Contour 보드) 등 여러 요인에 따라 달라집니다.
Contour는 Foundry의 병렬 컴퓨트 백엔드를 사용하여 Foundry 데이터에서 쿼리를 실행합니다. 따라서 Contour의 컴퓨트는 다음 공식으로 측정됩니다.
기본값으로 설정된 interactive_contour_usage_rate는 15입니다. 이는 항상 켜져있는 병렬 컴퓨트 프레임워크를 기반으로 Contour가 컴퓨트를 사용하는 속도입니다. Palantir과 기업 계약이 있는 경우, 컴퓨트 사용량 계산을 진행하기 전에 Palantir 담당자에게 문의하십시오.
# total_compute_seconds는 contour_usage_rate와 (driver_compute_seconds + executor_compute_seconds)의 곱입니다.
total_compute_seconds = contour_usage_rate * (driver_compute_seconds + executor_compute_seconds)
Contour의 "항상 준비된" 실행 시스템은 최종 사용자가 실행하는 ad-hoc 쿼리에 반응하도록 설계되었습니다. Foundry에서의 Contour 쿼리 비용은 Spark 클러스터에서 쿼리를 실행하는 데 필요한 시간과 쿼리가 실행되는 동안 사용된 코어 수에 기반합니다. 코어 수는 쿼리가 예약된 Spark 애플리케이션의 사용량을 살펴보아 파생됩니다.
대화형 모드에서는 Contour 보드가 생성되거나 업데이트될 때마다 컴퓨팅이 사용됩니다. 이에는 Contour 경로에서 주어진 보드의 하류에 영향을 주는 "계단식" 컴퓨팅이 포함됩니다. 예를 들어, 다음 액션은 Contour 분석에서 컴퓨팅을 사용합니다:
Contour 경로는 데이터셋으로 "저장"할 수 있습니다. 이렇게 하면 Contour 백엔드에서 생성된 기본 코드가 데이터셋 작업 사양으로 저장됩니다. 이 데이터셋 빌드는 그런 다음 일정이나 ad hoc으로 실행할 수 있습니다. 이러한 데이터셋 작업은 배치 작업으로 측정되며 대화형 Contour 사용이하는 "항상 켜져 있는" 오버헤드를 발생시키지 않습니다.
Contour 배치 데이터셋은 Code Repositories 및 Code Workbook을 통해 생성 및 업데이트된 데이터셋과 유사한 일반 병렬화 배치 계산으로 측정됩니다. 이러한 배치 계산은 다른 배치 계산과 동일한 비율로 컴퓨팅을 사용합니다.
대화형 사용법은 항상 작동하는 분석과 연결되어 있습니다. 주어진 Contour 분석에서 모든 대화형 컴퓨팅은 분석 리소스 자체에 연결됩니다.
컴퓨팅을 실행하는 개별 보드는 빌드 애플리케이션에서 볼 수 있는 Spark 메트릭을 생성합니다. 이는 각 보드의 컨텍스트 메뉴에서 작업 보기 섹션을 통해 액세스할 수 있습니다. Contour에서 배치 컴퓨팅 사용은 컴퓨팅이 생성하는 데이터셋에 연결되어 있으며 Code Repositories및 Code Workbook과 유사합니다. 대화형 및 배치 컴퓨팅 모두에서 리소스 관리 애플리케이션에서 전체 사용량을 확인할 수 있습니다.
Contour는 Spark 계산 프레임워크에서 실행되므로 데이터 규모와 쿼리 복잡성 (데이터에 대해 실행되는 작업 수와 종류)에 의해 주로 영향을 받습니다. 데이터에 수행해야 하는 작업이 더 많으면 백엔드가 결과를 계산하는 데 더 많은 컴퓨팅을 사용해야 합니다. 그러나 일부 작업이 다른 작업보다 훨씬 비용이 많이 들기 때문에 작업을 추가하고 전체 사용량을 줄일 수 있습니다 (예: 비싼 작업 앞에 필터 추가).
데이터에 대한 작업 수는 Contour 경로의 보드 수에 영향을 받습니다. 경로에서 더 아래쪽에 있는 보드는 경로에서 더 이른 시점의 보드로부터 결과물을 사용합니다. 경로에 새 보드를 추가하면 경로를 통해 전송되는 데이터가 변경되어 보드를 다시 계산하고 더 많은 컴퓨팅이 필요합니다.
더 많은 Contour 사용자가 있으면 쿼리가 늘어나면서 더 많은 컴퓨팅이 발생할 수 있습니다. 그러나 Contour에는 여러 사용자에 의한 컴퓨팅 사용량을 줄이는 두 가지 기능이 있습니다: 체크포인트와 캐싱.
분석 및 입력 데이터셋을 최적화하면 비용과 분석 시간을 줄일 수 있습니다. Contour 최적화에 대해 더 알아보기.
Contour는 Code Repositp와 같은 플랫폼의 다른 Spark 기반 제품과 동일한 Spark 측정 원칙 하에서 작동합니다. 비용 기반 라우팅을 사용하여 Contour는 데이터 크기와 쿼리 유형의 요구 사항을 효율적으로 충족하기 위해 백엔드 드라이버와 실행기의 크기를 자동으로 최적화합니다.
예제 Contour 드라이버 크기:
num_vcpu: 2 # 가상 CPU 개수
gib_ram: 11 # 기가바이트 RAM 용량
예제 Contour 실행자 크기:
num_vcpu: 2 # 가상 CPU 개수
gib_ram: 12 # 기가바이트 RAM 용량
num_executors: 3 # 실행자 개수
쿼리 실행 시간: 3초
인터랙티브 Contour 사용률: 15
# 드라이버의 계산 시간(초) = 인터랙티브 사용률 * 드라이버 계산 시간(초)
driver_compute_seconds = interactive_usage_rate * driver_compute_seconds
= 15 * max(2vcpu, 11gib / 7.5gib) * 3sec
= 15 * 2 * 3 = 90 계산-초
# 실행자의 계산 시간(초) = 인터랙티브 사용률 * 실행자 계산 시간(초)
executor_compute_seconds = interactive_usage_rate * executor_compute_seconds
= 15 * max(2vcpu, 12gib / 7.5gib) * 3sec * 3executors
= 15 * 2 * 3 * 3 = 270 계산-초
# 전체 계산 시간(초) = 드라이버 계산 시간(초) + 실행자 계산 시간(초)
total_compute_seconds = driver_compute_seconds + executor_compute_seconds
= 90 계산-초 + 270 계산-초 = 360 계산-초