After their blogpost about the Taxirides dataset, I reached out to the Tropos team and proposed to build a visualization on top of this dataset. They proposed to give me access to their Looker environment to get this done. I knew from previous conversations that Tropos recommends Looker as a visualization tool. I don’t have any experience with this software, so it will be a nice learning experience for me to try and get a dashboard up and running. Let’s see how easy and intuitive Looker really is – or not?

Exploring the data

The first step, linking to the dataset in Snowflake, was done by Tropos upfront. 

Now let’s start exploring the data. We click the button explore and select the dataset ‘Ridehistory’.

This way all dimensions and measures – defined as such in the data connection come to our disposal for further investigation. 

We click a measure and dimension to see if we can do anything with them. As soon as we select them, they also appear in the Data section on the right hand side of the screen. We select one dimension and one measure to try to build a bar chart to get a feeling of the number of rides per Trip Type. In the graphical interface this Looks like this:

We press run to generate this result:

The following SQL-code is generated:

The 1 and 2 in the Group By and Order By seem to represent the TRIP_TYPE and the Count. Let’s explore this some more by selecting an extra dimension and an extra measure. The result is that the Group By is updated, but the Order By is not. 

If you want to change the measure to order the data by, you can do this by opening the SQL Runner (button in the right bottom). Here you can edit the SQL code manually.

Let’s click run, this run took about 10 seconds to complete:

To create a visualization you can click the visualization bar in the Explore part of Looker and select a type of widget to get a preview. Here we see the labels are not very business friendly. 

By clicking edit you can add labels per measure. Here we see the trip type is shown right above the bars, but this is not very readable. For now we were just clicking around Looker a bit, without really thinking about the content of the graph. If we Look at the meaning of this graph, we have the Number of rides and the Tip amount and the Trip type per Vendor ID. 

Creating a bar chart to use in a dashboard

The chart here above doesn’t make a lot of sense, so let us take a step back and build a meaningful graph and use it in a dashboard.

We save this chart as a Look.

Now we can find all our saved Looks in our Guest folder and we can use it to build a dashboard.

When we add a couple of other graphs we can build a dashboard with them – select New and choose Dashboard in the top right corner next to the cog.

In the edit mode of the dashboard, we can add filters to select periods or text filters relevant to the data in the different graphs. If you Look closely to the address bar of the dashboard, you will notice that all filters that are applied in the data are listed in the URL. This makes the embedding of Looker objects in webpage and iframes easy, and allows you to use parameters from other softwares to filter the data.

So far this all Looks quit easy and intuitive, but what is this LookML we keep bumping into?

LookML

LookML is the name of the Looker mark-up language. Every object in Looker has its own LookML code that is generated automatically as you progress in the WYSIWYG editor.

WYSIWYG stands for What You See Is What You Get

means you can create objects by pointing and clicking that are immediately visually represented on your screen as you develop a dashboard.

This generated LookML code can be committed to Git but it also works the other way around: by pulling LookML code from a Git project you can generate any type of Looker object like data connections, dashboards or other visual objects.  The native integration of this LookML code in Git within Looker allows for professional versioning and collaboration, a unique feature for a data visualization tool as for as I know.

Conclusion

Looker is an intuitive tool to build use. In the short timeframe that I spent, I could build a basic dashboard. The native integration with Git is not standard in a dashboarding tool and allows for an end to end dev ops approach in a data project. A feat that is difficult to overestimate in an era of deployment in the cloud and very stringent requirements for audit trails that some customers require.