작업 소개

작업은 다음 유형의 SQL 코드 중 하나를 실행할 수 있습니다.

작업을 테이블 스트림 과 결합하여 최근에 변경된 테이블 행을 처리하는 지속적인 ELT 워크플로를 만들 수 있습니다. 스트림은 테이블의 새 데이터 또는 변경된 데이터에 대해 정확히 한 번 의미를 보장합니다.

작업을 독립적으로 사용하여 보고서 테이블에 행을 삽입하거나 병합하여 정기적인 보고서를 생성하거나 기타 정기적인 작업을 수행할 수도 있습니다.

이 항목의 내용:

컴퓨팅 리소스

작업에서는 SQL 코드 실행을 위한 컴퓨팅 리소스가 필요합니다. 개별 작업에 대해 다음 컴퓨팅 모델 중 하나를 선택할 수 있습니다.

  • Snowflake 관리(즉, 서버리스 컴퓨팅 모델)

  • 사용자 관리(즉, 가상 웨어하우스)

서버리스 작업

작업을 위한 서버리스 컴퓨팅 모델을 사용하면 사용자 관리 가상 웨어하우스 대신 Snowflake에서 관리하는 컴퓨팅 리소스에 의존할 수 있습니다. 컴퓨팅 리소스는 자동으로 크기가 조정되며, 필요한 경우 Snowflake가 각 워크로드에 대하여 확장하거나 축소합니다. Snowflake는 동일한 작업의 가장 최근 실행에 대한 통계의 동적 분석을 기반으로 주어진 실행에 대한 컴퓨팅 리소스의 이상적인 크기를 결정합니다. 서버리스 작업 실행의 최대 크기는 XXLARGE 웨어하우스에 해당하는 크기입니다. 계정의 여러 워크로드가 공통 컴퓨팅 리소스 세트를 공유합니다.

작업을 만들 때 서버리스 컴퓨팅 모델을 사용하는 옵션을 지정해야 합니다. CREATE TASK 구문은 사용자 관리 가상 웨어하우스에 의존하는 작업과 거의 똑같습니다. WAREHOUSE 매개 변수를 생략하면 Snowflake가 작업에 대한 컴퓨팅 리소스를 관리할 수 있습니다. CREATE TASK 명령을 실행하는 역할은 전역 EXECUTE MANAGED TASK 권한이 있어야 합니다. 작업의 액세스 제어 요구 사항에 대한 자세한 내용은 작업 보안 섹션을 참조하십시오.

서버리스 작업 실행 요금 청구는 컴퓨팅 리소스를 위해 웨어하우스에 의존하는 작업의 표준 크레딧 소비 모델과 다소 다릅니다. 자세한 내용은 작업 실행 요금 청구 섹션을 참조하십시오.

참고

서버리스 작업은 다음 오브젝트 유형과 함수를 호출할 수 없습니다.

  • Java 또는 Python 코드를 포함한 UDF(사용자 정의 함수).

  • Scala(Snowpark 사용)로 작성되거나 Java 또는 Python 코드가 포함된 UDF를 호출하는 저장 프로시저.

사용자 관리 작업

원한다면 다른 방법으로서, 작업을 만들 때 기존 가상 웨어하우스를 지정하여 개별 작업의 컴퓨팅 리소스를 관리할 수도 있습니다. 이 옵션을 사용하려면 작업에 의해 실행되는 SQL 동작에 알맞은 크기의 웨어하우스를 선택해야 합니다.

웨어하우스 크기 선택하기

기존 웨어하우스를 사용하여 개별 작업을 위한 컴퓨팅 리소스를 제공하도록 선택한 경우 웨어하우스 고려 사항 에 설명된 모범 사례를 따르는 것이 좋습니다. 웨어하우스 크기 및 클러스터링을 기반으로 특정 웨어하우스를 사용하여 단일 작업 또는 작업의 DAG 에 대한 평균 실행 시간을 분석하는 것이 좋습니다(또는 DAG).

(SNOWFLAKE 공유 데이터베이스에서) TASK_HISTORY Account Usage 뷰 를 쿼리합니다. 작업에 대해 예약된 시간과 완료된 시간 간의 평균 차이는 작업이 큐에 있는 기간을 포함하여 작업의 예상 평균 실행 시간입니다. 다른 프로세스가 현재 웨어하우스의 모든 컴퓨팅 리소스를 사용하고 있을 때 작업이 큐에 추가됩니다.

작업에 대해 정의된 SQL 문을 최적화할 수 없는 경우(문을 다시 작성하거나 저장 프로시저를 사용하여), 이는 작업(또는 DAG)에 대한 예상 평균 실행 시간이 됩니다. 작업(또는 DAG)이 이 윈도우 내에서 실행을 완료할 수 있도록 분석을 기반으로 웨어하우스에 적합한 크기를 선택합니다.

