If you follow Red Pill Analytics at all, you know that we have our hands in a bit of everything when it comes to data and analytics; having the opportunity to work with various tools and technologies is one of the many benefits to working at RPA. One particular tool that we have found ourselves working with more and more as of late is Looker. Looker continues to demonstrate success while gaining a ton of traction in the Business Intelligence and Analytics space and has no doubt won the praise of us Red Pillians. Offering both cloud and on-premise options for their customers, Looker is a data visualization tool with a modeling layer. Hold onto that thought.
And if you follow Red Pill Analytics, you know that we are big fans of all things version control. In fact, if you work with Oracle Business Intelligence Enterprise Edition (OBIEE) and are still using MUDE, passing around a .rpd file so that everyone can “commit to master”, or going as far as designating times that each developer can deploy changes or work online, all things I have seen or experienced working with various clients, you should have a look at Checkmate. That being said, RPA’s Checkmate is a multi-faceted tool that does more than version control but I digress…
Back to Looker. At a high level, Looker stores objects in two places — the internal application database for things like metadata, Looks (reports), and some dashboards as well as in files written in LookML, Looker’s proprietary domain-specific language (DSL). LookML is cool. LookML is really cool. It is really cool because it serves as the abstraction layer between the reporting and the database layers and it allows developers to code as simple or as complex as required. In other words: it is flexible. Having the LookML abstraction (or logical, or semantic) layer for modeling provides all of the things a modeling layer should provide: standardization, repeatability, scalability, DRY coding, the list goes on. LookML helps separate Looker from pure data visualization tools and allows it to scale to the enterprise. Don’t get me wrong, there is a time and a place where pure data visualization tools suffice but there are countless use cases where a logical layer of abstraction is a should or even a must have.
For anyone new to LookML or apprehensive about writing code, Looker does an exceptional job of publishing documentation on LookML. The IDE is also intuitive and provides dynamic lists and definitions as LookML is being written. Additionally, auto-complete functionality helps to speed things along.
What does all of this have to do with version control? The LookML files I have been going on about are typically stored in a Git repository using Looker’s native Git integration. Looker’s native Git integration! After following the four-step process of creating a Git repository, creating a Looker project, linking the project to the repository, and granting Looker access to write to the repository, that is all it takes to get going with a Git-linked Looker project.
Looker maintains a master branch and a development branch specific to each developer’s user account. Depending on the project configurations, developers can develop on his or her branch, commit code, and commit to master or open a pull request to have code deployed. The Git integration saw some significant enhancements with the release of Looker 5.0. Among the enhancements is the ability to create shared branches, switch branches, and read-only access to other developers’ branches. To grab a quote from RPA’s Stewart Bryson:
This is truly fantastic. Feature branches. Built right into a BI tool.
-Stewart, sometime last month, via Slack
I don’t disagree. Most BI tools either need a third-party companion tool such as Checkmate to manage version control or they can be set up in a round-about way to allow source code to be stored and accessed in a repository but Looker takes the cake on this one. Not that there is anything wrong with third-party applications to manage version control; have I mentioned Checkmate yet for those of you using OBIEE? Third-party applications are great but we created Checkmate because there were a handful of problems that needed to be solved, one of those being version control. Native version control built right into a BI tool, as Stewart said, is truly fantastic.
Normally, this topic would be a good candidate to walk through some of the setup and functionality step-by-step but the folks at Looker have already done that here and I’m not one for reinventing the wheel. Head on over to the Looker docs and see for yourself.
