Snowflake

Go to Database Configuration Instructions

Follow these steps to connect Looker to Snowflake:

Create a Looker user on Snowflake and provision access.
Set up a database connection in Looker.

Create a Looker User on Snowflake

We recommend the following commands for creating the Looker user. Make sure to run each line individually.

Optionally, add in the ON FUTURE keyword to persist GRANT statements on newly created objects. We recommend running this for tables in all schemas that Looker will use so you are not required to re-run GRANT statements as new tables are created.

-- change role to ACCOUNTADMIN use role ACCOUNTADMIN; -- create role for looker create role if not exists looker_role; grant role looker_role to role SYSADMIN; -- Note that we are not making the looker_role a SYSADMIN, -- but rather granting users with the SYSADMIN role to modify the looker_role -- create a user for looker create user if not exists looker_user password = '<enter password here>'; grant role looker_role to user looker_user; alter user looker_user set default_role = looker_role default_warehouse = 'looker_wh'; -- change role use role SYSADMIN; -- create a warehouse for looker (optional) create warehouse if not exists looker_wh -- set the size based on your dataset warehouse_size = medium warehouse_type = standard auto_suspend = 1800 auto_resume = true initially_suspended = true; grant all privileges on warehouse looker_wh to role looker_role; -- grant read only database access (repeat for all database/schemas) grant usage on database <database> to role looker_role; grant usage on schema <database>.<schema> to role looker_role; -- rerun the following any time a table is added to the schema grant select on all tables in schema <database>.<schema> to role looker_role; -- or grant select on future tables in schema <database>.<schema> to role looker_role; -- create schema for looker to write back to use database <database>; create schema if not exists looker_scratch; use role ACCOUNTADMIN; grant ownership on schema looker_scratch to role SYSADMIN revoke current grants; grant all on schema looker_scratch to role looker_role;

If you paste the above commands as a batch into the Snowflake connection panel, check the All Queries box to ensure all lines are run. By default, Snowflake runs only lines that are selected:

Adding the Connection

Follow the instructions for connecting Looker to your database, noting a few special settings:

SSL must be turned on.
Specify an account and warehouse via JBDC parameters. Use this format:
account=[account_name]&warehouse=[warehouse_name]
The account name is not the same as the database username. The Snowflake instance account is usually the first part of your Snowflake instance host URL. If your instance URL is mycompany.snowflake.com, your account name is mycompany.

If your Snowflake instance host URL includes an AWS region, do not include it in the account name. For example, if your Snowflake instance host URL is mycompany.us-east-1.snowflakecomputing.com, enter mycompany as your account name.
Whitelisting IPs is not required.
Be sure to include a default schema in the Schema field. You will still be able to query other schemas, but Snowflake expects this parameter in the JDBC string.
In the Temp Database field, the schema name LOOKER_SCRATCH should be in all caps. Snowflake changes the name to all caps on its end, so you can’t connect if you use lowercase on the Looker Connection Settings page.

Here is an example setup:

Designating Snowflake Warehouses on a Per-Group or Per-User Basis

You can use Looker user attributes to assign separate Snowflake warehouses to individual Looker users or groups. This is useful, for example, if you have users who require different levels of computing power. You can assign a warehouse with greater computing resources to just those users who need it, while assigning a warehouse with lesser resources to users with lesser needs.

To designate warehouses on a per-group or per-user basis:

Add the groups or users in Looker.
Define a user attribute to store the Snowflake warehouse names:
In the user attribute you just defined, assign the warehouse name values to the groups or users:
In the Additional Params field on the Connection Settings page, add the following, replacing snowflake_warehouse with the name of the user attribute you defined:

warehouse={{ _user_attributes['snowflake_warehouse'] }}

For example:
To test the individual connection settings, you can sudo as a user to whom you assigned a warehouse name value.

You can see more detailed instructions for this procedure on the Red Pill Analytics blog.

Snowflake’s Autosuspend Feature

Snowflake warehouses have an autosuspend feature that is enabled by default. After a specified period, the warehouse will autosuspend. If the warehouse is suspended, all queries produce an error. This error is not visible via dashboards (no data is normally shown), but it is visible when querying with the Explore page.

Snowflake also has an autoresume feature that will resume the warehouse when it is queried. However, resuming the warehouse can take up to five minutes, causing queries to hang for five minutes before returning. These features can be configured on the Warehouses tab:

PDT Support

For persistent derived table support, create a Snowflake user account for PDTs that has write access to your database and the default schema. On the Looker Connections Settings page, check the Persistent Derived Tables box. Then, in the PDT Overrides column, enter the username and password of the PDT user. See the Connecting Looker to Your Database documentation page for more information.

PDTs are not supported for Snowflake connections that use OAuth.

