Snowflake Engineer

Mission: "Mobilize the world's data to help organizations solve their most critical problems inside the AI Data Cloud." — Snowflake Inc.

Engineering Philosophy: "We believe that a cloud computing platform that puts data and AI at its core will offer great benefits to organizations by allowing them to realize the value of the data that powers their businesses." — Snowflake Leadership

Core Tenet: "True SaaS means zero infrastructure management—just bring your data and queries."

§1 · Quick Start

§1.1 · One-Minute Setup

Activate this skill for Snowflake-style data engineering:

# Add to CLAUDE.md
echo "Apply snowflake-engineer: multi-cluster shared data architecture, storage/compute separation, Snowpark data engineering, AI Data Cloud patterns." >> CLAUDE.md

§1.2 · Essential Context

Leadership Context:

• Frank Slootman (Chairman, Former CEO 2019-2024): Legendary enterprise operator, previously led ServiceNow IPO
• Sridhar Ramaswamy (CEO, Feb 2024-present): Former Google Ads SVP, co-founder of Neeva (AI search), driving AI Data Cloud transformation
• Benoit Dageville & Thierry Cruanes: Co-founders, architects of multi-cluster shared data architecture

§1.3 · Core Capabilities

1. Multi-Cluster Shared Data Architecture — Separation of storage, compute, and services layers
2. Virtual Warehouse Scaling — Independent scaling of compute with auto-suspend/resume
3. Snowpark Data Engineering — Python/Java/Scala natively in Snowflake, pushing compute to data
4. Zero-Copy Data Sharing — Secure data sharing without movement or copying
5. AI Data Cloud — Cortex AI, Snowpark ML, and LLM integration for AI/ML workloads

§2 · Snowflake Engineering Culture

§2.1 · Founding Principles (2012)

The Genesis: Benoit Dageville and Thierry Cruanes, both Oracle database architects, founded Snowflake in 2012 with a radical premise: rebuild the data warehouse from the ground up for the cloud era. Their insight was that traditional shared-nothing architectures were fundamentally constrained by coupling storage and compute.

Three Architectural Innovations:

The Frank Slootman Era (2019-2024):

"Snowflake would no longer have a headquarters but would be 'distributed'." — Frank Slootman, 2021

Slootman transformed Snowflake from a promising startup to a $60B+ public company (NYSE: SNOW, Sept 2020 IPO). His leadership focused on:

• Enterprise sales excellence and land-and-expand strategy
• Multi-cloud availability (AWS, Azure, GCP)
• Data marketplace and ecosystem development
• Consumption-based pricing model optimization

The Ramaswamy Era (2024-present): Sridhar Ramaswamy, former Google Ads leader and Neeva co-founder, is pivoting Snowflake toward the AI Data Cloud:

• Launch of Cortex AI for LLM integration
• Snowpark Container Services for application hosting
• Streamlit acquisition for data app development
• AI/ML-first positioning in the data platform market

§2.2 · Core Engineering Values

1. Simplicity Through Architecture

• No indexes to manage (automatic micro-partition pruning)
• No distribution keys to choose (storage is separate)
• No vacuum/analyze operations (automatic maintenance)
• No hardware to provision (true SaaS)

2. Performance Through Separation

┌─────────────────────────────────────────────────────────┐
│                    SERVICES LAYER                        │
│  (Authentication, Query Parsing, Optimization, Metadata) │
└─────────────────────────────────────────────────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
   ┌─────────┐       ┌─────────┐       ┌─────────┐
   │Compute A│       │Compute B│       │Compute C│
   │  (ETL)  │       │(Analytics)│     │  (ML)   │
   └────┬────┘       └────┬────┘       └────┬────┘
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ▼
        ┌─────────────────────────────────┐
        │         STORAGE LAYER            │
        │   (Cloud Blob Storage, Encrypted)│
        │   - Micro-partitions (50-500MB)  │
        │   - Columnar format              │
        │   - Automatic compression        │
        └─────────────────────────────────┘

3. Cost Optimization Culture

• Virtual warehouses auto-suspend when idle
• Multi-cluster warehouses scale based on concurrency
• Resource monitors enforce spending limits
• Storage and compute billed separately

§2.3 · AI Data Cloud Vision

Strategic Pillars (2024+):

§3 · Technical Architecture

§3.1 · Three-Layer Architecture

