Snowpark Container Services: SQL 実行¶

認証情報構成オプション¶

Snowflakeは、 SQL を実行するときに、アプリケーションコンテナがSnowflake提供の認証情報を使用してSnowflakeに対して認証することを推奨します。外部アクセス統合（EAI）を介して接続することで、他の認証情報を使用することは可能ですが、 EAI を介して接続する場合、Snowflakeの外部で実行され、インターネット経由でSnowflakeに接続しているかのようにサービスを扱います。

サービスコンテナからSnowflakeに接続するには、次の3つのオプションがあります。

• **Snowflakeが提供するサービスユーザー認証情報を使用する: ** Snowflakeが提供するすべてのサービスに、サービス認証情報と呼ばれる認証情報があります。サービスはこれらの認証情報を使用して、サービスユーザーとしてSnowflakeに接続します。

• **Snowflakeが提供する呼び出し元認証情報（呼び出し元権限）を使用する: ** 呼び出し元権限でサービスを構成すると、Snowflakeは呼び出しユーザーとしてSnowflakeに接続するための、サービスの認証情報も提供します。

• 他の認証情報を使用する: この場合は、有効な認証情報を使用して、サービスをSnowflakeのインターネットエンドポイントに接続できる外部アクセス統合（EAI）を使用します。このオプションを使用するには、管理者が EAI を作成してから、サービス所有者ロールへの統合に対する USAGE 権限を付与する必要があります。

  注釈

  外部アクセス統合を使用してSnowflakeにアクセスすることは、潜在的にセンシティブな情報をインターネット経由で送信することを意味します。

Snowflakeに接続するためにさまざまなSnowflakeドライバーを使用するコードの例については、 Snowflake接続サンプル をご参照ください。

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 を実行できます。

このセクションでは、2つの概念について説明します。

• サービスを作成するデータベースとスキーマを決定するために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 パラメーターを使用して指定されたウェアハウスは サービスユーザー のみのデフォルトです。サービスが他のユーザーに代わってSnowflakeに接続するとき、呼び出し元権限のシナリオ のコンテキストにおいて、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>':サービスは サービスユーザー としてクエリを実行し、サービスユーザーの名前はサービス名と同じであるため、サービス名をユーザー名として指定します。

• user_type = 'SNOWFLAKE_SERVICE' および user_name = '<service_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 = '<service_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 は、サービスユーザー名です。これは、サービス名と同じです。

• クエリは、スキーマ IDs （スキーマ名ではない）を使用してビューを結合し、同じスキーマを参照していることを確認します。スキーマをドロップして再作成すると、スキーマ ID は変更されますが、名前は同じままだからです。

クエリにオプションのフィルターを追加することができます。例:

• 特定のクエリを実行したサービスのみを取得するためのフィルター 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）を指定します。