This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
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.
LinkedIn
Twitter