Configuring OAuth for Snowflake Connections

Looker supports OAuth for Snowflake connections, meaning that each Looker user authenticates in to Snowflake and authorizes Looker to run queries on the database with their own Snowflake user account.

OAuth allows database administrators to:

Audit which Looker users are running queries against the database
Enforce role-based access controls using Snowflake permissions
Use OAuth tokens for all processes and actions that access Snowflake, instead of embedding Snowflake IDs and passwords in multiple places
Revoke authorization for a given user through Snowflake

With Snowflake connections that use OAuth, users must log in again periodically when their OAuth tokens expire. The duration of validity for Snowflake OAuth tokens is set through Snowflake itself.

Note the following for Snowflake with OAuth:

If a user allows their Snowflake token to expire, any schedules or alerts that they own will be affected. To guard against this, Looker will send a notification email to the owner of each schedule and each alert before the current active Snowflake OAuth token expires. Looker will send these notifications emails 14 days, 7 days, and 1 day before the token expires. The user can go to their Looker user page to reauthorize Looker to the database and avoid any interruption to their schedules and alerts. See the User page documentation for details.
Since Snowflake connections that use OAuth are “per user,” caching policies are also per user, and not just per query. So instead of using cached results whenever the same query is run within the caching period, Looker will use cached results only if the same user has run the same query within the caching period. For further information on caching, see the Caching Queries and Rebuilding PDTs with Datagroups documentation page.
Persistent derived tables (PDTs) are not supported for Snowflake connections with OAuth.
Admins, when they sudo as another user, will use that user’s OAuth access token. If the user’s access token is expired, the admin will not be able to have a new token created on behalf of the sudoed user; the user will have to log in to Snowflake and reauthorize Looker. See the Users documentation page for information on using the sudo command.

Configuring a Snowflake Database for OAuth with Looker

To create a Snowflake connection to Looker using OAuth, you must set up the OAuth integration in Snowflake. This requires a Snowflake user account with ACCOUNTADMIN permission.

You will need a different security integration for each Looker instance you have.

Run the following command in Snowflake:

CREATE SECURITY INTEGRATION LOOKER TYPE = OAUTH ENABLED = TRUE OAUTH_CLIENT = LOOKER OAUTH_REDIRECT_URI = 'https://<looker_hostname>/external_oauth/redirect';

Where <looker_hostname> is the hostname of your Looker instance.
Get the OAuth client ID and secret by running the following command:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('LOOKER');

The response will have an OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET that you will need later in this procedure.
In Looker, create a new connection to your Snowflake warehouse, as described on the Connecting Looker to Your Database documentation page. When creating the new connection, check the Use OAuth checkbox. When you select Use OAuth, you will see the OAuth Client ID and OAuth Client Secret fields:
Paste in the OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET values from Step 2.
Complete the rest of the procedure for Connecting Looker to Your Database.

Once you configure Looker’s connection to your database, you can test the connection itself by doing either of the following:

Click the Test These Settings button at the bottom of the Connections Settings page, as described on the Connecting Looker to Your Database documentation page.
Click the Test button by the connection’s listing on the Connections admin page, as described on the Connections documentation page.

Beyond that, you can test the connection and deploy it on a model by doing the following:

In Looker, go into Development Mode.
Navigate to the project files for a Looker project that uses your Snowflake connection.
Open a model file and replace the model’s connection value with the name of the new Snowflake connection, then save the model file.
Open one of the model’s Explores or dashboards and run a query. When you try to run a query, Looker will prompt you to log in to Snowflake.
Follow the login prompts for Snowflake and enter your Snowflake credentials.

Once you successfully log in to Snowflake, Looker will return you back to your query. If your query runs correctly, you can commit the new connection value and deploy your changes to production.

Signing In to Snowflake to Run Queries

Once the Snowflake connection is set up for OAuth, users will be prompted to log in to Snowflake before running queries. This includes queries from Explores, dashboards, Looks, and SQL Runner. Here’s an example Explore that uses a Snowflake connection for which the user must log in:

Users can also log in to Snowflake from the OAuth Connection Credentials section on their Account page.

To log in to your Snowflake account via Looker:

Select Account from the user menu.
Scroll down to the OAuth Connection Credentials section and click the Log In button for the desired Snowflake database.
Enter your Snowflake credentials through Snowflake’s interface and click Log In.
Click Allow to give Looker access to your Snowflake account.

Once you log in to Snowflake through Looker, you can log out or reauthorize your credentials at any time through your Account page, as described on the Personalizing Your User Account documentation page.

Feature Support

Looker’s ability to provide some features depends on whether the database dialect can support them.

In the current Looker release, Snowflake supports the following Looker features:

Next Steps

After you have connected your database to Looker, you’re ready to configure sign-in options for your users.