Query Your Data Guide
Last updated
Last updated
Prerequisite: Before using this walkthrough, please ensure that you’ve first done the Schema Monitoring and Automatic Sensitive Data Discovery walkthrough.
Prerequisites: Ensure you are using an Immuta-enabled cluster, as described in Part 3 of the POV Data Setup.
You must consider the Databricks user you are using. If you are a Databricks Admin, certain scenarios may allow you to bypass Immuta security controls. In Part 3 of the POV Data Setup you may have created a non-admin user, and it’s best to use that user in lieu of (or in combination with) your admin user, especially when querying your data in Databricks. When using the admin user, here are scenarios to consider, but the workflow that sent you to this page will describe if you should use the admin user in your queries or not:
Immuta enforcement occurs by rewriting the SQL query under the covers prior to the Databricks catalyst planning. This means all data interactions in Databricks must occur through a metastore SQL query - no direct file access. If you attempt direct file access to your cloud storage (S3, ADLS, Google Storage) it will be blocked. The below notebook will demonstrate querying data into a DataFrame in each language using this pattern. Note it is possible to configure direct file access using Immuta, but that is limited to file-level controls only and is not covered in this POV Guide. Please work with your Immuta expert for more information if you want direct file reads.
We highly recommend abstracting structured data with a metastore if you are not already doing so.
Run a query:
Download the following Notebook* to run queries.
Consider using an incognito/private window to use two different users (your admin user and the non-admin user you potentially created) to run queries, importing that notebook for both.
*That notebook contains generic queries; some of the walkthroughs may instruct you to run different queries.
Prerequisite: Ensure you have configured the Databricks SQL integration with Immuta as described in Part 3 of the POV Data Setup.
Immuta enforces policy by creating Databricks SQL views that contain all the policy logic.
When moving to production, for everyone but people that need to manage the raw tables, you should REVOKE access from the raw tables and instead only let users query these Immuta-managed views.
Those views are created in the database configured in Part 3 of the POV Data Setup
Table name of the raw table is maintained (as the view name) with the database appended to the front to avoid collisions.
Immuta handles GRANTing access to those views.
Run a query:
Make sure you select SQL from the upper left menu in Databricks.
Click Create → Query.
Select the database name used when configuring the integration in Part 3 of the POV Data Setup.
Run the following queries in the worksheet* (you must include the database):
select * from [database name from above].immuta_pov_immuta_fake_credit_card_transactions limit 100;
select * from [database name from above].immuta_pov_immuta_fake_hr_data limit 100;
Consider using an incognito/private window to use two different users (your admin user and the non-admin user you potentially created) to run queries.
*These are generic queries, some of the walkthroughs may instruct you to run different queries.
Prerequisite: Ensure you have configured the Snowflake integration with Immuta as described in Part 3 of the POV Data Setup.
Immuta enforces policy by creating Snowflake views that contain all the policy logic. Those views are available to the PUBLIC role in Snowflake, which is the foundation of every role. The outcome of this means:
When moving to production, for everyone but people that need to manage the raw tables, you should REVOKE access from the raw tables and instead only let users query these Immuta-managed views.
Since PUBLIC is the foundation of every role, you no longer need to manage Snowflake roles for your end users, roles can be limited to defining warehouse access.
You do not need to explicitly GRANT access to those views, that is handled by Immuta by GRANTing to the PUBLIC role (and further protecting using subscription policies you will configure in a future walkthrough).
Those views are created in the database configured in Part 3 of the POV Data Setup.
Schema name of the raw table is maintained.
Table name of the raw table is maintained (as the view name).
Run a query:
Create a new worksheet.
You must select the appropriate role/database/schema to query the views:
Role: any or just PUBLIC.
Warehouse: any.
Database: the database name used when configuring the integration in Part 3 of the POV Data Setup (default is IMMUTA).
Schema: POV_DATA (or whatever you named the schema in Part 2 of the POV Data Setup).
Run the following queries in the worksheet*:
select * from immuta_fake_credit_card_transactions limit 100;
select * from immuta_fake_hr_data limit 100;
Consider using an incognito/private window to use two different users (your admin user and the non-admin user you potentially created) to run queries.
*These are generic queries, some of the walkthroughs may instruct you to run different queries.
Prerequisite: Ensure you have configured the Synapse integration with Immuta as described in Part 3 of the POV Data Setup.
Immuta enforces policy by creating Synapse views that contain all the policy logic within a schema (contained in your dedicated SQL pool) that is created in Part 3 of the POV Data Setup.
When moving to production, for everyone but people that need to manage the raw tables, you should REVOKE access from the raw tables and instead only let users query these Immuta-managed views. In other words, only give them access to the schema created in Part 3 of the POV Data Setup.
Those views are created in the schema configured in Part 3 of the POV Data Setup.
Table name of the raw table is maintained with the database name appended to the front to avoid conflicts.
Immuta handles GRANTing access to those views.
Run a query:
From Synapse Studio click on the Data menu on the left.
Click on the Workspace tab.
Expand databases and you should see the dedicated pool you created: immuta_pov.
Expand immuta_pov and you should see the schema you created in Part 3 of the POV Data Setup.
Select that schema.
Select New SQL script and then Empty script.
Run the following queries* (note that Synapse does not support LIMIT and the SQL is case sensitive:
SELECT TOP 100 * FROM [schema].immuta_pov_immuta_fake_credit_card_transactions;
SELECT TOP 100 * FROM [schema].immuta_pov_immuta_fake_hr_data;
*These are generic queries, some of the walkthroughs may instruct you to run different queries.
Prerequisite: Ensure you have configured the Starburst (Trino) integration with Immuta as described in Part 3 of the POV Data Setup.
Immuta enforces policy by creating views that contain all the policy logic. Those views are created within a catalog that is created in Part 3 of the POV Data Setup.
The outcome of this means:
When moving to production, for everyone but people that need to manage the raw tables, you should REVOKE access from the raw tables and instead only let users query these Immuta-managed views.
You do not need to explicitly GRANT access to those views, that is handled by Immuta.
Those views are created in the catalog configured in Part 3 of the POV Data Setup.
Schema name of the raw table is maintained.
Table name of the raw table is maintained (as the view name).
Run a query:
Since Starburst (Trino) does not have a user interface, please use your tool of choice to connect.
Once connected, you should see the catalog that was created in Part 3 of the POV Data Setup.
Expand that and you should see the pov_data schema.
Expand that and you should see the secure views Immuta created, you can run these queries*:
select * from [catalog].pov_data.immuta_fake_credit_card_transactions limit 100;
select * from [catalog].pov_data.immuta_fake_hr_data limit 100;
*These are generic queries, some of the walkthroughs may instruct you to run different queries.
Prerequisites:
Ensure you have configured the Redshift integration with Immuta as described in Part 3 of the POV Data Setup.
You must use an RA3 instance type; this is because Immuta requires cross-database views and those are only supported in Redshift RA3 instance types.
If you get an error like this when querying the Immuta-generated views, you are NOT on an RA3 instance type:
Immuta enforces policy by creating views that contain all the policy logic. Those views are created within a database that is created in Part 3 of the POV Data Setup.
The outcome of this means:
When moving to production, for everyone but people that need to manage the raw tables, you should REVOKE access from the raw tables and instead only let users query these Immuta-managed views.
You do not need to explicitly GRANT access to those views, that is handled by Immuta.
Those views are created in the database configured in Part 3 of the POV Data Setup.
Schema name of the raw table is maintained
Table name of the raw table is maintained (as the view name)
Run a query:
Since Redshift does not have a user interface, please use your tool of choice to connect.
Once connected, you should see the database that was created in Part 3 of the POV Data Setup.
Expand that and you should see the pov_data schema.
Expand that and you should see the secure views Immuta created, you can run these queries*:
select * from [database].pov_data.immuta_fake_credit_card_transactions limit 100;
select * from [database].pov_data.immuta_fake_hr_data limit 100;
*These are generic queries, some of the walkthroughs may instruct you to run different queries.