7 reasons Looker built a new language for data
Daniel Mintz
Chief Data Evangelist
To many people, analytics tools all look the same. Some dashboards, a few reports, a way to slice data. That’s because the real differentiators lie behind the scenes, where the great tools are separated from the merely good ones (and the not so good ones).
Behind Looker’s pretty face is something quite revolutionary: LookML. And even though the vast majority of users will never see a line of LookML, this new language for data is what makes Looker uniquely powerful, agile, and trustworthy--for everyone.
LookML has plenty of fans me among them, but not everyone is immediately sold. When skeptics hear about LookML, they usually have one of two reactions:
- “Why invent a new data language when SQL already exists?” or
- “I have to write code (???)? Can’t I use a graphical user interface (GUI) instead?”
And if you’re not familiar with LookML, these questions are totally reasonable. Plenty of people have tried to replace SQL or build graphical programming languages and failed. But knowledge and understanding of that history is exactly why we’re confident this is the right path.
Firstly, it’s important to know that LookML isn’t a replacement for SQL—it’s a better way to write SQL.
That distinction is critical, because while general-purpose programming languages have proven vibrant and dynamic, the world of data languages has been pretty stagnant. Assembly became C became Java and Python and Ruby—letting programmers focus on writing great programs instead of low-level tasks like managing memory. But data languages haven’t seen the same evolution--data analysts still mostly write SQL by hand, worrying about low-level concerns every time they write a query.
When Lloyd Tabb, Looker’s founder, started designing LookML, he began with the belief that data languages needed to evolve. But that didn’t lead him to a graphical interface. Lloyd had seen many graphical languages, and he’d learned that they are inherently imprecise, inefficient, and bad at expressing complexity simply. That’s why they’re mainly used as teaching tools today, rather than for building production systems.
But Lloyd’s vision for LookML wasn’t just about avoiding pitfalls, it was about making data users’ lives better. So to spell out our thinking more clearly, let me lay out seven reasons we believe LookML is a major step forward for data languages:
LookML is all about reusability. Programmers have a mantra: Don’t Repeat Yourself. But most data analysis is full of repeated work. You extract raw data, prepare it, deliver an analysis, and...then never use any of that work again. This is hugely inefficient, since the next analysis often involves many of the same steps. With LookML, once you define a dimension or a measure, you build on it, rather than rewriting it again and again.
It’s easy to learn. LookML is constructed around SQL, specifically because SQL is ubiquitous. That lets us tap into a huge pool of people who are already familiar with it. A graphical language would force everyone to start learning from scratch. But the basics of LookML can be picked up by SQL-speaking data analysts in a couple of hours.
LookML is version controlled. Doing data well requires tracking what was changed when, by whom, and why. But graphical languages simply don’t allow that kind of modern version control. Previous attempts to incorporate version control into data systems have been clunky, proprietary, and have actually impeded collaboration. LookML provides version control using Git, the programming industry standard.
It’s simple to debug. If you’ve ever tried debugging a graphical language, you know the pain of trying to untangle a bird’s nest of connectors. LookML developers benefit from a full-fledged Integrated Development Environment featuring auto-completion, error highlighting, contextual help, and a validator that helps you fix errors. None of that would be possible with a graphical language.
LookML is built for today’s complex data. Trying to “dumb down” your data tools doesn’t make complexity go away. Bad tools just make complexity harder to deal with. LookML is a powerful tool for power users that helps them capture that complexity--whether inequality joins, many-to-many relationships, multi-level aggregation, or anything else--and render it invisible to end users.
It fosters collaboration. Software developers have developed immensely powerful tools for collaborating on complex projects, and data products need these too! You can’t serve your whole company’s data needs by yourself. But SQL is inherently disorganized and impenetrable, making true collaboration impractical. LookML is architected to make collaboration natural and easy.
LookML empowers data professionals to empower others. LookML is a tool for data analysts and developers, not end users. By helping analysts get the knowledge about what their data means out of their heads and into Looker, LookML makes that knowledge available to everyone. The “data model” that Looker helps you build enables non-technical users to do their jobs--building dashboards, drilling to row-level detail, and accessing complex metrics--without having to worry about what’s behind the curtain.
In short, LookML is SQL evolved. It leverages SQL’s power in a way that’s familiar to analysts, while abstracting away the low-level concerns that analysts usually have to manage.
It’s a powerful language with a huge community of developers who support each other. The pre-built analyses they share--to help integrate Salesforce data, build a cohort analysis, or model weather data--will give you a huge head start on common analytic tasks.
Finally, it’s a living language that’s constantly growing--adding new features, dialects, and integrations. So as data, databases, and data analysts change, LookML will be there to meet them.
