We architected Looker to be flexible, scalable and embeddable

  • 28 March 2022
  • 0 replies

Userlevel 5

This content, written by Colin Zima, was initially posted in Looker Blog on Feb 15, 2017. The content is subject to limited support.

Most companies use tens or even hundreds of business tools - marketing automation, financial planning, business analytics, talent management... the list goes on and on. The explosion of tools has created a huge amount of competition (for attention and dollars) among the vendors of those tools.

Because of that competition, pushing deeper insights to customers has become a critical method for vendors to differentiate themselves. Zendesk highlights analytics as the top driver of larger contract sizes. Countless other tools (, , ) have highlighted why the depth of the data tools they offer customers has been crucial to their success, both for their market shares and their bottom lines.

Vendors know they should have a data product, but don’t know where to start. Each tool's data schema is different; each customer's reporting needs are different; and the users accessing the tools are all different. This is where the architecture you choose becomes crucial.

Are you trying to deliver real-time analytics to marketers for ad placement? Are you delivering formatted executive reporting on a weekly basis? How sensitive is your customer’s data? Are you only interested in providing a custom exploration experience for premium customers? The way you answer each of these questions could lead you down completely different paths in building or selecting your analytics tooling.

But what happens when your needs (inevitably) evolve? Re-architecting your entire data warehouse because your reporting needs have changed isn’t efficient. We talk to some companies that have set up reporting in a data tool that ingests over 500 identical database schemas--each of which has to be updated individually.

We had all these ideas in mind as we thought about building Looker. How could we build a system that effectively adapts to customers’ changing needs rather than forcing their needs to conform to their tool?

That’s how Looker's embedded data platform, , was born. As head of product, I own the vision for where Powered by Looker is going. And I see it as critical that Powered by Looker can:

  • work with any relational database and dynamically return personalized results for any customer
  • dynamically connect to distinct, but identical, schemas or even databases for each and every customer without remodeling or duplicating reporting
  • offer simple, embeddable iframes that can instantly hook up to any authentication system and bring a reporting tool online in minutes
  • construct and reshape SQL to show the metrics that matter to your customers with your data model
  • power a custom front-end through an API suite that covers 110% of the front-end functionality of the Looker application
  • give customers a full exploration experience tailored to them rather than just static, pre-built reports

Our product philosophy is centered around flexibility, layered complexity, and complete extensibility. The Looker platform can adapt to your data schema the same way your application code does - dynamically.

Unlike nearly every other embeddable solution, Powered by Looker doesn’t move your data. That means that parameterizing users, reports, or database connections in Looker works as fluidly as it would in your backend.

When our customers start with one vision for their reporting--perhaps simple embedded dashboards--they can easily 'upgrade' the experience they offer users to full exploration with saving and scheduling. And, most importantly, because all of Looker--user management, report building, visualization construction-- is accessible and configurable from other pieces of software via the Looker API, it’s possible to build full-fledged applications on top of Looker’s platform.

And, of course, this all is powered by the scalable, configurable modeling layer that builds queries in Looker - fully version controlled, the same way your engineers are writing production code. This means when you roll something out that isn’t quite right, or accidently push buggy code you thought you had fixed, you can roll the update back. It’s as easy as reverting a project in git.

The bottom line is that the product team behind Powered by Looker designed an embedded tool we would want to work with. We made it flexible, powerful, and scalable, because that is what we look for when we buy products. Our hope is that our product allows our customers to give their customers everything they need from an embedded standpoint. That way, their engineers can remain focused on making their core product as competitive and powerful as possible.

Learn more about on the product page, or see it for yourself in a .

0 replies

Be the first to reply!