Snowpark for Data Engineers: Python DataFrames, UDFs, Vectorized UDFs, UDTFs, Stored Procedures, pandas on Snowflake, ML Training, Snowflake Notebooks, and Snowpark vs PySpark

Table of Contents

• What Is Snowpark?
• Setting Up a Snowpark Session
• Snowpark DataFrames — The Core API
• DataFrame Transformations
• Writing Data Back to Snowflake
• User-Defined Functions (UDFs)
• Vectorized UDFs — Batch Processing with pandas
• User-Defined Table Functions (UDTFs)
• Snowpark Stored Procedures
• pandas on Snowflake
• Machine Learning with Snowpark
• Snowpark vs PySpark — A Comparison for Data Engineers
• Snowflake Notebooks
• Common Mistakes
• Interview Questions
• Wrapping Up

In the previous post, we covered Snowflake’s SQL-native transformation tools: Streams, Tasks, Dynamic Tables, and MERGE. Those tools work entirely in SQL. But what if your team writes Python? What if you need pandas, scikit-learn, or custom functions that SQL cannot express? That is where Snowpark comes in — Snowflake’s developer framework that lets you write Python (or Java or Scala) code that runs inside Snowflake, not on your laptop or an external server.

Analogy — Cooking in the restaurant kitchen vs taking ingredients home. Before Snowpark, using Python with Snowflake meant extracting data to your laptop (taking ingredients home), processing it locally (cooking in your home kitchen), and loading results back (bringing the dish back to the restaurant). With Snowpark, you walk into the restaurant kitchen (Snowflake’s compute) and cook there — the ingredients (data) never leave the building, you use the restaurant’s professional equipment (Snowflake’s warehouses), and the dish goes straight to the table (Snowflake table). Faster, safer, and no hauling groceries across town.

What Is Snowpark?

Snowpark is a developer framework that provides a DataFrame API (similar to PySpark or pandas) for building data pipelines, UDFs, and stored procedures that run server-side on Snowflake’s compute infrastructure.

What Snowpark gives you:

  1. DataFrame API    -- Read, transform, and write data using Python syntax
                        (lazy evaluation, pushdown to Snowflake SQL engine)
  2. UDFs             -- Custom Python functions callable from SQL
  3. Vectorized UDFs  -- Batch UDFs using pandas for 30-40% better performance
  4. UDTFs            -- Functions that return multiple rows (tabular output)
  5. Stored Procedures -- Multi-step Python programs running server-side
  6. pandas on Snowflake -- Run pandas code directly on Snowflake data (Modin backend)
  7. ML Integration   -- Train scikit-learn, XGBoost models inside Snowflake

  Key principle: code runs WHERE the data is (in Snowflake), not where YOU are.
  Data never leaves Snowflake -- no extraction, no local processing, no re-loading.

Setting Up a Snowpark Session

Local Development

# Install Snowpark
# pip install snowflake-snowpark-python[pandas]

from snowflake.snowpark import Session

# Connection parameters
connection_params = {
    "account": "abc12345.us-east-1",
    "user": "naveen",
    "password": "your_password",          # Use env vars in production
    "role": "DATA_ENGINEER",
    "warehouse": "WH_ETL",
    "database": "RAW_DB",
    "schema": "VENDOR_A"
}

# Create a session
session = Session.builder.configs(connection_params).create()

# Verify connection
print(session.sql("SELECT CURRENT_WAREHOUSE(), CURRENT_DATABASE(), CURRENT_SCHEMA()").collect())
# [Row(CURRENT_WAREHOUSE()='WH_ETL', CURRENT_DATABASE()='RAW_DB', CURRENT_SCHEMA()='VENDOR_A')]

Snowflake Notebooks (In-Browser)

# In Snowflake Notebooks (Snowsight), the session is pre-configured
# No connection setup needed -- just start using it

# The session object is automatically available
df = session.table("orders")
df.show()

Snowpark DataFrames — The Core API

Snowpark DataFrames look like PySpark DataFrames but execute entirely inside Snowflake. They use lazy evaluation — transformations are not executed until you call an action (show, collect, write).

Analogy — A recipe vs cooking. Writing DataFrame transformations is like writing a recipe. df.filter(...) adds “remove the bad eggs” to the recipe. df.group_by(...) adds “sort by region.” Nothing actually happens until you say “Cook!” (call .show() or .collect()). At that point, Snowpark reads the entire recipe, optimizes it (maybe rearranging steps for efficiency), translates it into SQL, and sends it to Snowflake for execution.

