Superset 设计理念浅析

1,178 阅读5分钟

导读

本篇内容是笔者在做 开箱即用的 BI 工具 系列的过程中的一些个人总结。为了保证文章的整体结构,特单独提炼出这一篇关于 Superset 的解析。各位读者请放心,本篇内容会很独立,没有其他上下文也不影响阅读。

这是相关的第三篇,前两篇见 DataEase 设计理念浅析Metabase 设计理念浅析,目前的规划就差 Redash 了。

正文

核心还是探究 2 个问题:

  1. 如何解决图表属性配置问题?
  2. 如何解决不同数据源统一的问题?

Superset 简介

Superset is fast, lightweight, intuitive, and loaded with options that make it easy for users of all skill sets to explore and visualize their data, from simple line charts to highly detailed geospatial charts.

这是其 官网首页 给的定义。看一下效果图

image.png

快速熟悉功能可以参考 官网文档,当然体验之前你需要先把它本地部署起来,具体方法可以在笔者 开箱即用的 BI 工具 系列当中找,还是需要花费一些精力的。不想花精力的同学,可以先把本篇文章看完,初步了解下,有需求时再进一步自己实践。

创建视图

我们来看一下创建视图的界面,你需要在 Datasets 功能下选中一张表才能进入到下图的视图设置界面。但是官网给的图例和笔者本地搭的服务(2022.04.20 用 Docker 镜像部署)有些许出入,但都是表名大小写、按钮位置不一样这类的小问题,不影响主要内容。所以还是以官网给的图例为准,我们来分析下。

image.png

重点看中间的配置项部分,从上至下分别为:Chart Type、Time、Query

Chart Type 顾名思义,就是选择用什么图表展示。

Time 在 Demo 的柱状图当中默认作为横轴,可以进行 Year、Quarter、Month、Day 等维度的聚合。但是这个配置在其他图表类型里又不一定作为横轴,而且也不一定能够聚合。这点笔者在用的时候有一些疑惑,后面会用散点图的例子来说明。

Query 里面有 METRICS、FILTERS、GROUP BY(笔者本地部署版本中叫 DIMENSIONS) 等,会根据 Chart Type 的不同而改变。看过 DataEase 和 Metabase 解析的同学这时候已经得到答案了,重点还是 METRICS 和 GROUP BY 的抽象。

但是!惊喜来了!我们来看一下散点图的配置页面,这回就以笔者本地部署的截图为准了。笔者想要搭建如下的散点图:

  1. 横轴是时间(order_date),按季度汇总;
  2. 纵轴是订单数量汇总(SUM(quantity_ordered));
  3. 气泡大小代表销售额汇总(SUM(sales));
  4. 可选 - 按照产品线(product_line)分类。 然后……我就配不出来了。

image.png 见上图,X AXIS 这个属性必须要填 COLUMN 和 AGGREGATE,否则那个 SAVE 没法点,见下图。

image.png

折腾了半天也没成功,最终勉强用 AVG 函数试了一下,生成的图倒是想那么一回事,但是 hover 上去看详情就露馅了,AVG(quarter) = 2.7 是什么情况,谁能翻译翻译……

另外,在散点图中,Time 和 Query 的 DIMENSIONS(也就是 GROUP BY)不需要配置,配置了之后那效果就更惨不忍睹了。

这……太意外了,DIMENSIONS 既然不是所有图表都必填的,那这个抽象就不太对啊。没办法,在这卡住了,也就只能这样了。当然,很有可能是笔者用的还不太熟,知道怎么弄的小伙伴可以留言纠正一下,我及时改正。

数据抽象

目前来看 Superset 支持的数据源貌似没有 NoSQL 类的,比如最具代表性的 MongoDB,从 官网文档 教程当中连接数据库这部分来看,无论是新增 METRICS 还是新增 CALCULATED COLUMNS,都是采用 SQL expression 的形式,见下图。

image.png

image.png

所以笔者初步猜测,Superset 是以类 SQL 的形式来抽象统一数据层的。如果真是这样,那照 DataEase 和 Metabase 来说,就比较局限了。

总结

先说视图层的抽象,本以为其思路与 DataEase 和 Metabase 一样,表面上看起来也很像,但是一深究发现根本不是这么回事。也许是先研究了前两个,有一些先入为主了,回头想想,如果先试用的 Superset,笔者是断然提炼不出任何抽象的。散点图的那个例子,即使有了前两个产品作参考,也没有搞明白其设计思路,更不用说上来就用的同学了。

数据层,可以比较武断的说,只支持关系型数据库,而且并没有进一步抽象。或者说就是因为没有进一步抽象,所以才只能支持关系型数据库。

Superset 作为时间最久,Star 最多的项目,研究后得出这样的结论,让笔者很是诧异。甚至对自己的这个结论不是那么有信心,但这是目前笔者在现有认知和信息下得出的尽可能客观的结论。笔者甚至很希望有人能够指出自己还没有意识到的错误,真的非常渴望,毕竟客观数据与自己得到的结论差得有点多。最后,说点反向的分析往回圆一圆,留点空间。

  • 第一,虽然 Superset 目前只支持关系型数据库,但是毫无疑问,关系型数据库是现在绝对的主流,对于绝大多数项目来说,这不算是很大的问题;
  • 第二,虽然笔者想搭的散点图没有搭出来,但是我们平时用的最多的其实就是折线图和柱状图,最多再加上饼状图。这些功能已经能够满足我们日常 80% 的需求了,所以也算是够用了;
  • 第三,Airbnb、Apache 背书,进了 GitHub 主页之后,你不想着先点个 Star 吗?

好了,稍微留了点回旋余地,但是最后的最后,笔者不得不说,暂时是不会考虑优先使用 Superset 的。

“谨记,你是在寻找最好的答案,而不是你自己能得出的最好答案。”——Ray Dalio