Metabase 使用指南

一. 爲什麼從 ELK 遷移到 Metabase + OLAP

1.1 ELK 的問題

擴展性不強：Kibana 只能應用在 ElasticSearch 上
管理不便：在阿里雲等平臺，一個 ElasticSearch 集羣對應一個 Kibana，難以統一管理
開發成本：無法將圖表嵌入到其他應用中，需要二次開發圖形展示
性能一般：ElasticSearch 擅長全文搜索，在數據分析功能上的性能不如 OLAP 數據庫，並且存在一些限制，例如去重的精度不足，上限只有40000（默認準確度保證僅有3000）
運維成本：拋開搜索優化，仍需要維護好一套索引生命週期管理、索引模板，以及應對字段變更時的 reindex。此外，相同數據量下，Elastic 的壓縮比不如列式數據庫，內存佔用也更高，相應的成本也要高出不少。

1.2 Metabase + 其他DB 的優勢

擴展性： JDBC + Clojure multi-method 實現 Driver 擴展，即使開發新 Driver 的成本也不高。
統一入口： 使用相同後端存儲的 Metabase 可以同時管理多個不同的 DB
開發成本： 在 Metabase 開發的 Dashboard 可以直接嵌套到其他前端應用，並且維護有 JWT 認證。其他人員開發的 Question、Model、Metric 可以相互引用。

至於性能和運維成本，則由所選擇的後端 DB 所決定。Metabase 本身不需要進行多複雜的維護，單個 DB 故障並不會引起 Metabase 崩潰。

二. 提問

2.1 數據源

數據源有三種

Raw Data，即源數據，任一數據庫表都是源數據。可以直接點開任一 raw 表以表格方式查看數據。
Question，問題，已存儲的問題也可以成爲數據源，例如這樣一個問題：查詢過去一年內每天不同來源的消息量，我們可以基於這個問題構建一個過去6個月每週的消息量問題。
Model，模型，可以由 Question 或 SQL 提問後轉化，Model 某種程度上是一種物化視圖，物化不存儲數據，通常不直接用來可視化。例如有個人信息和訂單兩張實體表，可以把用戶名和用戶常買的物品、購買時間等組合爲一個新的模型。

2.2 構建問題

2.2.1 組成部分

Data 部分即前面的數據源

可以選擇需要的列，在查詢數據時減少干擾，提升速度。
可以 JOIN 三種數據源，但必須在同一個數據庫，當然，也要是同一種數據庫。也有例外，ClickHouse 可以使用 MySQL、Postgres、MongoDB 等外表。在 Metabase 上展示爲同一種數據庫，但實際類型不同。 JOIN 的不同模式（LEFT JOIN、RIGHT JOIN）可以點擊圖標切換。
Custom Column 類似於數據庫函數的接口抽象，不是所有驅動都支持該實現。一般用在統計階段。

（可選）Filter 部分即過濾器，選擇合適的 Filter 可以提速，也可以排除無關的結果。在數據表格預覽時可以直接在列上方過濾數據，例如這裏只看有折扣的客單價：

（可選）Summarize 部分即統計相關，需要結合分組操作。常用的例如 sum、count，如果需要構建更復雜的計算，可以使用 Custom Column，包含其他的數學函數和字符串函數，未必所有函數都可用

（可選）Sort 和 Limit 即排序和返回數量，排序在圖表上的展示區別不大，最好限制返回的數量（默認 10000）特別是在源表上。

2.2.2 調試 Question

每個階段都可以點擊小三角形預覽數據

在最終結果無法展示時，可以逐個階段預覽調試
在 JOIN 數據時，可以檢查是否 JOIN 模式存在錯誤，導致結果缺少或者重複

如果仍然無法解決問題，可以點擊右邊的 SQL 語句按鈕，由開發同學協助調試。

2.3 使用 SQL 構建問題

用 SQL 構建問題除了可以自由選擇函數外，也可以使用變量作爲過濾器。

使用變量的兩個關鍵語法是 {{variable}} 和 [[{{variable}}]] ，第一個爲一般變量，第二個爲可選變量，使用變量時不需要使用 where table.a = {{variable}} 方式，直接用 where = {{variable}} 使用可選變量時，不需要用 AND 連接。

有點繞？
看看例子：這是一個統計不同 HTTP 方法的 SQL，將 create_time 和 method 作爲過濾器，其中 create_time 是可選變量。

SELECT `inner_api_log`.`method` AS `method`, 
toDate(`inner_api_log`.`create_time`) AS `create_time`, count(*) AS `count`
FROM `inner_api_log` where {{method}} [[{{create_time}}]]
GROUP BY `inner_api_log`.`method`, toDate(`inner_api_log`.`create_time`)
ORDER BY `inner_api_log`.`method` ASC, toDate(`inner_api_log`.`create_time`) ASC

過濾器可以進一步設置，例如作爲下拉框（需要映射原始表，且差異值有限）或者作爲搜索框等等。

要進一步分析，將 SQL 保存的問題作爲數據源再次引用即可。
使用變量的 SQL 不可作爲 Model 使用

2.4 選擇可視化圖表

點擊可視化圖形選擇面板選擇可用的圖表，部分圖表未必適合當前數據，可能點擊後仍不可用。

2.5 設置圖表

2.5.1 通用設置