from snowflake.snowpark import Session
from snowflake.snowpark.functions import col, lit, upper, trim, sum as sum_, count, avg
from snowflake.snowpark.types import IntegerType, StringType, DecimalType

# Read a table as a DataFrame
df = session.table("RAW_DB.VENDOR_A.ORDERS")

# See the schema
df.schema
# StructType([StructField('ORDER_ID', LongType()),
#              StructField('CUSTOMER_NAME', StringType()),
#              StructField('AMOUNT', DecimalType(10,2)),
#              StructField('ORDER_DATE', DateType())])

# Preview data
df.show()

# Count rows (action -- executes immediately)
print(f"Row count: {df.count()}")

# See the SQL that Snowpark generates (debugging)
print(df.filter(col("AMOUNT") > 100).queries)

DataFrame Transformations

# Select specific columns
df_selected = df.select("ORDER_ID", "CUSTOMER_NAME", "AMOUNT")

# Rename columns
df_renamed = df.select(
    col("ORDER_ID").alias("id"),
    col("CUSTOMER_NAME").alias("name"),
    col("AMOUNT").alias("revenue")
)

# Filter rows
df_filtered = df.filter(col("AMOUNT") > 100)
df_filtered = df.filter((col("REGION") == "Ontario") & (col("AMOUNT") > 50))

# Add/transform columns
df_cleaned = df.with_column("CUSTOMER_NAME", upper(trim(col("CUSTOMER_NAME"))))
df_with_tax = df.with_column("AMOUNT_WITH_TAX", col("AMOUNT") * lit(1.13))

# Drop columns
df_slim = df.drop("INTERNAL_CODE", "TEMP_FLAG")

# Remove duplicates
df_deduped = df.drop_duplicates(["ORDER_ID"])

# Sort
df_sorted = df.sort(col("ORDER_DATE").desc())

# Limit
df_top10 = df.sort(col("AMOUNT").desc()).limit(10)

Aggregations

# Group by and aggregate
revenue_by_region = df.group_by("REGION").agg(
    count("ORDER_ID").alias("ORDER_COUNT"),
    sum_("AMOUNT").alias("TOTAL_REVENUE"),
    avg("AMOUNT").alias("AVG_ORDER_VALUE")
)
revenue_by_region.show()

# Multiple aggregations
daily_stats = df.group_by("ORDER_DATE", "REGION").agg(
    count("*").alias("ORDERS"),
    sum_("AMOUNT").alias("REVENUE")
).sort("ORDER_DATE")

Joins

# Read another table
customers = session.table("RAW_DB.VENDOR_A.CUSTOMERS")

# Inner join
orders_with_customers = df.join(
    customers,
    df["CUSTOMER_ID"] == customers["CUSTOMER_ID"],
    "inner"
).select(
    df["ORDER_ID"],
    customers["CUSTOMER_NAME"],
    df["AMOUNT"],
    df["ORDER_DATE"]
)

# Left join
all_customers = customers.join(
    df,
    customers["CUSTOMER_ID"] == df["CUSTOMER_ID"],
    "left"
)

Window Functions

from snowflake.snowpark.functions import row_number, rank, lag, lead, sum as sum_
from snowflake.snowpark import Window

# Row number per customer
window_spec = Window.partition_by("CUSTOMER_ID").order_by(col("ORDER_DATE").desc())

df_ranked = df.with_column("ROW_NUM", row_number().over(window_spec))

# Running total
running_window = Window.partition_by("CUSTOMER_ID").order_by("ORDER_DATE").rows_between(
    Window.UNBOUNDED_PRECEDING, Window.CURRENT_ROW
)
df_running = df.with_column("RUNNING_TOTAL", sum_("AMOUNT").over(running_window))

# Previous order amount (LAG)
df_with_prev = df.with_column("PREV_AMOUNT", lag("AMOUNT", 1).over(window_spec))

SQL Integration

# Run raw SQL and get a DataFrame
df_sql = session.sql("""
    SELECT region, COUNT(*) as order_count, SUM(amount) as revenue
    FROM RAW_DB.VENDOR_A.ORDERS
    WHERE order_date >= '2026-01-01'
    GROUP BY region
    ORDER BY revenue DESC
""")
df_sql.show()

