Cube Cloud

In my recent projects with Cube, I was tasked with finding crashes and the reasons behind them using three datasets: people, crash, and vehicles. I had to merge them and preprocess them, clean and fill the missing values and outliers, and then divide the datasets into the star schema. After filling the data from local sources, I uploaded the data to the server and ran Cube. We do this to retrieve data by creating hierarchies; for example, within a city, we can specify particular areas and then drill down. When we fetch one thing, we connect with the hierarchy to retrieve the latest part of the data.

I have recently worked with two tools related to Cube: SSIS and SSAS, which are SQL Server Integration Service and Analytical Service. It is important when we build the pipelines and make the checks to insert new data into the pipelines, validating any null or missing values that might still be there. To make the pipelines efficient, we have checks in the pipeline that enhance the efficient features for Cube as well as the keys.

Cube's caching mechanism impacts my database query loads and response times significantly. Once we create the star schema and Cube, we do this to retrieve specific data as quickly as possible because with billions of records, fetching everything takes a lot of time. We establish specific measures and counts and design a specific star schema. Based on that, we use fact tables and dimension tables to fetch records as quickly as possible.

When it comes to Cube's multi-tenant features, I need to observe the requirements of the data when it is available across different clouds, including Google GCP and AWS. If I need something that exists on both clouds, I have to fetch the specific data based on these requirements using data analytics queries and analytical queries.

Regarding Cube's dynamic access controls, I have to keep in touch with the compliance departments to control data security and inform them about everything I have. This includes encrypting the data to make it more efficient. Sharing everything with the compliance departments adds security features that make the dynamic data more secure and efficient. I understand that data is vital, and I need to ensure it remains confidential.

To evaluate Cube's efficiency in handling large data volumes, I use metrics including F1 scores, AUC (Area Under the Curve), and RMC (Root Mean Squares), along with RSE (Root Square Errors). These factors help me gauge the efficiency of the algorithms clearly.

Regarding improving Cube, I believe that when we are building hierarchies, I should enhance the type of hierarchies. For instance, in a few countries lacking state systems, there could be a hierarchy without proper categorization—such as continent, country, and city. Therefore, it would be beneficial if I could improve the hierarchies to retrieve data as quickly as possible from Cube.

I have been working with Cube for two and a half years. I am still working on many projects, and I have worked on many datasets, including vehicle crash results and HR-related datasets. I am still collaborating with professors on my Tech Well Group. I recently finished my internship from there as well. I am familiar with many of these aspects.

Regarding Cube's technical support, I have discussed issues with my professors whenever I faced technical difficulties. They provided guidance by suggesting possible troubleshooting methods to help overcome the technical issues I encountered.

When it comes to the initial setup of Cube, I faced some challenges, including server issues when uploading data from local sources to the Unipi servers. Most of the time, I encounter connectivity errors, but I navigate these issues by ensuring I match IDs and records and align the columns of the tables I have created in the data warehouse with those in local CSV files. Once everything is matched, I can transfer data to the data warehouse and construct the schemas. These are the common challenges I face while developing Cube, yet I still manage to proceed.

When considering other options in the market, I find that I make Cube when handling a large amount of data. I create Cube for specific segments of data. For example, if I manage one million records, I focus on that critical data which I will use most often. This is why I create Cube for that one million records, making it easier and faster to retrieve and validate the data.

I have not utilized Cube's pre-aggregation feature, but I have studied how to build decision trees from parent to child leaves. I understand how it is structured with two branches, three branches, and so on. I have worked on that aspect as well concerning decision trees.

From the functionality perspective, at this moment, I do not think there are any missing features in Cube that I would want to see included in the next release. Perhaps some features could be added depending on specific working conditions.

Given my experience with Cube, I would advise organizations to prioritize managing hierarchies when developing Cube, as hierarchies are vital for efficient data retrieval. The hierarchy resembles a tree structure with parent, child, and then child leaf, and it essentially continues. If I manage these hierarchies effectively, it greatly facilitates retrieving the specific data and records I need in an efficient and timely manner. Overall, I would rate this product a 7.5 out of 10.

Cube is an end-to-end digital move technology and solution that I have used in the digital era. I run various projects such as market research surveys, which are end-to-end projects where I use Cube for modeling and designing purposes.

Cube helps me significantly with financial planning and analysis. The tool creates spreadsheets for financial planning analysis, and there is an option for a repository of financial operation data. This allows my team to build faster, more accurate scenarios and reports.

