數據集市
出自 MBA智库百科(https://wiki.mbalib.com/)
數據集市(Data Mart)
目錄 |
數據集市也叫數據市場，是一個從操作的數據和其他的為某個特殊的專業人員團體服務的數據源中收集數據的倉庫。從範圍上來說，數據是從企業範圍的資料庫、數據倉庫，或者是更加專業的數據倉庫中抽取出來的。數據中心的重點就在於它迎合了專業用戶群體的特殊需求，在分析、內容、表現，以及易用方面。數據中心的用戶希望數據是由他們熟悉的術語表現的。
數據倉庫是一個集成的、面向主題的數據集合，設計的目的是支持DSS（決策支持系統）功能。在數據倉庫里，每個數據單元都和特定的時間相關。數據倉庫包括原子級別的數據和輕度彙總的數據，是面向主題的、集成的、不可更新的(穩定性)、隨時間不斷變化（不同時間）的數據集合，用以支持經營管理中的決策制定過程。
那麼數據集市就是企業級數據倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。為瞭解決靈活性和性能之間的矛盾，數據集市就是數據倉庫體繫結構中增加的一種小型的部門或工作組級別的數據倉庫。數據集市存儲為特定用戶預先計算好的數據，從而滿足用戶對性能的需求。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。
- 數據集市的特征包括規模小
- 有特定的應用
- 面向部門
- 由業務部門定義、設計和開發
- 業務部門管理和維護
- 能快速實現
- 購買較便宜
- 投資快速回收
- 工具集的緊密集成
- 提供更詳細的、預先存在的、數據倉庫的摘要子集
- 可升級到完整的數據倉庫
數據集市中數據的結構通常被描述為星型結構或雪花結構。一個星型結構包含兩個基本部分——一個事實表和各種支持維表。
事實表
事實表描述數據集市中最密集的數據。在電話公司中，用於呼叫的數據是典型的最密集數據；在銀行中，與賬目核對和自動櫃員機有關的數據是典型的最密集數據。對於零售業而言，銷售和庫存數據是最密集的數據等等。
事實表是預先被連接到一起的多種類型數據的組合體，它包括：一個反映事實表建立目的的實體的主鍵，如一張訂單、一次銷售、一個電話等等，主鍵信息，連接事實表與維表的外鍵，外鍵攜帶的非鍵值外部數據。如果這種非鍵外部數據經常用於事實表中的數據分析，它就會被包括在事實表的範圍內。事實表是高度索引化的。事實表中出現30到40條索引非常常見。有時實事表的每列都建了索引，這樣作的結果是使事實表中的數據非常容易讀取。但是，導入索引所需的資源數量必須為等式提供因數。通常，事實表的數據不能更改，但可以輸入數據，一旦正確輸入一個記錄，就不能更改此記錄的任何內容了。
維表
維表是圍繞著事實表建立的。維表包含非密集型數據，它通過外鍵與事實表相連。典型的維表建立在數據集市的基礎上，包括產品目錄、客戶名單、廠商列表等等。
數據集市中的數據來源於企業數據倉庫。所有數據，除了一個例外，在導入到數據集市之前都應該經過企業數據倉庫。這個例外就是用於數據集市的特定數據，它不能用於數據倉庫的其他地方。外部數據通常屬於這類範疇。如果情況不是這樣，數據就會用於決策支持系統的其他地方，那麼這些數據就必須經過企業數據倉庫。
數據集市包含兩種類型的數據，通常是詳細數據和彙總數據。
詳細數據
就像前面描述過的一樣，數據集市中的詳細數據包含在星型結構中。值得一提的是，當數據通過企業數據倉庫時，星型結構就會很好的彙總。在這種情況下，企業數據倉庫包含必需的基本數據，而數據集市則包含更高間隔尺寸的數據。但是，在數據集市使用者的心目中，星型結構的數據和數據獲取時一樣詳細。
彙總數據
數據集市包含的第二種類型數據是彙總數據。分析人員通常從星型結構中的數據創建各種彙總數據。典型的彙總可能是銷售區域的月銷售總額。因為彙總的基礎不斷發展變化，所以歷史數據就在數據集市中。但是這些歷史數據優勢在於它存儲的概括水平。星型結構中保存的歷史數據非常少。
數據集市以企業數據倉庫為基礎進行更新。對於數據集市來說大約每周更新一次非常平常。但是，數據集市的更新時間可以少於一周也可以多於一周，這主要是由數據集市所屬部門的需求來決定的。
數據集市怎麼建
建立不同規格的數據倉庫、數據集市的成本，國外的咨詢機構有專門的評估，在一定程度上可以借鑒。但是這些結果在國內也許並不適用，因為國情不同，在國內的構建成本需要專門的調研。以我們為企業構建的客戶主題數據集市為例，一般成本在20萬元到50萬元人民幣之間。
數據集市的設計可以採用迭代式的方法。在迭代式開發中，每個迭代為上一次的結果增加了新的功能。功能增加的順序要考慮到迭代平衡以及儘早發現重大風險。通俗地說，就是在正式交貨之前多次給客戶交付不完善的中間產品“試用”。這些中間產品會有一些功能還沒有添加進去、還不穩定，但是客戶提出修改意見以後，開發人員能夠更好地理解客戶的需求。如此反覆，使得產品在質量上能夠逐漸逼近客戶的要求。這種開發方法周期長、成本高，但是它能夠避免整個項目推倒重來的風險，比較適合大項目、高風險項目。
理論上講，應該有一個總的數據倉庫的概念，然後才有數據集市。實際建設數據集市的時候，國內很少這麼做。國內一般會先從數據集市入手，就某一個特定的主題（比如企業的客戶信息）先做數據集市，再建設數據倉庫。數據倉庫和數據集市建立的先後次序之分，是和設計方法緊密相關的。而數據倉庫作為工程學科，並沒有對錯之分，主要判別方式應該是能否解決目前存在的實際問題，併為今後可能發生的問題保持一定的可伸縮性。
數據集市能不能 “獨立”
企業規劃數據倉庫項目的時候，往往會遇到很多數據倉庫軟體供應商。各供應商除了推銷相關的軟體工具外， 同時也會向企業灌輸許多概念。其中，數據倉庫和數據集市是最常見的兩個術語了。各個供應商術語定義不統一、銷售策略不一樣，這往往會給企業帶來很大的混淆。最典型的問題是：到底是先上一個企業級的數據倉庫呢？還是先上一個部門級的數據集市？這其實是是否要上獨立型數據集市的問題。
數據集市可以分為兩種類型——獨立型數據集市和從屬型數據集市。獨立型數據集市直接從操作型環境獲取數據，從屬型數據集市從企業級數據倉庫獲取數據，帶有從屬型數據集市的體繫結構。
數據倉庫規模大、周期長，一些規模比較小的企業用戶難以承擔。因此，作為快速解決企業當前存在的實際問題的一種有效方法，獨立型數據集市成為一種既成事實。獨立型數據集市是為滿足特定用戶（一般是部門級別的）的需求而建立的一種分析型環境，它能夠快速地解決某些具體的問題，而且投資規模也比數據倉庫小很多。
獨立型數據集市的存在會給人造成一種錯覺，似乎可以先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換為數據倉庫。有些銷售人員會推銷這種觀點，其實質卻常常是因為建立企業級數據倉庫的銷售周期太長以至於不好操作。
多個獨立的數據集市的累積，是不能形成一個企業級的數據倉庫的，這是由數據倉庫和數據集市本身的特點決定的—數據集市為各個部門或工作組所用，各個集市之間存在不一致性是難免的。因為脫離數據倉庫的緣故，當多個獨立型數據集市增長到一定規模之後，由於沒有統一的數據倉庫協調，企業只會又增加一些信息孤 島，仍然不能以整個企業的視圖分析數據。借用Inmon的比喻：我們不可能將大海裡的小魚堆在一起就構成一頭大鯨魚，這也說明瞭數據倉庫和數據集市有本質的不同。
如果企業最終想建設一個全企業統一的數據倉庫，想要以整個企業的視圖分析數據，獨立型數據集市恐怕不是合適的選擇；也就是說“先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換為數據倉庫”是不合適的。從長遠的角度看，從屬型數據集市在體繫結構上比獨立型數據集市更穩定，可以說是數據集市未來建設的主要方向。
快速發展的、充滿競爭的商業世界對於及時、準確的信息有著永無止境的需求，一些IT專家對此認為其必然結果就是創建數據集市。其他專家卻質疑用戶和客戶所要付出的工作和成本。畢竟，難道不能直接從遺留系統和線上事務處理（On Line Transaction Processing，OLTP）系統通過特定的報表獲得相同的信息嗎?在EDS 的商業智能小組裡，我們就經常被問到這一問題。經驗讓我們有許多機會使我們的同行和客戶瞭解這項有用技術的價值。
那麼，一個組織為何要構建數據集市呢?雖然OLTP和遺留系統擁有寶貴的信息，但是可能難以從這些系統中提取有意義的信息並且速度也較慢。而且這些系統雖然一般可支持預先定義操作的報表，但卻經常無法支持一個組織對於歷史的、聯合的、“智能的”或易於訪問的信息的需求。因為數據分佈在許多跨系統和平臺的表中，而且通常是“髒的”，包含了不一致的和無效的值，使得難於分析。數據集市將合併不同系統的數據源來滿足業務信息需求。
若能有效地得以實現，數據集市將可以快速且方便地訪問簡單信息以及系統的和歷史的視圖。一個設計良好的數據集市將會：
