How to structure your LookML Project

It can be daunting to navigate through LookML, let alone start a new LookML project, but do not fear, this article is here! We hope this will help you tackle structuring your own LookML projects with ease.

We’d like to start by saying this is not the only way to structure a LookML project and by no means do you have to follow every single structure and organization that we suggest. It is simply an outline that we have developed over the past few years from which to draw inspiration from. It is important to note that our opinions may change over time as the analytics landscapes evolve and change.

Before we begin, a few requirements, we are under the assumption that:
- You are familiar with Looker and LookML, but if you need some guidance we highly recommend Looker’s documentation: https://docs.looker.com/.
- You have already set up your connections and at most created a LookML Project, if not, here is an article for reference: https://docs.looker.com/data-modeling/getting-started/create-projects.

Final note, this structure can only work with Looker 6.0+ because we heavily use the feature ‘IDE Folders.’

Now, let’s begin!

Here is the overarching structure we follow:

We aligned the folder structure this way to adhere with the relationships between LookML elements (example structure below). This method of organization has provided a greater ease of use and more efficient collaboration.

The Looker IDE has folders automatically set up in numerical and alphabetical order, therefore we typically name the folders with numbers first, and to keep everything tidy, we name folders in lowercase.

1. Documentation (‘1_documentation’)

• The files in this folder are exclusively markdown. Here is a reference on style guides for markdowns: https://docs.looker.com/dashboards/using-markdown-in-text-tiles
• Include a readme.md, this is an internal reference for looker developers. Things to add in this document: article references of looker guides, your own standard style guides of LookML and processes, and high level information about the Looker Project/Models
• Include markdown files of business KPIs and data guidance. Things to add in this document: general business definitions and why, and a business overview and references of data structures.

2. Model (‘2_model’)

• The files in this folder are Looker Models.
• When creating multiple Models, it is best to organize by business category or departments, especially because this can clean up the way users see Explores in the front end.
• We like to have 1 overarching Looker Model that isused for everyone in the organization. This is typically generic data exploration such as orders or members.
• We recommend the following structure of Models to be divided by departments such as: product, marketing, sales, etc.

3. View (‘3_view’)

• The files in this folder will include the majority of the development work. This includes all view files which will then be grouped into sections.
• There are 3 subfolders.

Derived Tables (1_derived_table)

• This includes view files of native derived tables or sql-based derived tables.
• You can then add other subfolders by business data categories such as: transactions, CRM, specific products, etc.
• The best way to structure your derived table views is to organize in the way of your company and the analytics reporting desired.
• An important suggestion we have is adding in ‘derived_’ in your view files as the start of the name. This will make it a very clean setup!

Extended Tables (2_extended_table)

• This includes extended tables from other views.
• This section is optional. You can definitely put extended tables as part of the derived tables. The reason we have found this setup to be better was because derived tables are more commonly used than extended tables, since these extended tables can be more of a specific use we keep this separate.

SQL Tables (3_sql_table)

• This will include view files that are NOT SQL manipulated but instead are connecting straight to a data warehouse table.
• You can then add other subfolders by schemas.
• An example of a view file that has no SQL manipulation (see below).

4. Dashboard (‘4_dashboard’)

• The files in this folder are LookML dashboards.

Final Thoughts

It’s worth noting the four main structure folders are set in stone as our structure guide. Afterwards, we often think through the rest of the structure from right to left. We start with the idea of creating the dashboards and reports we want to build, and then we specifically ask who are the audiences and can we group them together?

Work With Us

SLATE is an engineering company with a focus on modern approaches to data architecture and software development, and delivers custom solutions that allow organizations to gain insights to drive effective decision making. If you have a problem that you’d like us to help you with, then you can contact us via our website!