다음 다이어그램은 단일 작업이 20초 동안 대기한 다음 40초 동안 실행된 1분의 윈도우를 보여줍니다.

Example task batch window

다음 다이어그램은 각 실행을 완료하는 데 평균 5분이 필요한 DAG를 보여줍니다. 다이어그램은 완료할 DAG의 2회 실행에 대한 창을 보여줍니다. 이 창은 루트 작업이 시작되도록 예약된 시간부터 DAG의 마지막 하위 작업 실행이 완료될 때까지 계산됩니다. 이 예에서는 DAG의 3가지 작업 각각이 실행되는 동안 큐에 추가된 다른 동시 작업과 DAG가 공유됩니다. 이러한 동시 작업은 DAG의 각 작업 실행이 완료되고 다음 작업 실행이 시작되기 전에 사용 가능한 모든 리소스를 소비합니다. 결과적으로, 각 작업의 윈도우에는 다른 작업이 완료되고 컴퓨팅 리소스를 해제할 때까지 대기하는 동안 약간의 큐가 포함됩니다.

이 DAG가 전용 웨어하우스에서 실행되는 경우에도 선행 작업의 실행이 완료되고 모든 하위 작업이 실행된 이후에 짧은 지연이 발생할 것으로 예상되지만, 다른 작업과 공유된 리소스를 위한 큐는 발생하지 않습니다. 선택한 웨어하우스 크기는 선행 작업에 의해 동시에 트리거되는 여러 하위 작업을 수용할 수 있을 만큼 커야 합니다.

Example DAG batch window

컴퓨팅 모델 선택 권장 사항

다음 표에서는 서버리스 작업과 사용자 관리 작업을 사용할 시점을 결정하는 데 도움이 될 수 있는 다양한 요소를 설명합니다.

카테고리

서버리스 작업

사용자 관리 작업

참고

동시 작업 워크로드의 수, 지속 기간, 예측 가능성

너무 적은 수의 작업이 동시에 실행되거나 실행 후 (1분 이내에) 빠르게 완료되므로 웨어하우스를 완전히 활용할 수 없을 때 권장됩니다.

선택한 컴퓨팅 리소스의 크기는 이전 실행의 기록을 기반으로 하므로 비교적 안정적인 실행이 있는 작업이 서버리스 작업의 좋은 후보입니다.

사용 가능한 컴퓨팅 리소스를 활용하기 위해 동시 작업을 여러 개 예약하여 단일 웨어하우스를 완전히 활용할 수 있을 때 권장됩니다.

컴퓨팅 리소스에 대한 부하가 급증하거나 예측할 수 없을 때도 권장됩니다. 자동 일시 중단 및 자동 재개 가 활성화된 멀티 클러스터 웨어하우스 는 크레딧 소비를 조정하는 데 도움이 될 수 있습니다.

서버리스 작업의 경우 Snowflake는 실제 컴퓨팅 리소스 사용량을 기준으로 계정에 대한 요금을 청구합니다.

반대로, 사용자 관리 웨어하우스에 대한 요금 청구는 웨어하우스 크기를 기준으로 하며, 사용한 컴퓨팅 리소스에 관계없이 웨어하우스가 재개될 때마다 60초 이상 소요됩니다.

예약 간격

예약 간격 준수가 매우 중요할 때 권장됩니다.

독립 실행형 작업 또는 예약된 DAG의 실행이 이 간격을 거의 모두 초과하는 경우 Snowflake는 컴퓨팅 리소스의 크기를 늘립니다(최대 2X-Large 웨어하우스에 해당하는 크기까지).

예약 간격 준수가 덜 중요할 때 권장됩니다.

예약 간격 은 DAG에서 독립 실행형 작업 또는 루트 작업의 연속적인 예약 실행 간 시간 간격을 나타냅니다.

컴퓨팅 리소스를 늘리면 전부는 아니지만 일부 SQL 코드의 실행 시간이 단축되고 배치 윈도우 내에서 작업 실행이 완료되도록 보장하기에 충분하지 않을 수 있습니다.

서버리스 작업 실행의 최대 크기는 XXLARGE 웨어하우스에 해당하는 크기라는 점의 유의하십시오. 더 큰 웨어하우스가 필요한 작업 워크로드인 경우 필요한 크기의 웨어하우스를 참조하는 사용자 관리 작업을 만듭니다.

작업 일정 예약

독립 실행형 작업 또는 DAG의 루트 작업은 일반적으로 일정에 따라 실행됩니다. (CREATE TASK를 사용해) 작업을 생성하거나 (ALTER TASK 를 사용해) 나중에 생성하도록 일정을 정의할 수 있습니다.