Storage Layer

Micro-Partition Design:

• Data automatically partitioned into immutable micro-partitions (50-500MB uncompressed)
• Columnar storage with automatic compression
• Metadata pruning eliminates unnecessary partition scans
• Time Travel and Fail-safe through immutable snapshots

-- Micro-partition pruning example
SELECT * FROM sales 
WHERE sale_date >= '2024-01-01' 
  AND region = 'US';
-- Snowflake uses partition metadata to skip 95%+ of data

Storage Characteristics:

Compute Layer (Virtual Warehouses)

Warehouse Sizing:

Multi-Cluster Warehouses:

-- Create auto-scaling warehouse for variable concurrency
CREATE WAREHOUSE analytics_wh WITH
  WAREHOUSE_SIZE = 'LARGE'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 5
  SCALING_POLICY = 'STANDARD'  -- or 'ECONOMY'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE;

Scaling Policies:

• STANDARD: Clusters start immediately when queued queries > 0 (low latency)
• ECONOMY: Wait longer before starting clusters (cost optimization)

Services Layer

Responsibilities:

• Query parsing and optimization
• Metadata management (statistics, clustering information)
• Transaction management (ACID compliance)
• Authentication and access control
• Result caching

Result Cache:

• Persists query results for 24 hours
• Shared across users (if they have access)
• Eliminates recomputation for identical queries
• Critical for BI tool performance

§3.2 · Data Loading Patterns

Bulk Loading (Recommended for Large Volumes):

-- Stage configuration
CREATE OR REPLACE STAGE my_stage
  URL = 's3://my-bucket/data/'
  STORAGE_INTEGRATION = aws_integration;

-- COPY command with optimization
COPY INTO target_table
  FROM @my_stage
  FILE_FORMAT = (TYPE = PARQUET)
  MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE
  PURGE = TRUE;  -- Remove files after loading

Streaming Ingestion (Kafka/Snowpipe):

# Snowpark Python streaming example
from snowflake.snowpark import Session
from snowflake.snowpark.functions import col

session = Session.builder.configs(connection_parameters).create()

# Create streaming pipeline
stream_df = session.readStream \
    .schema(stream_schema) \
    .option("subscribe", "kafka-topic") \
    .load()

stream_df.writeStream \
    .option("checkpointLocation", "/checkpoints") \
    .toTable("streaming_target")

Data Loading Best Practices:

§3.3 · Snowpark Data Engineering

Python UDFs:

from snowflake.snowpark import Session
from snowflake.snowpark.functions import udf
from snowflake.snowpark.types import IntegerType, StringType

# Create a Python UDF that runs inside Snowflake
@udf(name="celsius_to_fahrenheit", 
     input_types=[IntegerType()], 
     return_type=IntegerType(),
     packages=['numpy'])
def celsius_to_fahrenheit(celsius):
    return (celsius * 9/5) + 32

# Use in SQL
session.sql("SELECT celsius_to_fahrenheit(25)").collect()

Vectorized UDFs (High Performance):

import pandas as pd
from snowflake.snowpark.functions import pandas_udf

@pandas_udf
def calculate_roi_vectorized(investment: pd.Series, returns: pd.Series) -> pd.Series:
    """Process millions of rows efficiently using vectorization"""
    return (returns - investment) / investment * 100

# Register and use
df = session.table("investments")
df.select(
    col("name"),
    calculate_roi_vectorized(col("investment"), col("returns")).alias("roi_pct")
).show()

Stored Procedures:

from snowflake.snowpark import Session

def data_quality_check_procedure(session: Session, database: str, schema: str, table: str) -> str:
    """
    Comprehensive data quality check procedure
    """
    # Get row count
    row_count = session.sql(f"""
        SELECT COUNT(*) FROM {database}.{schema}.{table}
    """).collect()[0][0]
    
    # Check for nulls in key columns
    null_check = session.sql(f"""
        SELECT 
            COUNT(*) - COUNT(id) as null_ids,
            COUNT(*) - COUNT(created_at) as null_timestamps
        FROM {database}.{schema}.{table}
    """).collect()[0]
    
    # Generate report
    report = f"""
    Data Quality Report for {database}.{schema}.{table}
    ============================================
    Total Rows: {row_count}
    Null IDs: {null_check[0]}
    Null Timestamps: {null_check[1]}
    Quality Score: {(1 - (null_check[0] + null_check[1]) / (row_count * 2)) * 100:.2f}%
    """
    
    return report

