Looker

---
name: looker
description: "Google Cloud Looker expert. Deep expertise in LookML semantic modeling, Explores, derived tables, caching with datagroups, embedded analytics, governance, Git-based development workflows, and Gemini AI integration. WHEN: \"Looker\", \"LookML\", \"LookML model\", \"LookML view\", \"LookML explore\", \"LookML refinement\", \"LookML extends\", \"Looker Explore\", \"Looker dashboard\", \"Looker embed\", \"Looker SDK\", \"Looker API\", \"Looker Studio\", \"Looker Studio Pro\", \"Open SQL Interface\", \"Looker semantic layer\", \"datagroup\", \"PDT\", \"persistent derived table\", \"derived table\", \"aggregate table\", \"aggregate awareness\", \"Looker connection\", \"Looker permissions\", \"access_filter\", \"access_grant\", \"Looker Blocks\", \"Looker Marketplace\", \"Looker Extension\", \"Extension Framework\", \"Looker Gemini\", \"Conversational Analytics\", \"LookML Assistant\", \"Looker Core\", \"customer-hosted Looker\"."
license: MIT
---

# Looker

This skill covers Looker, Google Cloud's enterprise business intelligence and analytics platform, in depth:

- LookML semantic modeling (views, models, Explores, dimensions, measures, dimension groups, derived tables, extends, refinements)
- Caching and performance (datagroups, PDTs, incremental PDTs, aggregate awareness, query caching)
- Data exploration (Explores, custom fields, merged results, cross-filtering, drill-down)
- Embedded analytics (SSO embed, Embed SDK, full-app embedding, Extension Framework, Spartan mode)
- Governance and security (access filters, access grants, model sets, permission sets, user attributes, row-level security)
- Git-based development (branching, pull requests, validation, data tests, deployment, Advanced Deploy Mode)
- Universal Semantic Layer (Open SQL Interface, BI connectors for Tableau/Power BI/Sheets, Conversational Analytics API)
- Looker Studio integration (Looker Studio Pro, Looker Studio in Looker, shared governance)
- AI features (Conversational Analytics, LookML Assistant, Visualization Assistant, Code Interpreter -- powered by Gemini)
- Deployment options (Looker Google Cloud Core, customer-hosted on VMs or Kubernetes)
- Data delivery (scheduled deliveries, conditional alerts, datagroup-triggered delivery)
- Extension Framework and Marketplace (custom applications, Looker Blocks, custom visualizations)

Looker is a managed/cloud service with continuous updates. There are no discrete version agents -- guidance applies to the current platform (Looker 25.x as of 2026).

## How to Approach Tasks

1. **Classify** the request:
   - **LookML modeling / semantic layer** -- Load `references/architecture.md` for LookML constructs, views, Explores, derived tables, refinements, extends, models
   - **Performance / caching / PDTs** -- Load `references/best-practices.md` for caching strategy, datagroups, PDTs, aggregate awareness; `references/diagnostics.md` for slow Explore diagnosis
   - **Troubleshooting** -- Load `references/diagnostics.md` for slow Explores, PDT failures, connection issues, LookML validation errors, query performance
   - **Embedding / integration** -- Load `references/architecture.md` for embedding methods, Extension Framework, Universal Semantic Layer
   - **Governance / security / permissions** -- Load `references/best-practices.md` for permission model, access filters, code review workflows
   - **Git workflow / deployment** -- Load `references/best-practices.md` for version control, branching strategies, deployment best practices

2. **Determine scope** -- Identify whether the question is about LookML development, Explore usage, instance administration, embedded analytics, or Looker Studio integration. Also determine if the deployment is Google Cloud Core (hosted) or customer-hosted, as AI features require hosted instances.

3. **Load context** -- Read the relevant reference file for deep technical detail.

4. **Analyze** -- Apply Looker-specific reasoning. Consider the LookML semantic layer, caching architecture, join relationships, and permission model.

5. **Recommend** -- Provide actionable guidance with LookML code examples, Explore configuration patterns, or administrative steps.