# Mix SQL and DataFrame operations
df = session.sql("SELECT * FROM orders WHERE status = 'active'")
df_processed = df.filter(col("AMOUNT") > 100).group_by("REGION").count()

Writing Data Back to Snowflake

# Write DataFrame to a new table
df_cleaned.write.save_as_table("ANALYTICS_DB.STAGING.ORDERS_CLEAN", mode="overwrite")

# Append to existing table
df_new_orders.write.save_as_table("ANALYTICS_DB.STAGING.ORDERS_CLEAN", mode="append")

# Write to a temporary table (session-scoped)
df_temp.write.save_as_table("temp_results", table_type="temporary")

# Export to stage as Parquet
df_cleaned.write.copy_into_location(
    "@raw_stage/exports/orders/",
    file_format_type="parquet",
    header=True,
    overwrite=True
)

User-Defined Functions (UDFs)

UDFs let you write custom Python functions and call them from SQL or DataFrames. The function runs server-side on Snowflake compute — data never leaves Snowflake.

# Register a simple UDF
from snowflake.snowpark.functions import udf
from snowflake.snowpark.types import StringType

# Inline UDF
@udf(name="clean_email", is_permanent=True, stage_location="@udf_stage",
     replace=True, return_type=StringType(), input_types=[StringType()])
def clean_email(email: str) -> str:
    if email is None:
        return None
    return email.strip().lower()

# Use in DataFrame
df_with_clean_email = df.with_column("CLEAN_EMAIL", clean_email(col("EMAIL")))

-- Use the UDF in SQL (after registration)
SELECT order_id, clean_email(email) as clean_email
FROM orders;

UDF with External Packages

# UDF that uses an external package
@udf(name="extract_domain", is_permanent=True, stage_location="@udf_stage",
     packages=["tldextract"], replace=True,
     return_type=StringType(), input_types=[StringType()])
def extract_domain(url: str) -> str:
    import tldextract
    if url is None:
        return None
    result = tldextract.extract(url)
    return f"{result.domain}.{result.suffix}"

Vectorized UDFs — Batch Processing with pandas

Vectorized UDFs process data in batches (pandas Series/DataFrames) instead of row by row. They are 30-40% faster than scalar UDFs for numerical computations.

from snowflake.snowpark.functions import pandas_udf
from snowflake.snowpark.types import PandasSeriesType, FloatType
import pandas as pd

# Vectorized UDF -- receives and returns pandas Series
@pandas_udf(name="normalize_amount", is_permanent=True, stage_location="@udf_stage",
            replace=True, return_type=PandasSeriesType(FloatType()),
            input_types=[PandasSeriesType(FloatType())])
def normalize_amount(amount_series: pd.Series) -> pd.Series:
    min_val = amount_series.min()
    max_val = amount_series.max()
    if max_val == min_val:
        return pd.Series([0.0] * len(amount_series))
    return (amount_series - min_val) / (max_val - min_val)

# Use in DataFrame
df_normalized = df.with_column("NORMALIZED_AMOUNT", normalize_amount(col("AMOUNT")))

User-Defined Table Functions (UDTFs)

UDTFs return multiple rows per input — useful for exploding, pivoting, or generating data.

from snowflake.snowpark.functions import udtf
from snowflake.snowpark.types import StructType, StructField, StringType, IntegerType

# UDTF: split a comma-separated string into rows
class SplitToRows:
    def process(self, input_str: str):
        if input_str is None:
            return
        for item in input_str.split(","):
            yield (item.strip(),)

split_udtf = session.udtf.register(
    SplitToRows,
    name="split_to_rows",
    output_schema=StructType([StructField("ITEM", StringType())]),
    input_types=[StringType()],
    is_permanent=True,
    stage_location="@udf_stage",
    replace=True
)

-- Use UDTF in SQL
SELECT t.order_id, items.ITEM
FROM orders t, TABLE(split_to_rows(t.tags)) items;

Snowpark Stored Procedures

Stored procedures run multi-step Python logic server-side. Unlike UDFs (which process individual rows), stored procedures orchestrate entire workflows.

from snowflake.snowpark.functions import col, upper, trim, current_timestamp