# Register procedure
session.sproc.register(
    data_quality_check_procedure,
    name="data_quality_check",
    packages=['snowflake-snowpark-python']
)

§4 · Performance Optimization

§4.1 · Query Optimization

Query Profile Analysis:

-- Enable query profiling
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

-- Execute query
SELECT * FROM large_table WHERE complex_condition;

-- View profile in UI or via
SELECT * FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
ORDER BY START_TIME DESC
LIMIT 10;

Common Optimization Patterns:

Clustering Keys:

-- For large tables with predictable filter patterns
ALTER TABLE sales 
CLUSTER BY (date_trunc('month', sale_date), region);

-- Natural clustering vs. explicit clustering
-- Snowflake automatically clusters micro-partitions
-- Explicit clustering needed for very large tables (>1TB)

§4.2 · Warehouse Optimization

Right-Sizing Strategy:

# Monitoring and optimization workflow
def analyze_warehouse_utilization(session, warehouse_name):
    """
    Analyze warehouse utilization and recommend sizing
    """
    query = f"""
    SELECT 
        WAREHOUSE_NAME,
        AVG(EXECUTION_TIME) as avg_execution_time,
        AVG(QUEUED_TIME) as avg_queued_time,
        AVG(BYTES_SCANNED) as avg_bytes_scanned,
        COUNT(*) as query_count
    FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
    WHERE WAREHOUSE_NAME = '{warehouse_name}'
      AND START_TIME >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    GROUP BY WAREHOUSE_NAME
    """
    
    result = session.sql(query).collect()
    
    # Analysis logic
    for row in result:
        avg_queue = row['AVG_QUEUED_TIME']
        if avg_queue > 10:  # seconds
            print(f"⚠️ High queue time detected: {avg_queue}s")
            print("Recommendation: Enable multi-cluster or increase warehouse size")
        elif avg_queue < 1:
            print(f"✅ Good utilization: {avg_queue}s average queue")
            
    return result

Materialized Views:

-- For frequently accessed aggregations
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT 
    date_trunc('day', sale_date) as day,
    region,
    SUM(amount) as total_sales,
    COUNT(*) as transaction_count,
    AVG(amount) as avg_transaction
FROM sales
GROUP BY 1, 2;

-- Automatic maintenance by Snowflake

§4.3 · Cost Management

Resource Monitors:

-- Create resource monitor to control spending
CREATE RESOURCE MONITOR monthly_budget WITH
  CREDIT_QUOTA = 10000  -- Monthly credit limit
  FREQUENCY = MONTHLY
  START_TIMESTAMP = '2024-01-01 00:00:00'
  TRIGGERS
    ON 75 PERCENT DO NOTIFY  -- Alert at 75%
    ON 90 PERCENT DO SUSPEND_IMMEDIATE;  -- Stop at 90%

-- Assign to warehouses
ALTER WAREHOUSE etl_wh SET RESOURCE_MONITOR = monthly_budget;

Cost Attribution:

-- Query cost analysis by user/warehouse
SELECT 
    USER_NAME,
    WAREHOUSE_NAME,
    DATABASE_NAME,
    SUM(EXECUTION_TIME) / 1000 / 60 as total_minutes,
    SUM(CREDITS_USED) as total_credits,
    COUNT(*) as query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY total_credits DESC;

§5 · Example Scenarios

§5.1 · Enterprise Data Warehousing

Context: Design a data warehouse for a retail company with $10B annual revenue, supporting 500 analysts and 50+ data sources.

Snowflake-Engineer Approach:

Phase 1: Architecture Design

Data Architecture:
  Ingestion Layer:
    - SAP ERP (Change Data Capture)
    - Salesforce (Bulk API)
    - E-commerce (Event streaming)
    - IoT sensors (Kafka)
    
  Storage Layer:
    Raw Zone: Unmodified source data
    Clean Zone: Validated, typed data
    Curated Zone: Business-ready models
    Analytics Zone: Aggregated summaries
    
  Compute Separation:
    ETL_WH: Large, 3-8 PM daily
    ANALYTICS_WH: Medium, auto-scale 1-10 clusters
    DATA_SCIENCE_WH: X-Large, on-demand
    ADHOC_WH: Small, per-team allocation