Snowflake는 일정이 있는 작업(즉, 독립 실행형 작업 또는 DAG의 루트 작업)의 인스턴스 하나만 지정된 시간에 실행되도록 합니다. 다음으로 예약된 실행 시간이 발생할 때 작업이 계속 실행 중이면 예약된 시간을 건너뜁니다.

Snowflake는 서버리스 작업을 위해 자동으로 컴퓨팅 리소스의 크기를 조정하고 확장합니다. 웨어하우스에 의존해 컴퓨팅 리소스를 제공하는 작업의 경우, 주어진 작업이 정해진 일정 내에 워크로드를 완료하도록 적절한 웨어하우스 크기를 선택합니다. 자세한 내용은 이 항목의 웨어하우스 크기 선택하기 를 참조하십시오.

작업 예약 및 일광 절약 시간제

작업 정의의 cron 식은 타임존 지정을 지원합니다. 예약된 작업은 지정된 타임존의 현지 시간으로 지정된 cron 식에 따라 실행됩니다. 일광 절약 시간제를 인식하는 타임존의 작업 예약과 관련하여 특별한 주의를 기울여야 합니다. 표준 시간에서 일광 절약 시간제(또는 그 반대로)로 전환되는 날의 특정 시간에 예약된 작업에서는 예기치 않은 동작이 수행될 수 있습니다.

예:

  • 일광 절약 시간제에서 표준 시간으로 변경되는 가을 동안 미국/로스_앤젤레스 타임존(즉, 0 1 * * * America/Los_Angeles)의 1 AM에 시작이 예약된 작업은 1 AM에 한 번 실행된 후 1:59:59 AM이 현지 시간 1:00:00 AM으로 변경될 때 다시 실행되어 두 번 실행됩니다. 즉, 현지 시간이 1 AM인 시점이 2개 있습니다.

  • 표준 시간에서 일광 절약 시간제로 봄철 변경 기간 동안에는 현지 시간이 AM 1:59:59에서 AM 3:00:00로 변경되므로 미국/로스_앤젤레스 타임존(즉, 0 2 * * * America/Los_Angeles) AM 2시에 시작하도록 예약된 작업은 전혀 실행되지 않습니다. 즉, 해당 날짜에는 현지 시간으로 AM 2시에 해당하는 시간이 없습니다.

일광 절약 시간제로 인한 예기치 않은 작업이 실행되지 않도록 하려면 다음 중 1개를 실행합니다.

  • AM 1시 ~ AM 3시 사이의 특정 시간에 작업이 실행(매일 또는 일요일이 포함된 주의 날에)되도록 예약하지 마십시오. 또는

  • 일광 절약 시간제로 인한 시간 변경을 보상하기 위해 매년 두 번 해당 시간에 예약된 작업에 대한 cron 식을 수동으로 조정합니다.

작업의 DAG

방향성 비순환 그래프(DAG)는 단일 루트 작업과 종속성을 기준으로 구성되는 추가 작업으로 이루어진 일련의 작업입니다. DAG는 단일 방향으로 흐르는데, 이는 곧 연속되는 작업에서 이후 작업은 이전 작업의 실행을 유발할 수 없다는 뜻입니다(즉, 루프). 각 작업(루트 작업 제외)에는 여러 선행 작업(종속 항목)이 있을 수 있으며, 이와 마찬가지로 각 작업에는 그에 종속된 여러 후속(하위) 작업이 있을 수 있습니다. 작업은 그 작업에 선행하는 작업이 전부 성공적으로 실행 완료된 후에만 실행됩니다.

루트 작업에는 DAG의 실행을 시작하는 정의된 일정이 있어야 합니다. 다른 각 작업에는 DAG의 작업을 연결하기 위해 정의된 선행 작업이 하나 이상 있습니다. 하위 작업은 그 작업에 선행하는 작업이 전부 성공적으로 실행 완료된 후에만 실행됩니다.

새 작업을 생성할 때(CREATE TASK … AFTER 사용) 또는 이후에(ALTER TASK … ADD AFTER 사용) 선행 작업을 지정할 수 있습니다. DAG는 최대 총 1,000개의 작업으로 제한됩니다(루트 작업 포함). 단일 작업에는 최대 100개의 선행 작업과 100개의 하위 작업이 있을 수 있습니다.

다음 기본 예에서는 루트 작업이 작업 B와 C가 동시에 실행되도록 합니다. 작업 D는 작업 B와 C가 모두 실행을 완료했을 때 실행됩니다.

Basic DAG example

다음 실제 예에서는 DAG를 사용하여 판매 데이터베이스의 차원 테이블을 업데이트한 후 팩트 데이터를 집계하는 방법을 보여줍니다.

Sales database DAG example

추가 예에서는 원격 메시징 서비스가 이전의 작업이 전부 성공적으로 실행 완료되었다는 알림을 보내도록 트리거하는 외부 함수를 호출하는 DAG의 종결 작업을 보여줍니다.

