一. 為什么從 ELK 遷移到 Metabase + OLAP
1.1 ELK 的問題
- 擴展性不強：Kibana 只能應用在 ElasticSearch 上
- 管理不便：在阿里云等平臺，一個 ElasticSearch 集群對應一個 Kibana，難以統(tǒng)一管理
- 開發(fā)成本：無法將圖表嵌入到其他應用中，需要二次開發(fā)圖形展示
- 性能一般：ElasticSearch 擅長全文搜索，在數(shù)據(jù)分析功能上的性能不如 OLAP 數(shù)據(jù)庫，并且存在一些限制，例如去重的精度不足，上限只有40000（默認準確度保證僅有3000）
- 運維成本：拋開搜索優(yōu)化，仍需要維護好一套索引生命周期管理、索引模板，以及應對字段變更時的 reindex。此外，相同數(shù)據(jù)量下，Elastic 的壓縮比不如列式數(shù)據(jù)庫，內(nèi)存占用也更高，相應的成本也要高出不少。
1.2 Metabase + 其他DB 的優(yōu)勢
- 擴展性： JDBC + Clojure multi-method 實現(xiàn) Driver 擴展，即使開發(fā)新 Driver 的成本也不高。
- 統(tǒng)一入口： 使用相同后端存儲的 Metabase 可以同時管理多個不同的 DB
- 開發(fā)成本： 在 Metabase 開發(fā)的 Dashboard 可以直接嵌套到其他前端應用，并且維護有 JWT 認證。其他人員開發(fā)的 Question、Model、Metric 可以相互引用。
至于性能和運維成本，則由所選擇的后端 DB 所決定。Metabase 本身不需要進行多復雜的維護，單個 DB 故障并不會引起 Metabase 崩潰。
二. 提問
2.1 數(shù)據(jù)源
數(shù)據(jù)源有三種
-
Raw Data，即源數(shù)據(jù)，任一數(shù)據(jù)庫表都是源數(shù)據(jù)?？梢灾苯狱c開任一 raw 表以表格方式查看數(shù)據(jù)。
示例訂單數(shù)據(jù) Question，問題，已存儲的問題也可以成為數(shù)據(jù)源，例如這樣一個問題：查詢過去一年內(nèi)每天不同來源的消息量，我們可以基于這個問題構(gòu)建一個過去6個月每周的消息量問題。
Model，模型，可以由 Question 或 SQL 提問后轉(zhuǎn)化，Model 某種程度上是一種物化視圖，物化不存儲數(shù)據(jù)，通常不直接用來可視化。例如有個人信息和訂單兩張實體表，可以把用戶名和用戶常買的物品、購買時間等組合為一個新的模型。
2.2 構(gòu)建問題
2.2.1 組成部分
- Data 部分即前面的數(shù)據(jù)源
- 可以選擇需要的列，在查詢數(shù)據(jù)時減少干擾，提升速度。
- 可以 JOIN 三種數(shù)據(jù)源，但必須在同一個數(shù)據(jù)庫，當然，也要是同一種數(shù)據(jù)庫。也有例外，ClickHouse 可以使用 MySQL、Postgres、MongoDB 等外表。在 Metabase 上展示為同一種數(shù)據(jù)庫，但實際類型不同。 JOIN 的不同模式（
LEFT JOIN、RIGHT JOIN）可以點擊圖標切換。 - Custom Column 類似于數(shù)據(jù)庫函數(shù)的接口抽象，不是所有驅(qū)動都支持該實現(xiàn)。一般用在統(tǒng)計階段。
- （可選）Filter 部分即過濾器，選擇合適的 Filter 可以提速，也可以排除無關(guān)的結(jié)果。在數(shù)據(jù)表格預覽時可以直接在列上方過濾數(shù)據(jù)，例如這里只看有折扣的客單價：
過濾數(shù)據(jù)
- （可選）Summarize 部分即統(tǒng)計相關(guān)，需要結(jié)合分組操作。常用的例如 sum、count，如果需要構(gòu)建更復雜的計算，可以使用 Custom Column，包含其他的數(shù)學函數(shù)和字符串函數(shù)，未必所有函數(shù)都可用
- （可選）Sort 和 Limit 即 排序和返回數(shù)量，排序在圖表上的展示區(qū)別不大，最好限制返回的數(shù)量（默認 10000）特別是在源表上。
2.2.2 調(diào)試 Question
每個階段都可以點擊小三角形預覽數(shù)據(jù)
- 在最終結(jié)果無法展示時，可以逐個階段預覽調(diào)試
- 在 JOIN 數(shù)據(jù)時，可以檢查是否 JOIN 模式存在錯誤，導致結(jié)果缺少或者重復
如果仍然無法解決問題，可以點擊右邊的 SQL 語句按鈕，由開發(fā)同學協(xié)助調(diào)試。
2.3 使用 SQL 構(gòu)建問題
用 SQL 構(gòu)建問題除了可以自由選擇函數(shù)外，也可以使用變量作為過濾器。
使用變量的兩個關(guān)鍵語法是 {{variable}} 和 [[{{variable}}]] ，第一個為一般變量，第二個為可選變量，使用變量時不需要使用 where table.a = {{variable}} 方式，直接用 where = {{variable}} 使用可選變量時，不需要用 AND 連接。
有點繞？
看看例子：這是一個統(tǒng)計不同 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 保存的問題作為數(shù)據(jù)源再次引用即可。
- 使用變量的 SQL 不可作為 Model 使用
2.4 選擇可視化圖表
點擊可視化圖形選擇面板選擇可用的圖表，部分圖表未必適合當前數(shù)據(jù)，可能點擊后仍不可用。
2.5 設置圖表
2.5.1 通用設置
點擊 Question 顯示通用菜單，可以添加描述、添加到 Dashboard、移動或歸檔等。
左下角的 History 按鈕可以查看版本歷史，每次保存或者回滾均會產(chǎn)生一條版本記錄。
2.5.2 折線、柱狀圖
- Data：即數(shù)據(jù)源，用來選擇展示的數(shù)據(jù)。數(shù)據(jù)旁邊的設置按鈕，可以用來格式化數(shù)據(jù)，例如數(shù)字的展示可以設置小數(shù)點，或者表示為貨幣，日期的格式等等
- Display：即展示效果，例如設置數(shù)據(jù)的顏色，設置目標線
- Axes：刻度，用來設置數(shù)據(jù)的呈現(xiàn)方式，例如大小分布很不均勻的數(shù)據(jù)（通常數(shù)據(jù)中的最大數(shù)字比最小數(shù)字大數(shù)百甚至數(shù)千倍）可以使用對數(shù)刻度（Log）或者冪次刻度（Power），遺憾的是，Metabase 不能選擇對數(shù)的底數(shù)大小。
下圖是分布不均的典型案例，由于某種數(shù)據(jù)暴漲，掩蓋了其他數(shù)據(jù)的趨勢展示，改為對數(shù)刻度就可以很好地展示：
Labels：標簽，或稱圖例標簽（Legend Label），可以添加備注
可視化界面（右側(cè)）：除了點擊圖例篩選、鼠標懸停查看具體值之外，還可以點擊圖形上的點，彈出的窗口可以做進一步值的篩選、或者分組操作。例如原問題是按 Category 分組，這里可以進一步按時間查看趨勢
當 X 軸為時間軸，鼠標可以選中區(qū)間查看對應時間范圍的數(shù)據(jù)分布。
2.5.3 表格
左側(cè)設置面板：
- Columns：列屬性，點擊設置按鈕設置列名，對于數(shù)值類型，支持以迷你條形圖方式展示，對于時間類型，支持格式化時間。
- Conditional Formating：即條件格式化。可以對滿足條件的值高亮顯示，高亮支持單色或顏色范圍展示
右側(cè)展示面板
-
點擊列名彈出快速操作，可以進行排序、過濾、或進一步統(tǒng)計
快速操作表格 - 點擊具體值彈出快速篩選窗口
- 右下角支持下載源數(shù)據(jù)到本地（JSON、Excel 或 CSV）如設置提醒，則會定時接收到該表格的郵件。
三. Dashboard 管理
3.1 編輯 Dashboard
- 右上角三個按鈕分別可以添加已保存的問題、添加文本（Markdown）和添加過濾器
- 鼠標懸停在任一組件上，可以移動位置，組件右下角可以拖動改變大小
- 非編輯模式，點擊任一問題標題，進入到相應問題詳情
- 對于地圖類型，支持設置默認展示區(qū)域
Tips: 默認提供了世界地圖和美國地圖，如果不能滿足你，可以在 AdminSetting 添加其他 Geojson 格式的地圖。
3.2 過濾器
過濾器支持幾種不同類型
添加過濾器后會固定在 Dashboard 上方，不隨頁面移動（Binding Top），拖動過濾器改變位置
-
設置聯(lián)動的圖表
點擊要設置的過濾器，然后在圖表上選擇聯(lián)動的列，選擇過濾條件就會聯(lián)動設置的圖表。如下圖所示，過去 30 天的過濾條件會應用在四個圖表上。 - （可選）設置默認的過濾選項、過濾器名稱
- 聯(lián)動過濾器，一般用在多級分組上，例如省-市等多級分類，選擇大一級分類會影響子分類選項。
3.3 可視化
如果修改圖表的標題、微調(diào)展示的顏色等操作，需要回到問題頁修改再保存，會使操作變得繁瑣，并增加不必要的新問題。
Dashboard 編輯模式下，支持在不修改圖表展示類型的情況下，修改該類型圖表幾乎所有參數(shù)，例如下圖所示，僅數(shù)據(jù)源不支持修改。
點擊 reset to default 會恢復到原問題的設置。
3.4 疊加圖表
在需要橫向?qū)Ρ鹊膱鼍埃袝r因為條件難以用單個 SQL 表達。
可以考慮下面的方式：
- 分別創(chuàng)建若干個問題。如果需要永久保存，可以再添加一個問題，JOIN 幾個問題實現(xiàn)圖表疊加。如果需要合并，查看 SQL 再轉(zhuǎn)化為新的問題即可。
- 若不需要，在 Dashboard 編輯模式下，添加 Add Series，搜索已保存的問題，如果問題存在感嘆號，則可能不兼容當前的圖表。疊加的圖表同樣支持在編輯模式下分別設置圖表。
3.5 點擊行為
- 跳轉(zhuǎn)到自定義鏈接：用來鏈接到外部的同一網(wǎng)址，或者跳轉(zhuǎn)到帶參數(shù)的指定詳情頁等。也可以跳轉(zhuǎn)到指定的 Dashboard 或者問題頁。
例如，在地圖圖表上添加搜索關(guān)鍵詞，點擊跳轉(zhuǎn)到 Google 搜索頁：
- 聯(lián)動頁面過濾器：下拉過濾器可能不夠直觀，下面的地圖例子，當點擊對應州的圖形時，會同步改變州（State）過濾器，其他引用的圖表就會一起更新。
四. 管理數(shù)據(jù)
4.1 管理數(shù)據(jù)源
添加數(shù)據(jù)源時，管理員需要做好以下操作
- 限制數(shù)據(jù)源權(quán)限，設置好組員的查看和編輯權(quán)
- 隱藏不必要的數(shù)據(jù)，例如ClickHouse 的 Kafka Engine 表、導入詳情表的物化表等對數(shù)據(jù)分析人員沒有意義。
一些數(shù)據(jù)列只提供給開發(fā)人員調(diào)試，對其他人員沒有意義的，同樣也要隱藏?；蛘?strong>某些列不適合統(tǒng)計，聚合可能導致崩潰。
數(shù)據(jù)可見性.png - 更改列屬性，Metabase 有時存在列的屬性推斷錯誤，例如某些列我們希望它有下拉過濾，但被推斷為其他類型，可以手動修改，再重新掃描該列。
4.2 創(chuàng)建模型（Model）
同樣是由表延展的數(shù)據(jù)，模型具有一定實體意義，通常不直接用來可視化，而是作為源數(shù)據(jù)，方便復用。
模型擁有和源數(shù)據(jù)一樣豐富的列屬性設置，這里不再贅述。
