- 資料倉庫教程
- DWH - 首頁
- DWH - 概述
- DWH - 概念
- DWH - 術語
- DWH - 交付流程
- DWH - 系統流程
- DWH - 架構
- DWH - OLAP
- DWH - 關係型 OLAP
- DWH - 多維 OLAP
- DWH - 模式
- DWH - 分割槽策略
- DWH - 元資料概念
- DWH - 資料市場
- DWH - 系統管理員
- DWH - 流程管理員
- DWH - 安全
- DWH - 備份
- DWH - 調優
- DWH - 測試
- DWH - 未來展望
- DWH - 面試問題
- DWH 有用資源
- DWH - 快速指南
- DWH - 有用資源
- DWH - 討論
資料倉庫 - 分割槽策略
分割槽是為了提高效能並簡化資料管理。分割槽還有助於平衡系統的各種需求。它透過將每個事實表劃分為多個單獨的分割槽來最佳化硬體效能並簡化資料倉庫的管理。在本章中,我們將討論不同的分割槽策略。
為什麼需要分割槽?
出於以下原因,分割槽非常重要:
- 便於管理,
- 協助備份/恢復,
- 提高效能。
便於管理
資料倉庫中的事實表的大小可能高達數百 GB。這種巨大的事實表作為單個實體非常難以管理。因此,它需要分割槽。
協助備份/恢復
如果我們不分割槽事實表,那麼我們必須載入包含所有資料的完整事實表。分割槽允許我們僅根據需要定期載入資料。它減少了載入時間,並提高了系統性能。
注意 - 為了減少備份大小,除了當前分割槽之外的所有分割槽都可以標記為只讀。然後,我們可以將這些分割槽置於無法修改的狀態。然後可以備份它們。這意味著只需要備份當前分割槽。
提高效能
透過將事實表劃分為資料集,可以增強查詢過程。查詢效能得到增強,因為現在查詢僅掃描相關的分割槽。它不必掃描所有資料。
水平分割槽
事實表有多種分割槽方式。在水平分割槽中,我們必須牢記資料倉庫的可管理性需求。
按時間劃分為相等段
在這種分割槽策略中,事實表是根據時間段進行分割槽的。這裡每個時間段代表業務內一個重要的保留期。例如,如果使用者查詢本月至今的資料,那麼將資料劃分為月度段是合適的。我們可以透過刪除其中的資料來重用分割槽表。
按時間劃分為不同大小的段
這種分割槽是在很少訪問舊資料的情況下進行的。它被實現為一組用於相對當前資料的小分割槽,以及用於非活動資料的大分割槽。
注意事項
詳細資訊可線上獲取。
物理表的數量保持相對較小,從而降低了運營成本。
此技術適用於需要混合使用資料深入瞭解近期歷史和資料探勘整個歷史的情況。
此技術不適用於分割槽配置檔案定期更改的情況,因為重新分割槽會增加資料倉庫的運營成本。
按不同維度分割槽
事實表也可以根據時間以外的其他維度進行分割槽,例如產品組、區域、供應商或任何其他維度。讓我們舉個例子。
假設市場職能已構建成不同的區域部門,例如按州劃分。如果每個區域都希望查詢其區域內捕獲的資訊,那麼將事實表劃分為區域分割槽將被證明更有效。這將導致查詢速度加快,因為它不需要掃描不相關的資訊。
注意事項
查詢不必掃描不相關的資料,從而加快了查詢過程。
此技術不適用於維度在未來不太可能發生變化的情況。因此,值得確定維度在未來不會發生變化。
如果維度發生變化,則必須重新分割槽整個事實表。
注意 - 我們建議僅根據時間維度執行分割槽,除非您確定建議的維度分組在資料倉庫的生命週期內不會發生變化。
按表大小分割槽
當沒有明確的依據可以根據任何維度對事實表進行分割槽時,我們應該根據其大小對事實表進行分割槽。我們可以將預設大小設定為臨界點。當表超過預設大小時,將建立一個新的表分割槽。
注意事項
這種分割槽管理起來很複雜。
它需要元資料來識別每個分割槽中儲存的資料。
分割槽維度
如果維度包含大量條目,則需要對維度進行分割槽。在這裡,我們必須檢查維度的尺寸。
考慮一個隨時間變化的大型設計。如果我們需要儲存所有變體以便應用比較,則該維度可能非常大。這肯定會影響響應時間。
迴圈分割槽
在迴圈技術中,當需要新分割槽時,舊分割槽會被存檔。它使用元資料允許使用者訪問工具引用正確的表分割槽。
此技術使資料倉庫內易於自動化表管理功能。
垂直分割槽
垂直分割槽將資料垂直拆分。以下影像描述瞭如何進行垂直分割槽。
垂直分割槽可以透過以下兩種方式執行:
- 規範化
- 行拆分
規範化
規範化是資料庫組織的標準關係方法。在這種方法中,行被摺疊成一行,因此它減少了空間。請檢視以下顯示如何執行規範化的表格。
規範化前的表格
| 產品ID | 數量 | 價值 | 銷售日期 | 商店ID | 商店名稱 | 位置 | 地區 |
|---|---|---|---|---|---|---|---|
| 30 | 5 | 3.67 | 2013年8月3日 | 16 | 陽光 | 班加羅爾 | S |
| 35 | 4 | 5.33 | 2013年9月3日 | 16 | 陽光 | 班加羅爾 | S |
| 40 | 5 | 2.50 | 2013年9月3日 | 64 | 聖安 | 孟買 | W |
| 45 | 7 | 5.66 | 2013年9月3日 | 16 | 陽光 | 班加羅爾 | S |
規範化後的表格
| 商店ID | 商店名稱 | 位置 | 地區 |
|---|---|---|---|
| 16 | 陽光 | 班加羅爾 | W |
| 64 | 聖安 | 孟買 | S |
| 產品ID | 數量 | 價值 | 銷售日期 | 商店ID |
|---|---|---|---|---|
| 30 | 5 | 3.67 | 2013年8月3日 | 16 |
| 35 | 4 | 5.33 | 2013年9月3日 | 16 |
| 40 | 5 | 2.50 | 2013年9月3日 | 64 |
| 45 | 7 | 5.66 | 2013年9月3日 | 16 |
行拆分
行拆分傾向於在分割槽之間保留一對一對映。行拆分的目的是透過減小其大小來加快對大表的訪問。
注意 - 使用垂直分割槽時,請確保不需要在兩個分割槽之間執行主要的聯接操作。
確定分割槽的鍵
選擇正確的分割槽鍵非常關鍵。選擇錯誤的分割槽鍵會導致事實表重新組織。讓我們舉個例子。假設我們要對以下表格進行分割槽。
Account_Txn_Table transaction_id account_id transaction_type value transaction_date region branch_name
我們可以選擇對任何鍵進行分割槽。兩個可能的鍵可能是
- 地區
- 交易日期
假設業務組織在 30 個地理區域中,每個區域都有不同數量的分支機構。這將為我們提供 30 個分割槽,這很合理。這種分割槽足夠好,因為我們的需求捕獲表明絕大多數查詢僅限於使用者自己的業務區域。
如果我們按交易日期而不是按區域進行分割槽,則來自每個區域的最新交易將位於一個分割槽中。現在,希望檢視其所在區域資料的使用者必須跨多個分割槽進行查詢。
因此,值得確定正確的分割槽鍵。