Cloud messaging notification DAG example

작업 소유권

DAG의 모든 작업은 작업 소유자가 같고(즉, 단일 역할이 모든 작업에 대한 OWNERSHIP 권한을 가져야 함) 동일한 데이터베이스 및 스키마에 저장되어야 합니다.

작업 소유권을 이전하면 이 작업과 모든 선행 작업 및 하위 작업 사이의 종속성이 단절됩니다. 자세한 내용은 이 항목의 선행 작업과 하위 작업 사이에서 단절된 링크 를 참조하십시오.

다음 활동 중 하나를 통해 DAG의 모든 작업 소유권이 한 번에 이전되면 DAG의 모든 작업 간의 관계가 유지됩니다.

  • DAG를 구성하는 모든 작업의 현재 소유자가 삭제됩니다(DROP ROLE 사용). 삭제된 역할이 소유한 오브젝트의 소유권은 DROP ROLE 명령을 실행하는 역할로 이전됩니다.

  • DAG를 구성하는 모든 작업의 소유권은 명시적으로 다른 역할로 이전됩니다(예: 스키마의 모든 작업에 대해 GRANT OWNERSHIP 실행).

DAG 중복 실행

기본적으로 Snowflake는 특정 DAG의 인스턴스가 한 번에 1개만 실행하는 것을 허용합니다. DAG에 있는 모든 작업의 실행이 완료된 후에만 루트 작업의 다음 실행이 예약됩니다. 이는 DAG의 모든 작업을 실행하는 데 필요한 누적 시간이 루트 작업의 정의에 설정된 명시적인 예약 시간을 초과할 경우 DAG의 실행을 한 번 이상 건너뛴다는 의미입니다. 동작은 루트 작업의 ALLOW_OVERLAPPING_EXECUTION 매개 변수에 의해 제어되며, 기본값은 FALSE입니다. 매개 변수 값을 TRUE로 설정하면 DAG 실행을 중첩할 수 있습니다.

또한 하위 작업은 그 작업의 모든 선행 작업이 자체 실행을 성공적으로 완료한 후에만 실행을 시작합니다. 시간 집약적인 SQL 작업을 실행하는 작업은 해당 작업을 선행 작업으로 식별하는 하위 작업의 시작을 지연시킵니다.

다음 예에서 DAG 실행은 이전 실행이 아직 완료되지 않았을 때 시작되도록 예약됩니다. 빨간색으로 표시된 부분은 중복되거나 동시 실행이 발생하는 기간입니다. 또한, 이 다이어그램은 사용자 관리 웨어하우스에서 각 작업이 실행되기 전에 큐에서 대기한 기간을 보여줍니다. Snowflake 관리 컴퓨팅 리소스를 사용할 경우 큐 기간이 없습니다.

Overlapping DAG runs

DAG의 중복 실행으로 인해 실행되는 SQL 읽기/쓰기 작업이 잘못된 데이터 또는 복제된 데이터를 생성하지 않으면 중복 실행이 허용되거나 권장될 수도 있습니다. 하지만 다른 DAG의 경우, 작업 소유자(DAG의 모든 작업에 대한 OWNERSHIP 권한을 가진 역할)가 루트 작업 실행 예약을 올바르게 설정하고 적절한 웨어하우스 크기를 선택(또는 Snowflake 관리 컴퓨팅 리소스를 사용)하여 루트 작업의 다음 실행이 예약되기 전에 DAG의 인스턴스가 완료되도록 해야 합니다.

루트 작업에 정의된 일정과 DAG를 더 잘 정렬하려면:

  1. 가능한 경우, 루트 작업 실행 간격의 예약 시간을 늘립니다.

  2. Snowflake 관리 컴퓨팅 리소스를 사용하도록 컴퓨팅 집약적 작업을 수정해 보십시오. 작업이 사용자 관리 컴퓨팅 리소스에 의존하는 경우 DAG에 있는 복잡하거나 대규모 SQL 문 또는 저장 프로시저를 실행하는 웨어하우스 크기를 늘리십시오.

  3. 각 작업이 실행하는 SQL 문 또는 저장 프로시저를 분석합니다. 코드를 다시 작성하여 병렬 처리를 활용할 수 있는지 파악합니다.

위에 설명한 방법으로도 해결되지 않으면, 루트 작업에서 ALLOW_OVERLAPPING_EXECUTION = TRUE로 설정하여 DAG의 동시 실행을 허용할 수도 있습니다. 이 매개 변수는 작업(CREATE TASK 사용) 또는 이후(ALTER TASK 사용)를 만들 때 정의할 수 있습니다.

DAG에서 종속 작업 보기

DAG에서 루트 작업에 대한 직접 하위 작업 또는 모든 작업을 보는 방법은 다음과 같습니다.

SQL

