After studying this material, you should be able to:
- Explain the core problem of scattered/inconsistent metrics in data-driven organizations
- Describe what a semantic layer is and why it matters
- Understand how DataJunction (DJ) solves metric management challenges
- Identify the key components and architecture of DataJunction
- Recognize real-world applications of semantic layers in experimentation platforms
Step-by-Step Teaching Guide
Step 1: Understanding the Core Problem
Why Metrics Become Messy
Imagine a large company where 100 different teams all track "user engagement" — but each team defines it slightly differently:
Team A: engagement = clicks / total users
Team B: engagement = time spent > 5 minutes
Team C: engagement = clicks + shares + comments
This creates three critical problems:
| Problem | Real-World Impact |
|---|---|
| Scattered definitions | Nobody agrees on one truth |
| Redundant datasets | Same data stored multiple times |
| Inconsistent pipelines | Different results for same question |
Netflix's Specific Pain Point
At Netflix, this problem was most visible in their Experimentation Platform (A/B testing system).
Old Process to Add ONE New Metric:
├── Requires tribal knowledge (undocumented know-how)
├── Complex engineering workflows
├── Multiple teams involved
└── Result: Weeks to onboard a single metric ❌
Key Insight: When adding a metric takes weeks, teams stop experimenting. Slow metrics = slow innovation.
Step 2: What Is a Semantic Layer?
Simple Definition
A semantic layer sits between your raw data and your business users. It translates technical data into consistent business definitions.
Raw Data Semantic Layer Business Users
───────── ────────────── ──────────────
user_events → "Monthly Active → Dashboard
clicks Users = unique Reports
timestamps users with ≥1 Experiments
event per month" AI/LLM queries
What a Semantic Layer Stores
Think of it as a dictionary + map for your data:
- 📖 Metrics — What you measure (revenue, engagement, retention)
- 📐 Dimensions — How you slice it (by country, device, date)
- 🔗 Relationships — How metrics and dimensions connect
- 📝 Definitions — Why each metric is calculated a specific way
Step 3: What Is DataJunction (DJ)?
Origin Story
Timeline:
2015 → Facebook creates internal project for "metrics portability"
└── Problem: Rebuilding metrics every platform upgrade
└── Solution: Abstract metric definitions from computation
2021 → Beto Dealmeida starts DJ as open-source GitHub project
2021+ → Netflix engineers expand and implement it
└── Authors: Olek Gorajek, Samuel Redai, Yian Shang
Why Netflix Chose DJ Over Alternatives
Netflix evaluated multiple tools:
| Tool | Strength | Weakness |
|---|---|---|
| Mando (internal) | Netflix-native | Limited scope |
| Minerva (AirBnB) | Proven at scale | Missing key feature |
| DataJunction | SQL parsing + graph storage | Needed development |
DJ's Winning Feature: SQL Graph Engine
DJ stores all definitions in a connected graph — similar to how databases store metadata about views.
Traditional Approach: DJ Approach:
───────────────────── ────────────
Metric A (isolated) Metric A ──→ Dimension X
Metric B (isolated) ↓ ↓
Metric C (isolated) Metric B ──→ Dimension Y
↓
Metric C (inherits from A+B)
Why this matters: You can trace any metric back to its source, understand dependencies, and reuse definitions automatically.
Step 4: DJ's Architecture at Netflix
The Three-Layer Structure
┌─────────────────────────────────────────────────────┐
│ │
│ LEFT: Raw Data MIDDLE: DJ Services │
│ ───────────── ───────────────── │
│ • Data tables ←───→ • Semantic Layer Engine │
│ • Event logs • SQL Parser │
│ • Pipelines • Graph Storage │
│ • Rich API │
│ │ │
│ RIGHT: Access Layer │
│ ──────────────── │
│ • Dashboards │
│ • Experiments │
│ • Data Explorer │
│ • LLM/AI queries │
└─────────────────────────────────────────────────────┘
The "Octopus" Concept
DJ can reach into many functional areas:
[DJ Core]
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Metadata SQL Generation Data Access
Storage & Parsing Layer
│ │ │
↓ ↓ ↓
Governance Dashboards Experiments
& Discovery (Superset) Platform
Netflix's Strategy: Focus on the core engine first. Everything else can be added later without rebuilding the foundation.
Step 5: Cubes — The Serving Interface
What Are Analytical Cubes?
A cube packages metrics and dimensions together for fast, organized data access.
Example Cube: "Streaming Performance"
┌─────────────────────────────────────┐
│ METRICS DIMENSIONS │
│ ───────── ────────── │
│ • Play rate • Country │
│ • Buffer rate • Device type │
│ • Completion % • Date │
│ • Content genre │
└─────────────────────────────────────┘
Why DJ Uses Cubes
| Benefit | Explanation |
|---|---|
| Familiarity | Data professionals already know this concept |
| Serving interface | Delivers both definitions AND fast data |
| Easy integration | Simple to connect to tools like Druid, Superset |
| Materialization | Can be stored directly in fast query engines |
Step 6: The Feedback Loop — DJ's Superpower
Linking Dashboards Back to Definitions
User sees metric on dashboard
│
↓
Clicks link → Goes to DJ definition
│
↓
Sees: How metric is calculated
What data sources it uses
What dimensions are available
│
↓
Runs ad-hoc analysis or modifies metric
│
↓
Changes flow back into DJ ecosystem ✅
Real-World Value: Instead of asking "why does this number look wrong?", users can immediately inspect the definition, trace the data, and fix issues themselves.
Step 7: Impact on Experimentation
Before vs. After DJ
BEFORE DataJunction: AFTER DataJunction:
──────────────────── ───────────────────
Weeks to add metric → Days (or hours)
Tribal knowledge required → Self-service UI/API
Scattered definitions → Single source of truth
Hard to debug → Traceable graph
Manual SQL writing → Auto-generated SQL
Why This Matters for A/B Testing
Experiment Quality Chain:
Good Data → Trustworthy Metrics → Reliable Results → Better Decisions
If metrics are broken:
Bad Metrics → Misleading Results → Wrong Decisions → Wasted resources ❌
Step 8: The Bigger Vision
DJ's Future at Netflix
Current State: Future State:
───────────── ────────────
Experimentation → ALL analytics at Netflix
platform only unified under DJ
Internal tools → + LLM/AI integration
only (accountable AI answers
about business metrics)
Why LLM Integration Matters
Without DJ + LLM: With DJ + LLM:
───────────────── ──────────────
"What is our retention rate?" "What is our retention rate?"
→ AI gives vague answer → AI gives precise answer
→ No source cited → Cites exact DJ definition
→ Can't verify → Links to data lineage ✅
Summary: Key Concepts to Remember
┌─────────────────────────────────────────────────────────┐
│ DATAJUNCTION ESSENTIALS │
├─────────────────────────────────────────────────────────┤
│ │
│ PROBLEM: Scattered, inconsistent, slow metrics │
│ │
│ SOLUTION: Semantic layer with graph-based SQL engine │
│ │
│ CORE FEATURES: │
│ • SQL parsing (input) + SQL generation (output) │
│ • Connected graph of all definitions │
│ • Cubes as serving interface │
│ • Rich API for integrations │
│ │
│ KEY BENEFIT: Single source of truth for metrics │
│ that any tool can consume │
│ │
│ DESIGN PHILOSOPHY: Build the core right first, │
│ expand later │
└─────────────────────────────────────────────────────────┘
Quick Knowledge Check
Test yourself with these questions:
- Why did Netflix's old metric system slow down experimentation?
- What specific feature made DJ stand out from competitors?
- How does a semantic layer differ from a regular database?
- What is a cube and why is it useful as a serving interface?
- Explain the feedback loop between dashboards and DJ definitions
- Why is a graph-based storage approach better than isolated metric definitions?