在上篇結尾處我提到“如果現在讓我重新選擇，我會使用哪個視覺化工具？”我的答案是 Redash，原因主要不是功能層面，而是技術層面。本篇就從專案關注度與活躍度，專案的技術架構，原始碼的規模與質量，這三個方面來比較一下 Superset，Redash 與 Metabase。

關注度與活躍度

看一個專案在 Github 上的星數，是評判一個專案成熟度最快速的方法。那除了星數以外，專案的 Github 頁面上還有什麼重要資訊呢？這裡我建議大家去看一看專案的 Insights。首先我們來看 Superset 最近一個月的活躍度

Superset Contributors

這張圖告訴我們以下幾個資訊

  • 這個專案最近一個月有 53 個提交，說明專案仍在積極開發中。圖中顯示專案在最近一個月有新增 21 萬行程式碼，這主要是因為提交了一個巨大的地理資料檔案，去掉這個檔案之後，實際新增的程式碼行數大約為 2000 行。
  • 從新增和處理的 Issue 與 PR 來看，專案的社群很活躍，專案開發者也在積極解決問題。 從短期指標來看，專案的活躍度很健康，開發者也在積極與社群互動。

Superset Contributors

專案的開發很平穩，最近一年的提交數量與之前相比維持在一個穩定的水平。但 Superset 有一個潛在風險就是近半年來幾乎所有的提交都來自同一個開發者。對於如此規模的專案來說，這不是一件好事。首先，隨著受關注度的提高，單個人的輸出可能無法滿足社群裡的各種需求，專案的迭代速度會因些受到影響。其次，專案可能會因為主力開發者的個人因素遭巨大影響，例如他對專案的熱情減退，或是因為工作原因無法繼續投入等等。所以理想情況是能有兩個或以上的主力開發者。

我們可以用類似的方法分析 Redash 與 Metabase 這兩個專案，三個專案的總體情況在下表中

Git Activity

從中可以發現，雖然 Superset 在 Github 上的星數遙遙領先其他兩個專案，但從迭代速度與開發者數量上來說是落後的。

Redash 在之前的三年時間裡一直只有一個主力開發者，但在 2017.10 之後有另一個主力開發者加入。總體來說，Superset 與 Redash 仍是個人秀，只有 Metabase 背後有一個團隊在支撐。從產品的完成度與更新速度上看，Metabase 也是三個專案中最好的。

技術架構

這裡說的技術架構包括開發用的語言，核心框架，以及所用到的第三方元件等。目前，我看開源專案的技術架構，主要考查以下幾個方面

  1. 該專案使用技術棧，自己的團隊是否熟悉？
  2. 當前的技術架構是否會阻礙專案今後的發展？
  3. 該專案在生產環境中部署是否有難度？
  4. 是否有完整的對接介面？

1），2），3）的重要性是顯而易見的，這裡對 4）做一個補充說明。這裡的對外介面，一般就是指 RESTful API。為什麼這很重要呢？首先，如果一個專案有出色 RESTful API，它就很容易與其它系統對接。並且可以在不改動原始碼的前提下，做很多的二次開發。其次，雖然在介面上操作很直觀，但要做大量重複勞動時，寫指令碼呼叫 API 來完成操作會更高效。例如，公司的報表有很多是類似，用 API 來建立這些報表可以避免介面上的重複操作，減少錯誤。

Superset 的技術架構

接下來我們就從上述 4 個方面對 Superset 做一個技術分析。

Superset 的後端用 Python 開發，主要用到的開源元件包括
- Flask App Builder（簡稱 FAB） - SQLAlchemy

我當前團隊的主力語言是 Python，所以這是一個加分項。SQLAlchemy 是非常成熟的資料庫 ORM 解決方案，也沒毛病。但問題出在了 FAB 上。注意，不要把這個開源元件與 Flask 混為一談，FAB 是構架在 Flask 之上的一個應用開發框架，可以根據資料庫的表結構，自動生成增刪查改的前端介面，功能上類似 Django Admin。

FAB 在初期可能可以為 Superset 的開發節省一些寫前端程式碼的時間，但從中長期來說，它嚴重限制了 Superset 介面的靈活性。在上篇文章中，我就吐槽過 Superset 裡 Dasbhoard 的管理不方便，許可權系統複雜，其實就是受制於 FAB。另外，FAB 本身已處於半死狀態，從 Github 上的記錄看，從 2016 後就沒什麼更新了。

在我看來，Superset 的開發者在選 FAB 做為核心框架時是有欠考慮的。在選框架時，我覺得應該為自己選擇一組稱手的工具，而不是一件半成品。好的工具可以至始至終為你提升開發效率。而半成品雖然在初期能讓你快速搭出一個 MVP，但長遠來看一定會擋你的路。FAB 就屬於後者。如果做簡單的管理系統或是開發原型，FAB 是不錯的選擇。但 Superset 的目標是成為一個優秀的開源商業分析平臺，FAB 註定會成為絆腳石。