Snowflake Information SchemaTASK_DEPENDENTS 테이블 함수를 쿼리합니다. DAG의 모든 작업을 검색하려면 함수를 호출할 때 루트 작업을 입력하십시오. 하위 작업을 입력하면 이 함수는 지정된 작업의 하위 작업과 그러한 하위 작업의 하위 작업 등을 반환합니다.

일시 중단된 하위 작업을 사용한 DAG 실행

루트 작업이 일시 중단되면 ALTER TASK … RESUME | SUSPEND를 사용하여 하위 작업을 재개하거나 일시 중단할 수 있습니다. 루트 작업을 재개하기 전에 일시 중단된 하위 작업을 재개할 필요는 없습니다.

DAG가 하나 또는 그 이상의 일시 중단된 하위 작업과 함께 실행 시에는 그와 같은 작업이 무시됩니다. 여러 선행 작업이 있는 하위 작업은 선행 작업 중 하나 이상 이 재개된 상태에 있고 재개된 선행 작업이 전부 성공적으로 실행 완료되는 한 실행됩니다.

DAG에서 일시 중단된 작업 재개하기

DAG의 모든 작업을 재귀적으로 재개하려면 각 작업을 개별적으로 재개하는 대신 SYSTEM$TASK_DEPENDENTS_ENABLE 함수를 쿼리하십시오(ALTER TASK … RESUME 사용).

실행 버전 관리

독립 실행형 작업 또는 DAG의 루트 작업이 처음 다시 시작되거나 EXECUTE TASK 를 사용하여 수동으로 실행되면 작업의 초기 버전이 설정됩니다. 작업이 루트 작업인 경우, DAG의 모든 작업에 대한 모든 속성 등 전체 DAG의 버전이 설정됩니다. 독립 실행형 작업 또는 DAG는 이 버전을 사용하여 실행됩니다. 작업이 일시 중단 및 수정된 후 독립 실행형 또는 루트 작업이 다시 시작되거나 수동으로 실행될 때 새 버전이 설정됩니다.

DAG에서 작업을 수정하거나 다시 생성하려면 우선 루트 작업을 일시 중단해야 합니다(ALTER TASK … SUSPEND 사용). 루트 작업이 일시 중단되면, 향후 예약된 모든 루트 작업 실행이 취소됩니다. 하지만 현재 실행 중인 작업(EXECUTING 상태의 작업)이 있을 경우, 해당 작업과 하위 작업은 현재 버전을 사용해 계속 실행됩니다.

참고

DAG가 실행되고 있는 동안 작업이 호출한 저장 프로시저의 정의가 변경되는 경우, 현재 실행 상태에 있는 작업이 저장 프로시저를 호출할 때 새 프로그래밍을 실행할 수 있습니다.

예를 들어 DAG의 루트 작업이 일시 중단되었지만 이 작업의 예약된 실행이 이미 시작되었다고 가정하겠습니다. 루트 작업이 여전히 실행되는 동안 DAG에 있는 모든 작업의 소유자는 하위 작업이 호출한 SQL 코드를 수정합니다. 하위 작업은 루트 작업이 실행을 시작할 때 최신이었던 버전의 DAG를 사용하여 정의에 있는 SQL 코드를 실행합니다. 루트 작업이 다시 시작되거나 수동으로 실행된 후의 새 DAG 버전이 설정됩니다. 이 새 버전에는 하위 작업에 대한 수정 사항이 포함됩니다.

작업 버전 기록을 검색하려면 SNOWFLAKE 공유 데이터베이스에서 TASK_VERSIONS Account Usage 뷰 를 쿼리하십시오.

태스크에 대한 세션 매개 변수 설정하기

작업이 실행되는 세션에 대한 세션 매개 변수를 설정할 수 있습니다. 이를 수행하려면 기존 작업을 수정하고 원하는 매개 변수 값을 설정합니다(ALTER TASKSET session_parameter = value[, session_parameter = value ... ] 사용).

작업은 모든 세션 매개 변수를 지원합니다. 전체 목록은 매개 변수 를 참조하십시오.

작업에서는 계정이나 사용자 매개 변수가 지원되지 않음 에 유의하십시오.

실행 실패 후 작업 자동 일시 중단

선택적으로, 지정된 횟수의 연속 실행이 실패하거나 시간 초과되면 작업을 자동으로 일시 중단합니다. 이 기능을 사용하면 Snowflake 크레딧을 소비하지만 완료에 실행 완료에 실패하는 작업을 일시 중단함으로써 비용을 절감할 수 있습니다. 실패한 작업 실행에는 작업 본문의 SQL 코드가 사용자 오류를 생성하거나 시간 초과되는 실행이 포함됩니다. 건너뛰거나 취소되거나 시스템 오류로 인해 실패하는 작업 실행은 쉽게 가늠할 수 없는 것으로 생각되어 실패한 작업 실행 수에는 포함하지 않습니다.

