Two BI acquisitions made big headlines in 2019: Salesforce acquired Tableau and Google acquired Looker. Tableau has been at the core of my work for a while, but I hadn’t heard much about Looker prior to Google’s purchase. However, since the acquisition, I’ve had a lot of time to develop with Looker on my own time and eventually in my client work. In this post, I’ll walk you through the tool and give some of my conclusions on its high and low points.
For the sake of a reference point, I am analyzing Looker’s capabilities partially with reference to Tableau, because that is what most of our audience is familiar with. However, I want to be clear that these are very different product offerings with what I consider to be very different audiences and agendas.
Before we get started with our look at Looker, it’s worth mentioning Google also has its own visualization product: Google Data Studio. My Tessellation colleague John already took a look at GDS and its comparison with Tableau, which you can read here.
What is Looker?
Looker is a BI platform that is focused on enabling users to easily explore and analyze data and then share those insights with others. The platform’s interface is divided into 3 main sections:
- Browse: take a look through folders of published content, such as Dashboards and Looks (the Looker equivalent to Tableau’s View)
- Explore: choose from any productionalized data source, referred to as an Explore, and ask ad hoc questions. From the queries, build visualizations that can be added to dashboards or shared as Looks. Explores are somewhat similar to Tableau Server’s published data sources, but more centralized.
- Develop: users with developer permissions can build views and Explores using LookML. When in “Developer Mode,” each developer has their own github branch, or shared branches for collaboration, to work through each project in an isolated environment before pushing to production.
How does it work?
Now let’s walk through some of the main steps to build a dashboard in Looker.
Connecting to Data
First, let’s talk through getting to the data you need.
If your data does not already exist in an explore in Looker, this will be a bit of a process. I’ll give the sparknotes. After enabling development mode, you can import your data source to a new view, either from a table or by scratch. Importing from a table will prompt Looker to auto-import each field in LookML and make its best guesses at the fields. This is a good starting point for your view, but usually needs finessing for a user-friendly interface in the eventual explore.
Once the view is to your liking, create a new explore in the data model and push it to production or continue working with it in development mode.
If your data source is already in Looker, this is a lot easier. Simply navigate to the explore you want and boom – you’re in.
Building a Visualization
Now let’s build a viz. Looker builds visualizations out of dimensions and measures selected from an Explore. You also have the option to filter or pivot values in the query. A query is run with the selected fields, and the visualization is automatically built from there.
The visualization type can be changed on the top visualization bar and the settings toggle can be used to customize. The customization options vary pretty widely between chart types, but you almost always have options for labeling values, showing legends, and showing/hiding an axis.
Once the visualization is finished, it can be saved either as a Look or saved to a Dashboard. Looks are separately published objects, but can also be consumed by zero to many dashboards in the same folder. Below I am adding the visualization to a new dashboard. Because it is not saved as a Look, this visualization will only be consumed by this dashboard.
Table Calculations
Table calculations are similar to Tableau’s calculated fields but require all fields used in the Table Calculation to be in the active query. Meaning, if I want to create an IF statement using an Event Date, Event Date must be selected in the active query. Event Date could then be hidden from the visualization if it is not relevant, but all returned query rows would still be “fanned out” by Event Date. You can probably start to see how this scenario might cause some issues.
Note: Custom Fields, which are a new beta field type, are a bit more flexible in that they do not require all fields to be in the active query. These utilize most of same built-in functions and require specific permissions to create.
One thing that I think Looker does particularly well with Table Calculations is comparisons to prior periods. Below, I am using the offset() function in a Table Calculation (this function is not available in Custom Fields) to find the previous row’s total order count. In this case, the previous row indicates the prior month’s order count.
Using the Single Value visualization type and enabling the Comparison setting will allow for a simple way to show change and add context to KPIs. This is one visualization type that I think is significantly less technically complex to create in Looker than other BI tools.
Dashboarding
Dashboard objects are called Tiles. These are semi-floating objects which can be easily moved around or changed in size. Tile types include visualizations, published Looks, text objects, and filters.
Customization on these tiles is, admittedly, fairly limited. You have some control over the size of tiles, whether their titles show, and you can add notes or annotations to further describe the tiles. You cannot change how the text looks (outside of a few options to bold or italicize in text tiles), add or change color to the tiles or dashboard background, or insert images or company logos.
The Pros
So after using Looker for awhile now, what are my favorite parts?
- Everything is in one platform. Your dashboards, explores, and development mode are all in one interface.
- I cannot overemphasize how much I love the development mode. I can work through and QA my calculations quickly and independently without messing up anyone using the explore. When it’s ready, I can use the content validator (seen below) to make sure I’m not ruining anyone’s day if I rename a field or change an explore.
- The platform has a security model that can meet a variety of permissions requirements.
- The ease of use in the explores enables hyper-quick visualization building and agility to go on to the next question.
- As I mentioned, comparisons to last period are generally a breeze.
The Cons
Where am I looking for more?
- You are limited to what developers have the capacity to create for you, in terms of Explores and the fields in those Explores. For example, the below boxplot requires all inputs to be coded into the LookML by someone with the developer capability. This is limiting for non-developer users.
- Table Calculation functionality is limited. Current capabilities for complex calculations (especially date calculations, due to the fanning out of rows in an active query) will likely require you to be pretty creative with your SQL and LookML. For example, IF-ELSE and CASE table calculations don’t exist; instead nested IF-statements are required.
- Table Calculations on totals are run as a calculation on the total row itself, rather than an aggregation of the data rows. This can produce odd results, as seen below. (Notice how the Total for the Outerwear Brand Counts (Table Calc) is 0.) Custom Fields are a step in the right direction, but only for those with proper permissions to make them.
- Building a data source requires knowledge of both LookML and SQL.
- No connections to excel or other static files.
- There is very little room to customize your dashboards. If you’re coming from a tool like Tableau or even Google Data Studio, you will feel limited by your options here. For example, text objects can only be bolded or italicized, with little control over much else.
What's the verdict?
If you’re looking for a highly secure tool for users to do ad hoc analysis on IT-curated data sources, Looker might be a fit for you. However, if you have a wide variety of complex blending requirements without a reporting database layer, need greater speed to insight on a wide variety of data sources, or highly value a custom visualization component, you might find that Looker will have a more difficult time checking all of the boxes.
I think of Self-Service BI tools and platforms on a spectrum, ranging from Highly Governed to Highly Self-Serve. I place Looker on the highly governed end, and Tableau more toward the opposite. This isn’t to say that you can’t have a governed Tableau environment or a “wild, wild west” self-service Looker instance- you can absolutely have either of those things. Looker’s current functionality just leans more toward the traditional IT focus, as a moderate level of SQL and LookML development is required to make a proper data source or a highly customized dashboard.
As shown by recent developments, such as enabling custom fields, the platform is making big improvements toward a more customized experience. Regardless of which tool is right for you and your organization, we should all keep our eyes on Looker and what fantastic things they’ll continue to do under the Google umbrella.
Do you have more questions about Looker or Tableau? Our team of data visualization experts is here to help!
