작업 소개¶

컴퓨팅 리소스¶

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

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

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

사용자 관리 작업¶

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

웨어하우스 크기 선택하기¶

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

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

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

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

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

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

작업 일정 예약¶

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

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

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

작업의 DAG¶

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

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

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

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

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

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

DAG 중복 실행¶

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

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

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

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

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

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

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

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

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

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

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

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

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

독립 실행형 작업 또는 DAG에서 루트 작업에 대한 SUSPEND_TASK_AFTER_NUM_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 또는 Snowsight 를 사용하여 계정의 작업 기록을 볼 수 있습니다. Snowsight 에서 작업 기록을 보려면 Snowsight 의 작업 기록 보기 섹션을 참조하십시오.

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

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

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

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

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

SQL

Snowflake Information Schema 의 TASK_HISTORY 테이블 함수를 쿼리합니다.

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

SQL

Snowflake Information Schema 의 CURRENT_TASK_GRAPHS 테이블 함수를 쿼리합니다.

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

SQL

Snowflake Information Schema 의 COMPLETE_TASK_GRAPHS 테이블 함수를 쿼리합니다.

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

작업 비용¶

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

사용자 관리 웨어하우스

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

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

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

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

작업에서 사용하는 크레딧 수를 알아보려면 Snowflake 서비스 사용 테이블 에서 《서버리스 기능 크레딧 테이블》을 참조하십시오.

요금 청구 는 테이블의 자동 클러스터링, 복제 및 장애 조치/장애 복구, 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>')
    )
  );

Copy

여기서

<데이터베이스_이름>

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

<작업_이름>

작업의 이름입니다.

모든 서버리스 작업에 대한 현재 크레딧 사용을 검색하려면 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 권한이 있는 역할)으로 작업을 실행하지만 작업 실행은 사용자와 연결되지 않습니다. 대신 각 실행은 시스템 서비스에 의해 실행됩니다. 작업은 특정 사용자와 분리되어 사용자가 삭제되거나 인증 문제로 인해 잠기거나 역할이 제거될 때 발생할 수 있는 복잡성을 방지합니다.

작업은 OPERATE 권한이 있는 다른 역할이 EXECUTE TASK를 통해 예약하거나 수동으로 실행하는지 여부에 관계없이 작업 소유자의 권한으로 실행됩니다.

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

작업 DDL¶

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

• CREATE TASK

• ALTER TASK

• DROP TASK

• DESCRIBE TASK

• SHOW TASKS

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

• GRANT <권한>

• REVOKE <권한>

• SHOW GRANTS

작업 함수¶

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

• SYSTEM$CURRENT_USER_TASK_NAME

• TASK_HISTORY

• TASK_DEPENDENTS

작업 보안¶

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;

워크플로¶

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

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

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

   참고

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

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