Today, we're happy to support Looker users switching over to Cube and present `lkml2cube`, a tool for converting [LookML](https://cloud.google.com/looker/docs/reference/lookml-quick-reference) models into the Cube data model. With this tool, you can easily migrate your existing [Looker](https://cloud.google.com/looker/) projects to Cube.

## Benefits of using Cube

Cube is a code- and API-first semantic layer that enables data engineers and developers to make their data consistent, secure, performant, and accessible across every application. Cube is commonly used to implement a *semantic layer*: a middleware between your data source and your application that provides a unified view of your data, regardless of where it is stored or how it is formatted.

By migrating your LookML models to Cube, you can achieve the following:

- **Reduced development time.** Once you have migrated your LookML models to Cube, you can start using Cube's powerful features, such as its pre-built calculations, dimensions, and measures, to create your data applications. Using Cube can save you a significant amount of development time.
- **Improved data quality.** Cube's semantic layer can help you improve your data quality by performing data transformations, validations, and aggregations. Using Cube's version-controlled semantic layer definition can help you to ensure that your data is consistent, accurate, and reliable.
- **Enhanced performance.** Cube's in-memory data store can help improve your data applications' performance by caching frequently accessed data, thus providing faster user response times.
- **Increased accessibility.** Cube's API-first design easily integrates Cube into your existing data applications.