# Register a stored procedure
@session.sproc(name="process_daily_orders", is_permanent=True,
               stage_location="@udf_stage", replace=True,
               packages=["snowflake-snowpark-python"])
def process_daily_orders(session: Session, processing_date: str) -> str:
    # Step 1: Read raw data
    raw = session.table("RAW_DB.VENDOR_A.ORDERS").filter(
        col("ORDER_DATE") == processing_date
    )
    raw_count = raw.count()

    # Step 2: Clean and transform
    cleaned = raw.with_column("CUSTOMER_NAME", upper(trim(col("CUSTOMER_NAME"))))\
                  .with_column("PROCESSED_AT", current_timestamp())\
                  .filter(col("AMOUNT") > 0)
    clean_count = cleaned.count()

    # Step 3: Write to silver layer
    cleaned.write.save_as_table(
        "ANALYTICS_DB.STAGING.ORDERS_CLEAN",
        mode="append"
    )

    # Step 4: Log results
    session.sql(f"""
        INSERT INTO ANALYTICS_DB.METADATA.PIPELINE_LOG
        (step_name, processing_date, raw_count, clean_count, status, logged_at)
        VALUES ('process_daily_orders', '{processing_date}',
                {raw_count}, {clean_count}, 'SUCCESS', CURRENT_TIMESTAMP())
    """).collect()

    return f"Processed {clean_count}/{raw_count} rows for {processing_date}"

-- Call the stored procedure from SQL
CALL process_daily_orders('2026-07-19');
-- Returns: "Processed 14580/15420 rows for 2026-07-19"

-- Schedule it with a Task
CREATE TASK daily_orders_task
  WAREHOUSE = WH_ETL
  SCHEDULE = 'USING CRON 0 6 * * * America/Toronto'
AS
  CALL process_daily_orders(CURRENT_DATE()::STRING);

pandas on Snowflake

Snowpark’s pandas integration (powered by Modin) lets you write pandas code that runs directly on Snowflake without pulling data to your laptop.

import modin.pandas as pd
import snowflake.snowpark.modin.plugin  # Activates Snowflake backend

# Read a Snowflake table as a Modin DataFrame (looks like pandas)
df = pd.read_snowflake("RAW_DB.VENDOR_A.ORDERS")

# Standard pandas operations -- but they run on Snowflake compute
df["CUSTOMER_NAME"] = df["CUSTOMER_NAME"].str.upper().str.strip()
df["AMOUNT_WITH_TAX"] = df["AMOUNT"] * 1.13

# Familiar pandas methods
summary = df.groupby("REGION").agg(
    order_count=("ORDER_ID", "count"),
    total_revenue=("AMOUNT", "sum"),
    avg_amount=("AMOUNT", "mean")
)
print(summary)

# Write back to Snowflake
summary.to_snowflake("ANALYTICS_DB.MARTS.REVENUE_BY_REGION", if_exists="replace")

pandas on Snowflake:
  Pros:
    - Familiar API for pandas users -- minimal learning curve
    - Data stays in Snowflake -- no extraction to local machine
    - Scales to billions of rows (unlike local pandas)

  Cons:
    - Not all pandas methods are supported yet
    - Performance depends on Snowflake query optimization
    - Debugging is harder (errors come from Snowflake, not local Python)

Machine Learning with Snowpark

from snowflake.ml.modeling.preprocessing import StandardScaler, OneHotEncoder
from snowflake.ml.modeling.linear_model import LogisticRegression
from snowflake.ml.modeling.pipeline import Pipeline
from snowflake.ml.registry import Registry

# Read training data
train_df = session.table("ANALYTICS_DB.CORE.CUSTOMER_FEATURES")

# Build an ML pipeline
pipeline = Pipeline(
    steps=[
        ("scaler", StandardScaler(input_cols=["TOTAL_ORDERS", "AVG_AMOUNT", "DAYS_SINCE_LAST_ORDER"],
                                   output_cols=["TOTAL_ORDERS_SCALED", "AVG_AMOUNT_SCALED", "DAYS_SCALED"])),
        ("encoder", OneHotEncoder(input_cols=["REGION"],
                                   output_cols=["REGION_ENCODED"])),
        ("model", LogisticRegression(
            input_cols=["TOTAL_ORDERS_SCALED", "AVG_AMOUNT_SCALED", "DAYS_SCALED", "REGION_ENCODED"],
            label_cols=["CHURN_FLAG"],
            max_iter=100
        ))
    ]
)