在前端，Superset 藉助 FAB 來生成大部分管理介面，而圖表或是 SQL 編輯器等對互動性要求很高的介面，則由 React + Redux 來實現。這種混合的模式讓前端程式碼顯得有些亂，說到底還是 FAB 留下的禍根。

Superset 的部署還是很簡單的。Web 伺服器是一個標準的 WSGI 應用，儲存層支援用任意的 SQL 資料庫（只需 SQLAlchemy 支援），所以部署方面無論是高可用還是水平擴充套件都很方便。

至於 API 介面方面，FAB 原生支援 RESTful API，可以對大部分物件做 CRUD 操作。但認證方式不夠靈活，只能通過 cookie，這對於指令碼或是伺服器端呼叫不太友好，所以我們對 Superset 做的第一個擴充套件就是添加了 API Token 的認證方式。

Redash 的技術架構

Redash 的伺服器端同樣是用 Python 來寫的，Web 框架以 Flask 為基礎，並充分利用了 Flask 的外掛生態圈，主要用了以下的元件
- API 框架：Flask-RESTful - 資料庫：Flask-SQLAlchemy - 認證：Flask-Login

個人覺得 Redash 的選擇比 Superset 更明智，選用的都是典型的工具型元件，不會對專案將來的發展產生限制。並且以上列出的三個開源元件都是很成熟的專案，在 Python 社群中被廣泛應用。

Redash 的前端是一個純的單頁應用，用 AngularJS（1.5）實現，結構清晰，程式碼整潔。但眾所周知，AngularJS 在 v2 之後做了巨大的架構調整，所以 AngularJS v1的處境就有些尷尬。這和目前 Python 2 的處境類似。短期內不會有問題，長期來講是個隱患。

在部署上，Redash 除了 SQL 資料庫外，還依賴於 Redis，但 Redis 只用來儲存查詢鎖（防止多個相同查詢同時進行），不需要做持久化。總體上說，Redash 的部署也比較簡單。另外，Redash 直接提供了 AWS 上的映象，以及開發環境的 docker-compose 配置，無論是對運維人員還是開發人員都蠻貼心的。

Redash 也提供了完整的 RESTful API 介面，它前端的單頁應用就是通過這套 API 與後端通訊的，所以理論上在前端介面上做的任何事，都可以用 API 來完成。它的 API 原生支援 API Token 的認證方式。

總體而言，Redash 在技術架構上做得比 Superset 更出色。

Metabase 的技術架構

Metabase 的後端是用 Clojure 寫的，前端是用 React + Redux 寫的單頁應用。

由於我對 Clojure 幾乎一無所知，所以後端架構方面也就不好做什麼評價了。React + Redux 是目前最流行的前端開發框架之一，Metabase 的系統切分與模組化做得非常出色，所以在前端架構方面 Metabase 我給滿分。

Metabase 是三個專案中唯一提供完整 API 文件的專案，這使得開發者即使完全不會 Clojure，依然可以憑藉豐富的 API 與文件完成許多二次開發。

部署方面，Metabase 提供了 Jar 檔案，Mac 應用程式，Docker 映象等方式可以讓使用者在本地快速嘗試該專案。而在生產環境中，它提供瞭如何在 AWS、Heroku、Kubernetes 上部署的詳盡文件，可謂體貼入微。

原始碼的規模與質量

以下是截至 2017 年 1 月 21 日，三個專案的原始碼的行數與測試程式碼行數。

Source code stats

從原始碼規模來看，Metabase 的規模明顯大於另兩個專案，這一方面說明 Metabase 的功能更豐富。另一方面，龐大的程式碼庫會使閱讀原始碼與二次開發的難度更大。Superset 的規模略大於 Redash，這也與兩個專案的定位相符。

原始碼的質量可以做定量與定性的分析，功能程式碼與測試程式碼的行數比可以做為一個重要的定量指標，這方面 Metabase 遙遙領先於另兩個專案。Superset 與 Redash 做得也還不錯，基本處於相同的水平。除此之外，定量分析也可以看單元測試的覆蓋率，以及一些靜態程式碼分析工具的結果，這裡就不贅述了。

定性的分析則是通過閱讀原始碼，對程式碼的邏輯條理與可讀性做一個主觀評估。在這方面，我的主觀評價是 Metabase 的程式碼品質最高，不僅整體程式碼結構清晰，模組切分合理，而且程式碼整潔度到了一個相當變態的水準，看起來賞心悅目。Redash 的程式碼結構也很乾淨，可以排第二，Superset 稍略一籌排在末位。這個結果與定量分析的結論是基本一致。

小結

本文以 Superset，Redash，Metabase 三個專案的比較為例，介紹了開源專案選擇上的一些原則。在本文的開頭，我提到如果重新選擇一個數據視覺化工具，我會選擇 Redash。這主要是因為 Redash 本身擁有合理的技術架構，而 Python 也恰好是團隊最熟悉的語言。

當然，不得不提，對 Metabase 這個專案越是深入瞭解，越覺得它背後一定有非常出色的團隊。這個產品從裡到外，處處滲透一種追求卓越的品質感，希望它能獲得更多的關注與更大的成功！

今天分享就到這裡，歡迎大家留言討論！