View the original community article here

Last tested: Dec 18, 2019
 

One of the core benefits of LookML is that it stops you from repeating yourself when doing data analysis. Whereas previously you may have saved snippets of SQL queries, bits of business logic you knew you might need again, this process can be error-prone and in a big organization, this doesn’t scale well. With LookML, you write down those snippets just once into universal and reusable query components that are easier to manage. In computer science, this concept is called D.R.Y., or Don’t Repeat Yourself, and it can save you a lot of time (and tears). The mantra is to write the code ahead of time, not every time.

What?

In large enterprises, the deployment of Looker can grow to a size where the core data team can no longer manage every department’s data needs, and some level of delegation must happen. Splitting up projects so that each department can manage their own becomes advantageous, but how do you maintain consistency?

In the hub and spokes architecture, a central data team manages a core project (the “hub”), while each department manages its own projects (the “spokes”). The hub contains universal business logic, whereas the spokes contain department-specific logic. With the release of Looker 6.8, hub logic is imported into the spokes via project import. This feature provides control over what developers have access to, while the extends feature gives developing departments the ability to customize for their end users.

At a high level, the hub contains shared code which everyone uses. From the hub, several spokes are created to edit and append the hub code for more use cases. Hub and spokes allows everyone to run at their own pace with distributed, scalable modeling ownership, while project import ensures everyone is still speaking the same language.

Why?

• Separate core - Protect core metrics from breakage
• Removes load and reliance on the central data team
• Gives greater flexibility and speed of delivery to business teams
• Encourages quicker adoption by empowering others
• Provides a way forward for regionalisation challenges

Requirements:

• Strong champions (or potential champions) of Looker across the wider business
• Tech and data savvy departments able to drive their own analytics agenda
• An environment comfortable with the concepts of code management

Limitations:

• Additional governance is required to facilitate code and content management

How?

​

Hub

The “Hub” project defines business metrics and is maintained by the Data Team. They work with internal teams to understand business needs, and as a result create standard views that can be used by any department. These views provide accurate, consistent information such as shared KPIs and business logic definitions..

Spokes

Spokes are additional projects, with visible Explores, to power content creation and self-service. Use Project Import to bring in views from the Hub. The content from the core Hub is read-only to the outer spokes, but spokes can use extends to add new fields, apply labels, or join in relevant tables, without altering the core content. Any logic that becomes core to the business should be moved to the Hub in time.

Spokes can also each use a separate DB connection. Separate connections allow us to bring in new datasets that had previously needed their own instances and remain secure.  

​

Hub and Spoke with Blocks

Want to use most of a block's logic, but tweak it to your use company's use case? This is a very common application of Hub and Spoke - use project import to reference the URL of the block's source code, and then extend that code in your own project, using your own connection. This means that as the block gets updated, so does your code, but you can add your own flavor (company-specific field labels and descriptions, individual logic, new explore definitions, etc.) to make the data work for your business.