Looker Hub and Spoke: Governed LookML at Scale

Key takeaways:

• Hub and spoke lets many Looker teams build on one governed LookML model instead of duplicating logic, so definitions stay consistent while teams keep local flexibility.
  
• The pattern is built on Looker's project import: A central hub project holds shared LookML, and spoke projects import it and extend it with refinements and extends.
• Choose local dependency for projects on the same instance, and remote dependency when you want versioned, Git-controlled imports across teams.
  

As Looker adoption grows across an organization, many teams end up needing the same core metrics with their own local variations. The clean way to serve them is to build once and reuse, and Looker's hub and spoke pattern is designed for exactly that. A central hub project holds a governed, generic LookML model, and each team's spoke project imports that model and tailors it without touching the shared definitions. The result is one source of truth for your metrics with room for local flexibility, which is also what makes LookML valuable as a semantic layer across Looker and the wider Google Cloud analytics stack.

What Hub and Spoke Solves

In a large deployment, letting every team write its own LookML leads to duplicated logic and metrics that quietly drift apart. Hub and spoke keeps that from happening. The hub defines shared views, explores, and business logic once, under tight control. Spokes inherit that code and adapt it for their own audiences, so a regional team or a business unit can add a dimension or a join without forking the core model. Everyone stays aligned on the same definitions, and governance lives in one place.

How It Works: Project Import

Looker implements hub and spoke through project import, declared in a project's manifest file. There are two ways to bring the hub into a spoke.

Local dependency imports a project on the same Looker instance:

project_name: "sales_spoke"
local_dependency: {
project: "hub"
}

Remote dependency imports a hub from a Git repository and pins it to a version with the ref subparameter, which can be a branch, a release tag, or a commit:

remote_dependency: hub {
url: "https://github.com/your-org/looker-hub"
ref: "main"
}

When you add a remote dependency and validate, Looker pulls the hub files in under the imported_projects folder and creates a manifest lock file to track the version in use. In the spoke, you then include the hub view files and layer your changes on top using refinements and extends, which let you adjust or add to an existing view or explore without editing the hub itself.

Best Practices for the Hub

The hub is a shared infrastructure, so treat it that way.

• Keep access tight: Limit who can change hub code and enforce it with pull request rules in Git so only approved developers can merge.
• Organize for reuse: Use a clear folder structure in the integrated development environment (IDE) so inherited code is easy to find and customize in spokes.
• Put logic in LookML: Encode business logic as dimensions and measures rather than table calculations, so spokes can reuse it.
• Document everything: Add descriptions to custom dimensions and measures, since spoke developers rely on them.
• Standardize refresh: Define common data groups and separate model files by connection.

Local or Remote: Which to Use

Local dependency is simplest when the hub and spoke live on the same instance and developers have model permissions in both. Choose remote dependency when you want version control over what the spoke consumes, when teams are separated, or when spoke developers lack permissions in the hub's models. Because remote dependency pins to a ref, you decide exactly when a spoke picks up hub changes: Update the ref, validate, and the spoke moves to the new version. That control is the main reason larger teams prefer it.

What to Keep in Mind

A few practical points help set expectations:

• Keep spokes current by updating the ref as the hub evolves; The manifest lock file handles the version tracking for you.
• Set roles deliberately: Give spoke LookML developers the privileges to modify spoke code, while business users get access to the dashboards built on top.

Scaling Looker with Confidence

Hub and spoke is how a Looker deployment stays consistent and governed as it grows across teams. As a Google Cloud partner, KPI Partners helps organizations design LookML architectures that balance central governance with team-level flexibility. When this is part of a broader move to modernize or consolidate business intelligence, our BI Modernization Accelerator brings the same structure to migrating and scaling models across platforms.