We’ll build a Looker alternative using dbt + Metriql + Google Data Studio and write a blog post to explain how you built this stack and to showcase it's +/-’s over Looker.

Steps

1. Fork https://github.com/metriql/metriql-public-demo and copy the models & seeds from dbt sample project: https://github.com/dbt-labs/jaffle_shop
2. Load this data into a BigQuery dataset.
3. Define metrics relevant to the dataset using Metriql. You should make use of Metriql’s relations and data studio semantic types.
4. Use Metriql’s integration with GDS and sync your metrics to GDS and start running ad-hoc analysis.
5. Prepare a GDS dashboard that you can link in your blog later on.
6. Write a tutorial like a blog to guide those who would like to use this free stack over LookML + Looker including screenshots and the Github repository

Tooling

• You can use Github's VSCode (example: https://github.dev/metriql/metriql-public-demo) and mention it as an alternative to Looker IDE.
• If you fork the public demo, it comes with Github Actions that run dbt as part of the continuous integration process. (https://github.com/metriql/metriql-public-demo/actions) You can mention Github Actions as an alternative to Looker's internal scheduler.
• We use CI and CD to deploy the data models to Heroku automatically when the data models change. (Bonus: testing data models as part of the CI process. Talk to @buremba about it before publishing the post)

Things to mention

• Looker has everything embedded into the product but the BI world is now decentralized. People use dbt for transformation, VSCode as an IDE, or their preferred BI tool to analyze the data. The missing layer was the metrics layer for all the BI tools, Metriql taps on this problem.
• Metriql is LookML for all the BI & data tools. Looker's strongest suit is LookML, there are better visualization products such as Tableau.
• Looker has APIs but it's not a metrics store because you can't integrate it with other BI tools.
• Looker is expensive

You'll build an end-to-end modern data stack using Meltano + dbt + Metriql and Superset and show how well these tools work together. You'll come up with a possible use case and relevant dataset to demonstrate the use of these tools.

We will rn Meltano with Github Actions just like how I run dbt using Github workflow so that the end-to-end pipeline can be reproducible by the people who would like to try it out on their data. I can guide you on that once we get in that step.

We can also have a button similar to the Metriql Demo data repo that spins up Superset in addition to Metriql on Heroku (I have a sample setup for it) so that within one click they can have everything in place easily!

If you can work with the marketing data, we can use our sample data for Facebook or Google Adwords. That way, people can fork the repo, change their credentials and API keys, and end up on the same reporting screen but on top of their data. (https://hub.meltano.com/extractors/facebook)

We'll build a semantic layer(aka metrics layer) using dbt + Metriql and synchronize metrics to Tableau and Looker and write a blog to showcase how powerful it's to use the same metrics in multiple BI tools at once. It can be considered as a follow-up post on this piece

Steps
1- Fork https://github.com/metriql/metriql-public-demo and copy the models & seeds from dbt sample project: https://github.com/dbt-labs/jaffle_shop
2- Load this data into a data warehouse using your preferred ETL tool.
3- Define metrics relevant to the dataset using Metriql (you should make use of Metriql's relations
4- Use Metriql's integrations to sync metrics to Tableau and Looker and start running ad-hoc analysis.
5- Prepare dashboards on both Tableau and Looker (you'll link them in your blog later on)
6- Write a blog post/tutorial including screenshots and a short video to explain how you built this semantic layer and compare it to other semantic layer solutions such as LookML.

Tooling

• You can use Github's VSCode (example: https://github.dev/metriql/metriql-public-demo) and mention it as an alternative to Looker IDE.
• If you fork the public demo, it comes with Github Actions that run dbt as part of the continuous integration process. (https://github.com/metriql/metriql-public-demo/actions) You can mention Github Actions as an alternative to Looker's internal scheduler.
• We use CI and CD to deploy the data models to Heroku automatically when the data models change. (Bonus: testing data models as part of the CI process. Talk to @buremba about it before publishing the post)

We will develop an app that lets Spotify users see their playlist/song data in a dashboard and run queries on Metriql. The aim of the project is to let data people interact with their actual data in Metriql and see how they can use it in a simple way.

User flow

1. The user will click a Login with Spotify button that redirects the user to Spotify and authenticates using OAuth.
2. Once the user is redirected back to the app, the app will start loading users' Spotify data into our Postgresql database.
   a. The data that we need to load includes the saved tracks and the songs in the user playlists. We should enrich the data and add info such as tempo, energy, etc. similar to cumul.io's Spotify project.
   b. Ideally we can perform these requests on users' browsers to push the work to the user's device if Spotify API supports CORS. This approach can also help us put a progress bar and be more responsive in loading the data. Once we load all the songs into an array, we can upload it to our server which creates a Postgresql table using the username of the user as a table name and load all the data into that table. Once we have the data in a table, we can create a Postgresql user and give the user access to that table. You can generate a random password and then show it to the user on the next screen.
   c. Once we have the data, we should define the metrics with Metriql deploy a Metriql server that will run the queries.
   d. The last step is a creating sample dashboard in an open-source BI tool such as Metabase or Superset. We can just manually create a dashboard from our data and make the table name to be a dashboard parameter. When embedding the dashboard, use locked parameters and use the table name as the value of the parameter. The dashboard will be embedded in the page and we will also put a link to the Metriql server so that the users can analyze the data in their preferred data tool.

Resources

Postgresql database:

We can use local Postgresql, I will provide the credentials of the production database later on)

The Javascript / HTML project that will access Spotify and load the data using its API into our server.

The HTML part is rather easy, there will be a Login with Spotify button, preferably a progress bar and an embedded dashboard. For the Javascript part that interacts with Spotify, we can use cumulio-spotify's codebase.

Metriql server

You can deploy Metriql locally and publish the data models in the Github repository. We will run the dbt using Github Actions and publish the dbt Docs on Github similar to https://github.com/metriql/metriql-public-demo and use the manifest.json URL to start Metriql. The users will use their Postgresql credentials to connect Metriql so that we can only give them the access to see their data.

Metabase server

We're not tied to Metabase. We can use Rakam as well. Once the other steps are done, we can discuss the solution accordingly. Ideally, we want to create a dashboard and parametrize the table name. As the table schema will be the same, we can model the data only once and embed the dashboard into our page that will not let the user change the parameter thus only see his/her data.