數據可視化的開源方案: Superset vs Redash vs Metabase (二)

03-27

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

關注度與活躍度

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

這張圖告訴我們以下幾個信息

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

接著我們來看項目的長期指標，提交歷史與貢獻者的分布

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

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

項目星數上月提交數量上月PR主力開發者

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

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

技術架構

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

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

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 日，三個項目的源代碼的行數與測試代碼行數。

項目前端代碼行數/測試行數後端代碼行數/測試行數

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

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

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

小結

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

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

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

-----------------

歡迎關注我的微信公眾號：yecomment