人是視覺動物，要用資料把一個故事講活，圖表是必不可少的。如果你經常看到做資料分析同事，在SQL客戶端裡執行完查詢，把結果複製/貼上到Excel裡再做成圖表，那說明你的公司缺少一個可靠的資料視覺化平臺。資料視覺化是Business Intelligence(簡稱BI)中的核心功能，有許多成熟的商用解決方案，如老牌的Tableau, Qilk，新生代的Looker，國內的FineBI等等。不過對於許多小公司來說，這些服務的License費用是一筆不小的開銷，且有一種“殺雞用牛刀”的感覺。那在開源軟體如此發達的今天，在資料視覺化方面，有什麼靠譜的方案可以選擇呢？今天給大家介紹三個比較知名的專案，分別是Superset, Redash和Metabase。前兩個我都在產生環境中實際使用過，在本文中會重點介紹。Metabase我只是試玩了一下，但我覺得這是一個非常有想法的專案，所以也會和大家聊聊我對它的看法。

選擇一個稱手的工具，功能上能滿足我的需求肯定是首要的。就先從功能需求講起，我們的資料倉庫用的是Amazon Redshift（如果你沒聽過Redshift，就把它看作是為大資料優化過的PostgreSQL），所以大部分的實際用例都是要將一個SQL查詢的結果視覺化。我們所需的圖表型別也就是常用的那幾種，包括折線圖，柱形圖，餅圖等。有了圖表之後，接下去就是把相關的圖表排版，生成報表頁面（Dashboard）。從資料安全性角度，我不希望每個員工都能自由訪問所有的Dashboard，所以每個Dashboard需要設定不同的訪問級別。另外，我會看重它是否有REST API，能否通過API來建立與管理報表，這部分我們放在以後的文章中再講。

除了滿足功能性需求，易用性與文件在評判一個工具時也是非常重要的。誰不想要一個簡單好用，文件清晰的產品呢？

下面我們就從功能性、易用性與文件等方面，來看看這三個開源專案的實際表現吧

Superset

Superset最初是由Airbnb的資料團隊開源的，目前已進入Apache Incubator，算是明星級的開源專案。老實講，我也是被Airbnb與Apache兩塊金字招牌吸引才入了坑。目前公司絕大部分報表都在Superset上，大大小小有50個Dashboard，包含了近900個圖表。在使用Superset之前我們用的是Looker(很不錯的商用BI工具，可惜太貴)，一年半前把Looker上所有的Dashboard遷移到Superset上，整個過程也很順利。用了一年多，雖然在不少小地方有些不滿意，但總體來說Superset很好地滿足了公司現階段在資料視覺化與業務報表方面的需求。

當你把一個數據庫連線到Superset上以後，你定義你要用的每一張表。Superset裡表的定義不但包括欄位，還需要定義指標（Metric）。指標是對欄位的某種統計結果，比如欄位上值的求和、平均值、最大值、最小值等。是不是有點糊塗了？但請回想一下，BI工具通常是用來做商業分析的。假想一個電商資料庫，雖然在資料表我們儲存每筆訂單的交易額，但在商業分析時上我們不關心單筆交易，我們關心的可能是一個時間段內的總交額，或是平均交易額。當你畫交易月報表時，你不會把每筆交易畫在圖上，而是把每天的總交易額用一個柱形在圖上表示。這就是為什麼Superset要引入“指標”這個概念。

對於資料分析人員來說，由於在Superset上他們不是直接寫SQL，而是通過選擇指標（Metric）, 分組條件（Group）和過濾條件（Filter）來畫圖表，所以在構建複雜查詢時可能會有些不適應。另一個難題是Superset裡的表不支援join，如果一個圖表裡的資料要從多個數據表裡取，那隻能通過建檢視來實現。Superset在0.11版本之後加入SQL Lab功能，支援從SQL查詢結果直接生成圖表。可惜，由於這個功能與Superset的核心設計格格不入，所以實現得比較差，沒什麼實用價值。

客觀地講，Superset裡引入自己的表與指標的概念，在邏輯上是合理的，在統一各種異型的資料來源時也是必要的。但實際操作中仍會讓人覺得有些麻煩，不夠直接了當。

Superset在視覺化方面做得很出色，不但是開源領域中的佼佼者，也把很多商用BI工具甩在身後。在0.20版本中支援的圖表型別已經達到了36種，而且在選擇圖表型別時，你可以看到每一種圖表的縮圖，下面這張截圖大家可以感受一下

Superset的另一個亮點是可以在多個時間維度上觀察，因為商業分析中的很多問題都是與時間密切相關的。Superset有4種專門針對時間序列的圖表，使用這些圖表時，你需要指定一個欄位為時間維度，之後就可以對時間維度做豐富的操作

