Holistics vs Looker: A Feature-by-Feature Comparison
Looker (acquired by Google) is a powerful business intelligence and analytics software that enables self service analytics.
This article is written by ex-Looker users, for experienced Looker professionals to hash out the similarities and differences between Holistics and Looker, and shares the use-cases the two tools best fit.
High-Level Comparison
Holistics and Looker are a very close comparison as both tools take a very similar approach to BI: code-based modeling layer with self-service data exploration.
Both tools are 100% cloud-based, provide a centralized data modeling approach for BI teams, and empower business users who don’t know SQL can do true self-service.
Looker is generally more mature than Holistics in terms of analytics functionality, but Holistics is also catching up fast. You can think about Holistics as a mini-Looker, where you get around 80% of the functionalities for probably 20% of the price.
A downside of Looker is that it requires your data team to learn LookML (which can be expensive to hire or train), while Holistics provides a gentler learning curve towards setting up data modeling.
Trial Experience and Pricing
While both tools are directionally similar, the go-to-market approaches are different, thus what the end customers experience throghout the evaluation process is different.
Looker’s target market are mainly enterprise customers, thus their entry price may not be affordable for some companies. They also do not provide a self-service trial experience, you need to contact a salesperson to even start to try out Looker.
On the other hand, Holistics provides an affordable alternative to Looker for SMBs and mid-markets. It provides a fully self-service trial process. Pricing is also transparent and starts at $100, making it easier to try out.
Data Modeling and Transformation Layer
Looker and Holistics are similar in that both provide a data modeling layer that translates between business users’ drag-and-drop inputs to a database query.
The data modeling layer not only provides self-service analytics for business users but also provide a centralized management interface for data analysts to ensure that the data exposed is accurate, maintainable and reusable.
Both tools invented their own modeling language. Looker with LookML (Looker Modeling Language) and Holistics with AML (Analytics Modeling Language).
Terminologies: While the approaches are similar, both tools use slightly different terminologieLet’s compare this terminology side by side to understand them better.
| Looker | Holistics | Purpose |
|---|---|---|
| Looker View | Holistics Data Model | A data entity, usually a logical mapping of a database table |
| Looker Explore | Holistics Dataset | A collection of Looker views / Holistics models. Shared with end users for data exploration purpose. |
| Looker Persisted Derived Table (PDT) | Holistics Transform Model | Persist results of a SQL query back into data warehouse |
| Looker Join | Holistics Relationship | Define the join/relationship between 2 views/models |
Looker Views vs Holistics Data Models
In Looker, we bring the metadata of our tables/views from our data warehouse with the import table option which autogenerates the basic lookML and creates the dimensions and measures for you to build on top of the view.
In Holistics, the metadata is imported using a similar import data table method where all the whole schema or selected tables can be imported automatically, and base dimensions are created by default.
Looker Explore vs Holistics Datasets
When it comes to data exploration Looker and Holistics have a similar concept but a different experience for the data consumers. Looker uses a concept called Explore to provide all the subject-specific data fields for their users to explore data and create relevant visualizations.
On other hand, Holistics uses the dataset concept to curate a subject-specific dataset for the data consumers to explore and create visualizations.
In both instances, SQL is generated auto-generated and non-technical users can still create reports and dashboards without much assistance from the technical team. This user experience is even better served to non-technical users as it mimics a very similar drag-drop interface like other BI tools such as Tableau etc.
Looker Derived Tables vs Holistics Transform Model
There are times when Looker or Holistics can’t support complex use cases in their modeling language and it needs to support a custom derived SQL to structure the data in a format that is friendly for visualizing. This is possible in Looker using its sql derived table syntax in LookML, whereas this is easily achieved in Holistics using its Transform Model feature.
This makes it easier for any Analytics/SQL Developer to solve complex use-cases using their native Data Warehouse SQL syntax.
LookML vs AML
With both Looker and Holistics offering the propriety language you can perform data transformations with tons of flexibility. Let’s take a look at LookML and AML code samples here.
Holistics AML tries to optimize for a better developer experience through auto-complete and instant feedback of errors. Their developer-first approach makes AML much easier to pick up and start developing than LookML. This similarity of the languages between the tool makes it easier for the developer to switch and adopt.
Dashboards Visualization Layer
When it comes to the dashboard visualization layer both tools offer varied chart options like a bar, line, heatmap, etc. However, Holistics provides better-looking charts and even more visualization types by default than Looker. For instance, if you want to keep all your metrics in one sheet and visualize it with sparklines, it can be visualized using their metric sheet widget type easily.
Initial Learning Curve
A requirement that immediately sets Looker apart from other alternatives is the need to invest time in an upfront data modeling step before any data visualizations can be done. For Looker, this means learning and preparing the modeling work in LookML first, as an abstraction on top of a SQL database.
Learning LookML is not rocket science but still takes significant effort, thus creating a fairly high barrier of entry. As a result, only analysts who are willing to invest in Looker’s approach would go through the process of learning it. Furthermore, Looker’s domain-specific language approach has a fairly long feedback cycle as analysts need to write the code, validate, save and only then can test it through exploring the resulting models. If there is an issue with the generated code, the analysts need to go back into fixing the code and repeat the cycle.
Holistics’ data modeling process, on the other hand, does not require the need to learn a new language.
The only requirement is some minimal SQL knowledge to model some advanced use cases such as custom fields. Analysts can jump right into the data modeling process and get the models out with minimal learning. Furthermore, the feedback cycle is small as the data modeling interface has integrated visualization output, making it apparent when there is some fault in the models. As the underlying models are also stored as a domain-specific language, Holistics also retains the advantages of this approach and allows more advanced users to have freedom over the modeling process.
Holistics vs Looker: A High-level Summary
| Aspect | Looker | Holistics |
|---|---|---|
| General | ||
| High-level Approach | Take similar approach: 1. Analysts define analytics logic centrally 2. Business users perform self-service data exploration | |
| Evaluation Process | Sales-led; Compulsory to speak to Sales | Self-service trial; Speak to sales for further questions. |
| Deployment | Cloud hosted or self-hosted | Cloud hosted |
| Compliance | GDPR; SOC2; HIPAA | GDPR; SOC2 Type II |
| Pricing | Opaque (need to speak to sales); Require high upfront commitments; Annual payment | Transparent; Can start small ($150/mo), scale up as usage grows; Pay monthly & annually |
| Support | Dedicated Customer Love team | Highly praised |
| Learning Curve | Steep. Require analysts to learn LookML, and work with code interface. | Gentler. Provide both visual interface (GUI) and code interface (AML) |
| Modeling Layer | ||
| Central Modeling Layer to define Business Logic | Yes, with LookML. | Yes. With AML. |
| GUI to model data | No. Only code-based interface. | Yes. Dual interface (both code-based and GUI-based). |
| Prebuilt Data Models | Yes, with Looker Blocks | No. |
| Integration with data transformation tool | No | Yes. Native integration with dbt. |
| Work with CSV / Google Sheets source | No. | Yes. Native support. |
| Developer Experience | ||
| Code-based approach | Yes (LookML) | Yes (AML) |
| Version Control with Git | Yes | Yes |
| API | Yes | Yes |
| Reporting & Visualization | ||
| Self-service Exploration | Yes | Yes |
| Visualizations | Rich visualization | Rich visualization |
| Custom Visualizations | Yes, through Looker Marketplace | Yes, through Vega-Lite |
| Pivot Table | Yes | More advanced, with subgroup calculation |
| Date Comparison | No native support (Workaround) | Native support with Period-over-Period Comparison |
| Embedding | Yes | Yes |
Conclusion
The above comparison shares a few highlights in the similarities between Holistics and Looker. Sign up for a Holistics trial and try it out yourself.
Here’s how an ex-Looker user made the switch to Holistics.
Because Data Team Is Not An IT Help Desk
Fewer ad-hoc data questions. Happier data teams. All starts with Holistics.