點擊 Question 顯示通用菜單，可以添加描述、添加到 Dashboard、移動或歸檔等。
左下角的 History 按鈕可以查看版本歷史，每次保存或者回滾均會產生一條版本記錄。

2.5.2 折線、柱狀圖

Data：即數據源，用來選擇展示的數據。數據旁邊的設置按鈕，可以用來格式化數據，例如數字的展示可以設置小數點，或者表示爲貨幣，日期的格式等等
Display：即展示效果，例如設置數據的顏色，設置目標線
Axes：刻度，用來設置數據的呈現方式，例如大小分佈很不均勻的數據（通常數據中的最大數字比最小數字大數百甚至數千倍）可以使用對數刻度（Log）或者冪次刻度（Power），遺憾的是，Metabase 不能選擇對數的底數大小。

下圖是分佈不均的典型案例，由於某種數據暴漲，掩蓋了其他數據的趨勢展示，改爲對數刻度就可以很好地展示：

Labels：標籤，或稱圖例標籤（Legend Label），可以添加備註
可視化界面（右側）：除了點擊圖例篩選、鼠標懸停查看具體值之外，還可以點擊圖形上的點，彈出的窗口可以做進一步值的篩選、或者分組操作。例如原問題是按 Category 分組，這裏可以進一步按時間查看趨勢

當 X 軸爲時間軸，鼠標可以選中區間查看對應時間範圍的數據分佈。

2.5.3 表格

左側設置面板：

Columns：列屬性，點擊設置按鈕設置列名，對於數值類型，支持以迷你條形圖方式展示，對於時間類型，支持格式化時間。

Conditional Formating：即條件格式化。可以對滿足條件的值高亮顯示，高亮支持單色或顏色範圍展示

右側展示面板

點擊列名彈出快速操作，可以進行排序、過濾、或進一步統計
點擊具體值彈出快速篩選窗口
右下角支持下載源數據到本地（JSON、Excel 或 CSV）如設置提醒，則會定時接收到該表格的郵件。

三. Dashboard 管理

3.1 編輯 Dashboard

右上角三個按鈕分別可以添加已保存的問題、添加文本（Markdown）和添加過濾器
鼠標懸停在任一組件上，可以移動位置，組件右下角可以拖動改變大小
非編輯模式，點擊任一問題標題，進入到相應問題詳情

對於地圖類型，支持設置默認展示區域

Tips: 默認提供了世界地圖和美國地圖，如果不能滿足你，可以在 AdminSetting 添加其他 Geojson 格式的地圖。

3.2 過濾器

過濾器支持幾種不同類型

添加過濾器後會固定在 Dashboard 上方，不隨頁面移動（Binding Top），拖動過濾器改變位置

設置聯動的圖表
點擊要設置的過濾器，然後在圖表上選擇聯動的列，選擇過濾條件就會聯動設置的圖表。如下圖所示，過去 30 天的過濾條件會應用在四個圖表上。
（可選）設置默認的過濾選項、過濾器名稱

聯動過濾器，一般用在多級分組上，例如省-市等多級分類，選擇大一級分類會影響子分類選項。

3.3 可視化

如果修改圖表的標題、微調展示的顏色等操作，需要回到問題頁修改再保存，會使操作變得繁瑣，並增加不必要的新問題。

Dashboard 編輯模式下，支持在不修改圖表展示類型的情況下，修改該類型圖表幾乎所有參數，例如下圖所示，僅數據源不支持修改。

點擊 reset to default 會恢復到原問題的設置。

3.4 疊加圖表

在需要橫向對比的場景，有時因爲條件難以用單個 SQL 表達。

可以考慮下面的方式：

分別創建若干個問題。如果需要永久保存，可以再添加一個問題，JOIN 幾個問題實現圖表疊加。如果需要合併，查看 SQL 再轉化爲新的問題即可。

若不需要，在 Dashboard 編輯模式下，添加 Add Series，搜索已保存的問題，如果問題存在感嘆號，則可能不兼容當前的圖表。疊加的圖表同樣支持在編輯模式下分別設置圖表。

3.5 點擊行爲

跳轉到自定義鏈接：用來鏈接到外部的同一網址，或者跳轉到帶參數的指定詳情頁等。也可以跳轉到指定的 Dashboard 或者問題頁。

例如，在地圖圖表上添加搜索關鍵詞，點擊跳轉到 Google 搜索頁：

聯動頁面過濾器：下拉過濾器可能不夠直觀，下面的地圖例子，當點擊對應州的圖形時，會同步改變州（State）過濾器，其他引用的圖表就會一起更新。

四. 管理數據

4.1 管理數據源

添加數據源時，管理員需要做好以下操作

限制數據源權限，設置好組員的查看和編輯權
隱藏不必要的數據，例如ClickHouse 的 Kafka Engine 表、導入詳情表的物化表等對數據分析人員沒有意義。
一些數據列只提供給開發人員調試，對其他人員沒有意義的，同樣也要隱藏。或者某些列不適合統計，聚合可能導致崩潰。
更改列屬性，Metabase 有時存在列的屬性推斷錯誤，例如某些列我們希望它有下拉過濾，但被推斷爲其他類型，可以手動修改，再重新掃描該列。

4.2 創建模型（Model）

同樣是由表延展的數據，模型具有一定實體意義，通常不直接用來可視化，而是作爲源數據，方便複用。

模型擁有和源數據一樣豐富的列屬性設置，這裏不再贅述。