Snowpark Container Services: SQL 실행¶

자격 증명 구성 옵션¶

Snowflake는 애플리케이션 컨테이너가 SQL을 실행할 때 Snowflake 제공 자격 증명을 사용하여 Snowflake에 인증할 것을 권장합니다. 외부 액세스 통합(EAI)을 통해 연결하여 다른 자격 증명을 사용할 수 있지만, EAI를 통해 연결하면 서비스가 Snowflake 외부에서 실행되고 인터넷을 통해 Snowflake에 연결되는 것처럼 처리됩니다.

서비스 컨테이너에서 Snowflake에 연결하는 3가지 옵션이 있습니다.

• Snowflake 제공 서비스 사용자 자격 증명 사용: Snowflake는 모든 서비스에 서비스 자격 증명이라는 자격 증명을 제공합니다. 서비스는 이러한 자격 증명을 사용하여 서비스 사용자로 Snowflake에 연결합니다.

• Snowflake 제공 호출자 자격 증명(호출자 권한) 사용: 호출자 권한으로 서비스를 구성하는 경우 Snowflake는 서비스가 호출하는 사용자로 Snowflake에 연결하기 위한 자격 증명도 제공합니다.

• 다른 자격 증명 사용: 이 경우에는 외부 액세스 통합(EAI)를 사용하여 유효한 인증 자격 증명을 통해 서비스를 Snowflake의 인터넷 엔드포인트에 연결할 수 있습니다. 이 옵션을 사용하려면 관리자가 EAI를 생성한 후 서비스 소유자 역할에 통합에 대한 USAGE 권한을 부여해야 합니다.

  참고

  외부 액세스 통합을 사용하여 Snowflake에 액세스하는 경우 인터넷을 통해 민감한 정보가 전송될 수 있습니다.

다양한 Snowflake 드라이버를 사용하여 Snowflake에 연결하는 코드의 예제는 `Snowflake 연결 샘플<https://github.com/Snowflake-Labs/sf-samples/tree/main/samples/spcs/sf-connection>`_을 참조하세요.

SNOWFLAKE_ACCOUNT = os.getenv('SNOWFLAKE_ACCOUNT')
SNOWFLAKE_HOST = os.getenv('SNOWFLAKE_HOST')

def get_login_token():
  with open('/snowflake/session/token', 'r') as f:
    return f.read()

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth'
)

ALTER USER my_user SET DEFAULT_SECONDARY_ROLES = ( 'ALL' );

-- Permissions to resolve the table's name.
GRANT CALLER USAGE ON DATABASE <db_name> TO ROLE <service_owner_role>;
GRANT CALLER USAGE ON SCHEMA <schema_name> TO ROLE <service_owner_role>;
-- Permissions to use a warehouse
GRANT CALLER USAGE ON WAREHOUSE <warehouse_name> TO ROLE <service_owner_role>;
-- Permissions to query the table.
GRANT CALLER SELECT ON TABLE T1 TO ROLE <service_owner_role>;

conn = snowflake.connector.connect(
  account = '<acct-name>',
  user = '<user-name>',
  password = '<password>'
)

SQL 실행을 위한 데이터베이스 및 스키마 컨텍스트 구성하기¶

Snowflake는 자격 증명을 제공할 뿐만 아니라 서비스가 생성되는 데이터베이스 및 스키마 컨텍스트도 제공합니다. 컨테이너 코드는 이 정보를 사용하여 서비스와 동일한 데이터베이스 및 스키마 컨텍스트의 SQL을 실행합니다.

이 섹션에서는 다음 두 가지 개념을 설명합니다.

• Snowflake가 서비스를 생성할 데이터베이스와 스키마를 결정하는 데 사용하는 논리.

• Snowflake가 이 정보를 컨테이너에 전달하여 컨테이너 코드가 동일한 데이터베이스 및 스키마 컨텍스트에서 SQL을 실행할 수 있도록 지원하는 방법.

Snowflake는 서비스 이름을 사용하여 서비스를 생성할 데이터베이스와 스키마를 결정합니다.

• 예 1: 다음 CREATE SERVICE 및 EXECUTE JOB SERVICE 명령에서는 서비스 이름에 데이터베이스 및 스키마 이름을 명시적으로 지정하지 않습니다. Snowflake는 현재 데이터베이스와 스키마에서 서비스와 작업 서비스를 생성합니다.

  -- Create a service.
  CREATE SERVICE test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = example_job_service ...
  

  Copy

