建立模型

為了讓非技術人員能夠輕鬆提出有關資料的問題，您可以做的最有價值的事情是將資料塑造成直覺式提問的形狀。

資料通常可能很混亂，尤其是對於新創公司而言。或者甚至不混亂：它可能是高度正規化的資料，針對交易而非分析進行最佳化。這表示您可能擁有一個資料庫，其中客戶資料分散在大量的表格中，這使得尚不熟悉資料庫的人員難以找到他們正在尋找的資訊（這還假設他們甚至知道聯結的運作方式）。

模型作為建構區塊

為了讓您的團隊更容易理解資料，在 Metabase 中，您可以建立衍生資料集，稱為模型，可以從不同的表格中提取資料。它們建立在 Metabase 問題的結果之上，您可以新增自訂、計算欄，並使用中繼資料註解所有欄，以便使用者可以將查詢產生器中的資料當作起點來進行操作。

如果您已經是經驗豐富的 Metabaser 使用者，您就會知道您可以從已儲存問題的結果中建立新問題。您可以將模型視為一種特殊的已儲存問題類型，但這樣說低估了它們的價值。

為什麼不執行 ETL 工作來在資料庫中建立模型？

Metabase 模型和 ETL 並非互斥。您可以（而且應該）同時利用兩者。並說明原因

1. 模型將資料建模工具交到了解業務領域的人員手中。 這非常重要。是的，資料工程師會更了解資料管道中的管線，但他們不一定了解特定團隊正面臨的問題，以及這些問題的各個部分應如何定義（例如，什麼符合活躍使用者的資格？）。貴組織中的各個團隊應該是定義您業務的人員，他們應該能夠根據團隊的運作方式、新產品供應、市場變化等來調整這些定義。透過模型，使用者不必透過資料團隊來新增新的計算欄或更新定義。而且不同的團隊會有不同的定義：您的銷售團隊對於客戶的模型可能與您的行銷或成功團隊不同。

2. 模型具有彈性。您可以即時建立、修改、切換模型 — 它們基本上只是查詢 + 描述。而且它們是 Metabase 中的一等公民，因此您可以將它們組織到集合中、連結到它們，並選擇它們作為新問題的起點，或將它們新增至儀表板。您也可以封存它們，或將它們改回已儲存問題（但您會遺失中繼資料）。相較之下，ETL 的工作量要大得多，而且通常由了解您的資料管道、知道如何編寫程式碼、排程工作等等的人員來控管。有一些很棒的工具可以協助您撰寫 ETL，但對於需要彈性解決方案的問題而言，它們通常是重量級的解決方案。

3. 模型是改善資料庫效能的墊腳石。在使用 Metabase 中的模型進行實驗之後，您可以將最受歡迎的模型「升級」為資料庫中的實體化檢視表。此處的實體化是指編寫 ETL 工作，以建立並定期更新資料庫中符合您模型的表格（具有相同的欄集），以便每次執行查詢時都不需要計算結果；資料庫可以像從原始資料表格中擷取結果一樣擷取結果。在資料庫中將表格實體化之後，您可以將 Metabase 中模型的原始查詢換成簡單的 SELECT * FROM materialized_model，或者只需刪除模型，並將實體化表格視為資料庫中的任何其他表格。（請注意，如果您變更模型的基本查詢，則需要更新每個欄的中繼資料）。

4. 模型可以為個別記錄建立索引，並使其在 Metabase 的搜尋中可用。 您可以在搜尋中呈現個別記錄，以便您可以查詢個別記錄，例如客戶名稱。

模型範例

在思考要在模型中包含哪些欄時，最好先列出您預期使用者會提出的問題類型，然後將欄新增至模型，以協助回答這些問題。假設我們想要為客戶建模。通常，我們可能想要定義類似活躍客戶的內容，也許是在過去一個月中至少造訪過我們網站一次的使用者，或者我們想要如何定義活躍客戶。但為了簡化起見，我們將使用 Metabase 隨附的範例資料庫來定義基本客戶的模型。我們預期想要了解有關客戶的一些事項

• 他們居住地，包括州和郵遞區號。
• 他們的來源（他們如何得知我們）。
• 他們在我們這裡總共花了多少錢。
• 他們下了多少筆訂單。
• 每筆訂單的平均總額。