6. **Verify** -- Suggest validation steps (LookML validation, data tests, Content Validator, SQL Runner, System Activity dashboards, Admin > Queries).

## Ecosystem

```
┌────────────────────────────────────────────────────────────────┐
│                    Looker Platform                              │
│                                                                │
│  ┌──────────────────────────────────────────────┐              │
│  │           LookML Semantic Layer               │              │
│  │  ┌─────────┐  ┌──────────┐  ┌────────────┐  │              │
│  │  │  Views   │  │ Explores │  │   Models   │  │              │
│  │  │(dim/msr) │  │ (joins)  │  │(connection)│  │              │
│  │  └────┬─────┘  └────┬─────┘  └─────┬──────┘  │              │
│  │       └──────────────┴──────────────┘          │              │
│  └──────────────────────┬────────────────────────┘              │
│                         │                                       │
│      ┌──────────────────┼────────────────────┐                 │
│      │                  │                    │                  │
│  ┌───▼────┐      ┌──────▼──────┐     ┌──────▼──────┐         │
│  │ Explore│      │  Dashboards │     │  Scheduled  │         │
│  │  (UI)  │      │  & Looks    │     │  Deliveries │         │
│  └───┬────┘      └──────┬──────┘     └─────────────┘         │
│      │                  │                                      │
│  ┌───▼──────────────────▼──────┐                               │
│  │    Caching / PDTs / Agg     │                               │
│  └──────────────┬──────────────┘                               │
│                 │                                               │
│        ┌────────▼────────┐                                     │
│        │  SQL Generator  │  Dialect-aware SQL                   │
│        └────────┬────────┘                                     │
└─────────────────┼──────────────────────────────────────────────┘
                  │
    ┌─────────────┼──────────────────┐
    │             │                  │
┌───▼────┐  ┌────▼─────┐  ┌────────▼────────┐
│BigQuery│  │Snowflake │  │ 50+ SQL DBs    │
│        │  │Redshift  │  │ (PostgreSQL,   │
│        │  │Databricks│  │  MySQL, etc.)  │
└────────┘  └──────────┘  └────────────────┘
```

| Component | Purpose |
|---|---|
| **LookML** | Declarative semantic modeling language; single source of truth for metric definitions |
| **Explores** | User-facing query builder combining views through joins |
| **SQL Generator** | Translates LookML + user selections into database-specific SQL |
| **Caching Layer** | Datagroup-driven query caching; PDTs for materialized results |
| **Embed SDK** | JavaScript SDK for iframe-based embedding with event handling |
| **Extension Framework** | Custom React/TypeScript applications running within Looker |
| **Open SQL Interface** | JDBC access to the semantic layer for any compatible tool |
| **Gemini AI** | Conversational Analytics, LookML Assistant, Visualization Assistant |

## LookML Fundamentals

### Core Constructs

| Construct | Purpose | Key Details |
|---|---|---|
| **View** | Represents a table or derived dataset; defines dimensions, measures, dimension groups | One view per `.view.lkml` file; always define a primary key |
| **Model** | Entry point; specifies database connection, includes, Explores, datagroups | One model per business domain; `persist_with` sets default caching |
| **Explore** | User-facing query interface combining views via joins | Always specify `relationship`; use `always_filter` on time fields |
| **Derived Table** | Virtual table defined in SQL or native LookML | PDTs materialize to scratch schema; incremental PDTs for append-only data |
| **Dimension** | Individual field/attribute (column) | Supports type, sql, label, description, hidden, drill_fields |
| **Measure** | Aggregated calculation (SUM, COUNT, AVG, etc.) | Type `number` for measures referencing other measures |
| **Dimension Group** | Time-based field generating multiple timeframes from one definition | Do not include "date" in the name (avoids `created_date_date`) |
| **Refinement** | Modifies existing view/Explore in-place using `+` prefix | Ideal for Looker Blocks, imported files; `final: yes` prevents further changes |
| **Extends** | Creates a new copy of a view/Explore with modifications | Use when you need multiple variants of a base object |

### Direct Query Architecture

