Snowflake / 資料操作與營運
Snowflake資料操作與營運學習指南
從權限確認到資料更新、復原、載入、自動執行與驗證,以同一條流程學習。重點不是背語法,而是知道執行前要確認什麼、失敗時如何復原,以及重新執行後要驗證什麼。
這是獨立學習教材,不重現Snowflake官方認證考試的範圍或題目。
規格確認 2026-10-08
把五個領域視為一個操作流程
五個領域彼此相連。先確認誰能修改哪個目標,再控制變更邊界,進行載入或重新執行,最後驗證結果。
權限與基本結構
確認Role、Database、Schema、Table、View與工作階段脈絡。
資料更新
判斷INSERT、UPDATE、DELETE、MERGE的範圍、重複與重新執行。
交易與復原
區分BEGIN / COMMIT / ROLLBACK與Time Travel / UNDROP。
載入與自動執行
連結Stage、File Format、COPY INTO、Task、Stored Procedure。
驗證與營運
確認JOIN粒度、NULL、延遲資料、筆數、鍵、值與重新處理。
執行變更前的五項確認
資料變更工作可依下列順序判斷。
| Step | Check |
|---|---|
| 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;| Statement | Purpose | Safety 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復原。
| Mechanism | Target | Use |
|---|---|---|
| ROLLBACK | 目前尚未確定的明確交易 | 取消目前工作單位。 |
| Time Travel | 保留期間內的歷史資料 | 查詢或利用過去狀態復原。 |
| UNDROP | 保留期間內支援的DROP物件 | 在允許時復原最近DROP的物件。 |
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是一張訂單一列、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設計。
| Level | What 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官方文件確認。保留期間與授權等會隨帳戶設定改變的值,仍需在實際環境確認。