Phase 2: Data Model

-- Raw layer: Landing zone
CREATE DATABASE retail_dw;
CREATE SCHEMA raw;

CREATE TABLE raw.sales_transactions (
    source_json VARIANT,  -- Store raw JSON
    _loaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    _file_name STRING,
    _batch_id STRING
);

-- Clean layer: Typed and validated
CREATE SCHEMA clean;

CREATE TABLE clean.sales (
    transaction_id STRING PRIMARY KEY,
    sale_date DATE,
    customer_id STRING,
    product_id STRING,
    quantity NUMBER(10,2),
    amount NUMBER(18,4),
    currency STRING(3),
    _loaded_at TIMESTAMP,
    _valid_from TIMESTAMP,
    _valid_to TIMESTAMP  -- For SCD Type 2
);

-- Curated layer: Business model
CREATE SCHEMA curated;

CREATE VIEW curated.daily_sales_metrics AS
SELECT 
    date_trunc('day', sale_date) as day,
    region,
    product_category,
    SUM(amount) as revenue,
    COUNT(DISTINCT customer_id) as unique_customers,
    SUM(quantity) as units_sold
FROM clean.sales s
JOIN clean.customers c ON s.customer_id = c.customer_id
JOIN clean.products p ON s.product_id = p.product_id
GROUP BY 1, 2, 3;

Phase 3: ETL Pipeline

# Snowpark-based ETL pipeline
from snowflake.snowpark import Session
from snowflake.snowpark.functions import col, when, to_date, lit
from snowflake.snowpark.types import StructType, StructField, StringType, DecimalType

def run_daily_etl(session: Session):
    """
    Production ETL pipeline with error handling
    """
    try:
        # Scale up for ETL
        session.sql("ALTER WAREHOUSE etl_wh SET WAREHOUSE_SIZE = LARGE").collect()
        
        # Step 1: Load raw data
        raw_df = session.read \
            .option("compression", "gzip") \
            .json("@raw_stage/sales/2024/01/15/")
        
        raw_df.write \
            .mode("append") \
            .save_as_table("raw.sales_transactions")
        
        # Step 2: Transform to clean layer
        clean_df = session.table("raw.sales_transactions") \
            .select(
                col("source_json"):transaction_id::string.alias("transaction_id"),
                to_date(col("source_json"):sale_date::string, 'YYYY-MM-DD').alias("sale_date"),
                col("source_json"):customer_id::string.alias("customer_id"),
                col("source_json"):product_id::string.alias("product_id"),
                col("source_json"):quantity::decimal(10,2).alias("quantity"),
                col("source_json"):amount::decimal(18,4).alias("amount"),
                lit('USD').alias("currency"),
                col("_loaded_at")
            ) \
            .filter(col("transaction_id").is_not_null())
        
        # Merge into clean table (SCD Type 2)
        clean_df.write \
            .mode("append") \
            .save_as_table("clean.sales")
        
        # Step 3: Data quality checks
        quality_result = session.sql("""
            SELECT 
                COUNT(*) as total_rows,
                COUNT(DISTINCT transaction_id) as unique_ids,
                SUM(CASE WHEN amount < 0 THEN 1 ELSE 0 END) as negative_amounts
            FROM clean.sales
            WHERE _loaded_at >= CURRENT_DATE
        """).collect()
        
        if quality_result[0]['NEGATIVE_AMOUNTS'] > 0:
            raise Exception("Data quality check failed: Negative amounts detected")
        
        # Step 4: Refresh materialized views
        session.sql("ALTER MATERIALIZED VIEW curated.daily_sales_summary SUSPEND").collect()
        session.sql("ALTER MATERIALIZED VIEW curated.daily_sales_summary RESUME").collect()
        
        # Scale down after ETL
        session.sql("ALTER WAREHOUSE etl_wh SET WAREHOUSE_SIZE = SMALL").collect()
        
        return {"status": "success", "rows_processed": quality_result[0]['TOTAL_ROWS']}
        
    except Exception as e:
        # Alert on failure
        session.sql(f"""
            INSERT INTO etl_log.error_log (error_time, error_message, pipeline_name)
            VALUES (CURRENT_TIMESTAMP(), '{str(e)}', 'daily_etl')
        """).collect()
        raise

Phase 4: Performance Results

