100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Data Warehouse & Analytics Engineering
25 minadvanced

Embedding Analytics and Row-Level Security

Embedding analytics means displaying BI tool dashboards inside a product application — the IPL fantasy platform shows each user their personal performance dashboard embedded in the app. Row-Level Security (RLS) ensures each embedded user sees only the rows they are authorised to see — a team analyst sees only their team's delivery data. Together, embedding and RLS enable multi-tenant analytics products where the same dashboard infrastructure securely serves thousands of users, each seeing their own personalised data slice powered by the same underlying warehouse tables.

The standard embedding pattern uses server-side signed JWT tokens. When a user navigates to the analytics section, the backend generates a JWT signed with a shared secret containing the user's identity and data access scope — `{team: 'MI', role: 'analyst'}`. The application embeds the BI tool dashboard in an iframe with this JWT as a parameter. The BI tool validates the JWT, extracts the user context, and applies the corresponding RLS filter to every query — ensuring all warehouse SQL includes `WHERE batting_team = 'MI'`.

Analogy🏏Cricket
🏏 Think of it like cricket: OLTP is the IPL's live ticketing counter — it handles thousands of simultaneous seat reservations, each requiring a precise single-seat record update with immediate confirmation. Speed per transaction and data consistency under concurrent updates are everything. OLAP is the IPL's season statistics department — it runs complex analytical queries across every ball bowled in every match of every season to produce the published rankings, economy rates, and historical comparisons. No one books a seat through the statistics department, and no broadcaster calls the ticketing counter for Bumrah's career economy rate. The two workloads demand completely different systems. Just as the ticketing counter is built for speed and correctness on one seat at a time and would buckle if asked to tally a decade of attendance mid-sale, an OLTP row-store excels at single-record writes but chokes on full-table aggregation; and just as the statistics department pores over millions of past deliveries but would be hopeless at booking a live seat under contention, the OLAP columnar engine sweeps billions of rows yet is the wrong tool for a fast single-row update. The physical design of each — row-oriented for the counter, columnar for the stats desk — is what makes it superb at its own job and unfit for the other's.
Lesson 22 of 35
0% complete