根據需求選擇欄位或表格的細緻度
細緻度 是建構資料模型時最重要的設計決策之一。 它定義了資料表中捕捉的 細節層 級，直接影響 儲存成本、 查詢效能以及你能回答的 分析問題 。 作為資料工程師，了解細節性有助於你設計出符合業務需求的表格，同時維持營運效率。
本單元說明在量度建模中的粒度意義，以及如何根據貴組織的需求評估不同的粒度選項。
了解顆粒感代表的意義
顆粒度，有時稱為 「顆粒」， 描述表格中每一列所代表的細節層級。 在事實表中，粒度決定了每行捕捉的業務事件或衡量標準。 在 維度表中，顆粒決定了實體的表示方式與版本控制。
考慮物聯網感測器資料情境。 你可以設計不同細節層級的事實表：
毫秒級粒度：每一列代表在毫秒級捕捉的單一感測器讀數。 這會捕捉最詳細的資訊，包括精確的時間戳、感測器值以及每次測量的裝置識別碼。
第二聚合粒度：每一列代表裝置每秒感測器的平均值、最小值或最大值。 個別讀數會匯總為每秒統計數據。
分鐘彙整粒度：每一列代表整整一分鐘內裝置的感測器統計數據。 這樣提供最少細節，但儲存空間也最少。
你選擇的顆粒會影響下游的所有東西。 一旦你在聚合過程中失去細節，就無法恢復。 如果你的分鐘彙總表顯示感測器X在某一分鐘的平均溫度為75°C，你無法判斷哪些毫秒出現了溫度突升，也無法確定異常發生的確切時刻。
評估影響細度決策的因素
選擇合適的細節需要平衡多個競爭的考量。 正確的選擇取決於你的具體商業環境和技術限制。
商務需求驅動著精細度
組織需要回答的分析問題應該是判斷細節細節的主要 因素 。 問問自己：所需的 最詳細的分析層級 是什麼？
如果營運工程師需要在毫秒級偵測設備異常，每分鐘的總量是不夠的。 如果管理人員只需要各生產線的每小時使用率摘要，那麼儲存所有感測器的讀數就是浪費資源。
請考慮下列案例：
| 業務需求 | 所需最小粒度 |
|---|---|
| 即時偵測設備振動異常 | 毫秒事件等級 |
| 分析溫度趨勢以進行預測性維護 | 第二彙總層級 |
| 監控每台裝置的每小時能源消耗 | 分鐘彙總層級 |
| 依設施報告每日生產指標 | 每小時總量水準 |
查詢模式會影響效能
使用者查詢資料的方式會影響最佳的細緻度。 當查詢通常會過濾並聚合到更高層級時，儲存過於細粒度的資料會產生 不必要的處理負擔。 每個查詢都必須掃描並彙整比必要的更多的列。
同時，資料儲存過於粗略，會阻礙使用者深入挖掘以回答詳細問題。 找到平衡需要理解目前及預期的查詢模式。
儲存與運算成本會累積
更細緻的粒度意味著 更多的列數，進而增加 儲存成本。 這也增加了 計算成本 ，因為查詢必須處理更多資料。 在 Azure Databricks 中，隨著歷史資料累積，這些成本會逐漸累積。
一個擁有數千個感應器、以毫秒間隔擷取讀數的製造工廠，每天可能會產生數十億最精細的資料列。 將統計數據彙總為每秒或每分鐘，可減少 99% 以上的列數，直接轉化為較低的儲存與查詢成本。
合規與稽核要求很重要
法規要求 有時會要求特定的細緻度。 金融服務組織通常必須保留 交易層級的細節 以供審計，無論儲存成本多少。 醫療機構可能需要追蹤個別病患互動以符合法規。
當合規性決定細化程度時，請清楚記錄相關要求。 當利害關係人質疑為何你儲存的細節超過單純分析需求時，這種理由很有幫助。
對事實資料表套用細微性
事實表最需要細緻決策，因為它們通常包含 最大量的資料。 事實表的粒度是由其 維度鍵的組合決定的。
銷售事實資料表包含日期、產品、客戶和商店的維度鍵，其資料精細度為「每個產品、每位客戶、每家商店、每天一個資料列」。這些維度值的每種唯一組合都會產生一個獨立的資料列。 在小時層級新增時間維度鍵會將精細度變更為「每個產品、每位客戶、每家商店、每小時一個資料列」，進而顯著增加資料列數。
這很重要
在新增任何欄位之前，請明確宣告您的事實表的顆粒度。 精細度聲明作為合約，指導所有後續的設計決策。 例如：「此事實資料表包含每個銷售訂單行項目的一個資料列。」
設計事實表時，請考慮您是否需要：
原子粒子：源系統中捕捉到的最細節層級。 選擇原子顆粒能提供 最大的分析彈性 ，因為你總是可以向上聚合，但無法分解向下。
彙總顆粒：預先彙總的資料，層級高於來源。 彙整事實表提升常見分析模式的 查詢效能 ，但限制使用者可回答的問題。
許多組織同時維護原子與彙總事實表，利用彙總表作為效能優化，同時保留原子細節以便臨時分析。 在 Azure Databricks 中， 實體化檢視 可自動維護這些聚合資料表，隨著底層原子資料變更而刷新。
對維度資料表套用細微性
維度表也有顆粒，但其運作方式與事實表顆粒不同。 維度粒度影響著你如何表示和版本化你的商業實體。
對於客戶維度，您可以選擇：
- 每位客戶一列：每位客戶的當前狀態，當屬性變更時即時更新（SCD 類型 1）。
- 每位客戶每版本一列：每當有重大變更時添加新列，以保留歷史狀態（SCD 類型 2）。
- 每位客戶每時段一列：定期快照，捕捉客戶屬性。
你選擇的尺寸顆粒必須 與事實表顆粒對齊。 如果您的事實資料表使用代理鍵追蹤指向客戶維度的各個交易，則您的客戶維度精細度必須支持這種關係。 參考客戶版本5的交易必須能在維度表中找到該特定版本。
選擇細緻度時的平衡權衡
沒有任何單一的細度選擇是普遍正確的。 每一個決策都涉及權衡，您必須根據自身具體需求進行權衡。
| 考量事項 | 細粒度 | 粗粒度 |
|---|---|---|
| 分析彈性 | 高階級 - 能回答詳細問題 | 低級-僅限於彙總分析 |
| 儲存成本 | 越高，需儲存的行數越多 | 較低 - 資料列數較少 |
| 查詢效能 | 聚合查詢速度較慢 | 常見模式的速度更快 |
| 歷史分析 | 支援時間點分析 | 可能會失去歷史細節 |
| 合規支援 | 對於審計需求來說更有利 | 可能不符合規定 |
當你不確定時， 從更細緻的細節開始 通常比較安全。 你之後可以建立彙總表來優化效能，但無法恢復從未被捕捉的 細節 。 不過，這項指引假設你有預算和基礎設施，能一開始支援更細粒度的儲存。
了解如何選擇合適的細度，能讓你設計出支持組織分析需求的資料模型，同時有效管理成本。 Azure Databricks 中建立與載入你所選細度資料表的實作細節，會在後續單元中說明。