Connecting Looker to a Semantic Layer: Integration Strategies

A semantic layer provides unified metric definitions that work across all analytics tools in an organization. For Looker users, this raises an interesting question - Looker already has LookML, its own semantic modeling language. How do these work together?

This guide explores strategies for connecting Looker to external semantic layers, including when and how to leverage both LookML and external semantic governance through platforms like Codd AI.

Understanding the Landscape

LookML's Strengths

LookML is a powerful semantic modeling language with:

• Declarative metric definitions
• Explore configurations for self-service analysis
• Strong version control integration
• Looker-specific features like drilling and linking

LookML's Limitations

However, LookML has boundaries:

Limitation	Impact
Looker-only	Definitions don't work in Tableau, Power BI, or SQL clients
Proprietary syntax	Requires specialized skills to maintain
Platform-locked	Metrics tied to Looker license and infrastructure
No AI integration	LLMs cannot directly consume LookML semantics

The Case for External Semantic Layers

An external semantic layer complements LookML by providing:

• Tool-agnostic metric definitions
• SQL-compatible interfaces
• AI and LLM consumption capabilities
• Independence from specific BI platforms

Integration Patterns

Pattern 1: Semantic Layer as Database Connection

Connect Looker to the semantic layer as if it were a database:

Looker → Database Connection → Semantic Layer → Data Warehouse

How it works:

1. Semantic layer exposes SQL-compatible endpoint
2. Looker connects using standard database connection
3. Semantic objects appear as tables/views
4. LookML models reference semantic layer objects

LookML example:

connection: "semantic_layer_connection"

explore: orders {
  label: "Orders (Governed Metrics)"
  description: "Order data from semantic layer with standardized metrics"
}

view: orders {
  sql_table_name: semantic.orders ;;

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.revenue ;;
    description: "Governed revenue metric from semantic layer"
  }
}

Pattern 2: Hybrid Semantic Approach

Use the external semantic layer for core metrics while LookML handles Looker-specific presentation:

External Semantic Layer: Core metrics, business logic, governance
LookML: Explores, drilling, Looker-specific features

Implementation:

1. Core metrics (revenue, users, orders) defined in semantic layer
2. Looker queries semantic layer for these metrics
3. LookML adds Looker features - drilling paths, explore joins, formatting
4. Report-specific calculations stay in LookML when truly Looker-only

Pattern 3: Semantic Layer as Upstream Source

The semantic layer materializes governed metrics. Looker consumes the materialized output:

Semantic Layer → Materialized Tables → Looker PDTs/Views

Benefits:

• Fast query performance
• Looker operates on pre-computed metrics
• Clear separation of concerns

Trade-offs:

• Data freshness limited to materialization schedule
• Additional storage for materialized tables

Implementation Guide

Step 1: Evaluate Current LookML

Audit existing LookML projects:

• Which metrics are defined in LookML?
• What business logic exists in measures?
• Which definitions need cross-tool consistency?
• What Looker-specific features are in use?

Step 2: Design the Integration Architecture

Decide how Looker and the semantic layer will interact:

Question	Consideration
Which metrics go where?	Core metrics in semantic layer, Looker presentation in LookML
What connection method?	Direct query vs. materialized tables
How to handle migrations?	Gradual transition vs. big-bang switch
What about existing explores?	Update to use semantic layer or maintain separately

Step 3: Configure the Connection

Set up Looker to query the semantic layer:

1. In Looker Admin, create new database connection
2. Configure connection parameters for semantic layer
3. Test connectivity with sample queries
4. Verify performance meets requirements

Step 4: Update or Create LookML

Modify LookML to consume semantic layer objects:

For new models:

• Point directly at semantic layer tables/views
• Keep measures simple - reference pre-calculated metrics

For existing models:

• Update sql_table_name to semantic layer objects
• Replace complex measure SQL with semantic layer columns
• Maintain Looker-specific features (drilling, formatting)

Step 5: Validate and Test

Ensure the integration works correctly:

1. Compare metric values with previous LookML definitions
2. Test explore functionality
3. Verify permissions and access controls
4. Check dashboard load times

Step 6: Migrate Dashboards and Looks

Update existing content:

1. Update data sources on dashboards
2. Adjust tile configurations if needed
3. Validate all visualizations render correctly
4. Update scheduled deliveries and alerts

Best Practices

Metric Ownership Clarity

Establish clear ownership between LookML and semantic layer:

• Semantic layer owns: Core business metrics, standard calculations, cross-tool definitions
• LookML owns: Explore configuration, drilling, Looker-specific presentation, user experience

Version Control Coordination

Both LookML and semantic layer definitions need version control:

• Coordinate changes that affect both systems
• Test semantic layer changes against LookML dependents
• Document which metrics come from which source

Performance Monitoring

Track query performance across the integration:

• Monitor semantic layer query latency
• Review Looker System Activity for slow queries
• Identify candidates for materialization or caching

Documentation Standards

Document the integration clearly:

• Which metrics come from semantic layer vs. LookML
• How to add new governed metrics
• When to use LookML vs. semantic layer
• Troubleshooting common issues

Handling Specific Scenarios

Scenario: Complex Derived Metrics

When Looker needs metrics not in the semantic layer:

Option A: Request addition to semantic layer (preferred for cross-tool consistency) Option B: Create LookML measure that combines semantic layer base metrics Option C: Use table calculations for truly ad-hoc needs

Scenario: Filtered Metrics

Semantic layer metrics that need Looker-specific filtering:

measure: revenue_current_quarter {
  type: sum
  sql: ${TABLE}.revenue ;;
  filters: [order_date: "this quarter"]
  description: "Q revenue - base metric from semantic layer"
}

Scenario: Period-over-Period Comparisons

Leverage semantic layer time dimensions with Looker presentation:

measure: revenue_prior_year {
  type: sum
  sql: ${TABLE}.revenue ;;
  filters: [order_date: "1 year ago for 1 year"]
}

measure: revenue_yoy_change {
  type: number
  sql: (${total_revenue} - ${revenue_prior_year}) / NULLIF(${revenue_prior_year}, 0) ;;
  value_format_name: percent_2
}

Codd AI Integration

Codd AI provides Looker integration capabilities:

• SQL-compatible endpoints Looker connects to directly
• Automatic metric exposure as queryable objects
• Governance that complements LookML capabilities
• AI-ready semantic definitions

Organizations can leverage both LookML's Looker-specific strengths and Codd AI's cross-tool governance.

Migration Considerations

Phased Approach

Migrate incrementally rather than all at once:

1. Start with new explores using semantic layer
2. Migrate high-value, cross-tool metrics next
3. Address legacy LookML over time
4. Keep Looker-only metrics in LookML indefinitely

Stakeholder Communication

Prepare users for changes:

• Explain why metrics may shift slightly
• Document intentional definition changes
• Provide comparison resources during transition

Rollback Planning

Have a fallback strategy:

• Keep old LookML models during transition
• Test thoroughly in development environment
• Stage migrations with ability to revert

The combination of Looker's visualization and exploration capabilities with external semantic layer governance creates a powerful analytics architecture that serves both Looker users and the broader organization.