Initially, we’ve created `lkml2cube` to facilitate our work while supporting the migration of Looker users to [Cube Cloud](https://cube.dev/product/why-cube-cloud). Now, we’re happy to put it into [open source](https://github.com/cube-js/lkml2cube) to assist more Looker users in their migration over to Cube.

Given Cube’s current position as a [leader and fast-mover](https://cube.dev/blog/cube-recognized-as-a-leader-and-fast-mover-by-gigaom) among semantic layers, there’s no surprise we see more and more companies migrating to Cube from their legacy solutions:

[![](https://ucarecdn.com/d266a78b-3dcf-4355-a59d-17a15007afa1/)](https://cube.dev/gigaom-rates-cube-as-a-leader-for-semantic-layers)

Here’s how one of Cube Cloud users describe their experience:

> We recently transitioned from Looker to Cube in an effort to enhance the user experience on our data-intensive internal platform, both in terms of performance and user interface. Our aim was to seamlessly embed data and analytics into our team's workflows.
> 
> With the invaluable assistance and robust tools provided by the Cube team, we successfully migrated a significant portion of our LookML project, encompassing hundreds of views and explores, to Cube’s data modeling language in just a matter of weeks.
> 
> *Director, Data Products at an investment firm*

## Migration example

Cube’s data modeling language has a few similarities with LookML, however, it’s arguably more powerful, flexible, and fit as a data modeling language for a modern semantic layer.

* [Cubes](https://cube.dev/docs/reference/data-model/cube) represent tables of data in Cube and are roughly equivalent to [views](https://cloud.google.com/looker/docs/reference/param-view) in LookML. However, cubes are a bit more powerful since they can contain [join](https://cube.dev/docs/reference/data-model/joins) and [pre-aggregation](https://cube.dev/docs/reference/data-model/pre-aggregations) definitions—the latter are used to provide granular query acceleration configuration and inform Cube’s [aggregate awareness](https://cloud.google.com/looker/docs/aggregate_awareness).
* [Views](https://cube.dev/docs/reference/data-model/view) sit on top of the data graph of cubes and create a facade of your whole data model; they are roughly equivalent to [explores](https://cloud.google.com/looker/docs/reference/param-explore) in LookML. However, when referencing cubes, views allow to define an exact full join path and remove the ambiguity of searching the join path within the data graph. `lkml2cube` accounts for this quirk of LookML and performs a breadth-first search in the data graph to find the most suitable join relationship.

Consider a simple Looker project that is structured in the following way: 

```
.
├── my_explores.model.lkml
└── views
    ├── line_items.view.lkml
    ├── orders.view.lkml
    ├── product_categories.view.lkml
    ├── products.view.lkml
    ├── suppliers.view.lkml
    └── users.view.lkml
```

After applying `lkml2cube`, an equivalent Cube project would be structured similarly: 

```
.
└── model
    └── cubes
        ├── line_items.yml
        ├── orders.yml
        ├── product_categories.yml
        ├── products.yml
        ├── suppliers.yml
        └── users.yml
    └── views
        └── orders_view.yml
```

You can generate the Cube data model for your entire Looker project by executing a single command against the file with LookML explores. `lkml2cube` would inspect that file, follow the references in the `include`parameter, and generate necessary cubes and views:

```bash
lkml2cube views my_explores.model.lkml --outputdir model/
```

For example, the following `views/orders.view.lkml` file…

```javascript
view: orders {
  view_label: "Orders"

  sql_table_name: "public.orders" ;;

  dimension: unique_key {
    type: string
    primary_key: yes
    sql: ${TABLE}."id" ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}."status" ;;
  }

  dimension_group: created_at {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}."created_at" ;;
  }

  measure: count {
    type: count ;;
  }

  measure: total_order_amount {
    type: sum
    sql: ${TABLE}."number" ;;
  }
```

...would be converted into the following `model/cubes/orders.yml` file:

```yaml
cubes:
  - name: orders
    sql_table: public.orders

    joins:
      - name: users
        sql: "{CUBE}.user_id = {users}.id"
        relationship: many_to_one

      - name: products
        sql: "{CUBE}.product_id = {products}.id"
        relationship: many_to_one

    dimensions:
      - name: id
        sql: "{CUBE}.id"
        type: number
        primary_key: true

      - name: status
        sql: "{CUBE}.status"
        type: string

      - name: created_at
        sql: "{CUBE}.created_at"
        type: time

    measures:
      - name: count
        type: count

      - name: total_order_amount
        sql: "{CUBE}.number"
        type: sum
```

Consequently, the following `my_explores.model.lkml` file...

```javascript
explore: orders {
  label: "Orders Summary"

  join: users {
    relationship: many_to_one
    sql_on: ${orders}.user_id = ${users}.id ;;
    type:  left_outer
  }

  join: products {
    relationship: many_to_one
    sql_on: ${orders}.product_id = ${products}.id ;;
    type:  left_outer
  }

  join: line_items {
    relationship: one_to_many
    sql_on: ${orders}.id = ${line_items}.order_id ;;
    type: left_outer
  }

  join: product_categories {
    relationship: many_to_one
    sql_on: ${products}.product_category_id = ${product_categories}.id ;;
    type: left_outer
  }

  join: suppliers {
    relationship: many_to_one
    sql_on: ${products}.supplier_id =${suppliers}.id ;;
    type: left_outer
  }
}

```

...would be converted into the following `model/views/orders_view.yml` file:

```yaml
views:
  - name: orders_view

    cubes:
      - join_path: orders
        includes: "*"

      - join_path: orders.users
        prefix: true
        includes: "*"

      - join_path: orders.products
        prefix: true
        includes: "*"

      - join_path: orders.line_items
        prefix: true
        includes: "*"

      - join_path: orders.products.product_categories
        prefix: true
        includes: "*"

      - join_path: orders.products.suppliers
        prefix: true
        includes: "*"
```

Note unambiguous join paths like `orders.products.product_categories` and `orders.products.suppliers` in the example above that `lkml2cube` was able to detect and express in the Cube data model. Over time, it would save hours, if not days, of work when building and debugging complex data models.

## Conclusion

`lkml2cube` is a powerful tool that can help you convert LookML models into Cube’s data modeling language and assist your migration from Looker to Cube. In case this tool is relevant to your data stack, please feel free to [check the documentation](https://cube.dev/docs/reference/python/lkml2cube) and give it a try.

Lastly, you're always very welcome to join our [Slack community](http://slack.cube.dev/) of more that 9,000 data practitioners and share your feedback on this update.

Paco Valdez

Looker

Supporting the transition to Cube's semantic layer from legacy solutions

Introducing a tool for Looker to Cube migration

Three months ago, we've introduced [Semantic Layer Sync](https://cube.dev/blog/introducing-semantic-layer-sync) to completely bridge the gap between the semantic layer and BI tools and enable instantaneous, zero-friction self-serve analytics. We've launched with several [supported BI tools](https://cube.dev/docs/product/workspace/semantic-layer-sync#supported-tools) and promised to gradually expand the spectrum of BI tools that work with Semantic Layer Sync.

**Today, we're delivering on that promise and introducing the Tableau support in Semantic Layer Sync.** Now you can author the data model in Cube Cloud and have it seamlessly synchronized with [Tableau Cloud](https://www.tableau.com/products/cloud-bi) or [Tableau Desktop](https://www.tableau.com/products/desktop) where you can access the data from the semantic layer to build workbooks and dashboards.

In the following demo video, you can see that it takes seconds to configure Semantic Layer Sync and surface a [view](https://cube.dev/docs/product/data-modeling/reference/view) from Cube's data model to a workbook both in Tableau Cloud and Tableau Desktop:

<video width="100%" controls><source src="https://ucarecdn.com/16a984fa-b3a2-411d-872d-184bc476f46a/video.mp4" type="video/mp4"/></video>

Over the last months, Semantic Layer Sync has proven itself as a feature that saves a lot of time for data engineers who define metrics in the semantic layer and enable self-serve analytics for their end users in BI tools. Now, it's time to integrate Semantic Layer Sync in your Tableau workflow.

**Semantic Layer Sync with Tableau is available in Cube Cloud on [Premium and above tiers](https://cube.dev/pricing), and [you can try it today](https://cubecloud.dev/auth/signup).** Please check the [documentation](https://cube.dev/docs/product/workspace/semantic-layer-sync#tableau) to learn more about accessing and configuring this feature. Join our Slack community at [slack.cube.dev](https://slack.cube.dev) to share your thoughts and opinions about this update.

If you'd like to see Semantic Layer Sync in action, you can also watch the recordings of recent webinars where we demonstrated and discussed how Semantic layer Sync works with [Preset](https://event.on24.com/wcc/r/4243489/38E64F4551ABDA2967D79B9FFEAE8D3D) and [Metabase](https://event.on24.com/wcc/r/4321808/0C4A58D931932D9BBDD35D7FADB71776), other popular BI tools.


Igor Lukanin

Tableau

Access data from the semantic layer to build workbooks and dashboards

Introducing Semantic Layer Sync with Tableau

The Cube and [Explo](https://www.explo.co/) [integration](https://cube.dev/blog/cube-and-explo-easy-customer-facing-analytics-with-the-universal-semantic) is exciting for data teams and application developers working to ensure fast and rich dashboards are in the hands of customers. Data teams can build beautiful, feature-rich customer-facing dashboards on data from any of the [large list of data sources that Cube supports](https://www.explo.co/integrations/cube). 

On the one hand, Cube’s [pre-aggregations and caching](https://cube.dev/product/caching-and-data-performance) ensure that performance will always be snappy. On the other, Explo provides incredible customization options that guarantee you’ll be able to make your dashboards fit right into the rest of your application. 

And [with both Cube and Explo](https://www.explo.co/partners/explo-cube), users will feel right at home. 

## The story that has Cube and Explo working together:

At Cube, we’re building a universal semantic layer to power every data application. 

We work to help users model all of their data with our sophisticated and flexible data modeling capabilities and manage access to that data with our powerful access control tools. Our unique [Cube Store](https://cube.dev/docs/product/deployment#cube-store) technology provides [fast in-memory caching and optional pre-aggregations](https://cube.dev/product/caching-and-data-performance) to provide the fastest response times for data applications. Finally, we provide [a comprehensive suite of API endpoints](https://cube.dev/product/data-apis) that enable developers to connect to Cube however they see fit.

One of the most frequent ways our customers take advantage of these functionalities is in customer facing scenarios. Customer facing analytics takes everything that’s hard about traditional BI and ups the stakes: you’re still connecting to data, dealing with data modeling, and building dashboards—but now you’re doing it with expectations for usability and performance that are more aligned with website expectations. Even if your internal stakeholders are ok with their dashboards taking ten or more seconds to load, your customers will very much *not* be ok with that.

Picture this: you’re hard at work developing your application and building features for your users. When you’re so deep into building the best UX possible, you probably don’t want to have to think about complicated data access patterns, performance and scaling concerns, and security when adding customer facing dashboards. That’s where Cube comes in. Let us deal with the hard work on the data side.

But what if you also don’t want to build your own customer facing dashboards with a front-end framework? Maybe you don’t want to deal with the maintenance, development costs, and time-to-value?  

## Cube and Explo: The Best of Both Worlds

Well—Cube has recently partnered with [Explo](https://www.explo.co/) to allow users to build beautiful, customer facing dashboards with their easy-to-use dashboard designer and then embed them into their applications easily. 

The Cube and Explo integration ([docs](https://docs.explo.co/data-sources/connecting-to-data-sources/data-source-types/cube)) empowers you to get the best of both worlds—for truly native, performant customer facing analytics with incredible time-to-value development. 

The Explo team has written [a fantastic guide](https://www.explo.co/blog/empowering-nosql-datasource-connectivity-unveiling-the-explo-and-cube-collaboration) detailing how to get started with Explo and Cube, featuring our ability to connect to NoSQL databases like MongoDB. Check it out to learn more about how our products work together and how we can help you delight your customers with powerful, fast dashboards.

Brian Bickell

Embedded Analytics

The Cube x Explo Integration

Cube and Explo: Easy Customer Facing Analytics with the Universal Semantic Layer

Any semantic layer is only useful if it delivers consistent metrics to data consumers, preferably more than just a single BI tool or data application.

![Semantic Layer in the data stack](https://ucarecdn.com/8434d52e-27a6-494e-acc4-7ffa7920f90e/)

Many aspects matter here:

- __Technical feasibility.__ Is there an API or integrations with existing BI tools?
- __Usability.__ How easy is it to query data for a data engineer or an end user?
- __Learning curve.__ How much ramp-up time is needed to become productive?

At Cube, we know for sure that there’s a design decision that checks all the boxes above and makes our semantic layer unmatched. Cube’s connectivity to BI tools is powered by the [SQL API](https://cube.dev/docs/backend/sql) that implements a Postgres-compatible protocol. That is, if your BI tool connects to Postgres, it will work with Cube.

Consequently, the learning curve is flat because you don’t need to study a new language or syntax to work with Cube. Good ol’ ANSI SQL works perfectly, and BI tools will generate SQL for your end users just fine.

```sql
SELECT
  DATE_TRUNC('DAY', timestamp) AS day,
  MEASURE(weekly_active)
FROM active_users
WHERE timestamp >= '2023-01-01'
GROUP BY 1
```

We always thought about ways to improve the experience with the SQL API and take using Cube with BI tools to the next level. Let's take a closer look at them.

Every BI tool has a [relatively thin data model](https://preset.io/blog/understanding-superset-semantic-layer/) inside with datasets, tables, columns, etc. However, keeping your semantic layer data model (i.e., cubes, views, measures, and dimensions exposed as tables and columns through the SQL API) in sync with your BI data model is a thankless job. Of course, every BI tool would inspect your data source and generate initial datasets upon first connection, and there’s a “Scan again” button somewhere in the settings. But do you, as a data engineer, wake up in the morning wishing to click that button every time you add a new measure, dimension, cube, or view to the semantic layer?

__Today, we are introducing [Semantic Layer Sync](https://cube.dev/docs/semantic-layer-sync), which completely bridges the gap between semantic layers and BI tools and enables instantaneous, zero-friction self-serve analytics.__ With Semantic Layer Sync, you can develop the data model and surface metrics from Cube to one or many BI tools in seconds while still having the benefit of never, ever breaking dashboards in a BI tool by untested changes.

## Semantic Layer Sync

Semantic layer Sync automatically synchronizes the data model from the semantic layer to Bl tools, making Cube-specific entities (e.g., cubes, views, measures, dimensions) match Bi-specific ones (e.g., datasets, tables, columns).

![SLS](https://ucarecdn.com/f598f41c-36ec-4ed9-960f-7c902a77ed74/)

An updated data model will automatically propagate to configured BI tools within seconds. In case you’re actively working on the data model in the [development mode](https://cube.dev/docs/cloud/workspace/development-api), you can manually trigger a sync to a separate, private dataset that would keep your production intact while allowing you to test your changes in a BI tool in addition to testing them in [Playground](https://cube.dev/docs/dev-tools/dev-playground).

See Semantic Layer Sync in action:

<video width="100%" controls><source src="https://ucarecdn.com/bb1ed393-c546-449d-a47a-ddcc20ad9f56/video.mp4" type="video/mp4"/></video>

Here’s some advice from [Tony Kau](https://www.linkedin.com/in/tonykau/), Partner Solutions Architect at Cube:

<Quote authorName="Tony Kau" authorAvatar="https://ca.slack-edge.com/T0FJ7RYAJ-U055M2SG8AZ-7548f748819c-512" authorRole="Partner Solutions Architect at Cube">

Cube insulates your BI tools from breaking upstream changes, but with great power of Semantic Layer Sync comes great responsibility.

  It is best practice to default to additive-only or versioned changes to the data model and be careful not to wreak havoc in downstream applications.

</Quote>

## Next steps

We’re releasing Semantic Layer Sync in preview. Currently, you can set up synchronization with [Apache Superset](https://superset.apache.org) (self-hosted), [Preset](https://preset.io) (managed), and [Metabase](https://www.metabase.com) (self-hosted and managed). We’re working with design partners on synchronization with Power BI, Tableau, and other BI tools. If you’d like to use Semantic Layer Sync with any BI tool, please [let us know](https://cube.dev/contact).

Here’s what [Juan Muñoz](https://www.linkedin.com/in/juanmmunoz/), Data Strategy and Innovation Lead at Breakthrough and an early adopter of Semantic Layer Sync, thinks:

<Quote authorName="Juan Muñoz" authorAvatar="https://ucarecdn.com/e2a25ca7-1f38-4e8a-90ad-ff69f400abe9/" authorRole="Data Strategy and Innovation Lead at Breakthrough">

We are just in the initial phase of testing Semantic Layer Sync. So far, having the ability to sync our dimensions and our measures to Preset is going to save us a bunch of time and eliminate any errors in trying to keep them in sync.

The semantic sync adds a lot of value for use cases like ours, where we need an analytical API that is consumed by an application as well as a BI tool.

</Quote>

__Next week, we’re [hosting a webinar](https://cube.dev/events/introducing-semantic-layer-sync-with-preset) on Semantic Layer Sync with Preset.__ Please join this webinar to see how Cube and Preset work together and hear from [Evan Rusackas](https://www.linkedin.com/in/rusackas/) (PMC member of Apache Superset), Tony Kau, and me.

__Semantic Layer Sync is available in Cube Cloud on [all tiers](https://cube.dev/pricing), and [you can try it today](https://cubecloud.dev/auth/signup).__ Join our Slack community at [slack.cube.dev](https://slack.cube.dev) to share your thoughts and opinions about this update.


News

Bridging the gap between the semantic layer and BI tools

Introducing Semantic Layer Sync

With [Metabase](https://www.metabase.com/) as the business intelligence platform, your team doesn’t need to speak SQL. It’s the easy, open-source way to help everyone in your company work with data like an analyst. Pairing it with [Cube](https://cube.dev/), the headless BI platform, will provide a consistent data model making it easy to build self-service analytics, shared across multiple teams.

Here’s what your Metabase dashboard will look like after we integrate it with Cube. If stuck, you can always refer to the [source code on GitHub](https://github.com/cube-js/cube.js/tree/master/examples/metabase).

![demo](https://ucarecdn.com/4d1d1527-a396-4b3a-8289-33c8812aaee6/)

> We've hosted a webinar on replacing Looker with Metabase and Cube. [Watch on-demand.](https://cube.dev/events/replacing-looker-with-cube-and-metabase)

## What is Metabase?

[Metabase](https://www.metabase.com/) is an [open-source](https://github.com/metabase/metabase) business intelligence platform with a low entry barrier, smooth visual interface, and generally pleasant user experience. It provides an easy way for everyone in your company to work with data like an analyst.

You can use Metabase to ask questions about your data, build self-service analytics, or even embed Metabase in your front-end data application to let your customers explore data on their own. You can save questions, group them into dashboards, and share both questions and dashboards with the your team.

Metabase enables three main scenarios:

* **Query and visualize your data.** Use the query builder to filter and summarize data. Choose between either the *Notebook editor* to ask sophisticated questions with joins, filters, and aggregations, or *Native queries* to compose questions in the database’s native query languages. Awesome if you're proficient with SQL!

* **Embed charts and share your results.** You can add questions to a dashboard and include filters and connect them to fields on questions to narrow the results. You can share the dashboard by sending the URL to your co-workers, or by embedding them using iframes. You can even embed the full Metabase app, which allows you to do things like delivering multi-tenant, self-service analytics.

* **Find things and stay organized.** Collections organize questions, models, dashboards, and other collections. They work like folders on a file system. Or, use the search bar to find data, metrics, segments, dashboards, models, and questions. But, [X-ray](https://www.metabase.com/docs/latest/exploration-and-organization/x-rays) is by far the most amazing feature in Metabase. X-raying a table will antomagically generate a bunch of questions that slice the table’s records in different ways and save it as a dashboard.

## What is Cube?

[Cube](https://cube.dev/) is the [headless BI](https://cube.dev/blog/headless-bi) platform for accessing data from [modern data stores](https://cube.dev/docs/config/databases), organizing it into consistent metrics definitions, and delivering them to downstream applications.

![headless BI](https://ucarecdn.com/dfb299b9-7e27-47f0-a362-0a14c643c740/)

Why would you want to have Cube in your data pipeline? **Data consistency.**

Cube will deliver consistent data to all teams using Metabase. Serving as a source of truth for the metrics definitions, access control rules, and caching settings, it solves the *many-to-many problem* many data teams have. Regardless of how many data sources (like Snowflake or Redshift) or data consumers (like Metabase) you have, Cube allows to get rid of siloed data pipelines.

![https://ucarecdn.com/728192a0-d30f-41c9-a8c9-f865361691e5/](https://ucarecdn.com/728192a0-d30f-41c9-a8c9-f865361691e5/)

Conceptually, Cube has four layers:

* **Data modeling.** With dozens of [supported data sources](https://cube.dev/docs/config/databases) and a [centralized data model](https://cube.dev/docs/schema/getting-started) for defining metrics definitions, you can make sure every team has access to exactly the same data, in Metabase and beyond.
* **Access control.** Cube’s [security configuration](https://cube.dev/docs/security) lets you manage who is able to access data and which data it is. As a part of that, Cube provides [row-level security](https://cube.dev/docs/security/context#security-context) and [multi-tenancy](https://cube.dev/docs/product/configuration/advanced/multitenancy) for Metabase users.
* **Performance.** Cube provides a [centralized caching layer](https://cube.dev/docs/caching) which ensures [consistent performance](https://cube.dev/docs/caching/pre-aggregations/getting-started) and data freshness across use cases or teams. As a result, your Metabase dashboards will load in under a second.
* **APIs**. Cube exposes three APIs: REST API, GraphQL API, and SQL API. Cube's [SQL API](https://cube.dev/docs/backend/sql) is fully Postgres-compliant, enabling connectivity to Metabase and, actually, any downstream tool that works with Postgres.

So, with Cube, you can use native, syntactically correct SQL queries, similar to how you’d query a data source directly:

```sql
SELECT
  DATE_TRUNC('day', createdAt) AS created_at_per_day,
  SUM(count) AS orders
FROM Orders
GROUP BY 1
ORDER BY 1 ASC
```

[Cube is open source](https://github.com/cube-js/cube.js), and you can self-host it in a cloud of your choice. Also, you can run Cube in [Cube Cloud](https://cube.dev/cloud) which provides fully managed experience with a [free tier](https://cube.dev/pricing).

## Integrate Metabase and Cube

Take a look a short video showcasing how Cube and Metabase work together:

<div style={{ position: 'relative', paddingBottom: '54.84375%', height: 0 }}><iframe src="https://www.loom.com/embed/38752bb23e5244d1a43675795c470a53" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}></iframe></div>

You can also follow more elaborate instruction below:

**Running Cube.** You can run Cube in two ways: either self-host it on your infrastructure or use the fully managed version in Cube Cloud.

For the sake of simplicity, we'll run [Cube Cloud](https://cube.dev/cloud). There’s a generous free tier for you to try. Go ahead, [sign up](https://cubecloud.dev/auth/signup) and follow the [instructions](https://cube.dev/docs/product/getting-started/core/create-a-project) on connecting to your data source and generating an initial data model.

Use these credentials to connect a sample e-commerce database to your Cube instance.

```bash
Hostname:  demo-db-examples.cube.dev
Port:      5432
Database:  ecom
Username:  cube
Password:  12345
```

This is what your deployment in Cube Cloud will look like:

![https://ucarecdn.com/4d1cf863-426c-4d40-829c-e3237a8e07d7/](https://ucarecdn.com/4d1cf863-426c-4d40-829c-e3237a8e07d7/)

Working with the data model. To see the data model you created above, navigate to the <Btn>Schema</Btn> tab. You will see files named `LineItems.js`, `Orders.js`, `Users.js`, etc. under the `schema` folder which defines the cubes in your data model.

![https://ucarecdn.com/b9d18c13-0d79-4487-9ed5-0a7c7c130db3/](https://ucarecdn.com/b9d18c13-0d79-4487-9ed5-0a7c7c130db3/)

Key ideas on what we’re seeing above:

- A cube is mapped to a table in your database to categorize measures (quantitative data) and dimensions (qualitative data) into [metrics definitions](https://cube.dev/docs/schema/reference/cube).
- This cube is mapped to the `public.orders` table.
- [Measures](https://cube.dev/docs/schema/reference/measures) are defined as aggregations (e.g. count, sum, etc.) over columns.
- [Dimensions](https://cube.dev/docs/schema/reference/dimensions) are mapped to columns.
- You can define complex measures and dimensions with custom SQL statements and references to other measures and dimensions.

**Customizing the data model.** You can add custom measures and dimensions, and edit them with filters or segments. In this example let’s update the schema by adding the `completedCount` measure to the `Orders` cube.

```javascript
completedCount: {
  type: `count`,
  filters: [{
    sql: `${CUBE}.status = 'completed'`
  }],
}
```

To do this, click the <Btn>Enter Development Mode</Btn> button in Cube Cloud to unlock the schema files for edits. This creates a development environment on a separate branch from your `main` branch. Here you can make changes to the data model before committing them to the main branch.

Here’s the `Orders.js` schema file, but with the added `completedOrders` measure. Paste this snippet into your `Orders.js` file.

```javascript
cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  preAggregations: {
    // Pre-Aggregations definitions go here
    // Learn more here: https://cube.dev/docs/caching/pre-aggregations/getting-started  
  },

  joins: {
    Users: {
      sql: `${CUBE}.user_id = ${Users}.id`,
      relationship: `belongsTo`
    },

    Products: {
      sql: `${CUBE}.product_id = ${Products}.id`,
      relationship: `belongsTo`
    }
  },

  measures: {
    count: {
      type: `count`,
      drillMembers: [id, createdAt]
    },

    number: {
      sql: `number`,
      type: `sum`
    },

    completedCount: {
      type: `count`,
      filters: [{
        sql: `${CUBE}.status = 'completed'`
      }],
    }
  },

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    status: {
      sql: `status`,
      type: `string`
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    },

    completedAt: {
      sql: `completed_at`,
      type: `time`
    }
  }
});
```

Once you commit and push this change, jump over to the Playground and run a query to get a response for the custom measure.

![https://ucarecdn.com/30dbcd19-a6c3-4d75-a532-5d4eeaea83f2/](https://ucarecdn.com/30dbcd19-a6c3-4d75-a532-5d4eeaea83f2/)

**Adding pre-aggregations.** Pre-aggregations are intermediate representation of the data, defined declaratively, computed in advance, persisted as tables, and used to accelerate queries. Cube has the ability to analyze queries against a defined set of pre-aggregations in order to serve the query from cache and not hit the data source directly.

Pre-aggregations physically reduce the size of the data. Fewer bytes to read, less time to return a response. This will dramatically improve query performance and provide a higher concurrency.

Let’s add a pre-aggregation definition to speed up the query above even more. Enter development mode once again, and edit the `Orders.js` file by pasting this piece of code in the pre-aggregations section.

```jsx
preAggregations: {
  completedOrdersByDay: {
    measures: [
      Orders.completedCount
    ],
    timeDimension: Orders.createdAt,
    granularity: `day`
  }
},
```

Here’s what the schema will look like.

![https://ucarecdn.com/3625d23f-91fc-4579-9f76-5d7638db32eb/](https://ucarecdn.com/3625d23f-91fc-4579-9f76-5d7638db32eb/)

Once you commit and push this change, jump over to the Playground and run the same query as you did above. This time you’ll see it return a response even faster:

![https://ucarecdn.com/b7e1d0ed-b9a9-4396-87fe-e335872382af/](https://ucarecdn.com/b7e1d0ed-b9a9-4396-87fe-e335872382af/)

**Integrating Metabase and building a dashboard.** You can run Metabase either in your infrastructure with the [open-source](https://github.com/metabase/metabase) version or use [Metabase Cloud](https://www.metabase.com/start/). For the sake of simplicity, let's [sign up](https://store.metabase.com/checkout/starter/login-details) for a Metabase free trial. Or, if you rather prefer using Docker, you can [run a Metabase instance yourself with Docker](https://www.metabase.com/docs/latest/installation-and-operation/running-metabase-on-docker).

Once you have signed in to your Metabase instance, go ahead and add a PostgreSQL data source. Cube’s SQL API speaks the PostgreSQL dialect of SQL which makes it compatible with all kinds of data tools, Metabase included. Copy the credentials from the SQL API section on the Overview page of Cube Cloud:

![https://ucarecdn.com/56fad92a-8a97-4e41-a602-4a36947be4e7/](https://ucarecdn.com/56fad92a-8a97-4e41-a602-4a36947be4e7/)

Or, you can use these sample credentials:

```bash
Host:      tan-ptarmigan.sql.gcp-us-central1.cubecloudapp.dev
Port:      5432
Database:  tan-ptarmigan
User:      cube
Password:  544056feb07f485e96913fc66b0404b4
```

Then, enter the credentials as a new PostgreSQL data source in Metabase.

![https://ucarecdn.com/3e4c319f-4708-493e-bd87-4a2a21d2f2ed/](https://ucarecdn.com/3e4c319f-4708-493e-bd87-4a2a21d2f2ed/)

Make sure to enable the "Use a secure connection (SSL)" toggle.

Now you can run queries to Cube from Metabase. By either using the Notebook editor to ask questions or Native queries, we can easily build a dashboard.

## Self-service analytics with Metabase

By far the most awesome feature in Metabase is the ability to X-ray a table and autogenerate a dashboard. Click the <Btn>⚡</Btn> icon to trigger the X-ray.

![https://ucarecdn.com/4db82cca-fae9-41ee-977e-261c5462a2fc/](https://ucarecdn.com/4db82cca-fae9-41ee-977e-261c5462a2fc/)

This will take you to an autogenerated dashboard. Here’s a [live preview](http://metabase.examplescube.dev/public/dashboard/947a9fa9-0c79-47e8-9cca-55cee7eafbcf) of what this dashboard looks like. 

![https://ucarecdn.com/e4b89682-d46a-460d-bcec-7e1a382a7446/](https://ucarecdn.com/e4b89682-d46a-460d-bcec-7e1a382a7446/)

Running an X-ray is an awesome way of hitting the ground running. But, let’s move on to more complex topics, building a custom dashboard.

Let's use the Notebook editor to ask a question. Select the `Orders` table. Summarize the `Sum of CompletedCount` by `CreatedAt: Day`.

![https://ucarecdn.com/0dd1a3d0-7e17-4e1f-85e4-374250e4a392/](https://ucarecdn.com/0dd1a3d0-7e17-4e1f-85e4-374250e4a392/)

This will visualize the same chart as we did before in the Cube Cloud Playground.

![https://ucarecdn.com/0f24c9ad-dbad-4508-8b79-054e1e5083d4/](https://ucarecdn.com/0f24c9ad-dbad-4508-8b79-054e1e5083d4/)

Using the Notebook editor is an awesome way of executing SQL without writing SQL. It’s great for team members that don’t speak SQL.

However, what about the ones that do? Let’s write a native SQL query next. Views in Cube can be queried the same way as cubes. This snippet below will return the same data as the Notebook query from above.

```sql
SELECT
  DATE_TRUNC('day', createdAt) AS created_at_per_day,
  SUM(completedCount) AS completed_orders
FROM Orders
GROUP BY 1
ORDER BY 1 ASC
LIMIT 10000
```

![https://ucarecdn.com/8d2a7839-e14a-40cf-879d-cb1aa56dce57/](https://ucarecdn.com/8d2a7839-e14a-40cf-879d-cb1aa56dce57/)

Once you’re happy with the questions, save them, and add them to a dashboard.

![https://ucarecdn.com/07c02752-3dc1-4a49-8fe3-204d1fa4a99c/](https://ucarecdn.com/07c02752-3dc1-4a49-8fe3-204d1fa4a99c/)

## Sharing and embedding Metabase dashboards

Metabase gives you multiple options to share dashboards. You can embed them by using iframes. You can share the dashboard by sending the URL to your co-workers. You can even embed the full Metabase app, which allows you to do things like delivering multi-tenant, self-service analytics.

In the Admin settings, click <Btn>Public Sharing</Btn> and toggle `Enable Public Sharing` to `Enabled`. This will allow you to create public URLs to share dashboards.

![https://ucarecdn.com/85d24d95-3eb8-4a67-b84c-eea5006a6319/](https://ucarecdn.com/85d24d95-3eb8-4a67-b84c-eea5006a6319/)

To embed dashboards jump below to the <Btn>Embedding</Btn> tab. Toggle it to <Btn>Enabled</Btn>, and you’re good to go.

![https://ucarecdn.com/3959935d-b3c0-4000-b40a-2076999f7885/](https://ucarecdn.com/3959935d-b3c0-4000-b40a-2076999f7885/)

To select a specific dashboard you want to share, go to the dashboard and click the <Btn>Sharing</Btn> button in the top right.

![https://ucarecdn.com/5fd254e2-566e-4bbe-be0e-0739541da643/](https://ucarecdn.com/5fd254e2-566e-4bbe-be0e-0739541da643/)

This will open up a prompt to select how to share the dashboard.

![https://ucarecdn.com/e84de9a9-680d-47bc-b147-ac6e7e960d72/](https://ucarecdn.com/e84de9a9-680d-47bc-b147-ac6e7e960d72/)

Check out the [Metabase docs](https://www.metabase.com/docs/latest/embedding/start) to learn more about embedding and sharing dashboards.

## Wrapping up

Using Metabase with Cube as a Headless BI layer will ensure data uniformity and consistent metrics definitions for your self-service analytics.

Would you like to explore more about Cube? [Check the docs](https://cube.dev/docs/) and create a free [Cube Cloud account](https://cubecloud.dev/auth/signup) today.

Also, please feel free to [join our community](https://slack.cube.dev/) of almost 7000 data practitioners on Slack, [drop us a line](https://cube.dev/contact), or give Cube a [star on GitHub](https://github.com/cube-js/cube.js). See you there!

Adnan Rahic

Metabase

Business intelligence for everyone, with consistency and without the SQL barrier. 

Self-service analytics with Metabase and Cube

When I was reading Pedram’s [deep dive on metrics layers](https://pedram.substack.com/p/what-is-the-metrics-layer) a few weeks ago, I couldn’t help but question the tool selection. One can obviously blame my employee-employer affiliation which is hard to deny. However, the real reason for that was this [summary statement](https://pedram.substack.com/p/what-is-the-metrics-layer):

> All three tools have different trade-offs, and their strengths and weaknesses tell of the challenges a metrics layer faces.
> 

While this is a true statement, it dismisses the fact that there’s an ergonomic, feature-complete, and accessible solution on the market that doesn’t suffer from highlighted pitfalls. With that, I’m putting Cube in the spotlight and kindly requesting your ~~blowback~~ [feedback on social media](https://twitter.com/thecubejs/status/1578049949811589123).

## In previous episodes

If you haven’t read the original [deep dive on semantic layers](https://pedram.substack.com/p/what-is-the-metrics-layer), please do. I promise it’s gonna be a rewarding experience.

There, Pedram mentions some prior thought leadership on the topic and introduces a challenge for three tools: Looker, dbt Metrics, and Lightdash. They have to model and provide access to the *Activation Metric*, a crucial characteristic of an imaginary B2B SaaS product with users and workspaces. A workspace is considered active if users perform some activation event, so we want to report on the activation rate daily, weekly, or monthly and how it changes over time. Later, Pedram shows how Looker, dbt Metrics, and Lightdash solve the data modeling and elaborates on their strengths and pitfalls.

Here’s the `workspace_details` table matching the imaginary dataset that was used by all tools to calculate the metrics. I’ve generated 20 million rows and put them into Postgres, so we have something to work with:

![dataset](https://ucarecdn.com/1f7f0a20-b331-4afa-9e63-7313a7e96c05/)

Now, let’s talk about Cube.

## Cube, the semantic layer

Cube is the [semantic layer](https://cube.dev) for building data applications, created to make data consistent and accessible. It solves the many-to-many problem many data teams have by serving as a source of truth for metrics definitions, access control rules, and caching settings.

![Cube in the pipeline](https://ucarecdn.com/dfb299b9-7e27-47f0-a362-0a14c643c740/)

Cube connects to numerous [data sources](https://cube.dev/docs/config/databases), from cloud data warehouses to [streaming platforms](https://cube.dev/blog/headless-bi-with-streaming-data), and delivers data to all kinds of [data consumers](https://cube.dev/docs/config/downstream) via multiple APIs, including the [SQL API](https://cube.dev/blog/expanded-bi-support). It is deliberately visualization-agnostic and delegates data presentation and visualization to BI tools, data notebooks, front-end apps, etc.

Cube is open source and there's also [Cube Cloud](https://cube.dev/cloud) that provides fully managed experience and additional tooling on Free, Standard, and Enterprise tiers (see [pricing](https://cube.dev/pricing)).

## Data modeling

In Cube, we define metrics in [data model](https://cube.dev/blog/open-source-data-modeling) files that seem to be heavily inspired by LookML.

At the top level, everything is grouped in “cubes” that are usually modeled over tables or views in the data warehouse but can also be modeled over pretty complex queries. Cubes include definitions for measures (quantitative features), dimensions (qualitative features), segments (reusable filters), and pre-aggregations (declarative definitions of rollups that drastically speed up queries, more on them later).

Here’s the data model for our activation metric:

```jsx
cube(`WorkspaceActivation`, {
  sql: `SELECT * FROM public.active_workspace_details`,

  measures: {
    count: {
      type: `count`
    },

    n_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
    },

    n_active_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
      filters: [ {
        sql: `${is_active_workspace} IS TRUE`
      } ],
    },

    activation_rate: {
      sql: `ROUND(100 * (1.0 * ${n_active_workspaces} / ${n_workspaces}), 2)`,
      type: `number`
    }
  },

  dimensions: {
    workspace_id: {
      sql: `workspace_id`,
      type: `number`,
      primaryKey: true
    },

    reporting_day: {
      sql: `reporting_day`,
      type: `time`
    },

    is_active_workspace: {
      sql: `is_active`,
      type: `boolean`
    }
  },
});
```

A few observations here:

- Similarly to Looker, we define measures as formulas, not as fully-formed SQL tables.
- While we can use “formatting” functions like `ROUND` in measure definitions, formatting options are deliberately limited. Cube puts the burden of data presentation on downstream tools.
- By default, we don’t have to specify how our reporting date should be broken down. We’ll be able to provide desired time granularity at query time.
- Needless to say, we can define other cubes and [joins](https://cube.dev/docs/schema/reference/joins#joins) between them.

## Query syntax

Cube provides a set of APIs to fetch data: [SQL API](https://cube.dev/docs/backend/sql) (mostly for BI tools and data notebooks), [REST API](https://cube.dev/docs/rest-api), and [GraphQL API](https://cube.dev/docs/backend/graphql) (mostly for front-end applications). A simple query to the SQL API:

```jsx
SELECT reporting_day, activation_rate
FROM WorkspaceActivation;
```

Of course, we can run a more complex query, too:

```jsx
SELECT
  DATE_TRUNC('WEEK', reporting_day) AS reporting_week,
  activation_rate
FROM WorkspaceActivation
ORDER BY 1 DESC;
```

Queries would turn into JSON when expressed in the REST API syntax. First one:

```json
{
  "measures": [
    "WorkspaceActivation.activation_rate"
  ],
  "timeDimensions": [ {
    "dimension": "WorkspaceActivation.reporting_day"
  } ]
}
```

Second one:

```json
{
  "measures": [
    "WorkspaceActivation.activation_rate"
  ],
  "timeDimensions": [ {
    "dimension": "WorkspaceActivation.reporting_day",
    "granularity": "week"
  } ],
  "order": {
    "WorkspaceActivation.reporting_day": "desc"
  }
}
```

Since we haven’t connected a downstream tool yet, we can run queries and explore the metrics in Cube’s [Playground](https://cube.dev/docs/dev-tools/dev-playground) with drop-down inputs for measures and dimensions:

![Playground](https://ucarecdn.com/0a0e01d2-cb3a-4cbe-8f2f-a87b257324bb/)

We can instantly get the JSON queries for the REST API here:

![JSON query](https://ucarecdn.com/51228e1d-33b6-46d7-8bf6-637e04261e2c/)

More conveniently, we can also look up the SQL statement that would be generated by Cube and run against the data warehouse when the query is executed. No surprise here: Cube uses the provided query and data model definitions to compose the final query: 

![Generated SQL query](https://ucarecdn.com/742514b5-ee4e-43dd-8c1b-d03b3284dbcc/)

## Query acceleration

Obviously, queries can be expensive: costly to run, too complex to wait for, or both.

In that case, we can define a pre-aggregation (actually, the recommendation is always to use pre-aggregations in production). Here’s what we need to append to the data model:

```jsx
  preAggregations: {
    main: {
      measures: [ activation_rate ],
      timeDimension: reporting_day,
      granularity: `week`,
      refreshKey: {
        every: `1 day`
      }
    }
  }
```

It instructs Cube to build a rollup and use it to serve queries that contain any subset of provided measures and dimensions (namely, `activation_rate` and `reporting_day` with weekly granularity). Usually, a single pre-aggregation speeds up multiple queries. We can also configure freshness: a pre-aggregation update can be triggered on schedule (e.g., every day) or when an arbitrary SQL statement yields a new result. 

Now, the last query would return the same result, but a completely different query would be executed against the data warehouse:

![Accelerated SQL query](https://ucarecdn.com/786f7cc1-791d-4122-b13a-b3660405f439/)

Truth be told, it wouldn’t be executed against the data warehouse at all. The `prod_pre_aggregations.workspace_activation_main` table is transparently created and maintained in [Cube Store](https://cube.dev/blog/introducing-cubestore), a custom-built massively distributed columnar storage for pre-aggregation data.

There’s an option to skip using Cube Store and store pre-aggregations in a data warehouse, but that’s not the most reasonable thing to do. With pre-aggregations in Cube Store, Cube can serve practically any query with sub-second latency (expect something between 50 ms and 500 ms) and allow for a decent concurrency (say, 100 QPS or maybe 1000 QPS).

Okay, but what would Cube do if we need to query for other granularity? Since it’s aware that queried measures are defined with distinct counts, it won’t be using the rollup and will transparently fall back to a query to the data warehouse (there’s an [option to disallow that](https://cube.dev/docs/caching/using-pre-aggregations#rollup-only-mode) at all times, if we need to).

![Non-accelerated SQL query](https://ucarecdn.com/a0d3bd13-889d-4a92-925d-984ee2dd9a4d/)

## Data consumers

Now, we’re ready to connect downstream tools. We can pick anything that supports Cube’s SQL API, and that’s practically any tool. Cube’s SQL API uses Postgres dialect and wire protocol, so if something works with Postgres as an upstream source, it works with Cube: 

![Supported data sources](https://ucarecdn.com/ba240ef2-11fc-477d-843d-39b0b9fe2649/)

We have numerous options here. Out of respect for the first tech company ever where the [first triple-name-tie is Claire](https://twitter.com/clairebcarroll/status/1570194384980971522), let’s connect Cube to [Hex](https://hex.tech):

![Connection to Hex](https://ucarecdn.com/7c89eb8a-d7dd-41b9-bcdb-c1889b70eba5/)

Indeed, [Hex works with Cube](https://cube.dev/blog/hex-integration-collaborative-data-notebooks):

![Hex notebook](https://ucarecdn.com/3761be9c-722c-461e-a1ba-7dcb01e1441b/)

In case we’re building a front-end app, we can directly `fetch` from the REST API endpoint or use the provided JavaScript client library:

```jsx
import cubejs from '@cubejs-client/core';

const cubejsApi = cubejs.CubejsApi(
  process.env.CUBE_TOKEN,
  { apiUrl: process.env.CUBE_API_URL }
);

const query = {
  measures: [ 'WorkspaceActivation.activation_rate' ],
  timeDimensions: [ {
    dimension: 'WorkspaceActivation.reporting_day',
    granularity: 'week'
  } ],
  order: {
    'WorkspaceActivation.reporting_day': 'desc'
  }
};

const resultSet = await cubejsApi.load(query);

console.log(resultSet.tablePivot());
```

Now you can plot the data with a [charting library](https://awesome.cube.dev/?tools=charts) of your choice:

![Data in the terminal](https://ucarecdn.com/dee1b9f9-74ff-4e06-8522-335922f2afd1/)

## Wrapping up

Hopefully, this write-up provides some insight into how Cube works and helps compare it to Looker, dbt Metrics, and Lightdash from the original [deep dive](https://pedram.substack.com/p/what-is-the-metrics-layer).

Also, if you’re using dbt Metrics, please keep in mind that you can leverage Cube’s [integration with dbt](https://cube.dev/blog/dbt-metrics-meet-cube) that transparently reads metrics definitions from dbt and automagically creates a data model from them.

Currently, Cube uses JSON-like markup for data model definitions and Looker-like metrics organization into cubes. Later in 2022, Cube is likely to [introduce YAML markup](https://forms.gle/4CZRRKK8nD4PvtxZA) for data models and an alternative approach to metrics.

With that, I do have an answer to the final question from Pedram’s article:

> Can a metrics layer be universal enough to gain applicability across the data stack yet still be designed in such a way to be relevant to BI tools?
> 

Yes. Try Cube.

The easiest way to get started with Cube is [Cube Cloud](https://cube.dev/cloud). It provides managed hosting and convenient tools for Cube, including the Playground, the data model editor with syntax highlighting, and—more importantly—the ability to instantly fork data models and query private versions of APIs while the production version stays intact and serves queries.

[Sign up for Cube Cloud](https://cubecloud.dev/auth/signup) on the free tier today and experience that yourself. Feel free to connect your production dataset or tinker with the Postgres instance used in this blog post:

```
Host:      demo-db-examples.cube.dev
Database:  ecom
User:      cube
Password:  12345
```

Deep Dives

Cube in the spotlight alongside Looker, dbt Metrics, and Lightdash.

Deep dive: What the heck is the Semantic Layer

The ongoing story of the digital age is still about [taking products apart](https://hbr.org/2014/06/how-to-succeed-in-business-by-bundling-and-unbundling). The wave of [bundling](https://towardsdatascience.com/the-great-data-debate-unbundling-or-bundling-7d7721ee8514), [unbundling](https://blog.fal.ai/the-unbundling-of-airflow-2/), and [rebundling](https://dagster.io/blog/rebundling-the-data-platform) happening in the data space has subsided, but the point remains. Generations of tools in the modern data stack, whatever it is, succeed each other primarily for two reasons:

- Emerging tools provide more flexibility and a lower entry barrier for practitioners.
- Alternatively, teams escape into a safe harbor of a well-known integrated solution that promises big returns on even bigger investments. Indeed, has anyone ever got fired for buying Looker?

Well, one can only so much joke about Looker. Things like Looker’s $2.6B acquisition by Google in 2019, Snowflake’s $3.4B IPO in 2020, or dbt Labs’ [four consecutive venture rounds](https://pedram.substack.com/i/54634871/the-devils-bargain-of-venture-funding) in 2020–2022 leading to a $4.2B valuation fuel the data industry and help put more tools into a data practitioner’s toolbox.

Today, we’re going to talk about Cube and Apache Superset—a bundle of tools representing a finer alternative to Looker in many use cases.

> We've had a webinar on replacing Looker with Cube and Superset. [Check the recording and slides.](https://cube.dev/events/replacing-looker-with-cube-and-superset)

## Free as in “open source”

[Cube](https://cube.dev) and [Superset](https://superset.apache.org) belong to different categories in the data stack. The former is the [headless business intelligence](https://cube.dev/blog/headless-bi) platform, and the latter serves as the data visualization and exploration platform. However, being open source and standing on the shoulders of giants are among many things that they have in common.

Both tools are licensed under Apache License 2.0 and actively developed on GitHub. Over the last 3 years, Cube’s [repository](https://github.com/cube-js/cube.js) has acquired almost 14,000 stars (an unmatched [leader in the category](https://twitter.com/sspaeti/status/1570044606338990081)). Written mostly in Rust, Cube’s data processing and storage are based on the [Arrow DataFusion](https://github.com/apache/arrow-datafusion) query execution framework which uses [Apache Arrow](https://arrow.apache.org/) as its in-memory format. Superset has a longer history (born at Airbnb in 2015 where it replaced Tableau, joined the Apache Incubator program in 2017), has a [repository](https://github.com/apache/superset) with 48,000 stars, and is powered by [Apache ECharts](https://echarts.apache.org/en/index.html), one of the most mature and popular charting libraries. 

![Cube and Superset](https://ucarecdn.com/5f3f2313-c055-4b9e-b345-56568c53aca2/)

You’re definitely free to take and use Cube and Superset at your own discretion, including self-hosting them in your private or public cloud. You’re also free to explore and get started with [Cube Cloud](https://cube.dev/cloud) and [Preset Cloud](https://preset.io/product/), fully managed platforms with freemium pricing models and plenty of quality of life features on top of open source products. Compare that to Looker’s “[request a demo](https://cloud.google.com/resources/looker-demo/?_ga=2.157282873.347220352.1663670208-344442256.1663670208)” paywall that would cost your team a few weeks of qualification calls on Google Meet before you start building.

## Simple as in “separation of concerns”

Cube is intentionally [headless](https://cube.dev/blog/headless-bi) and agnostic to the data presentation layer. However, it does a number of things and does them well:

- connects to a plethora of [data sources](https://cube.dev/docs/config/databases), from cloud data warehouses like BigQuery, Snowflake, and Redshift to streaming platforms like Kafka and Redpanda;
- provides a [data modeling](https://cube.dev/docs/schema/getting-started) layer as the centralized source of truth for metrics definitions;
- secures data with its [access control](https://cube.dev/docs/security) layer;
- makes sure any query runs well under a second with its [caching](https://cube.dev/docs/caching) layer;
- delivers data to any downstream tool, including BI tools like Superset, via its API layer that provides [SQL API, REST API, and GraphQL API](https://cube.dev/docs/config/downstream#ap-is-references).

Superset works by connecting to a data source and querying the data where it lives. The ideal way to use Superset is with a [dataset-centric approach](https://preset.io/blog/dataset-centric-visualization/) to modeling and visualization. 

A dataset-centric approach implies that a well-normalized dataset is used to “derive” richer datasets with extra semantics, making them valuable for analysis and visualization. By creating derived datasets that incorporate aggregate metric calculations earlier in the ETL/ELT process *before* surfacing for visualization, many of the issues with change management, maintenance, logic reuse within dashboards, etc. are significantly reduced for a better experience. 

Cube complements Superset in this way, and this allows for Superset-generated SQL queries to work with no issues when connected to a Cube environment (which is treated as a PostgreSQL database connection). 

![Looker vs Cube + Superset](https://ucarecdn.com/59031c52-890f-402f-9400-0d0d7034c887/)

You’re free to configure and fine-tune each tool and each layer within every tool when building with Cube and Superset. Want to build and schedule a report? Check Superset dashboards. Need to expose new metrics in that report? Cube’s data modeling layer is at your service.

## Compatible as in “no vendor lock-in”

Speaking of data modeling, Cube provides a [data modeling language](https://cube.dev/blog/open-source-data-modeling) that is not tied to any specific interface, visualization, or user experience. Unlike proprietary LookML definitions that require Looker IDE for syntax highlighting and linting, Cube’s data model is written in JavaScript (and [soon-to-be-written](https://forms.gle/4CZRRKK8nD4PvtxZA) in YAML) and feels native in your editor of choice. On top of that, you are able to generate a data model dynamically or even fetch it from a remote endpoint.

Consider an excerpt of Looker view from the recent [deep dive](https://pedram.substack.com/p/what-is-the-metrics-layer) by Pedram:

```yaml
view: workspace_activation {
  sql_table_name: "METRICS"."WORKSPACE_ACTIVATION" ;;

  dimension_group: date {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}."REPORTING_DATE" ;;
  }

  dimension: is_active_workspace {
    type: yesno
    sql: ${TABLE}."IS_ACTIVE_WORKSPACE" ;;
  }

  dimension: workspace_id {
    type: string
    primary_key: yes
    sql: ${TABLE}."WORKSPACE_ID" ;;
  }

  measure: count_workspaces {
    type: count_distinct
    description: "# of Workspaces"
    sql: ${workspace_id} ;;
  }

  measure: count_active_workspaces {
    type: count_distinct
    description: "# of Unique Workspaces Active within 1 Day"
    sql: ${workspace_id} ;;
    filters: [is_active_workspace: "yes"]
  }

  measure: activation_rate {
    type: number
    sql: ${count_active_workspaces} / ${count_workspaces} ;;
    value_format_name: percent_1
  }
}
```

Compare with the equivalent Cube data model (way less of `;;`, to say the least):

```javascript
cube(`WorkspaceActivation`, {
  sql: `SELECT * FROM public.active_workspace_details`,

  measures: {
    count: {
      type: `count`
    },

    n_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
    },

    n_active_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
      filters: [ {
        sql: `${is_active_workspace} IS TRUE`
      } ],
    },

    activation_rate: {
      sql: `ROUND(100 * (1.0 * ${n_active_workspaces} / ${n_workspaces}), 2)`,
      type: `number`
    }
  },

  dimensions: {
    workspace_id: {
      sql: `workspace_id`,
      type: `number`,
      primaryKey: true
    },

    reporting_day: {
      sql: `reporting_day`,
      type: `time`
    },

    is_active_workspace: {
      sql: `is_active`,
      type: `boolean`
    }
  },

  preAggregations: {
    main: {
      measures: [ activation_rate ],
      timeDimension: reporting_day,
      granularity: `week`,
      refreshKey: {
        every: `1 day`
      }
    }
  }
});
```

In a similar fashion, Cube’s API layer is compatible with practically any data consumer. When the time comes, and you realize that, alongside business users using dashboards and reports in Superset, you’d like to have data analysts crunching numbers and seeking insights in data notebooks, Cube will be there to help liberate your data.

![Data consumers](https://ucarecdn.com/b35f44ef-12a5-42d7-a618-74637fc3e0cd/)

You can expect any SQL query generated by your data exploration tool like Superset to work with Cube’s SQL API. Needless to say, equivalent queries to Cube’s REST API and GraphQL API will yield the same data:

```sql
SELECT
  DATE_TRUNC('WEEK', reporting_day) AS reporting_week,
  activation_rate
FROM WorkspaceActivation
ORDER BY 1 DESC;
```

Let’s have a bird’s-eye view here.

The generation of BI tools like Looker encouraged end-users to invest heavily in building out tons of LookML models to populate the semantic layer. While this established Looker as a source of truth in an organization for business metrics, it also created an immense amount of lock-in in your BI tool. You couldn’t take your LookML models with you and use them with another tool if you decided to switch BI tools. Google’s acquisition of Looker accelerated organizations’ anxieties around this lock-in, to the point that Google was actually [forced to integrate LookML with Tableau](https://roundup.getdbt.com/p/look-ml-tableau-metrics-layer). This way, organizations could use LookML for transformation (Looker’s strength) and Tableau for visualization (Tableau’s strength).

The future however is looking to be very different from the past:

- Open-source headless BI platforms like Cube provide unified semantic layers to sit between the database and BI later, eliminating the need, or providing alternate implementations, for expensive solutions like Looker that lock you in.
- Open-source BI tools like Superset with an intentionally thin semantic layer complement Cube and enable *last-mile data transformation* for the explicit purpose of data visualization in your BI tool.

When the need for a complex yet flexible metrics/semantic layer arises, Cube and Superset is a winning open source-based combo!

## Ready-to-go as in “today”

Now, you’re very much welcome to try Cube and Superset today and see them in action. Please join the Slack communities of [Cube](https://slack.cube.dev) and [Superset](https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI7jKWp~xc2zYRe~NqiY9Q) to share your feedback.

Please tune in to the [webinar on October 4](https://cube.dev/events/replacing-looker-with-cube-and-superset) with [Shreesham Mukherjee](https://www.linkedin.com/in/shreesham/), Developer Relations Engineer at Preset, and [Igor Lukanin](https://www.linkedin.com/in/igorlukanin/), Head of Developer Relations at Cube. We’ll discuss Cube and Superset as an open source alternative to Looker in popular use cases, demo both tools, and take your questions.

See you!

Shreesham Mukherjee

Respectfully unbundling the elephant in the BI room.

Open source Looker alternative with Cube and Apache Superset

These days, customer-facing analytics are everywhere. 

We are, after all, in The Data Age—hence why you’re reading this blog and why we’re writing it. And because of the ubiquity of data, as consumers, we’ve become extraordinarily curious; we want to know everything about our businesses, investments, and lap times. 

Consumers are pining for insights—presented in fast-loading, beautifully customized dashboards. And so, many companies are turning to embedded analytics with [Tableau](https://www.tableau.com/). 

But as more consumers demand analytics, raising the standards of UI customization, interactivity, and speed, what if there were a more tailored, more performant way to give users the insights they need?

Well, there is: embedded analytics with Tableau and [Cube](https://cube.dev/). Let’s explain. 

## What is Embedded Analytics?

Simply put, [embedded analytics](https://cube.dev/blog/what-is-embedded-analytics) is the practice of integrating data analytics and visualization capabilities with a user’s natural workflow, such as their web portals, internal tools, or applications. 

For example: with embedded analytics, rather than needing to export sales data from their e-commerce platform and then conduct analysis separately in Excel, a seller could derive insights from dashboards and reports available to them directly within their commerce portal. 

Of course, embedded analytics __can be used in internal- and external-facing applications to provide real-time static and interactive reports, dashboards, and data visualizations__. 

There are many benefits of using embedded analytics. First, it can __save the user time and effort__ and add a lot of value. In turn, this saved time and gleaned insights __contribute to a user-centric UX that drives adoption__—even among those who aren’t as analytics-experienced. And higher adoption means a __better ROI on internal tooling__ and an __increase in revenue for external tooling__. 

## Embedded Analytics with Tableau

![](https://ucarecdn.com/1b6df403-1884-4e4d-83b1-b26788833ef4/)

So, why do so many companies turn to [embedded analytics with Tableau](https://www.tableau.com/products/embedded-analytics)?

Tableau is one of the leading platforms for data visualization and dashboarding. It's based on its own VizQL, which expresses data visually by translating drag-and-drop actions into data queries. 

This drag-and-drop capability makes data analytics and business intelligence accessible to a much wider pool of people—which is a great thing. Clearly, given its smashing success, Tableau met a hot demand for data democratization and did it well. 

*However*, things get a little more hinky when it comes to the [embedded analytics stack](https://cube.dev/blog/modern-embedded-analytics). This is because users not only use Tableau for analytics within Tableau itself but also use it to power embedded analytics within other applications. 

The problem is that __having your embedded analytics with Tableau sit directly on top of your data warehouse comes with a few shortcomings__, such as:

1. Difficulty with customizability and designing user-centric UIs

2. Duplicated effort and opportunities for inconsistency when creating multiple sets of data definitions and security contexts

3. Weaker analytics performance

### 1) Difficulty with customizability and designing user-centric UIs
Tableau has many visualization layer options, but it just doesn’t have one for every audience or use case. You can undoubtedly brand the Tableau visualizations embedded in your app; however, there are restrictions on what you can build with the visualization layers Tableau offers (e.g., extremely use-case-specific drill-downs).

And so, __Tableau’s visualization templates may work just fine for 80% of your applications, but those that truly need a highly tailored, custom UI will require you to build a custom presentation layer from scratch__. 

The problem is that using multiple different visualization layers together with Tableau—meaning, both custom-built and from Tableau—leads to…

### 2) Duplicated effort and opportunities for inconsistency

![](https://ucarecdn.com/78d63d2b-23b9-48f4-bb96-8bab43cc7ded/)

So you want to use Tableau and a separate charting library to build a custom presentation layer? That makes perfect sense when you want to combine the advantages of Tableau’s presentation layers with the flexibility of a custom UI. 

However, the challenge lies in consistently orchestrating data modeling, security, and caching across all of your presentation layers. 

__By connecting multiple presentation layers to your data warehouse, you’ll need to individually orchestrate your data models and access controls so they’re uniformly defined__. That’s a lot of duplicated effort—which opens the door to gaps and errors. 

### 3) Weaker analytics performance

Lastly, powering embedded analytics with Tableau without a BI layer between Tableau and the data warehouse can cause latency in your user-facing visualizations and dashboards.

Latency is a true user adoption killer: a Google study showed that [bounce likelihood increased by 32%](https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/) when a page’s load time increased from one second to three, and by *90%* when page load time increased from one to five seconds. So, performance is essential.

__In a stack in which Tableau’s presentation layer sits directly on top of your data source, your users request data from the data source for every query__. At best, __this is redundant and costly__, as multiple users may be requesting the same information. 

At worst, however, building a stack like this __can result in latency and lower performance__. Request volume across users is unpredictable; you can’t control how many people simultaneously request data or consume visualizations. And so, if you have multiple presentation layers, each with duplicate data modeling, security, and caching layers, each making separate and redundant requests directly of the data source—that opens the door to latency.

Latency can be a problem even if you only use Tableau (don’t worry, we happen to have [a fix](https://cube.dev/cloud)). But, with multiple presentation layers, the chance of uneven performance across them is much higher. 

## The best of both worlds: embedded analytics with Tableau and Cube

Alright—let’s get to the solution. 

Tableau is a fantastic tool (in fact, here’s [how to use Tableau with Cube](https://cube.dev/blog/tableau-tutorial).) Combining it with custom presentation layers is a great way to get both efficient, out-of-the-box visualizations and user-centric UI for your embedded analytics. 

So how can you fix the issues above? With upstream, centralized data modeling, security, and caching orchestration. Hi, we’re [Cube](https://cube.dev/cloud). 

### Cube streamlines building embedded analytics with Tableau and custom presentation layers

![](https://ucarecdn.com/b52d016a-8ca8-4cdb-85aa-765669ff781c/)

Cube is a [headless BI](https://cube.dev/blog/headless-bi) platform that enables your data modeling, data access control, and caching layers to live upstream of every presentation layer and data application in your stack. 

So, rather than individually orchestrating r[ole-based access controls](https://cube.dev/docs/recipes/role-based-access#enforcing-role-based-access) or metrics definitions for each presentation layer, you’re centralizing and defining them once—removing duplicated effort and its inevitable inconsistencies.

### Cube ensures uniformly performant embedded analytics powered by Tableau and custom presentation layers

Cube’s robust caching layer manages the throughput of data requests and acts as a buffer between your data source and your data application. Its advanced [pre-aggregation capabilities](https://cube.dev/docs/caching#pre-aggregations), query queue, and [refresh keys](https://cube.dev/docs/caching#in-memory-cache-refresh-keys) protect your data warehouse from redundant, costly, and latency-causing queries. 

Designed to protect the data source from the possibility of even an unlimited number of concurrent requests, Cube can significantly speed up your embedded Tableau dashboards and visualizations. 

Cube also makes embedded analytics more performant even when built with a combination of Tableau and custom presentation layers. By allowing Cube to do the heavy lifting of data modeling, security, and caching orchestration, the presentation layers become very “thin”—essentially, not needing to process much. This enables them to become uniformly performant and allows the application’s embedded analytics to become more performant as a whole. 

## Learn More

Interest piqued? We thought it might be. 

Give your users a performant, data-rich embedded analytics experience with Tableau and Cube—especially since [Cube is free to use](https://cube.dev/cloud) and we already have a [tutorial for using Tableau with Cube](https://cube.dev/blog/tableau-tutorial).

Get in touch with us and the rest of the Cube community on [Slack](https://slack.cube.dev/) or [Github](https://github.com/cube-js/cube.js).

In the mood for some hands-on help with building a modern embedded analytics data stack? [Schedule a time to chat with us 1:1](https://cube.dev/contact).


Tamar Barlev

A “How-To” about how to make your embedded analytics flexible and performant. 

Embedded Analytics with Tableau and Cube

In case you missed it, we recently released [Cube’s SQL API][8], with expanded support for BI tools and data notebooks. 

That’s exciting (we’re *very* excited) because consistent, performant, and secure data is now accessible to any data consumer in your company—from app developers to general business users. Cube’s definitions are consistent across every application. 

Think of your favorite BI tools: if they can connect to a data store via SQL, they’ll work with Cube.

To illustrate the beautiful simplicity of connecting a BI application to Cube via our SQL API, we’re here with a quick tutorial using Tableau Online and Cube Cloud.

Let’s dive in. 

## Get started with Cube Cloud

This tutorial assumes you’re using Cube Cloud—and why wouldn’t you? Our managed service is both the fastest and most secure way to run Cube—and it’s free.

If you don’t have a Cube Cloud project already, [sign up for a free account here][12], then [follow these step-by-step instructions][11] to create a project. Don’t worry if you’d rather not connect your own database to Cube for this tutorial: we’ve got you covered with a sample database.

If you already have Cube Cloud set up, feel free to jump [here][95].

## Define measures and dimensions

When you create a project, you’ll notice that Cube automatically generates a basic data schema. But for this tutorial, let’s define at least one custom [measure][13] or [dimension][14] in Cube’s schema editor, too. You’ll use it in a few minutes.

In the left-hand navigation, select the schema editor and enter Development Mode.

In this example, in the cube `Orders`, we’ll define a new measure, `totalAmount`…

[![001-schema-define.png][1]][1]

…save our change, and Commit and Push it to production:

[![008-commit-and-save.jpg][15]][15]

The new definition is automatically added to Cube’s API, and you’re ready to…

## Grab SQL connection details

Navigate to the overview page and find the “SQL API” section. Click “How to connect your BI tool”.

[![002-sql-api.jpg][2]][2]

Here, you’ll find the details you need to connect Tableau Online to Cube:

[![003-grab-creds.jpg][3]][3]

You’ll need these when you…

## Configure Tableau

Let’s make a new Workbook using the menu at top right:

[![004-new.jpg][4]][4]

In the “Connect to Data” screen, select PostgreSQL.

[![009-connect-to-data.jpg][9]][9]

You’ll be prompted to add the connection details you opened in Cube. Copy, paste, and click “Sign In”.

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/37f7ace3-9b78-435d-9ff6-af329185d8f8.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/b1b2ff0a-2863-4180-b312-bd730ece029b.mp4" type="video/mp4" /></video>

## Understand Tables and Fields

If all goes according to plan, you’ll now see a list of each of your [cubes][16] listed as _Tables_.

Drag one of them—we’ll use `Orders` again—into the Workbook editor to begin exploring.

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/58fc30aa-0531-4394-ac76-3eacf1ce5d6b.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/89d4c3a1-604a-4af6-819b-5ca8cdc90d5d.mp4" type="video/mp4" /></video>

Et voila: now, every measure and dimension from Cube is available as a Tableau _Field_, including the custom measure we defined earlier, `totalAmount`.

[![006-tables-and-columns.jpg][6]][6]

## Build a worksheet

Now it’s time to try this out!

Build a simple chart in Tableau: drag a measure to “Rows” and a dimension to “Columns”:

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c59a8e90-55ab-46c9-9ee0-11d3aaf3fcf1.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8c159a96-79b4-4674-a9d0-7ccf09cbf4e7.mp4" type="video/mp4" /></video>

Just like _that_: your first Cube-powered visualization in Tableau!

## Learn more

As you can see, connecting Tableau to Cube via Cube’s SQL API makes Cube definitions accessible to every data consumer—so the same data can flow to both business users and data application developers.

Interest piqued? Check out our [SQL API docs][93], and our [guide to working with other BI tools][94].

And, watch this space because the fun is just beginning: we’re continuing to test and improve connectors for more BI applications. Have a favorite? [Let us know][92].

[1]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/870c6c3e-42bc-4d0f-b978-807f5307906f.png
[2]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/0a7c2fd9-ae76-425b-906d-2f644ef77eff.png
[3]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7831a318-a8f5-4d0c-9e7d-2d58671ab9fa.png
[4]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/64669cb0-78d2-4ad0-ab76-e1cdfae04453.png
[6]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7057552d-01d6-4e2e-9bd0-c1936ff1e03a.jpg
[8]: https://cube.dev/blog/expanded-bi-support
[9]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/dd3de7cb-e553-41e4-afb4-129e0485124a.png
[11]: https://cube.dev/docs/product/getting-started/core/create-a-project
[12]: http://cubecloud.dev
[13]: https://cube.dev/docs/schema/reference/measures
[14]: https://cube.dev/docs/schema/reference/dimensions
[15]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c264b798-c308-4e55-aedc-c8c62f414ed5.jpg
[16]: https://cube.dev/docs/schema/reference/cube
[92]: https://slack.cube.dev
[93]: https://cube.dev/docs/backend/sql
[94]: https://cube.dev/docs/config/downstream
[95]: #grab-sql-connection-details

Connecting Cube to Tableau tutorial

Apache Superset

Building dashboards over a semantic layer with Superset and Cube

In this tutorial, we'll learn how to build a metrics dashboard with Apache Superset, a modern and open-source data exploration and visualization platform. We'll also use Cube, an open-source metrics store, as the data source for Superset that will enable our dashboards to load in under a second — quite the opposite to what you'd usually expect from a BI tool, right?

Here's how the end result will look like:

![Screenshot 2021-11-24 at 05.04.36.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/11d780fa-b9b3-45d2-af61-e1f3ce270731.png)

Now we're all set. Let's see what's on the shelves of this metrics store 🏪

## What is Apache Superset?

[Apache Superset](https://superset.apache.org) is a data exploration and visualization platform or, in layman's terms, a tool that you can use to build dashboards with charts for internal users. Born at a hackathon at Airbnb back in 2015, with more than 41,000 stars on GitHub, now it's a leading open-source business intelligence tool.

Superset has connectors for numerous databases, from Amazon Athena to Databricks to Google BigQuery to Postgres. It provides a web-based SQL IDE and no-code tools for building charts and dashboards.

**Running Superset.** Now let's run Superset to explore these features. To keep things simple, we'll run a fully managed Superset in [Preset Cloud](https://preset.io), where you can use it forever for free on the Starter plan. (If you'd like to run Superset locally with Docker, please see [these instructions](https://github.com/cube-js/cube.js/blob/master/examples/superset/README.md#running-superset-locally).)

First, please proceed to the [sign up page](https://preset.io/registration/) and fill in your details. Note that Preset Cloud supports signing up with your Google account. Within a few seconds you will be taken to your account with a readily available workspace:

![Screenshot 2021-11-24 at 02.50.55.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8cc1e93b-3cd2-4232-b723-8f3b99f42324.png)

Switching to that workspace will reveal a few example dashboards that you can review later.

![Screenshot 2021-11-24 at 02.54.51.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/91134cc7-13e7-46de-b924-75c606c9fbbd.png)

Now, let's navigate to `Data / Databases` via the top menu and... Oops! We need a metrics store to connect to. Let's see how Cube can help us build one.

## What is Cube?

[Cube](https://cube.dev/) is an open-source [metrics store](https://cube.dev/blog/introducing-cube-sql/) with nearly 12,000 stars on [GitHub](https://github.com/cube-js/cube.js) to date. It serves as a single source of truth for all metrics and provides APIs for powering BI tools and building data apps. You can configure Cube to connect to any database, define your metrics via a declarative data schema, and instantly get an API that you can use with Superset or many other BI tools.

**Running Cube.** Similarly to Superset, let's run a fully managed Cube in [Cube Cloud](https://cube.dev/product/why-cube-cloud) that has a free plan as well. (If you'd like to run Cube locally with Docker, please see [these instructions](https://github.com/cube-js/cube.js/blob/master/examples/superset/README.md#running-cube-locally).)

First, please proceed to the [sign up page](https://cubecloud.dev/auth/signup) and fill in your details. Note that Cube Cloud supports signing up with your GitHub account. Within a few seconds you will be taken to your account where you can create your first Cube deployment:

![Screenshot 2021-11-24 at 03.06.16.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/1ccba445-9cbf-4bb6-acfe-1e3c1d2fa325.png)

Proceed with providing a name for your deployment, selecting a cloud provider and a region:

![Screenshot 2021-11-24 at 03.21.33.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/28ad847d-10f6-47ed-8bf5-66a2b441eef3.png)

At the next step, choose `Create` to start a new Cube project from scratch. Then, pick `Postgres` to proceed to the screen where you can enter the following credentials:

```
Hostname:  demo-db-examples.cube.dev
Port:      5432
Database:  ecom
Username:  cube
Password:  12345
```

![Screenshot 2021-11-24 at 03.22.40.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/835c5600-7f79-44b3-81c1-3726a787c440.png)

Cube will connect to a publicly available Postgres database that I've already set up.

The last part of configuration is the [data schema](https://cube.dev/docs/schema/getting-started) which declaratively describes the metrics we'll be putting on the dashboard. Actually, Cube can generate it for us! Pick the top-level `public` database from the list:

![Screenshot 2021-11-24 at 03.22.55.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c721028f-e20c-425c-900d-75b9f294a3bc.png)

In a while, your Cube deployment will be up and running:

![Screenshot 2021-11-24 at 03.24.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5c39e57e-3311-4f40-9b89-8bc40d49df00.png)

**Defining metrics.** Please navigate to the "Schema" tab. You will see files like `LineItems.js`, `Orders.js`, `Users.js`, etc. under the "schema" folder.

![Screenshot 2021-11-24 at 03.25.51.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8fb089b2-f33a-4795-9450-9f564dbd40d4.png)

Let's review `LineItems.js` which defines the metrics within the "LineItems" cube. This file is different from the one in Cube Cloud, but we'll take care of that later.

```jsx
cube(`LineItems`, {
  sql: `SELECT * FROM public.line_items`,

  measures: {
    count: {
      type: `count`
    },

    price: {
      sql: `price`,
      type: `sum`
    },

    quantity: {
      sql: `quantity`,
      type: `sum`
    },

    // A calculated measure that reference other measures.
    // See https://cube.dev/docs/schema/reference/measures#calculated-measures
    avgPrice: {
      sql: `${CUBE.price} / ${CUBE.quantity}`,
      type: `number`
    },

    // A rolling window measure.
    // See https://cube.dev/docs/schema/reference/measures#rolling-window
    revenue: {
      sql: `price`,
      type: `sum`,
      rollingWindow: {
        trailing: `unbounded`,
      },
    }
  },

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    }
  },

  dataSource: `default`
});
```

Key learnings here:

- the cube is a logical entity that groups measures and dimensions together
- using the `sql` statement, this cube is defined over the entire `public.line_items` table; actually, cube can be defined over an arbitrary SQL statement that selects data
- measures (quantitative data) are defined as aggregations (e.g., `count`, `sum`, etc.) over columns in the dataset
- dimensions (qualitative data) are defined over textual, numeric, or temporal columns in the dataset
- you can define complex measures and dimensions with custom `sql` statements or references to other measures

**Development mode.** Now, let's update the schema file in Cube Cloud to match the contents above. First, click `Enter Development Mode` to unlock the schema files for editing. This essentially creates a "fork" of the Cube API that tracks your changes in the data schema.

Navigate to `LineItems.js` and replace its contents with the code above. Then, save your changes by clicking `Save All` to apply the changes to the development version of your API. You can apply as many changes as you wish, but we're done for now. Click `Commit & Push` to merge your changes back to the main branch:

![Screenshot 2021-11-24 at 03.33.47.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/85eeca4a-e85f-4109-8459-4dbde074d005.png)

On the "Overview" tab you will see your changes deployed:

![Screenshot 2021-11-24 at 03.37.57.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5e7746a3-8839-47e3-bddc-a8b67460207a.png)

Now you can explore the metrics on the "Playground" tab:

![Screenshot 2021-11-24 at 03.41.38.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/df9a8062-4026-4476-8c65-b10e1360075e.png)

Good! We've built a metrics store that we can connect to Superset. How?

Please go back to the "Overview" tab and click `How to connect`. The "SQL API" tab will have a toggle that enables the API for Superset and other BI tools. Turning it on will provide you with all necessary credentials:

![Screenshot 2021-11-24 at 03.46.54.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e2751eeb-c7bb-4f8d-9ff9-d6184097e9ce.png)

Now, let's build a dashboard!

## Building a dashboard in Superset

We'll need to go through a few steps:

- [connect Superset to Cube](https://cube.dev/docs/recipes/using-apache-superset-with-cube-sql)
- define the datasets
- create charts and add them to a dashboard

Let's go!

![Screenshot 2021-11-24 at 03.44.32.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/dee5d4cc-df2a-47a8-a812-9e54aef57e5d.png)

**Connect Superset to Cube.** Switch back to the workspace we've created earlier. Then, navigate to `Data / Databases` via the top menu, click `+ Database`, select `MySQL`, and fill in the credentials from your Cube Cloud instance — or use the credentials below:

- Host: `aquamarine-moth.sql.aws-us-east-2.cubecloudapp.dev`
- Port: `3306`
- Database name: `db`
- Username: `cube@aquamarine-moth`
- Password: `6300005f8da3ef74fa64a5bf9b1b6fcd`
- Display name: `Cube Cloud` (it's important)

![Screenshot 2021-11-24 at 03.53.07.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/42812095-82d4-4a65-a918-ab173c45689e.png)

You can press `Connect` now.

**Define the datasets.** Navigate to `Data / Datasets` via the top menu, click `+ Dataset`, and fill in the following credentials:

- Database: `Cube Cloud` (the one we've just created)
- Schema: `db`
- See table schema: `LineItems`

![Screenshot 2021-11-24 at 03.58.02.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/d8e50fc9-4df7-425b-b57b-f3904de984e0.png)

You can press `Add` now. Then, please repeat this for `Users` and `Orders`.

**Create charts and a dashboard.** We'll take a leap and create everything in a single step.

In Superset, you can export a dashboard with all charts as a JSON file and import it later. Navigate to `Dashboards` and click the link with an icon on the right:

![Screenshot 2021-11-24 at 04.01.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e2ea0cbd-1cd0-439d-8c4d-a36d9e61b0c7.png)

Download [this file](https://raw.githubusercontent.com/cube-js/cube.js/master/examples/superset/acme-dashboard.json) to your machine, select it, and click `Import`:

![Screenshot 2021-11-24 at 04.02.38.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5256114e-d4a4-4e4d-96b0-137aee522bcb.png)

Whoa! Now we have a complete dashboard for Acme, Inc. Click on it to view:

![Screenshot 2021-11-24 at 05.04.36.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/11d780fa-b9b3-45d2-af61-e1f3ce270731.png)

Looks nice, doesn't it? Let's explore what's under the hood and how you can build it on your own.

## Diving deep into Superset

**Anatomy of a dashboard.** You can see that charts on the dashboard are aligned by the grid. To rearrange them, click on the pencil icon in the top right corner. You can add tabs, headers, dividers, Markdown blocks, etc. Of course, you can also add charts.

![Screenshot 2021-11-24 at 05.06.41.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/f8905469-8f64-4e3d-85d0-e7ae283673f3.png)

**The simplest chart.** Navigate to `Charts` via the top menu and click on any chart with the `Big Number` visualization type, e.g., Customers. In my opinion, that's the simplest chart you can create in Superset. It contains a single metric, and I doubt a chart can get simpler than that.

![Screenshot 2021-11-24 at 05.07.29.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/afde957b-bdc9-4083-a704-11006c8805f1.png)

Let's dissect how a chart is defined:

- Visualization type: `Big Number` — that's where you can select or change the chart type
- Time column: `createdAt` — interestingly enough, any chart should have this time column defined even if the displayed data has no temporal components
- Metric: `COUNT(*)` — that's the most important part of any chart configuration; upon clicking on this metric, you'll see that you can either select a saved definition, "simply" select a column and an aggregation, or write a "custom SQL" expression

When all config options are set, press `Run` to fetch the data, then `Save` to persist a chart or add it on a dashboard (no need to do it now, it's already added).

**A less simple chart.** Navigate to `Charts` via the top menu and click on any chart with the `Big Number with Trendline` visualization type, e.g., Revenue. Still, it contains a single metric as well as a sketchy chart in the bottom.

![Screenshot 2021-11-24 at 05.08.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/103ea21b-ef9b-4e17-b9a9-580d24a271b1.png)

Let's dissect how this chart is defined (only new options):

- Time grain: `Month` — defines the temporal granularity for metrics calculations
- Time range: `Last year` — specifies the date range for this chart
- Metric: `revenue` — it's interesting; click on this metric to learn that it's defined using "custom SQL"; that's because the aggregation has already been performed by Cube, no need to aggregate aggregated values, right?

**Other charts.** Actually, now you know everything you need to explore and dissect other charts. Just keep in mind that Superset has plenty of customizations you can apply to charts — see the "Customize" tab for inspiration.

![Screenshot 2021-11-24 at 05.09.15.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/eec079db-5c09-42be-822e-5ab583ce016d.png)

**Viewing SQL.** For any chart, you can reveal the SQL query to Cube which is generated by Superset to fetch the data. Press the burger button (with triple horizontal lines) in the top right corner, then `View query`. Good ol' SQL, nice:

![Screenshot 2021-11-24 at 05.09.42.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/68e680a9-3826-4597-8e21-934f901779c3.png)

Also, if you wanna use the aforementioned SQL IDE, navigate to `SQL Lab / SQL Editor` via the top menu.

## Making business intelligence fast ⚡

There's only one thing left to explore, but it's a huge one.

Let's navigate back to the Acme, Inc. dashboard. It takes 2-3 seconds to load, and the infinity-shaped spinners are clearly visible. They are not annoying, but honestly — wouldn't you like this dashboard to load instantly? Yep, well under a second.

Cube provies an out-of-the-box [caching layer](https://cube.dev/docs/caching) that allows to pre-compute and materialize the data required to serve the queries. All you need to do is define which queries should be accelerated. It's done declaratively in the data schema files. (Please also note that Superset has its own lightweight [caching layer](https://superset.apache.org/docs/installation/cache) that might be handy in cases when you need to push your Cube + Superset to the limit.)

Please go back to your Cube Cloud instance, enter the development mode, switch to the "Schema" tab, and update your data schema files with small snippets as follows.

First, `LineItems.js` should look like this:

```jsx
cube(`LineItems`, {
  sql: `SELECT * FROM public.line_items`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count, CUBE.revenue, CUBE.price, CUBE.quantity ],
      timeDimension: CUBE.createdAt,
      granularity: 'day'
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    },

  ...
```

Second, `Orders.js` should look like this:

```jsx
cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count ],
      dimensions: [ CUBE.status ],
      timeDimension: CUBE.createdAt,
      granularity: 'day'
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    },

  ...
```

Lastly, `Users.js` should look like this:

```jsx
cube(`Users`, {
  sql: `SELECT * FROM public.users`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count ],
      dimensions: [ CUBE.city, CUBE.gender ]
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    }

  ...
```

Don't forget to click `Save All`, then `Commit & Push`, and check that your changes were deployed at the "Overview" tab. In the background, Cube will build the necessary caches.

It's time to get back to your dashboard and refresh it. Now refresh it one more time. See? The dashboard loads in under a second. ⚡

Of course, you have plenty of options to fine-tune the caching behavior, e.g., specify the [cache rebuilding schedule](https://cube.dev/docs/caching/using-pre-aggregations#refresh-strategy).

## Wrapping up

Thanks for following this tutorial. I encourage you to spend some time [in the docs](https://superset.apache.org/docs/intro) and explore other features of Apache Superset. Also, please check out Preset docs that are packed with great content, e.g., on [creating charts](https://docs.preset.io/docs/create-a-chart).

**Also, thanks for learning more about building a metrics store with [Cube](https://cube.dev/). Indeed, it's a very convenient tool to serve as a [single source of truth for all metrics](https://cube.dev/blog/introducing-cube-sql/).**

Please don't hesitate to like and bookmark this post, write a comment, and give a star to [Cube](https://github.com/cube-js/cube.js) and [Superset](https://github.com/apache/superset) on GitHub. I hope these tools would be a part of your toolkit when you decide to build a metrics store and a business intelligence application on top of it.

Good luck and have fun!

Building a metrics dashboard with Superset and Cube

Today, Cube powers analytics features inside thousands of applications where developers have leveraged Cube’s data schema as a **metrics layer**—a consistent, single source of truth. By powering a single repository of metrics, Cube helps developers quickly and reliably ship embedded analytics features and other data-powered applications with the peace of mind that their metrics definitions remain consistent.

Cube solves this problem very well for application developers, but it’s been unsolved for users of dashboards and business intelligence tools, and the data engineering teams that support them.

In most modern organizations, there are multiple tools that consume data from the same single warehouse but perform their own downstream metrics calculations. This leads to inconsistent calculations and disagreements between teams: **How do we calculate revenue? Does it include revenue from X cohort? How do monthly payments affect annual projections?**

The more tools an organization uses, the more inconsistencies and conflicts arise, and the harder it is for a business to make decisions using accurate data. To avoid this, they need a centralized, upstream location in which to build and maintain their metrics, so that every tool works from the same source of metric truth.

Today, I’m excited to share a way for Cube to function as a metrics store for any data consumer: we’re proud to announce the new [Cube SQL API](https://cube.dev/docs/backend/sql/). With the addition of this API, Cube now functions as a headless BI layer to provide consistent metrics to any querying and visualization tool.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/ebff03e0-fbcd-4941-9a3c-cc71b6142561.png)

## How it works

In the modern data stack, Cube acts as a proxy for data warehouses and translates every incoming query, whether it is JSON, GraphQL, or SQL, into native queries to the underlying data storage.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7bf46e5f-f4b8-4f2a-a236-c067ff894d86.png)

Cube translates queries by using a JSON-based data modeling layer consisting of cubes. Think of these as database views, backed by either a reference to an existing database table or a new table created by SELECT statement. Cubes contain defined measures and dimensions.

**Measures** are quantitative data, such as the number of units sold, unique visits, profit, and so forth. **Dimensions** are categorical data, such as state, gender, product name, or units of time. (You can learn more about Cube’s [data schema](https://cube.dev/docs/schema/getting-started) in the docs.)

Below is an example of the cube we can use to describe metrics about leads for a sales organization.

```javascript
cube(`Leads`, {
  sql: `
    SELECT
      persons.id,
      persons.created_date,
      deals.id as deal_id
    FROM persons
      LEFT JOIN deals ON deals.person_id = persons.id
  `,

  title: `Leads`,
  description: `Leads for Insides Sales`,

  measures: {
    count: {
      type: `count`
    },
    converted_to_deal_count: {
      type: `count`,
      filters: [
        { sql: `(${is_converted_to_deal}) = true` }
      ]
    },
    to_deal_conversion_rate: {
      type: `number`,
      sql: `ROUND(${converted_to_deal_count} / NULLIF(${count}, 0) * 100, 2)`,
      format: `percent`
    }
  },

  dimensions: {
    time: {
      sql: `created`,
      type: `time`
    },
    is_converted_to_deal: {
      type: `boolean`,
      sql: `deal_id IS NOT NULL`
    }
  }
})
```

With the above definitions of our metrics we can ask questions like **"What is our monthly lead-to-deal conversion rate over the last year?"**

When we query Cube’s metrics layer via the SQL API, cubes will be presented as tables and measures and dimensions as columns. To answer the above question with SQL we need to write the following query:

```sql
SELECT DATE_TRUNC('month', time),
       to_deal_conversion_rate
FROM leads
WHERE time >= '2021-01-01'
  AND time < '2022-01-01'
GROUP BY 1
```

Cube will translate this query into the query for the underlying database.

```sql
SELECT
  DATETIME_TRUNC(
    DATETIME(created_date, 'UTC'),
    MONTH
  ) `leads__time_month`,
  ROUND(
    count(
      CASE WHEN ((deal_id IS NOT NULL) = true) THEN 1 END
    ) / NULLIF(count(*), 0) * 100,
    2
  ) `leads__to_deal_conversion_rate`
FROM
  (
    SELECT
      persons.id,
      persons.created_date,
      deals.id as deal_id
     FROM persons
      LEFT JOIN deals ON deals.person_id = persons.id
  ) AS `leads`
WHERE
  (
    created_date >= TIMESTAMP('2021-01-01T00:00:00.000Z')
    AND created_date <= TIMESTAMP('2021-12-31T23:59:99.999Z')
  )
GROUP BY
  1
ORDER BY
  2 DESC
LIMIT
  10000
```

You can query Cube with SQL from your favorite programming language, such as Python.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2b0d23c8-37fa-4550-8c99-53196c832a26.gif)

Most powerfully, because the Cube SQL API speaks MySQL-compatible SQL, you also can connect your favorite BI tool—like Superset, Metabase, or Tableau—directly to Cube, and let Cube generate SQL to fetch and display data. Here’s an example of using Superset with the Cube SQL API.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/a775a871-8e89-451c-afb1-671b6dd22e3f.png)

You can check our documentation for the full [Superset integration tutorial](https://cube.dev/docs/recipes/using-apache-superset-with-cube-sql).

## Built-in relational cache

Every query can leverage Cube’s pre-aggregations layer—a database-agnostic materialization engine—in order to make dashboards and reports load in milliseconds instead of minutes.

While defining metrics, developers can specify which metrics they want to pre-aggregate. Cube will run complex calculations beforehand in the background and will create a cache table with the results. All queries will be served from this cache table, dramatically increasing dashboards’ performance.

## Where we go next

We’re excited about today’s launch, but it is only the beginning of the journey!  We’re committed to supporting all the major SQL operations, and improving error handling to provide more useful tips to users. Please let us know in our Slack channel if you see something that is not working as you expected.

Everything described here is available in Cube’s OSS offering, licensed under Apache 2.0. In addition, we're working on cataloguing and collaboration tools for the Cube metrics layer in Cube Cloud, our fully-managed Cube service. Watch this space.

If you’re interested in learning more, [please give us a try.](https://cubecloud.dev/auth/signup)

Artyom Keydunov

Introducing the Cube SQL API: Building Metrics Stores with Cube

Nakshatra Mukhopadhyay

Data Visualization

Tableau-like Charts with MuzeJS, Cube, and React

We recently covered how to build an analytics dashboard using react, vue, or angular. But if you don't want to code and host your own dashboard, you have some open-source alternatives. Today I'll show you how to build an analytics dashboard using [Cube](https://cube.dev) Backend and [Redash](https://redash.io/).
You can find the resulting dashboard live [here](https://app.redash.io/statsbot/public/dashboards/Wq8iPcQwYDGTF3GqMSAQGP10Mg6mgTxl1r5C6MKH).

![Dashboard](https://media.graphcms.com/XVo6igwnQy25V6dHDWXp)

## Why Cube?
You can always connect Redash directly to your database. You can then write queries in pure SQL and build the same dashboard. It's easy to manage if you have one dashboard and just a couple of queries. But usually, a small dashboard is just a first step in building a complex analytics solution. As your business grows, your volume of data also grows. And soon, you may find a hundred dashboards with thousands of queries used by multiple departments. Now imagine you changed a column in the database. All of the queries should be checked and updated.

Another problem may be the data volume. Say you have a large dashboard powered by some complex queries that take some time to execute. Once you change a filter value on that dashboard, all queries will get executed on the database. In a simple case, it may take a long time to update the dashboard, but if you're using a per-query billed database like Google Bigquery or AWS Athena, this will also hit your monthly bill. 

Cube solves both of these problems. The queries used in Redash may be updated independently, so updating a column name or adding a join condition is a simple update in the data schema file. Also, Cube.js Backend manages [pre-aggregations](https://cube.dev/blog/high-performance-data-analytics-with-cubejs-pre-aggregations/), which helps with loading lots of data fast and efficiently. Cube pre-aggregates data for huge queries in separate tables and updates them in the background. This is efficient in terms of performance and cost. [Here](https://cube.dev/docs/guides/recipes/code-reusability/schema-generation) you can find a guide on Cube Data Schema to understand core concepts better.

## Setting up Cube Backend

To launch a Cube Backend, you'll need to provide a database where your analytics data is stored and a hosting option. In this demo, we'll use Postgresql database with our demo dataset. If you don't have access to your analytics database right now, you can use this dataset:

```bash
curl http://cube.dev/downloads/ecom-dump.sql > ecom-dump.sql
createdb ecom
psql --dbname ecom -f ecom-dump.sql
```

Now when you have your database running, we have to choose a deployment option. For this demo, we'll host our backend on [Heroku](https://heroku.com/). There's a guide for other deployment options in the [documentation](https://cube.dev/docs/deployment).

Let's install `cubejs-cli` and create a new Cube.js app:

```bash
npm install -g cubejs-cli
cubejs new redash-demo -d postgres
cd redash-demo
```

Now we have to set a data model. For this demo, we'll define only one cube and skip advanced options, which are covered in the [documentation](https://cube.dev/docs/product/data-modeling/overview).

```javascript
cube(`Users`, {
  sql: `SELECT * FROM users`,

  measures: {
    count: {
      sql: `id`,
      type: `count`
    }
  },

  dimensions: {
    city: {
      sql: `city`,
      type: `string`
    },

    signedUp: {
      sql: `created_at`,
      type: `time`
    },

    companyName: {
      sql: `company_name`,
      type: `string`
    }
  }
});

```

Now when we have our data model set we can deploy this app to Heroku:

```bash
git init
git add -A
git commit -am "Initial commit"
heroku create cubejs-redash-demo
git push heroku master

```

## Creating a Redash Dashboard

To use Cube Backend with Redash, you need to create a [JSON Data Source](https://redash.io/help/data-sources/querying/urls).

Once you've done that, you can create a query. There are a couple of options like URL and Authorization Headers that will be shared across all of the queries, so you can create one query and then fork it to create others. Here's a simple query that will count all Orders in our demo dataset:

```yaml
url: "YOUR-CUBEJS-URL/cubejs-api/v1/load"
headers: 
    Authorization: YOUR-API-TOKEN
path: data
params:
    query: '{"measures": ["Orders.count"]}'
```

Here you need to provide your API URL, which depends on the deployment option you chose. Also, you need to create an [API Token](https://cube.dev/docs/security) to authenticate requests. 
Now click "Save" and "Execute." You should get a response that looks like this:

![Query results](https://media.graphcms.com/8gWHLswcSBKExUAsNVzV)

Now you can add a visualization. For this query, we'll use a simple "counter" option:

![Counter](https://media.graphcms.com/ZpZ50RTD6ghE0V1X3SlA)

Let's create a more sophisticated query. We'll create a Stacked Bar Chart for the orders. First, let's define the query: 

```yaml
url: "https://awesome-ecom.gcp-us-central1.cubecloudapp.dev/cubejs-api/v1/load"
headers: 
    Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.K9PiJkjegbhnw4Ca5pPlkTmZihoOm42w8bja9Qs2qJg
path: data
params:
    query: '{
      "measures":["Orders.count"],
      "dimensions":["Orders.status"],
      "timeDimensions":[{"dimension":"Orders.createdAt",
        "dateRange":["2017-01-01","2018-12-31"],
        "granularity":"month"
      }]
}'
```

Save and execute the query and you'll get a table, which is the default visualization. Let's create a Bar Chart:

![Stacked Bar Chart](https://media.graphcms.com/3GcT1LjVQaqqHNybhp3e)

Now we have enough queries to create a dashboard. Click "Create" -> "Dashboard," choose a name, and go ahead adding your query widgets.

And the dashboard is done!

## Setting Filters

There's also a Redash option called Parameters. We can set some query values using it. Let's add a daterange filter to our queries:

```yaml
url: "https://awesome-ecom.gcp-us-central1.cubecloudapp.dev/cubejs-api/v1/load"
headers: 
    Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.K9PiJkjegbhnw4Ca5pPlkTmZihoOm42w8bja9Qs2qJg
path: data
params:
    query: '{"measures":["Orders.count"],
        "timeDimensions": [{
          "dimension" : "Orders.createdAt",
          "dateRange": ["{{ daterange.start }}","{{ daterange.end }}"]
        }]
    }'
```

You can see we've added params using the `{{ }}` expression. Now let's change the parameter type to daterange:

![Daterange Filter](https://media.graphcms.com/Xi0H6jBPSdW6GuOtwDwN)

Click "Save" and "Execute." Now this query has a daterange filter. You can add other parameters to the query in the same manner. Also, you can set multiple queries to use one dashboard-level filter value using the "edit Parameters" menu. Here's an example:

![17wbnsakge7l603k5sbr.png](https://media.graphcms.com/2mhGyZOLR0KAUxa1rFli)

And it's done! Now we have a live dashboard in Redash, which you can publish, query, or even run on a display with auto-update.

BI & Data Exploration