• 예 2: 다음 CREATE SERVICE 및 EXECUTE JOB SERVICE 명령에서 서비스 이름에는 데이터베이스 및 스키마 이름이 포함됩니다. Snowflake는 현재 스키마에 관계없이 지정된 데이터베이스(test_db)와 스키마(test_schema)에서 서비스와 작업 서비스를 생성합니다.

  -- Create a service.
  CREATE SERVICE test_db.test_schema.test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = test_db.test_schema.example_job_service ...
  

  Copy

Snowflake는 서비스를 시작할 때 다음 환경 변수를 사용하여 실행 중인 컨테이너에 데이터베이스 및 스키마 정보를 제공합니다.

• SNOWFLAKE_DATABASE

• SNOWFLAKE_SCHEMA

컨테이너 코드는 다음 예제와 같이 연결 코드에 환경 변수를 사용하여 사용할 데이터베이스와 스키마를 결정할 수 있습니다.

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth',
  database = os.getenv('SNOWFLAKE_DATABASE'),
  schema = os.getenv('SNOWFLAKE_SCHEMA')
)

예

자습서 2 에서는 Snowflake와 연결하고 SQL 문을 실행하는 Snowflake 작업 서비스를 만듭니다. 다음 단계에서는 자습서 코드가 환경 변수를 사용하는 방법을 요약합니다.

1. 공통 설정(공통 설정 섹션 참조)에서는 데이터베이스와 스키마를 포함한 리소스를 만듭니다. 또한 세션에 대한 현재 데이터베이스와 스키마를 설정합니다.

   USE DATABASE tutorial_db;
   ...
   USE SCHEMA data_schema;
   

   Copy

2. 작업 서비스를 생성(EXECUTE JOB SERVICE를 실행하여)한 후 Snowflake는 컨테이너를 시작하고 컨테이너에서 다음 환경 변수를 세션의 현재 데이터베이스 및 스키마로 설정합니다.

   • SNOWFLAKE_DATABASE가 “TUTORIAL_DB”로 설정됨

   • SNOWFLAKE_SCHEMA가 “DATA_SCHEMA”로 설정됨

3. 작업 코드(자습서 2의 main.py 참조)는 다음 환경 변수를 읽습니다.

   SNOWFLAKE_DATABASE = os.getenv('SNOWFLAKE_DATABASE')
   SNOWFLAKE_SCHEMA = os.getenv('SNOWFLAKE_SCHEMA')
   

   Copy

4. 작업 코드는 데이터베이스와 스키마를 SQL 문을 실행할 컨텍스트로 설정합니다(main.py 의 run_job() 함수).

   {
      "account": SNOWFLAKE_ACCOUNT,
      "host": SNOWFLAKE_HOST,
      "authenticator": "oauth",
      "token": get_login_token(),
      "warehouse": SNOWFLAKE_WAREHOUSE,
      "database": SNOWFLAKE_DATABASE,
      "schema": SNOWFLAKE_SCHEMA
   }
   ...
   

   Copy

   참고

   SNOWFLAKE_ACCOUNT, SNOWFLAKE_HOST, SNOWFLAKE_DATABASE, SNOWFLAKE_SCHEMA는 Snowflake가 애플리케이션 컨테이너에 대해 생성하는 환경 변수이지만 SNOWFLAKE_WAREHOUSE 는 그렇지 않습니다(Snowflake가 웨어하우스 이름을 컨테이너에 전달하지 않으므로 자습서 2 애플리케이션 코드에서 이 변수를 생성함).

컨테이너용 웨어하우스 지정하기¶

서비스가 Snowflake에 연결하여 Snowflake 웨어하우스에서 쿼리를 실행하는 경우 웨어하우스를 지정하는 다음 옵션이 있습니다.

• 애플리케이션 코드에서 웨어하우스를 지정합니다. 코드에서 쿼리를 실행하려면 Snowflake 세션을 시작할 때 연결 구성의 일부로 웨어하우스를 지정하십시오. 예를 보려면 자습서 2 를 참조하십시오.

• 서비스 생성 시 기본 웨어하우스를 지정합니다. 기본 웨어하우스를 제공하려면 CREATE SERVICE 명령 또는 EXECUTE JOB SERVICE 명령에 선택적 QUERY_WAREHOUSE 매개 변수를 지정합니다. 애플리케이션 코드가 연결 구성의 일부로 웨어하우스를 제공하지 않는 경우 Snowflake는 기본 웨어하우스를 사용합니다. ALTER SERVICE 명령을 사용하여 기본 웨어하우스를 변경합니다.

  참고

  QUERY_WAREHOUSE 매개 변수를 사용하여 지정된 웨어하우스는 :doc:`서비스 사용자</developer-guide/snowpark-container-services/spcs-execute-sql>`의 경우에만 기본값입니다 서비스가 다른 사용자를 대신하여 Snowflake에 연결하는 경우 :ref:`호출자 권한 시나리오<label-spcs_additional_considerations_configuring_callers_rights>`의 컨텍스트에서 Snowflake는 사용자의 기본 웨어하우스를 사용합니다.

