Consider the following Snowpark Python code that creates a DataFrame and applies a filter:
from snowflake.snowpark import Session
session = Session.builder.configs({"account": "xyz", "user": "abc", "password": "***", "role": "SYSADMIN", "warehouse": "COMPUTE_WH", "database": "TEST_DB", "schema": "PUBLIC"}).create()
df = session.create_dataframe([(1, 'apple'), (2, 'banana'), (3, 'cherry')], schema=["id", "fruit"])
filtered_df = df.filter(df["id"] > 1)
result = filtered_df.collect()What will result contain?
from snowflake.snowpark import Session session = Session.builder.configs({"account": "xyz", "user": "abc", "password": "***", "role": "SYSADMIN", "warehouse": "COMPUTE_WH", "database": "TEST_DB", "schema": "PUBLIC"}).create() df = session.create_dataframe([(1, 'apple'), (2, 'banana'), (3, 'cherry')], schema=["id", "fruit"]) filtered_df = df.filter(df["id"] > 1) result = filtered_df.collect()
Remember that filter keeps rows where the condition is true.
The filter df["id"] > 1 keeps rows with id 2 and 3. The collect() method returns these rows as a list of Row objects.
You want to create a Snowpark DataFrame from a Python list of tuples. Which method should you use?
Look for the method that directly accepts Python data.
The create_dataframe() method creates a DataFrame from local Python data like lists or tuples.
collect() on a Snowpark DataFrame?In Snowpark for Python, what is the behavior of the collect() method on a DataFrame?
Think about what happens when you want to get all data from Snowflake to Python.
The collect() method runs the query and fetches all results into a list of Row objects in Python memory.
When configuring a Snowpark Session in Python, which option is the most secure way to handle authentication?
Think about how to keep passwords safe and not expose them in code.
Using environment variables or a secrets manager keeps credentials out of code and reduces risk of leaks.
In a Python app using Snowpark, how should you manage the Session object to optimize resource use and avoid errors?
Consider resource efficiency and connection limits.
Reusing a single Session per app run reduces overhead and avoids exhausting connections. Closing it at the end cleans up resources.