독립 실행형 작업 또는 DAG에서 루트 작업에 대한 SUSPEND_TASK_AFTER_FAILURES = num 매개 변수를 설정합니다. 매개 변수가 0 보다 큰 값으로 설정되면 독립 실행형 작업 또는 DAG의 실행에 다음 동작이 적용됩니다.

  • 독립 실행형 작업은 연속 작업 실행이 지정된 횟수만큼 실패하거나 시간 초과되면 자동으로 일시 중단됩니다.

  • 루트 작업은 DAG에서 임의의 단일 작업 실행이 실패하거나 연속 실행에서 지정된 횟수만큼 시간 초과되면 자동으로 일시 중단됩니다.

이 매개 변수는 작업을 만들거나(CREATE TASK 사용) 이후에 만들 때(ALTER TASK 사용) 설정할 수 있습니다. 설정은 Snowflake 관리 컴퓨팅 리소스(예: 서버리스 컴퓨팅 모델) 또는 사용자 관리 컴퓨팅 리소스(즉, 가상 웨어하우스)에 의존하는 작업에 적용됩니다.

SUSPEND_TASK_AFTER_NUM_FAILURES 매개 변수는 계정, 데이터베이스 또는 스키마 수준에서도 설정할 수 있습니다. 이 설정은 모든 독립 실행형 작업 또는 수정된 오브젝트에 포함된 루트 작업에 적용됩니다. 매개 변수를 더 낮은(즉, 더 세분화된) 수준에서 명시적으로 설정하면 더 높은 수준에서 설정된 매개 변수 값이 재정의됩니다.

수동으로 작업 실행하기

EXECUTE TASK 명령은 작업에 대해 정의된 일정과 무관하게 예약된 작업(독립형 작업 또는 DAG의 루트 작업)의 실행을 1회 수동으로 트리거합니다. 루트 작업을 성공적으로 실행하면 마치 루트 작업이 정의된 일정에 따라 실행된 것처럼, DAG의 하위 작업은 선행 작업이 완료될 때 계단식 실행이 트리거됩니다.

이 SQL 명령은 프로덕션에서 신규 또는 수정된 독립 실행형 작업과 DAG가 SQL 코드를 실행하도록 활성화하기 전에 이들을 테스트하는 데 유용합니다.

스크립트나 저장 프로시저에서 이 SQL 명령을 직접 호출합니다. 또한 이 명령은 외부 데이터 파이프라인에서 작업 통합을 지원합니다. Snowflake 계정을 인증하고 SQL 작업을 승인할 수 있는 모든 서드 파티 서비스는 EXECUTE TASK 명령을 실행하여 작업을 실행할 수 있습니다.

참고

미리 보기 기능으로 지원됩니다.

계정의 작업 로드 내역 보기

다음 역할(또는 지정된 권한이 있는 역할)은 SQL을 사용하여 지정된 날짜 범위 내의 작업 기록을 볼 수 있습니다.

  • 계정 관리자(즉, ACCOUNTADMIN역할이 있는 사용자).

  • 작업 소유자(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할).

  • 전역 MONITOR EXECUTION 권한이 있는 모든 역할.

단일 작업의 실행 기록을 보는 방법은 다음과 같습니다.

SQL

Snowflake Information SchemaTASK_HISTORY 테이블 함수를 쿼리합니다.

현재 예약되었거나 실행 중인 DAG 실행에 대한 세부 정보를 보는 방법은 다음과 같습니다.

SQL

Snowflake Information SchemaCURRENT_TASK_GRAPHS 테이블 함수를 쿼리합니다.

지난 60분 동안 성공, 실패 또는 취소된 DAG 실행의 세부 정보를 보는 방법은 다음과 같습니다.

SQL

Snowflake Information SchemaCOMPLETE_TASK_GRAPHS 테이블 함수를 쿼리합니다.

(Account Usage 에서) COMPLETE_TASK_GRAPHS 뷰 뷰를 쿼리합니다.

작업 실행 요금 청구

SQL 코드 실행을 위한 작업 수행과 관련된 비용은 작업을 위한 컴퓨팅 리소스의 출처에 따라 다릅니다.

사용자 관리 웨어하우스

Snowflake는 클라이언트 또는 Snowflake 웹 인터페이스에서 같은 SQL 문을 실행하기 위한 웨어하우스 사용량과 유사하게, 작업이 실행되는 동안의 웨어하우스 사용량을 기준으로 크레딧 사용 에 대해 계정에 요금을 청구합니다. 초당 크레딧 청구 및 웨어하우스 자동 일시 중단을 사용하여 더 큰 웨어하우스 크기로 시작한 후 작업 워크로드에 따라 크기를 조정할 수 있는 유연성이 제공됩니다.