• 從不同時間粒度去檢視你關心的指標（小時/日/周/月/季度/年）
• 對時間序列做rolling average，比如看一個指標的7日平均線
• 可以對時間序列做偏移，再做對比，比如把本週的銷售業績與上週同期放在一張圖表中對比
• 不在圖表上顯示指標的絕對值，而是顯示它隨著時間變化的增長速度

以上這些都是在資料分析中非常實用的功能。

說完優點，再說說Superset的槽點，最大的槽點是當圖表與報表多了以後，管理不方便。這個問題其實很好解決，只要在圖表和報表管理時，加上分組或是資料夾的概念就可以了，但至今未見類似的功能。現在公司900多個圖表都在一個大列表下，雖然Superset支援Search, Filter或是Favorite，但查詢起來還是太麻煩。

Superset的文件也比較糟糕，雖然在安裝與快速入門方面提供了很完整的文件，但在具體功能的介紹方面文件嚴重缺失。就算有些功能有文件，文件的結構也很混亂，所以大部分功能只能自己去嘗試，好在這個工具本身並不難用，自己去摸索各個功能也不太困難。

Redash

如果說Superset是構建一個BI平臺，那Redash目標就是更純粹地做好資料查詢結果的視覺化。Redash支援很多種資料來源，除了最常用的SQL資料庫，也支援MongoDB, Elasticsearch, Google Spreadsheet甚至是一個JSON檔案。Redash的官方文件裡列出了它所支援的所有資料來源。

它不需要像Superset那樣在建立圖表前先定義表和指標，而是可以非常直觀地將一個SQL查詢的結果視覺化，這使得它上手很簡易。或者說Redash僅僅實現了Superset中SQL Lab的功能，但卻把這個功能做到了極致。

Redash有兩個非常實用的功能，Query Snippet與Query Parameters。

Query Snippet很好地解決了查詢片段的複用問題。做資料報表時經常要用到十分複雜的SQL語句，這些語句是肯定有一些片段是可以在多個Query中複用的。在Redash中我們可以將這些片段定義成Snippet，之後方便地複用。

Query Parameters可以為查詢新增可定製引數，讓這個圖表變得更靈活。比如一個App的日活指標，我可能有時要按iOS/Android切分，有時要按地域切分，或是按新老使用者切分。在Superset的Dashboard上我要做三個表圖。Redash裡我可以把Query的groupby做為一個引數，這樣就可以在一張圖上搞定。用的時候，運營人員可以圖表上方的一個下拉框裡選擇切分的方式，非常直觀好用。

Redash的Dashboard可以通過命名來進行分組，Dashboard的名字可以有一個字首並以冒號結尾，字首相同的Dashboard就會自動被分為一組。例如“Growth: Daily”，“Growth: Weekly”這兩個Dashboard都會被分到“Growth”組下。

相比Superset，Redash在文件方面做得更好，除了快速入門教程以外，每一個功能模組都有文件且條理清晰。

當然Redash也有自己的不足之處，它的視覺化種類比Superset遜色不少（不過其實也夠用了）。另外，由於它只是純粹地把資料查詢結果視覺化，所以也沒有Superset裡那些對時間維度上的聚合與對比的操作。

Metabase

由於我並沒有在生產環境下使用過Metabase，只在自己本本上試用過這個工具。所以我只能說一下對它的第一印象。

剛開始用的就覺得這個工具的介面好漂亮，明顯是經過UI設計師仔細調校過的。相對的，Superset與Redash一看就是程式設計師充當設計師的產物。

用了一會兒之後，我覺得Metabase與Superset雖然都想要打造一個完整的BI平臺，但在理念上是不同的。Metabase非常注重非技術人員（如產品經理、市場運營人員）在使用這個工具時的體驗，讓他們能自由地探索資料，回答自己的問題。而在Superset或是Redash裡，非技術人員基本上只能看預先建好的Dashboard，不懂SQL或是資料庫結構的他們，很難自己去摸索。我非常喜歡Metabase的理念，它更接近一款成熟的商業化產品。當然要把這個理念變為現實是很有挑戰的，目前我不知道在面臨複雜的真實業務環境中，Metabase是否有想像中那樣美好。

另外值得一提的是，Metabase的文件也是三個專案中寫得最好最完整的，內容非常豐富。

將來若是有機會，我很願意更深入地去體驗這個產品。

小結

本文簡單地介紹了三個開源的資料視覺化工具Superset, Redash和Metabase，三者各有所長，我覺得並不存在絕對的最強者。對於剛剛開始搭建BI平臺的公司，我相信它們都可以滿足大部分報表與業務分析的需求。

雖然Superset是我們公司現在主要使用的視覺化工具，但我問過自己“如果現在讓我重新選擇，我會使用哪個開源專案？”我的答案是Redash，而原因主要不是功能層面，而是技術層面。這裡正好可以引出我們下篇要聊的內容，從技術框架與原始碼層面來比較一下這三個專案，以及我選擇開源專案的一些通用原則，敬請期待！