3 ms·

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

sturgill 7y ago
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.
- buremba 7y ago
  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 https://github.com/rakam-io/recipes. We recently published a VSCode extension for it: https://marketplace.visualstudio.com/items?itemName=rakam.rakam-data-modeling https://marketplace.visualstudio.com/items?itemName=rakam.ra...
  - luckydata 7y ago
    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.
garyclarke27 7y ago
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.
- buremba 7y ago
  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/warehouse/page 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.

sturgill 7y ago

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.

buremba 7y ago
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 https://github.com/rakam-io/recipes. We recently published a VSCode extension for it: https://marketplace.visualstudio.com/items?itemName=rakam.rakam-data-modeling https://marketplace.visualstudio.com/items?itemName=rakam.ra...
- luckydata 7y ago
  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.

garyclarke27 7y ago

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.

buremba 7y ago
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/warehouse/page 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.