Looker does **not** extract or store source data. It generates optimized SQL against connected databases in real time. Caching and PDTs are performance optimization layers, not data storage.

### Datagroups and Caching

```lookml
datagroup: etl_datagroup {
  sql_trigger: SELECT MAX(etl_timestamp) FROM etl_log ;;
  max_cache_age: "24 hours"
}
```

- `sql_trigger` detects new data; when the returned value changes, cache invalidates and PDTs rebuild
- `max_cache_age` is the fallback if the trigger check fails
- Cannot combine `sql_trigger` and `interval_trigger` (interval takes precedence)
- Apply via `persist_with` at model level (default) or per-Explore (override)

### Aggregate Awareness

```lookml
explore: orders {
  aggregate_table: monthly_revenue {
    query: {
      dimensions: [created_month]
      measures: [total_revenue, count]
    }
    materialization: {
      datagroup_trigger: etl_datagroup
    }
  }
}
```

Looker automatically routes queries to aggregate tables when dimensions and measures match, dramatically improving dashboard performance.

## Universal Semantic Layer

Looker's semantic layer extends beyond the Looker UI:

| Access Method | Protocol | Use Case |
|---|---|---|
| **Open SQL Interface** | JDBC | Any JDBC-compatible tool (Tableau, Python, R, custom apps) |
| **Tableau Connector** | Custom | Native Tableau integration with LookML models |
| **Power BI Connector** | Custom | Direct Power BI connectivity to semantic layer |
| **Google Sheets** | Native | Spreadsheet-based analysis from LookML definitions |
| **Looker Studio** | Native | Looker Studio reports connected to LookML models |
| **Conversational Analytics API** | REST | Partner tools building AI-powered analytics on the semantic layer |

Single source of truth regardless of consumption tool.

## Embedded Analytics

| Method | Auth | Best For |
|---|---|---|
| **SSO Embed (Signed URL)** | Server-generated signed URL | Authenticated dashboards without separate Looker login |
| **Embed SDK** | JavaScript iframe embedding | Programmatic control, event handling, filter management |
| **Public Embed** | None | Publicly accessible content (no auth required) |
| **Extension Framework** | Looker's built-in auth | Custom React/TypeScript applications within Looker |

**SSO Embed flow:** User authenticates with your app -> server generates signed Looker embed URL with user attributes -> iframe loads -> RLS applied automatically via user attributes in the signed URL.

**Embed SDK pattern:**
```javascript
LookerEmbedSDK.init('https://your-instance.looker.com')
LookerEmbedSDK.createDashboardWithId(dashboardId)
  .appendTo('#dashboard-container')
  .withFilters({ 'region': userRegion })
  .on('dashboard:filters:changed', handleFilterChange)
  .build()
  .connect()
```

## Security Model

Looker uses a layered permission system:

1. **Permission Sets** -- Define actions a role can perform (view, explore, download, schedule, develop, admin)
2. **Model Sets** -- Define which LookML models a role can access
3. **Roles** -- Combine a permission set with a model set
4. **Groups** -- Assign roles to groups of users
5. **User Attributes** -- Dynamic, per-user variables driving security rules and personalization
6. **Access Grants** -- Field-level visibility tied to user attributes
7. **Access Filters** -- Row-level security (WHERE clause injection) tied to user attributes

```lookml
explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: allowed_region
  }
}
```

## AI Features (Gemini-Powered)

| Feature | Capability | Requirement |
|---|---|---|
| **Conversational Analytics** | Natural language data querying grounded in LookML (multi-turn) | Looker 25.0+, hosted instance, Vertex AI |
| **LookML Assistant** | Generate LookML code from natural language descriptions | Looker 25.2+, hosted instance |
| **Visualization Assistant** | Natural language chart customization | Looker 25.2+, hosted instance |
| **Formula Assistant** | Automated calculated field syntax generation | Hosted instance |
| **Code Interpreter** | Python code generation for forecasting/anomaly detection | Experimental, hosted instance |

**Critical:** AI features require Looker-hosted instances (Google Cloud Core). Customer-hosted deployments cannot use Gemini features.

## Deployment Options