두 가지 방법을 모두 사용하여 웨어하우스를 지정하는 경우 애플리케이션 코드에 지정된 웨어하우스가 사용됩니다.

서비스 사용자 쿼리 기록에 액세스하기¶

``user_type``이 SNOWFLAKE_SERVICE인 경우 QUERY_HISTORY 뷰 또는 QUERY_HISTORY 함수를 필터링하여 서비스 사용자로 서비스에서 실행된 쿼리를 찾을 수 있습니다.

예 1: 서비스에서 실행되는 쿼리를 가져옵니다.

SELECT *
FROM snowflake.account_usage.query_history
WHERE user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
AND user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
order by start_time;

WHERE 절에서:

• user_name = '<service_name>': 서비스가 :doc:`서비스 사용자</developer-guide/snowpark-container-services/spcs-execute-sql>`로 쿼리를 실행하므로 서비스 이름을 사용자 이름으로 지정하고, 서비스 사용자 이름은 서비스 이름과 동일합니다.

• user_type = 'SNOWFLAKE_SERVICE' 및 user_name = '<서비스_이름>': 서비스에서 실행된 쿼리만 검색되도록 쿼리 결과를 제한합니다.

• user_database_name 및 user_schema_name: 서비스 사용자의 경우 서비스의 데이터베이스와 스키마입니다.

QUERY_HISTORY 함수를 호출하여 동일한 결과를 얻을 수 있습니다.

SELECT *
FROM TABLE(<service_db_name>.information_schema.query_history())
WHERE user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
AND user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
order by start_time;

WHERE 절에서:

• user_type = 'SNOWFLAKE_SERVICE' 및 user_name = '<서비스_이름>' 은 쿼리 결과를 서비스에서 실행된 쿼리만 검색하도록 제한합니다.

• user_database_name 및 user_schema_name 이름은 (서비스 사용자에 대한) 서비스의 데이터베이스 및 스키마입니다.

예 2: 서비스에서 실행되는 쿼리 및 해당 서비스 정보를 가져옵니다.

SELECT query_history.*, services.*
FROM snowflake.account_usage.query_history
JOIN snowflake.account_usage.services
ON query_history.user_name = services.service_name
AND query_history.user_schema_id = services.service_schema_id
AND query_history.user_type = 'SNOWFLAKE_SERVICE'

쿼리는 QUERY_HISTORY 및 SERVICES 뷰를 결합하여 쿼리를 실행한 쿼리 및 서비스에 대한 정보를 검색합니다. 다음 사항을 참고하십시오.

• 서비스에서 실행되는 쿼리의 경우 query_history.user_name 은 서비스 사용자의 이름이며, 이는 서비스 이름과 동일합니다.

• 스키마를 삭제한 후 다시 생성하면 스키마 ID는 변경되지만 이름은 그대로 유지되므로, 쿼리는 스키마 이름이 아닌 스키마 IDs를 사용하여 뷰를 조인해 동일한 스키마를 참조하도록 합니다.

쿼리에 선택적 필터를 추가할 수 있습니다. 예:

• 특정 쿼리를 실행한 서비스만 검색하려면 query_history 를 필터링합니다.

• 특정 서비스에서 실행된 쿼리만 검색하려면 services 를 필터링합니다.

예 3: 모든 서비스에 대해 서비스 사용자 정보를 가져옵니다.

SELECT services.*, users.*
FROM snowflake.account_usage.users
JOIN snowflake.account_usage.services
ON users.name = services.service_name
AND users.schema_id = services.service_schema_id
AND users.type = 'SNOWFLAKE_SERVICE'

쿼리는 ACCOUNT_USAGE 스키마에서 SERVICES 및 USERS 뷰를 조인하여 서비스 및 서비스 사용자 정보를 검색합니다. 다음 사항을 참고하십시오.

• 서비스가 쿼리를 실행할 때 서비스 사용자 권한으로 쿼리를 실행하고 서비스 사용자의 이름은 서비스 이름과 동일합니다. 따라서 조인 조건 users.name = services.service_name 을 지정합니다.

• 서비스 이름은 스키마 내에서만 고유합니다. 따라서 쿼리는 각 서비스 사용자가 속한 특정 서비스(다른 스키마에서 실행되는 다른 동일한 이름의 서비스가 아닌)에 대해 일치하도록 조인 조건(users.schema_id = services.service_schema_id)을 지정합니다.