Unity Catalog & Data Quality – Secure, Governed, and Trusted Data
Story
Imagine your company, ChocoVault, is a large chocolate manufacturer with multiple teams working on different data sets scattered across many tools and clusters. Previously, managing data access was like juggling many loose balls:
- Permissions were scattered across clusters, tables, and users.
- Different teams used different systems, creating confusion.
- Tracking who accessed or changed data was difficult.
- Sharing data between teams meant creating copies, wasting space, and causing version confusion.
In short, data governance was fragmented and complicated.
The Solution: Unity Catalog — The Centralized Data Gatekeeper
Now, Unity Catalog acts as one secure control tower for all your company’s data in Databricks, providing:
- Centralized Permissions: Manage who can access data, no matter the workspace or cluster — all in one place.
- Structured Data Organization: Organize data like a library — Catalog (big container) → Schema (section) → Tables (books).
- Audit & Lineage: See who accessed or changed data, when, and track the full journey of data from source to final report.
- Role-Based Access with SSO & SCIM: Integrate with your company’s identity system so roles and permissions sync automatically.
- Row/Column Level Security: Protect sensitive data by hiding or filtering rows and columns based on who’s asking.
- Cross-Workspace Sharing: Share live data across teams without making multiple copies.
Step-by-Step Story: How ChocoVault Uses Unity Catalog
1. Creating the Data Framework: Catalog, Schema, and Tables
You start by creating a Catalog called choco_vault (your entire data universe), a Schema called Dairy_milk (a section within the catalog), and a Table called ghee_choco which holds information about your products.
Create Catalog choco_vault;
Use Catalog choco_vault;
Create Schema Dairy_milk;
Create Table Dairy_milk.ghee_choco (
id INT,
size INT,
taste STRING
);
Simple Explanation:
Think of this like setting up your data library with shelves (catalogs), book sections (schemas), and books (tables).
2. Controlling Access with Roles and Permissions
You create groups for different teams like “Data Analytics” and “Data Engineers.” Then, assign them rights:
- Analytics team can view the data.
- Engineers can change the data structure.
Grant Select on Table Dairy_milk.ghee_choco to 'Data Analytics';
Grant Modify on Schema Dairy_milk to 'Data Engineers';
Create Group Data_Analytics;
Create Group AMS_EDW_SUPPORT;
Alter Group Data_Analytics ADD User('hcprofs@company.com', 'ch@na.company.com');
Simple Explanation:
This is like giving your marketing team permission to read sales reports, but only your engineers can update the product details.
3. Fine-Grained Control: Row-Level Filtering
You don’t want everyone to see all data. For example, only Indian users can see certain rows:
Create or replace Function is_indian_user(user String)
Returns BOOLEAN
Return user IN ('harish@company.com', 'riya@company.com');
Alter Table Dairy_milk.ghee_choco
SET ROW filter Dairy_milk.is_indian_user(added_by);
Simple Explanation:
It’s like a filter that only shows each employee their own salary info or lets bank staff see only their branch’s data.
4. Checking Who Can Do What: Verifying Permissions
You can easily check who has access to what with:
Show Grants on Table Dairy_milk.ghee_choco;
Show Grants on Schema Dairy_milk;
Simple Explanation:
This is your security checklist, making sure permissions are set correctly.