What is our primary use case?
We needed Cube in order to have a robust semantic layer on top of our ClickHouse database to avoid exposing our projection database directly in our app, and we needed to have sub-second latency metrics for our users.
We directly embed the queries generated by Cube in our app.
Our software engineering team provides the data team with events coming from ClickHouse. We ingest this data and enrich it with other sources, which allows us to create new dimensions and measures that should be displayed in our app. We did not want to expose our data warehouse or our production database directly in the app, so we use Cube to generate JavaScript queries and put them directly in our customer's app. A specific use case is for our deliverability team, which provides our clients with metrics about email deliveries.
What is most valuable?
Cube is a robust semantic layer that is really helpful in converting SQL queries into JavaScript functions, and it integrates smoothly in our single page framework application.
Among others, I would highlight the ability to convert SQL queries into JavaScript functions easily, as well as the cache feature that is really helpful in managing our resources.
For the deliverability team use case, we needed to have almost real-time data displaying at sub-second latency. We are using the cache feature that stores the results every five minutes. This allows us to have almost real-time metrics while managing our resources efficiently at scale.
What needs improvement?
There is something that should be improved. We are providing metrics on email, and in the email industry we have both transactional emails and marketing emails. We have different models for these, but the metrics are actually the same: open rates, deliverability rates, soft bounce rates, and other metrics. There is no way to create a real template that is not exposed directly in the UI. We basically customized it by creating a file for all the metrics, and then we extended our previous views with this template. However, this template is exposed directly in the UI, which is not relevant for us. We do not want people using the UI and selecting metrics from this template.
For the UI, our use case is more for back-end engineering, so not everyone using it is using the UI. Something that could be really helpful when using the UI is the ability to make it nicer and more intuitive. To illustrate what I am saying, we cannot order the fields in the UI. We cannot say that we want organization ID to be on top. It is going to be sorted alphabetically, and I do not think that is the most practical way to manage everything, especially when we have views with roughly one hundred dimensions and of course some measures as well.
For how long have I used the solution?
We have been using Cube for roughly one year and a half.
What do I think about the stability of the solution?
Cube is definitely stable.
What do I think about the scalability of the solution?
Cube is really scalable. The one thing I did not test so far is the way it handles nested fields, but I am sure it is doing so properly. If it handles this kind of thing, in the future we could get rid of Omni and maybe switch to Cube fully.
How are customer service and support?
We did not really have to deal with customer support since we implemented it internally with on-premises.
Which solution did I use previously and why did I switch?
We do not have previous solutions for this specific use case, but we have plenty of different solutions. We have ClickHouse, and we have data exposed through another semantic layer called OmniVision and OmniAnalytics, which is directly plugged into our data warehouse on BigQuery. In app, we have three different sources exposed: one directly from ClickHouse for main dashboards, one from Cube directly, and one from Omni semantic layer for self-service analytics.
We considered using the semantic layer of Omni, but it is actually really expensive. We needed to separate our use cases. One thing that would be really helpful using Cube would be to have the ability to generate charts directly and embed them inside our app. I would say we could quit Omni for this kind of feature.
How was the initial setup?
Implementation was super smooth. Within two weeks, we were up and running and the metrics were exposed in our app. We also really enabled a team within the company that was not able to play with data and expose it to the client, especially since this is a very niche team inside the company. We could not measure the ROI per se, but our ideal customer profile and targeted clients were really amazed by this because it was providing them with the way our server is running for them to handle their marketing campaigns. It is more for advanced users, but it is really important for them because they need to see the ROI in everything they pay for.
What other advice do I have?
There is something that should be improved. We are providing metrics on email, and in the email industry we have both transactional emails and marketing emails. We have different models for these, but the metrics are actually the same: open rates, deliverability rates, soft bounce rates, and other metrics. There is no way to create a real template that is not exposed directly in the UI. We basically customized it by creating a file for all the metrics, and then we extended our previous views with this template. However, this template is exposed directly in the UI, which is not relevant for us. We do not want people using the UI and selecting metrics from this template.
One thing that would be really helpful using Cube would be to have the ability to generate charts directly and embed them inside our app. I would say we could quit Omni for this kind of feature.
I would recommend starting with a use case directly, using Docker, and putting it up and running really quickly. Then plug a source. Do not plug many sources at the very beginning. Just try it, check the value proposition, and I am pretty sure you will be amazed in no time. Identify a pain point and try to tackle it with Cube. Once you have done this step, you are pretty much committed to the solution because it works. I would rate my overall experience with this solution as nine out of ten.
Which deployment model are you using for this solution?
On-premises
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?