What Google Should Do with Looker

If you follow what’s going on in the world of technology that implements a modern data supply chain, then Google’s $2.6 billion acquisition of Looker, announced on June 6, was big news.

From most reporting on this acquisition you get the impression that Google bought Looker to help its cloud offerings. But details on how it will help have not been specified. In the articles about the acquisition, what Google is doing with its cloud is not discussed. This is primarily because the business press really doesn’t cover tech, but rather just money and corporate events.

I do cover tech and have worked to create content for Looker and most of the other BI and data discovery players. This acquisition is interesting because it may support a direction that could help Google complete its story about being the cloud that unlocks the power of your data.

To understand what Looker may do for Google we need to look at:

What does Looker do?

  • Short answer, build wide, deep, and explorable data models based on SQL repositories.

Why would Google want Looker?

  • To complete its story about being the best cloud for data.

What I would do with Looker if I were Google:

  • Productize data models for lots of domains and automate the creation of models using Look ML.

What could go wrong?

  • Looker could come to be seen as a Google-only technology. Looker’s customer focus and listening culture could be smothered.

What Does Looker Do?

From a high level, Looker appears to be a company like Qlik, Tableau, or Microsoft PowerBI, a system for data discovery that allows data to be organized and then delivered through explorable dashboards.

But this obscures the real power of Looker, its Look ML modeling language, and Looker CEO Frank Bien’s founding vision for Third Generation BI. (See: “Looker CEO Explains How To Enter Data Platform Era, Avoiding Data Breadlines And Brawls”.)  

As the linked article explains, Bein saw the increase in computing power, and the speed and quality of SQL databases, would allow a deep and wide data model to be delivered on demand from the database.

Looker created LookML, essentially a programming language for creating data models. The data in the models described in LookML can then be delivered by SQL generated on demand. The earliest SQL databases might not have been able to deliver snappy performance but today’s databases can.

What LookML does that is different than the other companies is create a deep and wide data model. In the other data discovery systems, a query or an integrated extract is explored. LookML can create a model that includes much more data both in width and depth.

The width comes from the ability to not just join data based on a query but on data relationships expressed on LookML.

The depth comes from the fact that if you want to allow it, the exploration process always can let the user get down to the data in tabular form. This ability to directly inspect the data is really important to serious data analysts.

LookML has other properties as well.

Because the SQL is generated, a variety of problems related to writing SQL properly can be avoided — for example, inconsistent results when computing aggregates. (See: “A simple explanation of Symmetric Aggregates or: Why On Earth Does My SQL Look Like That?”.)

Fine grained access control can be described in the model.

And like all the other vendors, Looker wants to connect to every source and feed every downstream consumer of data. The company has paid a lot of attention to supporting embedded analytics and making a reusable library of components called Looker Blocks.

So in most successful BI implementations, there is a set of data that becomes canonical that describes a business. I call that set of data and the way that it is assembled and delivered the data product. Looker has become popular because LookML provides a way to describe a large data model and allow it to grow in an orderly way.

Why Would Google Want Looker?

Google is buying Looker because they realize that if they are going to fulfill their story as being the best cloud to unlock the power of your data, they must have a solution for supporting wide, deep and scalable data models.

Google’s Big Query platform is an awesome database and plenty of people put Looker on top of it.

Looker needs an awesome database that is able to pull in many sources for one key reason. Looker is based on generating SQL for a set of tables inside one database. Looker wisely has not taken on the challenge of implementing a federated SQL query that combined data from many SQL databases. This would be a different product.

But the modern SQL databases like Big Query, Presto, Snowflake, RedShift and many others, allow data in object storage or flat files or NoSQL databases to be incorporated into one SQL database.

Most of the Looker implementations I have run across are on these modern databases, although Looker does have a following for people who have large enterprise data warehouses based on Teradata and other technology from that generation.

But remember, Looker is playing the role of creating the wide and deep data model already on Google Cloud Platform. The official blog post announcing the acquisition pointed to 350 customers who were doing just that. Why bother buying Looker then given the risks I outline at the end of this article?

In my view, to make a leap forward Google must leverage Looker in new ways that it couldn’t easily do if Looker were a third party company. But in leveraging Looker it must not make Looker a captive Google technology that does not have an ambition to be a universal data model for all repositories.

What I Would Do If I Were Google

So, if I were in a product management meeting at Google after the acquisition, this would be my agenda.

First of all, I would start making products out of LookML models. Creating deep and wide data models for industries such as retail, manufacturing, life sciences, financial services, and productizing the connections with the data sources and Big Query would create a compelling starting point that would not diminish any of Looker’s appeal as a universal data access method. This end-to-end solution could be offered on other clouds as well as on Big Query. Google’s power as master of data could be expressed in this form. Such a move would move data productization to a higher level, something that Google needs to do to make its cloud compelling.

Second, I would address the core problem with Looker right now, the difficulty of building LookML. Google should be able to put its machine learning and devOps mojo to work to create a low-code, declarative, guided way to create LookML models. I’m thinking of something like Cascalog did for Cascading, a declarative code generator. If you could create a way to suck in huge amounts of data and gradually make sense of it without having to do a lot of coding that would empower huge amounts of partners with domain knowledge, who will be the engine of growth for Google’s cloud.

Third, I would seek to support data experts who are looking to monetize their expertise by creating a channel that allows them a piece of the action when they put their productized data offering on the Looker/GCP stack. The plumbing of a data supply chain is not nearly as complicated as the data relationships. If Google can find a way to become the way that data experts can productize and sell their data expertise, a thousand niche data models will bloom.

Fourth, I would consider buying Qubole as well to further embrace the idea of supporting data experts and teams that want to use a wide variety of repositories and tools but don’t have IT and engineering support.

I’m going to run this agenda by all of the Looker users I know and see how they extend it, but this is a good starting point that goes beyond just doing a brand slap of Google on Looker, which really won’t do much good at all.


What Could Go Wrong?

The biggest risk is that Looker becomes seen as a Google only platform. Already on the tech lists I follow, users are worried about this. The friendly people at Qlik, Tableau, and Informatica will keep focus on this issue until Google proves that Looker will really be a universal. Google must over communicate and over deliver so that Looker becomes an on-ramp for bringing data into Google from other platforms. This will be hard but doable.

The second risk is that Google’s culture of engineering excellence and bravado overcomes the customer focused “Love Looker Love” culture of listening, learning, and humility Frank Bien has created. (See “What Is a Startup? Looker’s Frank Bien on Scaling Startup Culture” for a summary and “Early Adopter Podcast: Analytics and Data with Looker’s Frank Bien” for a deep dive.) Google’s problem in its cloud efforts can be summed up in this way: At Google it is cooler to create an awesome scalable system that breaks new ground than to create a rickety prototype the people use. Engineers and teams and Amazon really want the second type of victory. Google wants the first. From my perspective Looker is closer to Amazon’s customer focus right now than Google’s culture. I hope it stays that way.

Author: Dan Woods

My mission: Find technology for Early Adopters. Follow me on Twitter @danwoodsearly and on LinkedIn www.linkedin.com/in/danwoodsearly/. I am a CTO, writer, and consultant. For tech vendors, I help explain their technology. For users, I help find, select, and deploy new solutions that have explosive business value. I love to speak and share ideas.