Snowflake 관리 리소스(즉, 서버리스 컴퓨팅 모델)

Snowflake는 실제 컴퓨팅 리소스 사용량을 기준으로 계정에 요금을 부과하며, 이는 활성 상태일 때 크레딧이 사용되어 유휴 상태가 되거나 과도하게 사용될 수 있는 고객 관리 가상 웨어하우스와 다릅니다. 요금은 컴퓨팅 시간 크레딧 사용으로 측정되는 리소스 총 사용량(클라우드 서비스 사용량 포함)에 따라 계산됩니다.

Snowflake는 작업 기록에서 작업 실행을 분석하여 동적으로 컴퓨팅 리소스의 이상적인 크기를 결정하고, 이러한 컴퓨팅 리소스를 일시 중단하여 비용을 절감합니다. Snowflake는 부하 용량을 관리하여 수요를 충족하는 최적의 컴퓨팅 리소스를 보장합니다. Snowflake 제공 컴퓨팅 리소스의 관리 비용을 회수하기 위해, 리소스 소비에 1.5배의 배율 을 적용합니다. 하지만 서버리스 컴퓨팅 모델은 여전히 ​​사용자 관리 웨어하우스에 비해 컴퓨팅 비용을 줄일 수 있고, 경우에 따라 그 절감 효과가 상당한 수준입니다.

컴퓨팅 시간당 청구되는 Snowflake 크레딧:

  • Snowflake 관리 컴퓨팅 리소스: 1.5

  • 클라우드 서비스: 1

요금 청구 는 테이블의 자동 클러스터링, 데이터베이스 복제 및 장애 조치/장애 복구, Snowpipe 등의 다른 Snowflake 기능과 유사합니다.

특정 작업에 대한 현재 크레딧 사용을 검색하려면 SERVERLESS_TASK_HISTORY 테이블 함수를 쿼리하십시오. 작업 소유자(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)로서 다음 문을 실행합니다.

SET num_credits = (SELECT SUM(credits_used)
  FROM TABLE(<database_name>.information_schema.serverless_task_history(
    date_range_start=>dateadd(D, -1, current_timestamp()),
    date_range_end=>dateadd(D, 1, current_timestamp()),
    task_name => '<task_name>')
    )
  );

여기서:

<데이터베이스_이름>

작업을 포함하는 데이터베이스의 이름입니다.

<작업_이름>

작업의 이름입니다.

모든 서버리스 작업에 대한 현재 크레딧 사용을 검색하려면 SERVERLESS_TASK_HISTORY 뷰를 쿼리하십시오. 계정 관리자(즉, ACCOUNTADMIN 역할을 가진 사용자)로서 다음 문을 실행합니다.

SELECT START_TIME, END_TIME, TASK_ID, TASK_NAME, CREDITS_USED, SCHEMA_ID, SCHEMA_NAME, DATABASE_ID, DATABASE_NAME
  FROM snowflake.account_usage.serverless_task_history
  ORDER BY start_time, task_id;

시스템 서비스 이해하기

Snowflake는 작업 소유자의 권한(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)으로 작업을 실행하지만 작업 실행은 사용자와 연결되지 않습니다. 대신 각 실행은 시스템 서비스에 의해 실행됩니다. 작업은 특정 사용자와 분리되어 사용자가 삭제되거나 인증 문제로 인해 잠기거나 역할이 제거될 때 발생할 수 있는 복잡성을 방지합니다.

작업 실행은 사용자와 분리되기 때문에 작업 실행에 대한 쿼리 기록은 시스템 서비스와 연결됩니다. SYSTEM은 계정의 사용자가 아니며, 숨은 서비스입니다. 따라서 이 서비스에 대한 사용자 자격 증명이 없으며 개별 사용자(Snowflake 또는 사용자 계정의)는 사용자 ID를 가정할 수 없습니다. 시스템 서비스에 대한 활동은 사용자의 계정으로 제한됩니다. 다른 작업에 적용되는 것과 동일한 암호화 보호 및 기타 보안 프로토콜이 이 서비스에 내장되어 있습니다.

작업 DDL

작업의 생성 및 관리를 지원하기 위해 Snowflake가 제공하는 특수 DDL 명령 세트는 다음과 같습니다.

또한, 공급자는 다음과 같은 표준 액세스 제어 DDL을 사용하여 ELT에 필요한 데이터베이스 오브젝트에 대한 액세스를 확인, 권한 부여 또는 취소할 수 있습니다.

작업 함수

작업에 대한 정보 검색을 지원하기 위해 Snowflake는 다음과 같은 SQL 기능 세트를 제공합니다.

작업 보안

액세스 제어 권한

작업 만들기

작업을 만들려면 최소한으로 다음의 권한이 있는 역할이 필요합니다.

오브젝트

권한

