Metabase also allows you to add click events to your charts, which we’ve found to be quite powerful. A big seller is also the ability to share links to a query you’ve been playing around with, without the need to save it as a dataset. These are baked into the SQL you write yourself.
You can add in filters that are quite smart and based of column values. The charting collection isn’t vast but contains a lot of the general useful charts. You can write queries or build them with some help from the tool and add visualizations on top. Basically all the things that are hard to describe, but you know feels right when you use a tool. What we are looking for here is a smooth query to chart experience, cross filtering, query sharing and general usability.
Metabase >Redash > Superset UX and Dashboarding experienceīy far the most important criteria, also the hardest to compare as each tool comes with its own strengths. (If you want to see how we handle messy spreadsheets check out our open source refinery project) Alerting or generating a daily report can help with that. However, we still want to record that as something for us to follow up on. These are best effort and if one sheet is badly formatted the process doesn’t need to fail. What we’ve really wanted lately is the ability to monitor our data and business outcomes.įor example, we have processes in place that take care of extracting data from Excel workbooks. As mentioned before we’ve been doing pretty well when it comes to monitoring our live systems and overall infrastructure health (courtesy of New Relic). Redash > Superset > Metabase Alerting and reportingĪlerting has been another one of those really important requirements we’ve had. Redash: Rich selection of data sources out the box. The process is simple and done as python packages. Plugins for the non-standard ones need be installed within the chart to be enabled. Superset: A rich selection of data sources. Metabase: No official support for Athena, so we had to enable a community plugin within the helm config. So the ability to add plugins, or the out of the box setup has been greatly appreciated. It can pretty much scan tens of GBs in seconds. Athena is a distributed query service and its done wonders for us when it comes to querying our data lake. We are heavy users of AWS Athena here at Vortexa. Superset > Metabase > Redash Data sources No extra work is needed for the alert and schedulers as those are spun by default, however, you again end up with a bunch of worker pods. Dependencies are redis and a database that are also spinnable through the chart. Redash: No official helm chart, however, the community one is part of the main redash repo, hence closely evolves with redash itself. It ends up with a bunch of pods, some of which workers other for scheduling. Dependencies are redis and a database, and it does provide you with an option to spin those up for you. things like Alerts, Reports and extra data source connectors. The chart itself is pretty configurable and a lot of the functionality is driven within the setup here. Superset: Comes with official support for helm. It then spins up one pod in your cluster and configuration is pretty straightforward and can be done within the tool UI once. As a dependency Metabase requires only a DB connection that it uses for storing state. Metabase: The official Helm chart Metabase comes with has been sadly discontinued, so we’ve had to use a community one. With some of the tools we’ve had to redeploy them a bunch of times until a successful ordered birth happens. Having a good, configurable and up to date helm chart played a big role in this category.Īnother important criteria here for us has been how easy is it is to debug problems and track failures, and things like multiple kube pods can make things harder. As such, we’ve been using Helm to assist with our Kubernetes deployments.
Metabase permissions code#
Infrastructure as code has been really important for us at Vortexa. In any case, lets jump right into the details. These tools evolve and change pretty quickly, so other pains we’ve had might not exist by the time you read this. Some of the criteria is biased towards our own deployment methods and stack needs(Kubernetes, AWS Athena etc.), so they might not apply to your case. We’ll now look at the more detailed analysis, which I need to preface with the obvious warnings.
0 kommentar(er)
