Solving Multi-Tenancy: How to Reuse Looker Dashboards for Different Data Sources

[Francesco_V]

Solving Multi-Tenancy: How to Reuse Looker Dashboards for Different Data Sources

Do you need to use the same Looker dashboard or a set of Looker definitions with different databases? This guide is for you!

Imagine these situations:

• A company with customers in different regions (like Europe and North America): They need to store data separately to follow rules like GDPR, even if the data looks the same.

• A customer with different types of users: Some users log in with their own accounts (OAuth), while others use special “Service Accounts” to refresh dashboards.

• A service provider with many clients: They want to share the main Looker definitions (LookML code and dashboards) with all clients, but also let each client customize their own data setup.

Within a single Looker setup, there are a few things to keep in mind:

• No duplicate model names: You can’t have two models with the exact same name in one Looker instance. This means you can’t use the same code from a Git repository (where you store your Looker code) for multiple Looker projects in that single instance.

• One model, one connection: Each Looker model can only connect to one database. This connection stays the same for everyone using that model.
  Looker connections support only a single type of credentials (OAuth, Service Account) and a single configuration for persistent derived tables (PDTs).

• Dashboard tiles are linked to one model: A tile of a LookML dashboard is always tied to a specific model that by default is a constant.

These limitations can be easily managed if you use multiple Looker instances, each with its own database connections, while still sharing your Looker code through Git. Unfortunately, this solution might increase your costs.

Be aware that there are easier options for managing dynamic configuration of connections and tables through user attributes (database configuration, table name injection, for example), so, before considering the approach described in this article, make sure that you cannot address your use case by leveraging user attributes.

This article will show you a way to use Looker’s “import” feature, creating dashboards and models once and using them in many different ways in a single instance.

Setting up Your Main Project and Dashboards for Flexibility

This section explains how to make your Looker project easy to expand and reuse. Here’s what we’ll do:

1. Create a “manifest file” to declare a constant: Think of a constant as a placeholder for a value that can change later.

2. Update your dashboards: We’ll change how dashboards refer to models, using our new constant instead of a fixed model name.

Create a Manifest File

To get your project ready, you’ll need to create a manifest file. In this file, we’ll declare a constant called model_name. The value of this constant will be the name of your model file (without the .model part).

Here’s an example:

project_name: "baseproject"

constant: model_name {
  value: "basemodel"
  export: override_required
}

In this example, if your model file is basemodel.model, the constant’s value should be basemodel. This helps ensure that your LookML dashboards continue to work correctly.

By exporting a constant with override_required, you make sure that the project that is importing your definitions will provide a new value.

The following image represents the main files involved.

If your project has multiple models, you’ll need to declare a separate constant for each one.

Edit Model References in Tiles of Your LookML Dashboards

LookML dashboards usually have a direct reference to the models where their “Explores” (data explorations) are defined. We’re going to replace these direct model names with the constant we just defined in the manifest file.

To refer to a constant in LookML, you use the syntax @{constant_name}.

Here’s an example of how a dashboard might look after this change:

---
- dashboard: thelooksimpledashboard
  title: TheLookSimpleDashboard
  layout: newspaper
  description: ''
  elements:
  - title: TheLookSimpleDashboard
    name: TheLookSimpleDashboard
    model: "@{model_name}"  <-- Notice the change here!
    explore: order_items
    type: single_value
    fields: [order_items.total_sale_price]
    limit: 500
    column_limit: 50
    query_timezone: UTC
    custom_color_enabled: true
    show_single_value_title: true
    show_comparison: false
    comparison_type: value
    comparison_reverse_colors: false
    show_comparison_label: true
    enable_conditional_formatting: false
    conditional_formatting_include_totals: false
    conditional_formatting_include_nulls: false
    show_view_names: false
    show_row_numbers: true
    truncate_column_names: false
    hide_totals: false
    hide_row_totals: false
    table_theme: editable
    limit_displayed_rows: false
    defaults_version: 1
    listen: {}
    row:
    col:
    width:
    height:

If you have multiple models, make sure that you update all of their names to use the equivalent constant.

Extend the Base Project

Now, let’s talk about how to set up an “extend project” – a project that uses the definitions from your main “base project”.

Assuming you’ve already created and configured a blank project, we’ll do the following:

1. Create a manifest file for the extend project: This file will link back to the base project and let us change (override) the model_name constant.

2. Create a model file: This file will include the model from the base project.

Create the Manifest File for the Extend Project

Any project that wants to use files from other projects needs a project manifest file. If you don’t have one, you can create it.

Looker supports importing projects both locally (from your computer) and remotely (from a Git repository). In our example, we’ll use remote import by adding the remote_dependency parameter:

project_name: "extendproject"

remote_dependency: baseproject {
  url: "git@github.com:francescoviganogoogle/viganobqhubproject.git"
  ref: "master"
  override_constant: model_name {
    value: "extendmodel"
  }
}

Here, the value in override_constant represents the name of your extend model. This means that any dashboards imported from the base project will now use this extendmodel model.

If you define multiple constants in your base project, remember to override all of them in your extend project’s manifest file.

To fully set up remote import, you’ll also need to manage the authentication credentials as explained in the documentation.

Create a Model File for the Extend Project

As a final step, you need to create a model file in your extend project. This file must have the same name as the constant you created in the manifest file (for example, extendmodel.model).

The basic content of this model file needs to:

1. Include the model file defined in your base (“hub”) project.

2. Reference the connection that this specific customer or region will use.

include: "//baseproject/models/*.model.lkml"

connection: "extend1_connection"

If your base project has multiple models, you’ll need to create a corresponding model file for each in your extend project. Make sure the constant overrides, model names, and include statements are all consistent.

Seeing the Solution in Action

To show how this all works, we’ve set up and deployed both the base and extend projects in a single Looker instance. We’ve also put our LookML dashboards into one folder.

You’ll notice that each project has its own version of the same dashboard, and they can exist side-by-side.

If you open both dashboards and look at the URL in your browser, you’ll see that the model name is different for each.

When you explore data from each dashboard, you’ll find that the individual charts and tables use data from two distinct models. Each of these models, in turn, connects to its own unique database. This setup ensures that every dashboard can link to completely separate projects, keeping customer or regional data isolated.

Further Extend Models and LookML Definitions

Upon establishing a connection between the extended project and the base project, Looker offers two primary mechanisms for further customization of views, Explores, and dashboards:

• Extend: The extends parameter enables the development of content and settings based on an existing view, explore, or dashboard file, utilizing the extended object file as a foundational element. In the event of conflicts, the extending object’s settings will take precedence, overriding those of the extended object.

• Refinement: LookML refinements facilitate the adaptation of an existing view or Explore without requiring the creation of a new one.

A detailed examination of the functionalities of “extend” and “refinement” falls outside the scope of this article.

What This Means for You (Conclusions)

By using Looker’s remote project dependencies and constants, which you can change (override), organizations can effectively handle situations where they have data for many different tenants in different regions or with different connection configurations.

This method offers a powerful way to scale your Looker deployments efficiently. It centralizes your core business logic, models, and dashboard definitions in one main base project. This significantly reduces the need to develop and maintain the same things over and over again. Your extend projects can then use this core logic (including dashboards) and easily change specific settings, like the database connection, to keep data strictly separate.

Ultimately, this approach lets you define your analytics once and use them widely, ensuring consistency, good governance, and flexibility across all your Looker environments.