導讀

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

這是相關的第二篇，第一篇見 DataEase 設計理念淺析，後續計劃還會有 Superset 和 Redash 的文章。

正文

核心還是探究 2 個問題： 1. 如何解決圖表屬性配置問題？ 2. 如何解決不同資料來源統一的問題？

Metabase 簡介

Metabase is a deep product with a lot of tools to simplify business intelligence, from embeddable charts and interactive dashboards, to GUI and SQL editors, to auditing and data sandboxing, and more.

這是其 官網文件 給的定義。看一下效果圖

可以觀看 demo 來快速瞭解其操作。特別值得一提的是它首頁的 slogan：

Have questions about your data? Metabase has answers.

Meet the easy, open source way for everyone in your company to ask questions and learn from data.

注意關鍵字 question，整個產品都圍繞這個詞在設計。單從這點，就可以看出整個產品是想以普通非技術人員的視角來設計，這無疑是很有趣，很有啟發性的。具體怎麼設計的，我們接著看。

Question

互動操作

如下圖一個 Question 由 Data、Join data、Filter、Custom column、Summarize（by） 幾部分構成，我們分別來看一下。

• Data 就是選表，必選，選擇已連線的資料庫中的表；
• Join data 可以理解為 SQL 的 join，就是把兩張表用各自的某個欄位關聯起來；
• Filter 就是過濾，對前兩步選出的資料進行篩選，如 total > 1000 這種，其本質是利用了 Metabase 提供的公式（expressions）功能，只是為常用邏輯提供了視覺化方式的配置；
• Custom column 就是自定義列。利用 Metabase 提供的公式（expressions）功能生成計算出來的新列，使用起來跟 Excel 的函式功能一樣；
• Summarize 就是統計規則，是生成圖表的核心功能，比較複雜，我們單獨列出來講。

Summarize

分成 Pick the metric（以下簡稱 Metric） 和 Pick a column to group by（以下簡稱 Group） 兩步。先說 Metric。點選按鈕之後，會彈出內建的統計方法列表和自定義公式。內建方法包括：Count of rows、Sum of、Average of 等，選擇之後會根據方法的不同，列出可選擇的欄位。比如選了 Sum of，就只能選擇數值型別的欄位；選擇了 Count of rows，就不需要再選欄位；選擇了 Number of distinct values of，就可以選擇所有型別的欄位。可以新增多個 Metric。

然後再說 Group，這個操作就比較簡單了，可以選擇所有欄位，也可以新增多個。這裡提一個讓筆者比較小驚喜的互動的設計，對於 Date and Time 類的欄位，可以選則按照什麼維度彙總，如下圖展示的按月，按季度等。另外數值型別、經緯度也有統計範圍的選擇。

解析

互動說完了，但是怎麼理解這波操作呢？Metric 和 Group 對應了圖表裡的什麼呢？

看了 DataEase 設計理念淺析 這篇文章的同學可能好理解一些，Metric 與 Group 分別對應了 DataEase 中指標和維度的概念。雖然 Metabase 沒有明確的提出這兩個概念，而是儘量以自然語言的形式來引導使用者。這麼做對於簡單圖表是非常容易理解的，比如只有兩個維度的普通折線圖、柱狀圖。但是，當我們想使用稍微複雜一點的圖表時，還是需要理解這兩個概念。比如我們對 demo 影片中的例子做一下改動，想生成一個散點圖，要求如下： 1. 橫軸是日期，按季度統計； 2. 縱軸是銷售的產品數量； 3. 氣泡大小表示銷售產品的總金額； 資料部分需要這樣配置： 進入檢視設定頁面，預設是折線圖，當我們選擇散點圖時，有三個圖表屬性需要我們選擇，而且初始值都是空的。這時候我們就需要手動配置了。配置後如下圖：

細心的同學可能發現了，Bubble size 和 Y-axis 只能選擇 Metric 配的兩個欄位，而 X-axis 能選擇所有的三個欄位。對比一下，如果放在 DataEase 裡，X-axis 應該就只能選擇 Group 中的欄位。

那麼很明顯了，Metabase 的圖表中，每個圖表屬性也是具有限制的，有的只可以選擇 Metric，有的只可以選擇 Group，有的都可以選，這個思路與 DataEase 基本是一致的。只是它們的互動實在是差的很大，讓我們很難第一眼就發現這個相同點。

第 1 個問題解析完了，來看第 2 個問題。

Data Model

Metabase 利用 Data Model 這個抽象解決了不同資料來源統一的問題。當成功連結資料來源後，就會根據所連資料庫的表生成 Data Model（以下簡稱 Model），比如 demo 中的 Model 如下：

可以看到，左側的列表實際上就是匯入的資料庫的表，關鍵看右側的 Type 列。這意味著你是可以修改某列的資料格式的，粗略數了一下，有 10 個大類，50 多個小類，單從數量來看，比起 DataEase 的 5 個左右，可謂十分細緻了。比如 DATE AND TIME 大類下分了 Cancelation data、Cancelation time、Cancelation timestamp、Join date 等 15 個小類。

在 DataEase 設計理念淺析 一文中已經對這種設計有了說明，這裡就不再贅述了。而且聰明的同學看到這裡，應該已經抓到其核心理念了。

總結

開頭提出的兩個關鍵問題，Metabase 分別用 Data Model 和 Metric/Group 的抽象解決了。值得一提的是，整個產品到處都能夠體現一個理念：要對非開發者友好。

比如 Question 的設計，就很符合一般人（非開發）的思維習慣。

還有 Data Model Type 的設計，為了做到讓非開發者使用方便，愣是擴充出了 50 多個情景化、語義化的小分類（雖然底層其實就是那幾個資料型別而已）。

這些設計是否合理，筆者沒有資格評論，但是這種設計的目的筆者是看到了。話說回來，作為技術人員，筆者還是會更關注其抽象，也就是 Data Model 和 Metric/Group 的部分。這塊的設計思路和 DataEase 還是很像的，起碼從筆者目前探究的深度來看，是看不出多大區別的。

可惜的是 Metabase 的資料來源沒有提供外部 API 的接入。筆者認為 API 接入是一個能相容任何場景的接入方式，只是實現起來還是需要接入方進行一定的開發，不過畢竟能夠兜住全部的底。

“完美不在於無以復加，而在於無可刪減，萬事莫不如此。”—— Antoine de St.Exupery