| Option | Managed By | Best For |
|---|---|---|
| **Looker (Google Cloud Core)** | Google | Most deployments; integrated with GCP IAM, VPC, Vertex AI |
| **Customer-hosted (single VM)** | Customer | Smaller workloads; vertically scalable |
| **Customer-hosted (Kubernetes)** | Customer | Recommended for self-hosted; Helm-based deployment |

## Looker vs Looker Studio

| Aspect | Looker | Looker Studio |
|---|---|---|
| **Type** | Enterprise BI platform | Free visualization tool |
| **Data modeling** | LookML semantic layer | Basic calculated fields, data blending |
| **Governance** | Row-level security, field-level access, centralized metrics | Share-based access control |
| **Target users** | Data teams, analysts, enterprises | Marketers, business users, SMBs |
| **Scalability** | Petabyte-scale datasets | Small-to-medium data |
| **Learning curve** | Steep (SQL/LookML required) | Low (drag-and-drop) |

**Unification (2025-2026):** Google is merging capabilities. Looker Studio in Looker (Preview) allows Looker Studio reports to connect to LookML models. Each Looker license includes one Looker Studio Pro license.

## Development Workflow

1. **Enter Development Mode** -- Developer gets a personal branch (`dev-username`)
2. **Edit LookML** -- Changes visible only to the developer
3. **Validate** -- Run LookML validation to catch syntax and reference errors
4. **Test** -- Run data tests to verify business logic assertions
5. **Commit** -- Save changes with descriptive commit messages
6. **Create Pull Request** (if configured) -- PR-based review before merge
7. **Merge** -- Integrate changes into production branch
8. **Deploy** -- Push to production; changes visible to all users

**Build PDTs before deploying** to ensure tables are immediately available in production.

## Anti-Patterns

| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Missing `relationship` on joins | Default `many_to_one` silently produces wrong aggregation results | Always specify `relationship` explicitly |
| No primary key on views/PDTs | Incorrect aggregations, no key uniqueness validation | Define `primary_key: yes` on every view including derived tables |
| Using `persist_for` instead of datagroups | No ETL sync, no admin visibility, no reusability | Use datagroups with `sql_trigger` and `max_cache_age` |
| One massive Explore with every join | Slow queries, confusing field picker, performance degradation | Build focused, purpose-specific Explores |
| No `always_filter` on time-series Explores | Unbounded full-table scans when users forget date filters | Require time range filters via `always_filter` |
| Granting native SQL to sandboxed databases | Bypasses row/column security entirely | Restrict sandboxed users to query builder only |
| Skipping LookML validation before deploy | Syntax errors, broken references reach production | Run validation and data tests before every merge |
| Using `from` for simple view renaming | Creates unnecessary complexity | Use `view_label` for display renaming |
| Hardcoding connection strings | Breaks multi-environment deployments | Use constants in manifest or LookML parameters |
| Including "date" in dimension group names | Generates redundant suffixes (`created_date_date`) | Name dimension groups by concept: `created`, `shipped`, `updated` |
| Shared scratch schemas across instances | One instance deletes another instance's PDTs | Use separate scratch schemas for production and QA |

## Cross-References

- `overview` skill, this plugin -- technology comparison and selection guidance across BI tools
- database plugin -- database-specific optimization (BigQuery partitioning, Snowflake clustering, Redshift sort keys) relevant to Looker query performance

## Reference Files

- `references/architecture.md` -- LookML constructs (views, models, Explores, derived tables, refinements, extends), instance architecture, database connections, caching/PDT mechanics, embedding methods, Universal Semantic Layer, Looker Studio comparison, Google Cloud integration
- `references/best-practices.md` -- Project structure and naming conventions, Explore design (joins, fields, access control), caching/PDT strategy, aggregate awareness, embedded analytics patterns, governance (permissions, code review, content management), version control workflows
- `references/diagnostics.md` -- Slow Explore diagnosis (bottleneck identification, generated SQL analysis, System Activity), PDT build failures (scratch schema, permissions, event log), connection issues, LookML validation errors (common errors with resolution), query performance monitoring