導讀

本篇內容是筆者在做 開箱即用的 BI 工具 系列的過程中的一些個人總結。為了保證文章的整體結構，特單獨提煉出這一篇關於 Redash 的解析。各位讀者請放心，本篇內容會很獨立，沒有其他上下文也不影響閱讀。

這是設計理念淺析的最後一篇文件，坑終於填完了。前面的系列文章見 《DataEase 設計理念淺析》、《Metabase 設計理念淺析》、《Superset 設計理念淺析》。

正文

核心還是探究 2 個問題：

1. 如何解決圖表屬性配置問題？
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 步： 1. Connect a Data Source. 2. Create your first Query. 3. Create your first Dashboard. 第一步見上文引用的文件，第三部很簡單，就不說了，我們主要看第二步。實現一個簡單的柱狀圖，橫座標 - 部門名；縱座標1 - 部門人數；縱座標2 - 平均薪資。

我們按照視訊中的步驟操作，輸入下面的 SQL： 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