tee / insights
LEARNING / SNOWFLAKE首頁

Snowflake / 資料操作與營運

Snowflake資料操作與營運學習指南

從權限確認到資料更新、復原、載入、自動執行與驗證,以同一條流程學習。重點不是背語法,而是知道執行前要確認什麼、失敗時如何復原,以及重新執行後要驗證什麼。

這是獨立學習教材,不重現Snowflake官方認證考試的範圍或題目。

規格確認 2026-10-08

把五個領域視為一個操作流程

五個領域彼此相連。先確認誰能修改哪個目標,再控制變更邊界,進行載入或重新執行,最後驗證結果。

A

權限與基本結構

確認Role、Database、Schema、Table、View與工作階段脈絡。

B

資料更新

判斷INSERT、UPDATE、DELETE、MERGE的範圍、重複與重新執行。

C

交易與復原

區分BEGIN / COMMIT / ROLLBACK與Time Travel / UNDROP。

D

載入與自動執行

連結Stage、File Format、COPY INTO、Task、Stored Procedure。

E

驗證與營運

確認JOIN粒度、NULL、延遲資料、筆數、鍵、值與重新處理。

執行變更前的五項確認

資料變更工作可依下列順序判斷。

StepCheck
1. Context確認CURRENT_ROLE()、CURRENT_DATABASE()、CURRENT_SCHEMA()。
2. Scope以完整限定名稱與精確WHERE限制物件和資料列。
3. Boundary若多個DML必須一起成功或失敗,先決定交易邊界。
4. Re-run確認再次執行不會產生重複或重複修改。
5. Validate不要只看成功狀態,要以筆數、鍵和值驗證。

A. 確認權限與目標範圍

Snowflake使用者透過Role工作,Role取得的Privilege決定可存取的物件。SQL語法正確也可能因權限不足而失敗。先確認目前Role、Database與Schema,也能降低誤改其他環境或同名Table的風險。

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;
StatementPurposeSafety question
INSERT新增資料列同一輸入是否可能被新增兩次。
UPDATE修改符合條件的資料列WHERE範圍是否過大。
DELETE刪除符合條件的資料列能否先用SELECT確認精確目標。
MERGE依比對結果修改、加入或刪除ON鍵與source唯一性是否明確。

MERGE可依source與target的比對結果組合UPDATE、INSERT、DELETE。但MERGE本身不會自動讓重複source變成唯一。先決定Business Key,再確認source在該鍵上唯一。

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能全部還原。

ROLLBACK處理目前尚未確定的交易。已COMMIT的變更或已DROP物件屬於另一種復原問題。在適用的保留期間內,可用Time Travel查看過去資料,支援的物件可用UNDROP復原。

MechanismTargetUse
ROLLBACK目前尚未確定的明確交易取消目前工作單位。
Time Travel保留期間內的歷史資料查詢或利用過去狀態復原。
UNDROP保留期間內支援的DROP物件在允許時復原最近DROP的物件。

D. 連結檔案載入與自動執行

檔案載入可用 Stage → File Format → COPY INTO → Table 理解。Stage代表檔案位置,File Format定義CSV、JSON等的解讀方式,COPY INTO把資料載入Table。

StageFile FormatCOPY INTOTableTask / Stored Procedure
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是一張訂單一列、ORDER_ITEMS是一項商品一列,1對多JOIN自然會重複訂單。先確認每個Table的一列代表什麼。

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;

處理延遲到達資料時,要區分業務或事件時間與載入時間。若以重疊處理區間捕捉晚到資料,需搭配可安全重新執行的去重或MERGE設計。

LevelWhat to check
1. 筆數以COUNT(*)檢查大量遺漏或增加。
2. 鍵檢查Business Key遺漏、多餘與重複。
3. 值比較重要欄位及SUM、MIN、MAX等彙總。

理解確認

打開答案前,依目標範圍、交易邊界、重新執行、驗證的順序思考。

01只想取消客戶1001的訂單,但UPDATE沒有WHERE。問題是什麼?

全部資料列都會成為目標。先用SELECT確認條件,再用精確WHERE限制UPDATE。

02COUNT(AMOUNT)是95,COUNT(*)是100。先檢查什麼?

可能有5列的AMOUNT為NULL。COUNT(column)不計NULL。

03重新處理同一批Stage輸入。只有INSERT SELECT安全嗎?

不一定。同一資料可能再次加入。需設計Business Key、去重或合適的MERGE。

04BEGIN後執行UPDATE、CREATE TABLE、ROLLBACK。UPDATE一定會還原嗎?

不能這樣保證。Snowflake的DDL會隱含COMMIT進行中的交易。

05MERGE以ORDER_ID比對,但source有多個相同ORDER_ID。要確認什麼?

讓source在Business Key粒度唯一,避免一個target列同時依賴多個source列。

06source與target都是10,000列,可以判定成功嗎?

不行。還要檢查遺漏或重複鍵,以及重要值是否一致。

最後檢查

每個情境依序確認物件、權限、資料列範圍、交易邊界、重新執行與驗證。只會SQL語法,卻沒有限制目標,仍不是安全操作。

OBJECTPRIVILEGEWHERETRANSACTIONRE-RUNVALIDATE

官方資料

本文行為依Snowflake官方文件確認。保留期間與授權等會隨帳戶設定改變的值,仍需在實際環境確認。