數據倉庫的基本架構

數據倉庫的基本架構
數據倉庫的目的是構建面向分析的集成化數據環境，爲企業提供決策支持（Decision Support）。其實數據倉庫自己並不「生產」任何數據，同時自身也不須要「消費」任何的數據，數據來源於外部，而且開放給外部應用，這也是爲何叫「倉庫」，而不叫「工廠」的緣由。所以數據倉庫的基本架構主要包含的是數據流入流出的過程，能夠分爲三層——源數據、數據倉庫、數據應用：

從圖中能夠看出數據倉庫的數據來源於不一樣的源數據，並提供多樣的數據應用，數據自上而下流入數據倉庫後向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平臺。
數據倉庫的數據來源
數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動均可以認爲是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線，也能夠認爲是數據倉庫的血液，它維繫着數據倉庫中數據的新陳代謝，而數據倉庫平常的管理和維護工做的大部分精力就是保持ETL的正常和穩定。
數據倉庫的數據存儲
數據倉庫並不須要儲存全部的原始數據，同時數據倉庫須要儲存部分細節數據。簡單地解釋下：
a.爲何不須要全部原始數據？數據倉庫面向分析處理，可是某些源數據對於分析而言沒有價值或者其可能產生的價值遠低於儲存這些數據所須要的數據倉庫的實現和性能上的成本。好比咱們知道用戶的省份、城市足夠，至於用戶究竟住哪裏可能只是物流商關心的事，或者用戶在博客的評論內容可能只是文本挖掘會有須要，但將這些冗長的評論文本存在數據倉庫就得不償失；
b.爲何要存細節數據？細節數據是必需的，數據倉庫的分析需求會時刻變化，而有了細節數據就能夠作到以不變應萬變。若是咱們只存儲根據某些需求搭建起來的數據模型，那麼顯然對於頻繁變更的需求會手足無措；
c.爲何要面向主題？面向主題是數據倉庫的第一特性，主要是指合理地組織數據以方面實現分析。對於源數據而言，其數據組織形式是多樣的，像點擊流的數據格式是未經優化的，前臺數據庫的數據是基於OLTP操做組織優化的，這些可能都不適合分析，而整理成面向主題的組織形式纔是真正地利於分析的，好比將點擊流日誌整理成頁面（Page）、訪問（Visit或Session）、用戶（Visitor）三個主題，這樣能夠明顯提高分析的效率。
數據倉庫基於維護細節數據的基礎上在對數據進行處理，使其真正地可以應用於分析。主要包括三個方面：
1.數據的聚合
這裏的聚合數據指的是基於特定需求的簡單聚合（基於多維數據的聚合體如今多維數據模型中），簡單聚合能夠是網站的總Pageviews、Visits、Unique Visitors等彙總數據，也能夠是Avg. time on page、Avg. time on site等平均數據，這些數據能夠直接地展現於報表上。
2.多維數據模型
多維數據模型提供了多角度多層次的分析應用，好比基於時間維、地域維等構建的銷售星形模型、雪花模型，能夠實如今各時間維度和地域維度的交叉查詢，以及基於時間維和地域維的細分。因此多維數據模型的應用通常都是基於聯機分析處理（Online Analytical Process, OLAP）的，而面向特定需求羣體的數據集市也會基於多維數據模型進行構建。
3.業務模型
這裏的業務模型指的是基於某些數據分析和決策支持而創建起來的數據模型，好比用戶評價模型、關聯推薦模型、RFM分析模型等，或者是決策支持的線性規劃模型、庫存模型等；同時，數據挖掘中前期數據的處理也能夠在這裏完成。

數據倉庫的數據應用
報表展現
報表幾乎是每一個數據倉庫的必不可少的一類數據應用，將聚合數據和多維分析數據展現到報表，提供了最爲簡單和直觀的數據。
即時查詢
理論上數據倉庫的全部數據（包括細節數據、聚合數據、多維數據和分析數據）都應該開放即時查詢，即時查詢提供了足夠靈活的數據獲取方式，用戶能夠根據本身的須要查詢獲取數據。
數據分析
數據分析大部分基於構建的業務模型展開，固然也可使用聚合的數據進行趨勢分析、比較分析、相關分析等，而多維數據模型提供了多維分析的數據基礎；同時從細節數據中獲取一些樣本數據進行特定的分析也是較爲常見的一種途徑。
數據挖掘
數據挖掘用一些高級的算法可讓數據展示出各類使人驚訝的結果。數據挖掘能夠基於數據倉庫中已經構建起來的業務模型展開，但大多數時候數據挖掘會直接從細節數據上入手，而數據倉庫爲挖掘工具諸如SAS、SPSS等提供數據接口。

數據倉庫的開發流程：

第1天到第n天的現象
創建數據倉庫不是一蹴而就的。相反，數據倉庫只能一次一步地進行設計和載入數據，即它是進化性的，而非革命性的。數據倉庫的創建要採用有序地反覆和一次一步的方式。下圖說明一個創建數據倉庫的典型過程。

第1天，通曉本質上進行操做型處理的幾個系統。
第2天，對數據倉庫中第一個主題領域的最初幾個表載入數據，此時就會產生必定的好奇心，用戶開始發現數據倉庫和分析處理。
第3天，更多的數據載入數據倉庫，而且隨着數據量增大，將吸引更多的用戶。一旦用戶發現有較容易載入的集成數據源，並有在時間維上觀察數據的歷史基礎，這就不只僅是好奇心了。大約此時，認真的DSS分析員漸漸地被吸引到數據倉庫中。
第4天，隨着更多的數據載入數據倉庫，一批存儲在操做型環境的數據被適當地放入數據倉庫中。如今，咱們就「發現」數據倉庫是可用來進行分析處理的信息源。各類各樣的DSS應用出現了。的確，伴隨着如今存入數據倉庫的大規模數據，此時開始出現如此多的用戶和如此多的處理請求，以至於一些用戶進入數據倉庫的要求和分析工做被推遲。進入數據倉庫的競爭成爲使用數據倉庫的障礙。
第5天，部門數據庫(數據集市，或OLAP )開始興起，各部門發現經過把數據從數據倉庫輸入它們本身的部門處理環境，會使它們的處理既便宜又容易。到達部門級的數據吸引着一些D S S分析員。
第6天，部門系統出現繁忙，獲得部門數據比得到數據倉庫的數據更便宜、更快、更容易。很快最終用戶就放棄數據倉庫的細節，去進行部門處理。
第n天，這種體系結構獲得充分發展。生產系統的原始集合中只剩下操做型處理。數據倉庫具備豐富的數據，並有一些數據倉庫的直接用戶和許多部門數據庫。由於在部門級上得到處理所須要的數據既容易又便宜，因此大部分DSS分析處理都在部門級進行。
固然，從第1天到第n天的進化須要很長的時間，一般須要幾年。而且在從第1天到第n天的處理過程當中，DSS環境在不斷地提升和職能化。

元數據管理

元數據（Meta Date），其實應該叫作解釋性數據，或者數據字典，即數據的數據。主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及ETL的任務運行狀態。通常會經過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操做和管理能達成協同和一致。