Performance Metrics:
- Data Load: 500M rows/hour (Large warehouse)
- Query P95: <2 seconds for analyst queries
- Concurrent Users: 500+ without degradation
- Storage Efficiency: 10:1 compression ratio
- Cost: $50K/month (compute + storage)

§5.2 · ETL Optimization

Context: Existing ETL pipeline processes 2TB daily but takes 8 hours—needs optimization to meet 4-hour SLA.

Snowflake-Engineer Approach:

Phase 1: Bottleneck Analysis

-- Identify slow queries
SELECT 
    QUERY_ID,
    QUERY_TEXT,
    EXECUTION_TIME / 1000 as execution_seconds,
    COMPILATION_TIME / 1000 as compilation_seconds,
    BYTES_SCANNED / POWER(1024, 3) as gb_scanned,
    PARTITIONS_SCANNED,
    PARTITIONS_TOTAL
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE WAREHOUSE_NAME = 'ETL_WH'
  AND EXECUTION_TIME > 300000  -- >5 minutes
  AND START_TIME >= DATEADD(day, -1, CURRENT_TIMESTAMP())
ORDER BY EXECUTION_TIME DESC
LIMIT 20;

Phase 2: Optimization Implementation

Before (Slow):

-- Sequential row-by-row processing
INSERT INTO target_table
SELECT 
    source.*,
    complex_function(col1, col2),
    another_function(col3)
FROM source_table source
JOIN lookup_table lookup ON source.id = lookup.id
WHERE source.status = 'pending';

After (Optimized):

-- Use temporary tables for complex transformations
CREATE TEMPORARY TABLE temp_transformed AS
SELECT 
    source.id,
    source.col1,
    source.col2,
    lookup.reference_data
FROM source_table source
JOIN lookup_table lookup ON source.id = lookup.id
WHERE source.status = 'pending';

-- Parallel insert with warehouse scaling
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

INSERT INTO target_table
SELECT 
    id,
    col1,
    col2,
    complex_function(col1, col2),
    reference_data
FROM temp_transformed;

-- Clustering for future queries
ALTER TABLE target_table CLUSTER BY (id);

Phase 3: Snowpark Optimization

# Vectorized transformation with Snowpark
from snowflake.snowpark.functions import pandas_udf
import pandas as pd

@pandas_udf
def batch_transform(ids: pd.Series, values: pd.Series) -> pd.Series:
    """Process batches efficiently instead of row-by-row"""
    # Vectorized operation
    return ids.str.upper() + '_' + values.astype(str)

# Use in pipeline
df = session.table("source_table")
df_transformed = df.withColumn(
    "transformed_id", 
    batch_transform(col("id"), col("value"))
)
df_transformed.write.mode("overwrite").save_as_table("target_table")

Phase 4: Results

Before Optimization:
- Runtime: 8 hours
- Warehouse: X-Large (continuous)
- Cost: 128 credits/run

After Optimization:
- Runtime: 2.5 hours
- Warehouse: Large (dynamic scaling)
- Cost: 45 credits/run
- Improvement: 3.2x faster, 65% cost reduction

§5.3 · Multi-Cloud Deployment

Context: Global enterprise needs data residency in AWS (US), Azure (Europe), and GCP (Asia) with cross-region data sharing.

Snowflake-Engineer Approach:

Phase 1: Multi-Cloud Architecture

Deployment Strategy:
  AWS US-East:
    Account: PROD_US
    Role: Primary data ingestion
    Data: Raw transactions, US customer data
    
  Azure West-Europe:
    Account: PROD_EU
    Role: EU data residency
    Data: EU customer data, GDPR-compliant
    
  GCP Asia-Southeast:
    Account: PROD_ASIA
    Role: APAC operations
    Data: Asia-Pacific transactions

Cross-Cloud Replication:
  - Aggregated analytics shared via Secure Data Sharing
  - Global dimension tables replicated
  - Regional compliance enforced at account level

Phase 2: Data Sharing Setup

-- Primary account (AWS US)
CREATE SHARE global_analytics_share;

GRANT USAGE ON DATABASE analytics_db TO SHARE global_analytics_share;
GRANT USAGE ON SCHEMA analytics_db.global TO SHARE global_analytics_share;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_db.global TO SHARE global_analytics_share;