Cube completes my tasks very easily and takes less time, allowing me to deliver any project in a timely manner to our clients. Cube has definitely helped me a great deal.

I was running a financial project where my team was taking too much time, and when I ran that project on Cube, it helped me move from manual data management to strategic analysis very easily.

Everything is functioning well, but Cube is a little bit slow when I use multiple projects at the same time, which makes it very hard to run.

I would appreciate if Cube could be more human accessible, as there is no free access available. I am not getting access to the knowledge center.

I have used Cube for around three years.

Cube only supports daily use. If I increase the workload, then it will not work as efficiently as I would want it to per my expectations.

I do not have any experience with customer support for Cube, so I am not going to share any opinion on customer support. Some colleagues told me you can use different tools as well.

I did not use any different solution before Cube, so I do not have much idea. However, when I used traditional BI, it was the same.

I did not see any return on investment from Cube.

The cost is around $1,500 per month. The exact number is not coming to my mind, but it is approximately $1,500 or $200 per month.

LookML is also an option similar to Cube. Another option I evaluated was Looker.

My experience with pricing, setup cost, and licensing for Cube was good and it helped me a great deal in analyzing the pricing. I believe Cube's relationship with my company is as a reseller. My overall review rating for this product is 8.

Cube is used at Brevo to expose customer-facing analytics in the product. The DBT semantic layer proved effective for internal BI, but for customer-facing analytics, a high-concurrency app was needed. Cube was ideal for defining a single source of truth, queryable via API with rapid response times thanks to Cube Store and caching.

Example use cases include an emailing analytics portal offering insights into deliverability metrics, such as hard bounce rates. This metric is defined in Cube and is calculated by dividing the sum of delivered emails by those with a hard bounce event. Governance of metrics is crucial for consistency across the product, reducing discrepancies and ensuring everyone is aligned.

Key to this strategy is having versioned metrics governed by GitHub, offering transparency and impact analysis when changes occur, aligning communications with the backend development team on a unified front.

The first major impact observed was a reduction in support tickets. Internally, uncertainty around metric definitions was resolved, aligning everyone. Additionally, a customer NPS survey showed high satisfaction with data quality and bug reduction. Previously, discrepancies between UI reports and analytics caused customer frustrations and increased support tickets.

NPS improved to approximately eight out of ten for our feature, and internally ticket handling times decreased, allowing reallocation of resources to higher-impact projects. Financially, less churn on customer analytics offers has also led to more revenue and an overall positive ROI.

Cube's standout features include assisted modeling with AI for quicker onboarding, saving time in developing the semantic layer. Cube's semantic layer centralizes a single source of truth for metrics, preventing data drift, heightened by version control. Additionally, Cube's pre-aggregations and Cube Store boost query performance for significant data sets, offering rapid results, crucial for user experience.

The performance of the tool with pre-aggregation is excellent, providing fast response times and reliable metric governance. AI capabilities enhance the developer experience, and its robust features markedly impact business operations.

Cube's interface can be challenging for non-technical users, needing clearer use-case examples to ease integration into workflows. Despite AI introductions, deterministic outputs require better contextual understanding of company needs. Cube's SQL API, while useful, sometimes struggles with complex BI-generated SQL. Enhancements in SQL pass-through could alleviate occasional issues, such as timeouts and CPU impact when handling advanced functions in TRIM or window functions.

I have been using Cube for approximately one year and a half.

Cube is very stable. We have never experienced any issues.

Our customer analytics software scales excellently, managing thousands of customer requests per second without issues. Cube's API is robust, with multiple Cube API and refresh worker instances managed behind a load balancer, supporting organizational scalability by dividing into microservices.

We have limited customer support interactions, mainly utilizing Cube's Slack community for inquiries.

We did not have any solution before. We did not have a semantic layer before implementing Cube.

It is difficult to quantify exactly, but less churn on our customer analytics offer means more revenue. Additionally, reduced ticket times allow staff reallocation to impactful projects, signaling positive ROI.

We do not have much experience because we are using the open source version. As we are hosting it ourselves, we do not pay much.

I am aware of alternatives in the DBT semantic layer. Cube was chosen due to its caching and Cube Store capabilities essential for customer-facing dashboards. No other solutions were evaluated once Cube's benefits were validated in a DBT community article.

Understanding Cube's capabilities and adapting organizational data philosophies are imperative. Initial adoption should focus on building a minimum viable semantic layer, consolidating key metrics into a single source of truth to showcase the tool's value. Budget constraints dictate the choice between open source or cloud implementations. I would rate this product an eight out of ten.