참고

계정

EXECUTE MANAGED TASK

Snowflake 관리 컴퓨팅 리소스(서버리스 컴퓨팅 모델)에 의존하는 작업을 만들 때만 필요합니다.

데이터베이스

USAGE

스키마

USAGE, CREATE TASK

웨어하우스

USAGE

컴퓨팅 리소스를 위해 사용자 관리 웨어하우스에 의존하는 작업에만 필요합니다.

작업 소유하기

작업이 생성된 후 작업 소유자(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)에는 다음 권한이 있어야 합니다.

오브젝트

권한

참고

계정

EXECUTE TASK

역할이 소유한 모든 작업을 실행하기 위해 필요합니다. 역할에 대한 EXECUTE TASK 권한을 취소하면 모든 후속 작업이 해당 역할에서 시작되지 않습니다.

계정

EXECUTE MANAGED TASK

Snowflake 관리 컴퓨팅 리소스에 의존하는 작업을 만들 때만 필요합니다.

데이터베이스

USAGE

스키마

USAGE

작업

OWNERSHIP

웨어하우스

USAGE

또한 역할은 작업에서 실행되는 SQL 문을 실행하기 위해 필요한 권한이 있어야 합니다.

작업 다시 시작 또는 일시 중단하기

작업 소유자 외에도 작업에 대한 OPERATE 권한이 있는 역할은 작업을 일시 중단하거나 재개할 수 있습니다. 이 역할은 작업을 포함하는 데이터베이스 및 스키마에 대한 USAGE 권한이 있어야 합니다. 다른 권한은 필요하지 않습니다.

작업이 재개되면 Snowflake는 작업 소유자 역할에 이 항목의 작업 소유 에 나열된 권한이 있는지 확인합니다.

작업 관리자 역할 만들기

사용 편의성을 위해, 사용자 지정 역할(예: taskadmin)을 만들고 이 역할에 EXECUTE TASK 권한을 할당하는 것이 좋습니다. 권한을 부여할 수 있는 모든 역할(예: SECURITYADMIN 또는 MANAGE GRANTS 권한을 가진 역할)은 이 사용자 지정 역할을 작업 소유자 역할에 부여하여 자체 작업을 변경하도록 허용할 수 있습니다. 작업 소유자 역할이 작업을 실행할 수 있는 기능을 제거하려면 작업 소유자 역할에서 이 사용자 지정 역할을 취소하기만 하면 됩니다. 이 사용자 지정 역할을 생성하지 않도록 선택하는 경우 계정 관리자는 작업 소유자 역할에서 EXECUTE TASK 권한을 취소해야 합니다.

예를 들어, 사용자 지정 역할 이름 taskadmin 을 만들고 해당 역할에 EXECUTE TASK 권한을 부여합니다. taskadmin 역할을 myrole 이라는 작업 소유자 역할에 할당합니다.

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;

-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

사용자 지정 역할 및 역할 계층 구조 생성과 관련한 자세한 내용은 액세스 제어 구성하기 를 참조하십시오.

작업 소유자 역할 삭제하기

지정된 작업의 소유자 역할(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)이 삭제되면 작업은 소유자 역할을 삭제한 역할에 의해 《재소유》됩니다. 이를 통해 소유권이 역할 계층 구조의 루트에 더 가까운 역할로 이동됩니다. 작업이 다시 소유되면 작업이 자동으로 일시 중단됩니다. 즉, 현재 진행 중인 모든 실행이 처리를 완료하지만 새 소유자가 작업을 명시적으로 재개될 때까지 새 실행을 예약할 수 없습니다. 이에 대한 근거는 특정 역할에 대한 액세스 권한이 있는 사용자가 역할이 제거될 때 갑자기 더 높은 권한으로 실행되는 작업을 남겨두는 것을 방지하기 위한 것입니다.

실행 중인 작업이 실행 중인 역할이 작업이 실행되는 동안 삭제되면 작업은 삭제된 역할에서 처리를 완료합니다.

워크플로

이 섹션에서는 작업 설정 워크플로에 대한 높은 수준의 개요를 제공합니다.

  1. 다음 단계의 명령을 실행하는 데 사용할 수 있는 역할을 생성하려면 이 항목의 작업 관리자 역할 만들기 단계를 완료하십시오.

  2. CREATE TASK 사용하여 작업 만들기 작업은 기본적으로 일시 중단됩니다.

    참고

    작업을 생성하기 작업에서 참조할 SQL 문이 예상대로 실행되는지 확인하십시오. 작업은 이미 철저한 테스트를 거친 SQL 문 또는 저장 프로시저를 자동화하는 것이 그 취지입니다.

  3. ALTER TASK … RESUME를 실행하면 작업 정의에 지정된 매개 변수를 기반으로 작업이 실행됩니다.

맨 위로 이동