Hacker News Reader

Comment by blowski | Hacker News Reader

I don't really understand what this article is trying to say, other than "isn't Looker great!".

Having timely and detailed data available to a wide range of people in the organisation is now seen as a competitive advantage in many industries. There's a lot of tech out there to help with this.

But I could have written this article talking about how companies like Reltio are relying on NoSQL solutions to "empower the enterprise", or how Firebase is allowing startups to not worry about data structures, or how HSBC is deploying blockchain solutions, or how Spark means you can combine data from all different sources. It would still be just as accurate and meaningful. As it is, it just sounds like an infomercial for Looker.

View on HN

The weirdest part to me is that they went from 'Everyone is back to using SQL because it's good at querying and you don't need to learn a proprietary language' to 'Let's use LookML instead'.

Correct but the problem with raw SQL is that it's not composable easily. LookML essentially provides that composability on top of SQL.

I don’t agree - I find SQL easy to compose using CTEs and Functions - Postgres 12 is amazing for this because chained CTEs are now just as fast as traditional nested joins (which can be hard to decipher). Also lateral joins are great for composing set returning functions - Postgres joins them automatically - like magic.

CTEs solve the problem to some extent only for the data-sources. You often need to have snippets, expression functions, being able to compose multiple expressions, be able to compile SQL queries that are both efficient and readable if you want to be able to cooperate with different data analysts. It's not because SQL is limited, it works the way it's designed.

Take this example: https://github.com/rakam-io/recipes/tree/master/segment/ware... It also makes use of CTEs and lateral joins but it also needs to use a templating engine (Jinja) for data models and Jsonnet for analysis models similar to LookML in order to provide that composability.

Agreed. LookML is to SQL what SASS is to CSS: not necessary but it sure makes certain things easier.

I’m not connected with Looker in any way, and they are pretty expensive, but the product is awesome.

I agree with you, Looker is awesome but it's far from perfect. It does solve most of the problems in a convenient way but as the data modeling gets more and more complex and they're not going to able to iterate the product at that pace, it's the destiny of almost all the enterprise products.

Product analytics is one of these complex use-cases. You can't really find a convenient way to run funnel and retention queries in Looker, it only focuses on slicing/dicing the data with their models. Moreover, it has a high learning curve even for the enterprise and there are definitely better ways to approach this problem.

Disclaimer: We're actually working on a LookML alternative based on Jsonnet that will be a better alternative for event modeling. This is how it looks like: https://github.com/rakam-io/recipes. We recently published a VSCode extension for it: https://marketplace.visualstudio.com/items?itemName=rakam.ra...

I find lookml extremely useful but if you have something built for event analytics I can’t wait to try it. Looking at the docs, it’s not clear to me how I get started though. Maybe an introductory tutorial on open source stack and freely available dataset would help a little with that. Just a suggestion.

Its a blogvertisment by Holistics, which is a competitor to Looker.

Oh, I've never heard of them, thanks for the heads up. Explains why it reads like an advert - because it is.

These days blogs hosted on company sites are almost invariably marketing of some flavour. Even if they're tech heavy, it's marketing to e.g. improve hiring.

Reply on news.ycombinator.com