# Train the model (runs on Snowflake compute)
pipeline.fit(train_df)

# Predict
predictions = pipeline.predict(train_df)
predictions.select("CUSTOMER_ID", "CHURN_FLAG", "PREDICTION").show()

# Register the model
reg = Registry(session=session)
reg.log_model(
    model=pipeline,
    model_name="churn_predictor",
    version_name="v1",
    sample_input_data=train_df.limit(10)
)

Snowpark vs PySpark — A Comparison for Data Engineers

Key difference in how they work:

  Snowpark:
    df.filter(col("amount") > 100).group_by("region").count()
    -> Snowpark generates SQL: SELECT region, COUNT(*) FROM ... WHERE amount > 100 GROUP BY region
    -> SQL runs on Snowflake warehouse (SQL engine)
    -> Result returns to Python

  PySpark:
    df.filter(col("amount") > 100).groupBy("region").count()
    -> Spark creates an execution plan with stages and tasks
    -> Plan runs on Spark cluster (distributed engine)
    -> Data shuffled between worker nodes
    -> Result returns to driver

  Snowpark pushes computation down to Snowflake's SQL engine.
  PySpark distributes computation across a Spark cluster.
  For SQL-expressible operations, Snowpark is often simpler.
  For complex ML and iterative algorithms, PySpark is more flexible.

Snowflake Notebooks

Snowflake Notebooks (GA 2024, enhanced 2026) provide an in-browser notebook environment similar to Jupyter or Databricks notebooks — no local setup needed.

Snowflake Notebooks features:

  Languages: Python (Snowpark), SQL, Markdown
  Environment: runs inside Snowsight (browser-based)
  Packages: install via Anaconda channel (pre-approved packages)
  Session: pre-configured -- no connection setup needed
  Collaboration: share notebooks within your account
  Version control: Git integration for notebook versioning
  Compute: uses your Snowflake warehouse

  When to use Snowflake Notebooks:
    - Quick data exploration without local setup
    - Prototyping Snowpark transformations
    - Training ML models on Snowflake data
    - Sharing analysis with team members

  When to use local development instead:
    - Full IDE features (VS Code, PyCharm)
    - Custom package management
    - CI/CD integration
    - Complex debugging

Common Mistakes

1. Pulling data to local with collect() or to_pandas() for large datasets. df.collect() and df.to_pandas() pull all data to your local machine or the driver node. For 100 million rows, this crashes your session. Use Snowpark transformations to filter and aggregate BEFORE collecting, or use df.to_pandas() only on small aggregated results.

2. Not understanding lazy evaluation. Snowpark DataFrames are lazy — df.filter(...) does not execute anything. Only actions (show, collect, count, save_as_table) trigger execution. If you are debugging and wondering why nothing happens, check that you have called an action.

3. Using Python loops instead of DataFrame operations. Iterating over rows with a Python for loop defeats the purpose of Snowpark. The data is in Snowflake — let Snowflake’s SQL engine process it in parallel. Use DataFrame operations (filter, group_by, with_column) instead of extracting rows and looping in Python.

4. Registering scalar UDFs when vectorized UDFs would be faster. Scalar UDFs process one row at a time. Vectorized (pandas) UDFs process batches of rows using pandas Series. For numerical computations, vectorized UDFs are 30-40% faster. Always use @pandas_udf for math-heavy operations.

5. Not specifying packages in UDF/stored procedure registration. If your UDF or stored procedure imports an external package (numpy, requests), you must declare it in the packages parameter during registration. Forgetting this causes ImportError at runtime because the package is not available on Snowflake’s server-side environment.

6. Using Snowpark when SQL would be simpler. Snowpark is powerful, but a simple INSERT INTO ... SELECT in SQL is often clearer and faster than the equivalent Snowpark DataFrame chain. Use Snowpark when you need Python logic (string parsing, regex, ML models, external API calls). Use SQL for straightforward joins, aggregations, and transformations.

7. Not using Snowpark-optimized warehouses for ML workloads. Standard warehouses allocate memory proportional to warehouse size. Snowpark-optimized warehouses provide 16x more memory per node, which is essential for ML model training and large pandas operations. Use them when you get out-of-memory errors.