-- Add consumer accounts
ALTER SHARE global_analytics_share ADD ACCOUNTS = 
    azure_eu_account,
    gcp_asia_account;

-- Consumer account (Azure Europe)
CREATE DATABASE global_analytics FROM SHARE aws_us_account.global_analytics_share;

-- Create secure view for regional compliance
CREATE SECURE VIEW eu_customers_only AS
SELECT * FROM global_analytics.customers
WHERE region = 'EU';

Phase 3: Cross-Cloud Query Federation

# Python connector for cross-cloud queries
import snowflake.connector

# Connect to multiple accounts
us_conn = snowflake.connector.connect(
    account='us-east.snowflakecomputing.com',
    user='admin',
    warehouse='ANALYTICS_WH'
)

eu_conn = snowflake.connector.connect(
    account='west-europe.azure.snowflakecomputing.com',
    user='admin',
    warehouse='ANALYTICS_WH'
)

# Aggregate data across regions
def get_global_metrics(date):
    us_data = us_conn.cursor().execute(f"""
        SELECT SUM(revenue) FROM us_sales WHERE date = '{date}'
    """).fetchone()[0]
    
    eu_data = eu_conn.cursor().execute(f"""
        SELECT SUM(revenue) FROM eu_sales WHERE date = '{date}'
    """).fetchone()[0]
    
    return {'us': us_data, 'eu': eu_data, 'global': us_data + eu_data}

Phase 4: Failover Strategy

-- Set up account-level replication
CREATE DATABASE global_db;
ENABLE REPLICATION TO ACCOUNTS aws_us_account, azure_eu_account;

-- In case of regional outage
-- 1. Promote secondary account
ALTER DATABASE global_db PRIMARY;  -- On Azure account

-- 2. Redirect application connections
-- 3. Resume operations with <5 min RTO

§5.4 · Real-Time Analytics

Context: E-commerce platform needs real-time dashboards showing sales, inventory, and customer behavior with <10 second latency.

Snowflake-Engineer Approach:

Phase 1: Streaming Architecture

# Kafka to Snowflake streaming
from confluent_kafka import Consumer
from snowflake.snowpark import Session

session = Session.builder.configs(connection_parameters).create()

# Configure Snowpipe for streaming ingestion
session.sql("""
    CREATE OR REPLACE PIPE sales_stream_pipe
    AUTO_INGEST = TRUE
    AS
    COPY INTO raw.sales_stream
    FROM @kafka_stage
    FILE_FORMAT = (TYPE = JSON)
""").collect()

# Enable auto-ingest via SQS/SNS
session.sql("""
    ALTER PIPE sales_stream_pipe REFRESH
""").collect()

Phase 2: Stream Processing

-- Create stream on source table
CREATE OR REPLACE STREAM sales_changes ON TABLE raw.sales;

-- Create task for real-time aggregation
CREATE OR REPLACE TASK realtime_sales_aggregation
  WAREHOUSE = 'STREAMING_WH'
  SCHEDULE = '1 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('sales_changes')
AS
  MERGE INTO analytics.realtime_sales AS target
  USING (
    SELECT 
      date_trunc('minute', sale_time) as minute,
      product_id,
      SUM(amount) as revenue,
      COUNT(*) as transactions
    FROM sales_changes
    GROUP BY 1, 2
  ) AS source
  ON target.minute = source.minute AND target.product_id = source.product_id
  WHEN MATCHED THEN UPDATE SET
    target.revenue = target.revenue + source.revenue,
    target.transactions = target.transactions + source.transactions
  WHEN NOT MATCHED THEN INSERT (minute, product_id, revenue, transactions)
    VALUES (source.minute, source.product_id, source.revenue, source.transactions);

Phase 3: Dashboard Optimization

-- Pre-aggregated summary for dashboards
CREATE DYNAMIC TABLE realtime_dashboard_metrics
  TARGET_LAG = '1 MINUTE'
  WAREHOUSE = 'STREAMING_WH'
AS
SELECT 
  date_trunc('minute', current_timestamp) as metric_time,
  COUNT(*) as transactions_per_minute,
  SUM(amount) as revenue_per_minute,
  COUNT(DISTINCT customer_id) as active_customers,
  AVG(amount) as avg_transaction_value
FROM raw.sales_stream
WHERE sale_time >= dateadd(minute, -5, current_timestamp);

§5.5 · AI/ML Pipeline

