Looker vs Tableau 2016
Looker and Tableau have taken almost diametrically opposed approaches to business analytics. Looker has a powerful language at its heart and Tableau relies almost entirely on visual constructs. Both support a rich visual environment, but Looker adds its powerful LookML language, capable of performing complex functions in just a few lines of code. It also directly accesses data instead of pulling it into its own data store, although Tableau has recently made moves in this direction too.
The decision to choose Looker or Tableau will depend on need. Tableau is relatively easy to use but can run out of steam for more complex needs. The decision to not include some form of language is a flaw in my opinion. Looker on the other hand can have its functionality extended via LookML, and the language serves the double function of also allowing a powerful semantic layer to be set up, where complex functions can be accessed as easily as routine measures and dimensions.
Several crowd based review sites (G2 Crowd for example) have recently scored Looker very highly, and it reinforces our view that some form of language will always be an essential component in business intelligence. It serves to address the highly bespoke needs most businesses have, makes complex data manipulation routine and serves to standardize the analytical environment. Tableau is lacking in this respect, and users need to be sure that their needs will not move outside certain bounds if they decide to choose Tableau.
Looker
Looker is definitely different from most of the contemporary BI platforms now crowding the market. The emphasis is much more on the transformation of raw data into a form that makes sense to the business. Many BI platforms come with a metadata layer, but Looker goes well beyond most other products. It also connects directly to data sources, with no intermediary data warehouse, although in some respects this is just semantics, since it needs the services of a query based database (HP Vertica for example). So the real differentiator is that it does not come with its own data warehouse, but uses the services of external databases.
Of course Looker does all the usual things – charts, dashboards, reports, collaboration and so on. However it calls upon a central repository of data and metric definitions like few other products do. This is both a strength and a weakness. It does ensure that the whole enterprise sees one version of the truth. However those users who might want to ‘do their own thing’ will feel inhibited to some extent.
At the heart of Looker is its modeling language, LookML. It is no exaggeration to say that LookML can often perform a task in just a few lines of code that might require hundreds of lines of SQL. This language facilitates a ‘just-in-time’ approach to data processing, where transformations and calculations are calculated when needed (officially called a late-binding model). This obviates the need to perform many ETL type operations and formatting of data.
Looker is best suited to organizations with the necessary discipline to create an enterprise wide BI facility with centrally defined functionality. The modeling language facilitates complex data transformation and the calculation of complex metrics. It may be overkill for some businesses, but it does open new possibilities for greater data analysis sophistication.
User Interface
Dashboards, tables and charts are the main visual currency of Looker, and because it connects directly to the full data sets there is no real limitation on how far a user can drill down into data. Because various metrics, calculations, and queries can be centrally defined, the user will typically be selecting items of interest from menus.
The web based interface means charts and dashboards can be viewed from any device with a web browser. A great deal of intelligence is built into the user interface, with automatic resizing and scaling. Looker supports third-party authentication via LDAP and Google Apps, and multi-factor authentication in the method of the user’s choice.
Modeling Language
At a time when most BI vendors are shying away from anything that looks like a programming language, Looker has placed its LookML modeling language at the heart of the product. This is not just a mechanism for creating queries and calculations, but allows data to be processed as it might using an ETL tool, supports complex data manipulation and processing logic. The net result of this is that data remains in its raw form in the relevant databases, and is transformed on the fly as it it needed.
Integration
Applications can expose Looker’s visuals using the RESTful API. The ‘Powered by Looker’ facility allows users to embed Looker analytics in any website, portal or app, or to OEM the entire Looker platform.
Looker also provides integration with Google Docs and Sheets, a robust API for developers, an additional package for R developers, and a Ruby SDK to help users build custom apps.
Tableau
Without doubt Tableau set the pace for easy-to-use data visualization and exploration software. In practical terms this means business users can get to their data, typically without assistance from IT, and create graphs, charts and dashboards in a way that is most meaningful to them. Authoring takes place on Tableau Desktop which, as a stand-alone environment, can perform its own analysis, either against the Tableau in-memory database, or against external data sources – databases, cloud data sources, spreadsheets and so on. In a group or enterprise setting Tableau Server acts as a central facility for data access, delivering visualizations, enforcing security and managing user access. Tableau Server distributes visualizations through the web browser to almost any device that supports a web browser – desktops and mobile devices.
The architecture of Tableau Server is scalable, and is well demonstrated by the Tableau Public free service where millions of visualizations (albeit simple ones) are served up every day. It does support some level of extensibility, particularly the coding of bespoke applications that are not natively supported, but users have to resort to XML code to achieve this.
One of the more intriguing aspects of Tableau is its integration with the analytic language R. It is such a stark contrast – the easy to use Tableau product set, and the not so easy to use R programming language. Even so it does give advanced users, and programmers the ability to add other forms of analysis into the Tableau environment, and particularly statistical analysis and predictive analytics. This contrasts with some of the competition (Spotfire particularly) who, in addition to an easy to use visualization capability also offer easy to use statistics and predictive analytics tools.
I set out by saying that Tableau set the pace, but in reality it is now at least equalled by several other products. Qlik Sense and Spotfire have both been reengineered for an easy to use experience, and there are cloud based products such as Sisense and GoodData. And of course we should not forget Microsoft’s latest foray into the world of data visualization and exploration with Power BI Designer. It’s immature, but it will be disruptive.
User Interface
As with most platforms of this type Tableau presents a drag and drop data exploration interface. It is Tableau Desktop, which can be installed on Mac and PC, that provides the visualization authoring environment. It provides most of the chart types and tabular representations a user might need, with intelligent assistance during the visualization creation phase. Tableau Desktop serves multiple purposes in addition to authoring. It allows users to manipulate metadata, and publish a workbook (a complete visualization package that can be executed by Tableau Server).
Users of Tableau Desktop can elect to load data into the columnar, in-memory, compressed database. Provided the data fits, it’s very fast – although data can also be cached on disk with an inevitable degradation in performance. This has become almost a standard way of delivering fast desktop analytics, and it’s very effective. If high performance analytics databases such as HP Vectra are used then the user can connect directly to these.
Tableau Server users are presented with ready-made workbooks displaying dashboards and reports. These are not static entities, and provide all the facilities for data manipulation a users might wish to perform – drill down and through for example. Accessing data sources is fairly straight forward, and it is a simple matter to blend data from several data sources.
The support for geographic data is particularly well regarded by Tableau users, and finds wide application where location is an important part of the information set.
Data Handling
Tableau will handle almost any form of data – databases, cloud data sources, OLAP cubes (with some limitations), big data databases, Excel spreadsheets – and so on. It also allows users to combine data from as many data sources as necessary. There are two basic forms of data access in Tableau. The first is the live connection where Tableau issues dynamic SQL or MDX (for OLAP cubes) directly to the data source. The in-memory database is a highly compressed in-memory engine that can hold very large amounts of data – because of the compression factor.
Extracts are a major feature in Tableau, and as the name suggests they are ready built extracts, possibly from much larger databases. These are stored in the columnar database, and most data sources can be treated in this way with the exception of OLAP cubes. The sharing of packaged workbooks depends on these extracts for sharing.
Architecture
The Tableau Server architecture supports excellent scaling through a multi-tier architecture. It allows Tableau to scale out and up as required. The components of the server architecture are:
- The VizQL Server – authenticated users can open a view and this server then sends requests to the relevant data sources. The results are sent back to the user as a HTML5 rendered image. This server component can be replicated as many times as necessary.
- Application Server – is the gateway to Tableau and handles various permissions, content browsing and server administration. Again this server component can be replicated as needed.
- Data Server – provides IT with a mechanism for IT to monitor, manage meta data and access to data sources.
- Backgrounder – refreshes extracts from databases.
Developer Support
Various APIs are provided for integration of Tableau objects with production applications.
- The JavaScript API supports the embedding of visualizations into web applications, with the ability to mimic look and feel of the host applications.
- A data extract API provides direct access to data sources, allowing data to be pre-processed before being used by Tableau. It also facilitates the creation of data extracts, which are used directly by Tableau visualizations.
- The REST API supports the direct manipulation of Tableau Server objects.
Users can extend the functionality of Tableau provided they have some knowledge of XML.
Governance and Management
The management of data access is governed by IT through the Data Server. The Tableau Server provides data isolation and multi-tenancy. Multiple “sites” can be hosted in a singe server, and each site can have multiple projects, which in turn can have multiple workbooks. Each entity can be managed as desired.
Authentication and security support Microsoft Active Directory, SAML, oAuth and a native authentication managed by Tableau Server.