导读
本篇内容是笔者在做 开箱即用的 BI 工具 系列的过程中的一些个人总结。为了保证文章的整体结构，特单独提炼出这一篇关于 Redash 的解析。各位读者请放心，本篇内容会很独立，没有其他上下文也不影响阅读。
这是设计理念浅析的最后一篇文档，坑终于填完了。前面的系列文章见 《DataEase 设计理念浅析》、《Metabase 设计理念浅析》、《Superset 设计理念浅析》。
正文
核心还是探究 2 个问题：
- 如何解决图表属性配置问题？
- 如何解决不同数据源统一的问题？
Redash 简介
Redash helps you make sense of your data
Connect and query your data sources, build dashboards to visualize data and share them with your company.
这是其 官网首页 给的定义。官网给的图例不是那么炫酷，也不太好截图，大家自行前往观看吧。看一下首页的 Demo 视频也可以。想体验还是要先在本地部署，而且 Redash 没有准备内置的体验数据，需要自己准备数据库，会麻烦点。具体方法见 开源 BI 工具调研：Superset、Metabase、Redash、DataEase（二）- 本地部署。我们使用 employees 这个库，其表结构如下：
创建视图
首页指南有如下 3 步：
- Connect a Data Source.
- Create your first Query.
- Create your first Dashboard. 第一步见上文引用的文档，第三部很简单，就不说了，我们主要看第二步。实现一个简单的柱状图，横坐标 - 部门名；纵坐标1 - 部门人数；纵坐标2 - 平均薪资。
我们按照视频中的步骤操作，输入下面的 SQL：
SELECT
departments.dept_name AS dept_name, avg(salaries.salary) AS avg, count(distinct salaries.emp_no) AS count
FROM salaries
LEFT JOIN dept_emp ON salaries.emp_no = dept_emp.emp_no LEFT JOIN departments ON dept_emp.dept_no = departments.dept_no
GROUP BY departments.dept_name
ORDER BY departments.dept_name ASC
然后添加视图，按下图设置就能够得到想要的视图了。
经过测试发现，X Column、Y Columns、Group by 都可以选择 dept_name、avg、count 中的任何一个，没有任何限制。只是当其中一个选了之后，别的选项就没法再选已被选中的值了。
如果从上述观察到的现象来看，在图表属性这块，Redash 没有做任何抽象，把所有控制权都交给了用户，似乎默认用户是比较专业的。不过从 Query 的操作都要用 SQL 语句这个设计来看，似乎也符合 Redash 的思路。
既然没有抽象，那对于视图的扩展反而简单了，只需要引入新的图表，把字段配置可视化，就完成了，剩下所有的事情交给用户去思考，去理解，去做。
怎么说呢，这也是一个思路，虽然让习惯于用户思维的笔者，觉得设计的不太友好。但是不得不说，从扩展性上来说，它真的没什么问题，只是对于用户的使用有一定的门槛而已。好吧，即使是这样，也稍微觉得有点别扭。
数据
上文的例子已经说明了，Redash 直接用 SQL 从连接的数据源里面 query 数据。而且读出来的数据貌似也没有类型的概念，只是纯展示。也是，计算什么的都用 SQL 语句做了，与视图对接也没有抽象，可以随便选，要数据类型干嘛呢？连接其他类型数据源也基本是用相应的语句，详见 Setup & Querying。
总结
好吧，笔者目前得出了一个有些意外的结论：Redash 最大的设计就是没有设计。没有多加抽象层，没有多加概念。就是把 SQL 查询和生成图表的过程可视化了，可以说跟写代码的思路完全一样，倒是挺纯粹。
也就是说，想用好 Redash，你起码是一个会写 SQL，知道图表各个属性怎么配置的“全栈工程师”才行。嗯……各位自行判断吧。
“在激烈竞争中，取胜的系统在最大化或者最小化一个或几个变量上会走到近乎荒谬的极端。”——Charlie Thomas Munger