8. Mixing up temporary and permanent UDFs/procedures. Temporary UDFs exist only for the current session and disappear when you disconnect. Permanent UDFs persist across sessions and are callable from SQL. For production pipelines, always register as permanent with is_permanent=True and a stage_location.

Interview Questions

Q: What is Snowpark and why is it important for data engineers? A: Snowpark is Snowflake’s developer framework that provides a DataFrame API for Python, Java, and Scala. It lets data engineers write code that runs server-side on Snowflake’s compute, so data never leaves Snowflake. The DataFrame API uses lazy evaluation and pushes operations down to Snowflake’s SQL engine. Snowpark is important because it enables Python-first teams to build data pipelines, register custom functions (UDFs), and train ML models without extracting data to external systems.

Q: How does Snowpark’s lazy evaluation work? A: Snowpark DataFrames are lazily evaluated. Transformations like filter, select, group_by, and with_column build an execution plan but do not execute immediately. Only action methods like show, collect, count, and save_as_table trigger execution. When an action is called, Snowpark translates the entire chain of transformations into optimized SQL, sends it to the Snowflake warehouse, and returns the result. This allows Snowflake to optimize the entire query plan rather than executing operations one at a time.

Q: What is the difference between scalar UDFs and vectorized UDFs in Snowpark? A: Scalar UDFs process one row at a time, receiving individual values and returning individual values. Vectorized UDFs (pandas UDFs) process batches of rows as pandas Series, receiving an entire column batch and returning a Series. Vectorized UDFs are 30-40% faster for numerical computations because they use pandas vectorized operations instead of Python-level loops. Use scalar UDFs for simple string or logic operations. Use vectorized UDFs for math, statistics, and any operation that benefits from batch processing.

Q: How does Snowpark compare to PySpark? A: Both provide DataFrame APIs with lazy evaluation, but they execute differently. Snowpark translates operations into SQL and pushes them down to Snowflake’s SQL engine. PySpark distributes operations across a Spark cluster. Snowpark requires zero infrastructure management (just pick a warehouse size). PySpark requires cluster configuration. Snowpark is best for SQL-heavy teams adding Python capabilities. PySpark is best for Python-first teams doing large-scale data engineering and ML. The API syntax is very similar, so skills transfer between them.

Q: What is pandas on Snowflake? A: pandas on Snowflake uses the Modin library to execute pandas operations directly on Snowflake compute. You write standard pandas code (read, filter, groupby, merge), but instead of running locally on your laptop, the operations run on Snowflake’s warehouses. Data never leaves Snowflake. This scales pandas to billions of rows (local pandas crashes on large data) and keeps data governance intact. Not all pandas methods are supported yet, but common operations work.

Q: When would you use a Snowpark stored procedure vs a Dynamic Table? A: Use a Dynamic Table when the transformation is a straightforward SQL query with a freshness requirement. Dynamic Tables are simpler and automatically managed by Snowflake. Use a Snowpark stored procedure when you need Python-specific logic: ML model inference, complex string parsing, calling external APIs, multi-step workflows with error handling and conditional branching, or operations that require external Python packages. Stored procedures can be scheduled via Tasks, making them part of automated pipelines.

Q: How do you handle dependencies and packages in Snowpark UDFs? A: Specify required packages in the packages parameter when registering the UDF or stored procedure. Snowflake downloads these packages from its curated Anaconda channel. For packages not in the channel, upload wheel files to a stage and reference them. Always test that your packages are available in Snowflake’s environment before deploying to production. After registration, the packages are cached on the warehouse for fast subsequent invocations.

Wrapping Up

Snowpark brings Python’s flexibility to Snowflake’s scale and security. The DataFrame API lets you build transformations without SQL. UDFs and vectorized UDFs extend Snowflake’s SQL with custom Python logic. Stored procedures orchestrate multi-step pipelines. pandas on Snowflake makes the familiar pandas API work at warehouse scale. And Snowflake Notebooks give you a browser-based development environment with zero setup.

The key insight: Snowpark is not a replacement for SQL — it is a complement. Use SQL (and Dynamic Tables) for straightforward transformations. Use Snowpark when you need Python logic, ML capabilities, or custom functions that SQL cannot express. Most production Snowflake environments use both.

Related posts: – Snowflake Overview & Architecture – Snowflake Transformations & CDC – PySpark Foundations – PySpark DataFrame Transformations – Python pandas Deep Dive