在真實模型中，您可能會想要回答更多問題，這將需要更多欄來回答（例如客戶的年齡、他們在網站上花費的時間、新增和從購物車中移除的商品，或您認為團隊想要詢問的所有其他資料點）。模型的想法是擺脫所有將所有這些資料整合在一起的樣板程式碼，以便使用者可以開始操作他們真正感興趣的資料。

這是我們使用查詢產生器建立的問題

對於我們的資料，我們選取了 Orders 表格，將其聯結到 People 表格，摘要了訂單總額的總和、計算了列數，並使用自訂運算式計算了平均訂單總額：= Sum([Total]) / Count。接下來，我們依下列項目分組：User_ID、People.Created_At、State、Zip 和 Source。

我們儲存該問題，按一下問題標題以顯示問題側邊欄（您可能需要重新整理瀏覽器），然後按一下模型圖示（堆疊成三角形的三個建構區塊），將問題變成模型。

將中繼資料新增至模型是關鍵

這是模型的超能力，而且對於使用 SQL 查詢建立的模型特別有用，因為 Metabase 不知道 SQL 查詢傳回的欄類型。

按一下模型名稱將顯示模型側邊欄，讓我們可以選擇自訂中繼資料。在這裡，我們可以為欄提供更友善的名稱、為欄新增描述（將在懸停時顯示），並告知 Metabase 欄包含的資料類型。

如果我們改為使用SQL 查詢來建立相同的客戶模型（請參閱上方的模型範例），Metabase 將無法自動執行其常用的鑽取魔法。

但是，如果我們將一些中繼資料新增至模型的欄（也就是模型定義及其查詢傳回的欄位），我們可以還原鑽取選單和所有其他 Metabase 魔法。

例如，如果這是定義我們模型的查詢

SELECT
    orders.user_id              AS id,
    people.created_at           AS join_date,
    people.state                AS state,
    people.source               AS source,
    Sum(orders.total)           AS total,
    Count(*)                    AS order_count,
    Sum(orders.total)/Count(*)  AS avg_total
FROM orders
LEFT JOIN people
   ON orders.user_id = people.id
GROUP  BY
    id,
    city,
    state,
    zip,
    source

Metabase 不會自動知道 state 或 total 或任何其他欄的資料類型。但是，如果我們在模型的中繼資料中手動設定每個結果欄的類型，則 Metabase 就能夠在圖表上呈現鑽取選單，並知道它應該為該欄使用哪種類型的篩選條件（例如，數字的篩選條件將具有與日期或類別不同的選項）。

模型可以在搜尋中呈現個別記錄

模型的另一個簡潔的中繼資料功能：您可以選擇為模型中的值建立索引，以便它們顯示在 Metabase 的搜尋結果中。

在這裡，我們開啟了透過比對此欄在搜尋中呈現個別記錄的選項（右下角）

例如，您可以為模型中包含客戶名稱的欄建立索引，以便使用者可以輸入像 Hudson Borer 這樣的客戶，並直接跳到該客戶的詳細檢視。

透過為模型中的記錄建立索引，您也可以對它們進行 X 光檢視。請參閱模型文件以取得更多詳細資訊。

略過 SQL 變數

這裡有一個值得注意的細微重點。如果您習慣使用已儲存問題和 SQL 變數（例如欄位篩選條件）來建立「模型」，以便使用者可以取得這些問題並將它們連接到儀表板篩選條件，則模型在這裡採用了不同的方法。模型不適用於變數，因為它們不需要變數。一旦您告知 Metabase 模型的欄類型，您就可以從該模型開始提出問題、儲存它，並且能夠將其連接到儀表板篩選條件。無需在 SQL 程式碼中放入變數。

如果您將模型新增至儀表板，您會注意到您無法將其任何欄對應到儀表板篩選條件，即使在您為這些篩選條件設定類型之後也是如此。若要使用模型取得相同的結果，您可以

• 建立不含變數的模型。
• 儲存以模型為基礎的問題。
• 將該問題新增至儀表板。
• 將篩選條件新增至儀表板。
• 將篩選條件對應到問題上的適當欄。

如需更多資訊，請參閱儀表板篩選條件。

延伸閱讀

• 建立和管理模型.