Context: Build a customer churn prediction model using Snowflake's ML capabilities.

Snowflake-Engineer Approach:

Phase 1: Feature Engineering

from snowflake.snowpark import Session
from snowflake.ml.feature_store import FeatureStore, Entity, FeatureView

session = Session.builder.configs(connection_parameters).create()

# Define customer entity
customer_entity = Entity(
    name="CUSTOMER",
    join_keys=["CUSTOMER_ID"],
    description="Customer entity for churn prediction"
)

# Create feature view
feature_store = FeatureStore(session)

features_df = session.table("sales.transactions").groupBy("customer_id").agg(
    count("*").alias("total_transactions"),
    sum("amount").alias("total_spend"),
    avg("amount").alias("avg_transaction"),
    datediff("day", max("transaction_date"), current_date()).alias("days_since_last_purchase")
)

feature_view = FeatureView(
    name="customer_churn_features",
    entities=[customer_entity],
    feature_df=features_df,
    refresh_freq="1 day"
)

feature_store.register_feature_view(feature_view)

Phase 2: Model Training

from snowflake.ml.modeling.xgboost import XGBClassifier
from snowflake.ml.modeling.preprocessing import StandardScaler
from snowflake.ml.modeling.pipeline import Pipeline

# Get training data
training_df = session.table("ml.churn_labeled_dataset")

# Create ML pipeline
pipeline = Pipeline([
    ("scaler", StandardScaler(input_cols=["total_spend", "avg_transaction"], output_cols=["scaled_spend", "scaled_avg"])),
    ("classifier", XGBClassifier(
        input_cols=["scaled_spend", "scaled_avg", "total_transactions", "days_since_last_purchase"],
        label_cols=["churned"],
        output_cols=["prediction"],
        max_depth=6,
        learning_rate=0.1,
        n_estimators=100
    ))
])

# Train model
pipeline.fit(training_df)

# Save to registry
from snowflake.ml.registry import Registry
registry = Registry(session)
registry.log_model(
    model=pipeline,
    model_name="customer_churn_predictor",
    version="v1",
    sample_input_data=training_df.limit(100)
)

Phase 3: Inference

# Load model and predict
model = registry.get_model("customer_churn_predictor").version("v1")

# Batch prediction on all customers
customers = session.table("customers.active")
predictions = model.run(customers, function_name="predict")

# Store predictions
predictions.write.mode("overwrite").save_as_table("ml.churn_predictions")

# Create actionable segment
high_risk = session.table("ml.churn_predictions").filter(col("prediction_probability") > 0.8)
high_risk.write.mode("overwrite").save_as_table("marketing.high_churn_risk")

§6 · Tool Reference

§6.1 · Snowflake Tool Ecosystem

§6.2 · Key SQL Patterns

Time Travel:

-- Query historical data
SELECT * FROM sales AT (OFFSET => -60*60*24);  -- 1 day ago

-- Undrop table
UNDROP TABLE sales;

-- Clone at specific time
CREATE TABLE sales_backup CLONE sales AT (TIMESTAMP => '2024-01-15 00:00:00'::TIMESTAMP);

Zero-Copy Cloning:

-- Instant environment provisioning
CREATE DATABASE dev CLONE prod;
CREATE SCHEMA test CLONE prod.analytics;
CREATE TABLE test_table CLONE prod.analytics.sales;
-- No data movement, just metadata

Secure Data Sharing:

-- Share with partner organization
CREATE SHARE partner_share;
GRANT USAGE ON DATABASE analytics TO SHARE partner_share;
GRANT SELECT ON VIEW analytics.summary TO SHARE partner_share;
ALTER SHARE partner_share ADD ACCOUNTS = partner_account_id;

§7 · Quality Checklist

§7.1 · Design Review

• Warehouse sizing matched to workload pattern
• Multi-cluster enabled for variable concurrency
• Auto-suspend configured for cost optimization
• Resource monitors set up for spending control
• Data sharing architecture defined if needed
• Security roles and row access policies configured
• Time Travel retention aligned with compliance needs

§7.2 · Performance Review

• Queries use partition pruning (check query profile)
• Clustering keys defined for large tables (>1TB)
• Materialized views for repeated aggregations
• Result caching leveraged for BI workloads
• Snowpark UDFs vectorized for batch processing

§7.3 · Operations Review

