Snowflakeデータ操作・運用 学習ガイド

5分野を一つの処理として捉える

5分野は独立していません。誰がどの対象を変更するかを決め、変更単位を管理し、取り込みや再実行を行い、最後に結果を検証する流れでつながっています。

A. 権限と対象を確定する

SnowflakeではユーザーがRoleを使い、Roleに付与されたPrivilegeでオブジェクトへアクセスします。SQLが正しくても権限不足なら実行できません。最初に現在のRole、Database、Schemaを確認すると、別環境や同名テーブルへの誤操作を減らせます。

SELECT
  CURRENT_ROLE(),
  CURRENT_DATABASE(),
  CURRENT_SCHEMA();

Schema内のオブジェクトは database.schema.object の完全修飾名で指定できます。更新系SQLでは SALES_DB.CORE.ORDERS のように対象を明示すると、セッションの現在DatabaseやSchemaへの依存を減らせる指定方法です。

SELECT *
FROM SALES_DB.CORE.ORDERS;

読み取りだけなら、必要なDatabaseとSchemaへのUSAGE、対象TableへのSELECTなど、目的に必要な権限だけを付ける考え方が基本です。強いRoleへ切り替える前に、必要な操作を確認します。

B. 安全にデータを更新する

INSERTは行を追加し、UPDATEは既存行を書き換え、DELETEは行を削除します。UPDATEとDELETEでWHERE句を省くと全行が対象になるため、更新前に同じ条件でSELECTし、対象件数とキーを確認する習慣が役立ちます。

SELECT ORDER_ID, CUSTOMER_ID, STATUS
FROM SALES_DB.CORE.ORDERS
WHERE CUSTOMER_ID = 1001;

UPDATE SALES_DB.CORE.ORDERS
SET STATUS = 'CANCELLED'
WHERE CUSTOMER_ID = 1001;

MERGEはsourceとtargetの一致条件に応じてUPDATE、INSERT、DELETEを組み合わせられます。ただしMERGEを使うだけでsourceの重複が消えるわけではありません。Business Keyを決め、sourceがそのキーで一意かを確認してからMERGEします。

MERGE INTO SALES_DB.CORE.ORDERS AS t
USING LANDING_DB.RAW.ORDERS_STAGE AS s
  ON t.ORDER_ID = s.ORDER_ID
WHEN MATCHED THEN
  UPDATE SET t.STATUS = s.STATUS, t.AMOUNT = s.AMOUNT
WHEN NOT MATCHED THEN
  INSERT (ORDER_ID, CUSTOMER_ID, AMOUNT, STATUS)
  VALUES (s.ORDER_ID, s.CUSTOMER_ID, s.AMOUNT, s.STATUS);

NULLは0や空文字列とは異なります。NULLの判定には IS NULL / IS NOT NULL を使うのが基本です。再実行では、同じ入力をもう一度処理しても最終状態が変わらない冪等性を確認します。

C. トランザクションと復旧を分けて考える

BEGINで明示トランザクションを開始し、COMMITで確定、ROLLBACKでそのトランザクション内の変更を取り消します。複数のDMLを一つの成功・失敗単位にしたいときに使います。

BEGIN TRANSACTION;

UPDATE SALES_DB.CORE.ORDERS
SET STATUS = 'CLOSED'
WHERE ORDER_DATE < '2026-01-01';

COMMIT;

SnowflakeではDDL文が実行されると、進行中のトランザクションは暗黙的にCOMMITされ、DDL自体は独立したトランザクションとして処理される仕様です。DDLはROLLBACKできません。明示トランザクションにDMLとDDLを混ぜて『全部戻る』と考えないことが大切です。

ROLLBACKは現在のトランザクションを戻す仕組みです。すでに確定した変更やDROP済みオブジェクトの復旧は別の話で、保持期間内ならTime Travelで過去状態を参照し、UNDROPで削除したオブジェクトを復元できる場合があります。

D. ファイル取り込みと自動実行をつなぐ

ファイル取り込みは Stage → File Format → COPY INTO → Table の順に捉えると整理できます。Stageはロード元ファイルの場所を表し、File FormatはCSVやJSONなどの読み方を定義し、COPY INTOがTableへロードします。

COPY INTO SALES_DB.CORE.ORDERS
FROM @LANDING_DB.RAW.ORDER_STAGE
FILE_FORMAT = (
  FORMAT_NAME = 'LANDING_DB.RAW.ORDER_CSV'
);

自動実行ではTaskが『いつ実行するか』を担当し、Stored Procedureは『何をどう処理するか』をまとめる役割として使えます。TaskからStored Procedureを呼び、内部でMERGEや検証を行う構成も考えられます。

E. 件数・キー・値で検証する

JOIN後に行数が増えても、すぐに誤りとは限りません。ORDERSが1注文1行、ORDER_ITEMSが1商品1行なら、1対多のJOINで注文行が商品数だけ増えるのは自然です。各Tableの1行が何を表すかという粒度を先に確認します。

COUNT(*)は行数を数えますが、COUNT(column)はその列がNULLの行を数えません。件数一致だけでも完全な検証にはなりません。sourceとtargetの件数が同じでも、キーや値がずれている可能性があります。

SELECT COUNT(*) AS row_count,
       COUNT(AMOUNT) AS amount_count
FROM SALES_DB.CORE.ORDERS;

SELECT ORDER_ID, COUNT(*) AS duplicate_count
FROM SALES_DB.CORE.ORDERS
GROUP BY ORDER_ID
HAVING COUNT(*) > 1;

遅延到着データを扱うときは、業務日時と取り込み日時を区別します。処理期間を重ねて再取得するなら、再処理で重複しない設計との組み合わせが必要です。

理解度チェック

答えを見る前に、対象範囲、トランザクション境界、再実行、検証の順で考えてください。

公式資料

仕様はSnowflake公式ドキュメントで確認しています。保持期間や権限構成など、アカウント設定で変わる値は実環境も確認してください。

• Access control
• Object name resolution
• CURRENT_ROLE
• UPDATE
• DELETE
• MERGE
• Transactions
• Time Travel
• UNDROP TABLE
• COPY INTO <table>
• Internal stages
• Tasks
• Stored procedures
• COUNT
• IS NULL