• Monitoring dashboards in Snowsight
• Alert rules for credit consumption spikes
• Runbooks for common issues
• Backup strategy (cloning vs. replication)
• Disaster recovery plan with cross-cloud failover

§8 · Risk Framework

§8.1 · Common Pitfalls

§8.2 · Security Considerations

-- Row Access Policy for multi-tenant security
CREATE ROW ACCESS POLICY region_policy AS (region_val VARCHAR) RETURNS BOOLEAN ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN TRUE
    WHEN CURRENT_ROLE() = 'US_ANALYST' AND region_val = 'US' THEN TRUE
    WHEN CURRENT_ROLE() = 'EU_ANALYST' AND region_val = 'EU' THEN TRUE
    ELSE FALSE
  END;

-- Apply to table
ALTER TABLE sales ADD ROW ACCESS POLICY region_policy ON (region);

§9 · Learning Resources

§9.1 · Essential Documentation

§9.2 · Snowflake Engineering Blogs

• Snowflake Blog (snowflake.com/blog)
• Snowpark Best Practices
• Performance Optimization Guides
• Customer Success Stories

§10 · Quick Reference Cards

§10.1 · Warehouse Sizing Guide

X-Small:   1 credit/hr   | Development, testing
Small:     2 credits/hr  | Light analytics
Medium:    4 credits/hr  | Standard workloads
Large:     8 credits/hr  | Heavy ETL
X-Large:  16 credits/hr  | Large-scale analytics
2X-Large: 32 credits/hr  | Enterprise workloads
3X-Large: 64 credits/hr  | Massive scale
4X-Large:128 credits/hr  | Maximum performance

Per-second billing with 60-second minimum

§10.2 · Query Optimization Checklist

□ Use partition pruning (check query profile)
□ Filter early in WHERE clauses
□ Avoid SELECT * in production
□ Use LIMIT for exploration
□ Consider materialized views for aggregations
□ Cluster large tables on frequently filtered columns
□ Use result cache for repeated queries
□ Scale warehouse for heavy operations

§10.3 · Cost Management Checklist

□ Auto-suspend enabled on all warehouses (<5 min)
□ Resource monitors set with thresholds
□ Multi-cluster scaling policy appropriate
□ Storage retention aligned with needs
□ Regular review of Account Usage views
□ Separate warehouses by workload type
□ Use X-Small for development

End of Skill Document

"The goal is not just to store data, but to mobilize it—to help organizations solve their most critical problems inside the AI Data Cloud." — Snowflake Engineering Philosophy

Workflow

Phase 1: Assessment

| Done | Phase completed | | Fail | Criteria not met |

• Gather requirements

| Done | All tasks completed | | Fail | Tasks incomplete |

• Analyze current state

Phase 2: Planning

| Done | Phase completed | | Fail | Criteria not met |

• Develop approach

| Done | All tasks completed | | Fail | Tasks incomplete |

• Set timeline

Phase 3: Execution

| Done | Phase completed | | Fail | Criteria not met |

• Implement solution

| Done | All tasks completed | | Fail | Tasks incomplete |

• Verify progress

Phase 4: Review

| Done | Phase completed | | Fail | Criteria not met |

• Validate outcomes

| Done | All tasks completed | | Fail | Tasks incomplete |

• Document lessons

Examples

Example 1: Standard Scenario

Input: Design and implement a snowflake engineer solution for a production system Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring

Key considerations for snowflake-engineer:

• Scalability requirements
• Performance benchmarks
• Error handling and recovery
• Security considerations

Example 2: Edge Case

Input: Optimize existing snowflake engineer implementation to improve performance by 40% Output: Current State Analysis:

• Profiling results identifying bottlenecks
• Baseline metrics documented

Optimization Plan:

1. Algorithm improvement
2. Caching strategy
3. Parallelization

Expected improvement: 40-60% performance gain

§ 1.2 · Decision Framework — Weighted Criteria (0-100)

Composite Decision Rule:

• Score ≥85: Proceed
• Score 70-84: Conditional with monitoring
• Score <70: Stop and address issues

§ 1.3 · Thinking Patterns — Mental Models

Domain Benchmarks

Done Criteria

• All tasks completed per specification
• Quality standards met
• Stakeholder approval received

Fail Criteria

• Quality defects detected
• Requirements not met
• Timeline/budget overrun