數據倉庫

著名的數據倉庫專家W.H.Inmon在其著做《Building the Data Warehouse》一書中給予以下描述：數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。

對於數據倉庫的概念咱們能夠從兩個層次予以理解，首先，數據倉庫用於支持決策，面向分析型數據處理，它不一樣於企­業現有的操做型數據庫；其次，數據倉庫是對多個異構的數據源有效集成，集成後按照主題進行了重組，幷包含歷史數據，並且存放在數據倉庫中的數據通常再也不修改。 
數據庫是一個裝數據（信息的原材料）的地方。 
數據倉庫是一種系統，這種系統也是用數據庫裝東西。 
數據倉庫系統（用數據庫裝東西）與其餘基礎業務系統（例如財務系統、銷售系統、人力資源系統等，也是用數據庫裝東西）的區別是： 
基礎業務系統的特色是各管各的，例如財務系統生產了白菜，那麼用一個數據庫來裝，人力資源系統生產了豬肉，再用一個數據庫來裝。我要作一道菜，須要分別到各個數­據庫去取，比較麻煩（現實的狀況是大部分時候讓種菜的農民伯伯送過來，但送過來的東西不必定是我想要的，並且不一樣的時候我想要不一樣的東西，常常會被農民伯伯罵，­弄得雙方都不開心）。另一方面，各個數據庫中放的是一些比較原始的東西，我要拿過來作菜，還須要通過很麻煩的清洗過程，一不當心裏面可能就藏着一條大青蟲。 
那麼，數據倉庫系統就是創建一個大的超市，將各地農民伯伯出產的東西收集過來，清洗乾淨，分門別類地放好。這樣，你要哪一種菜的時候，直接從超市裏面拿就能夠了。 

早期一直不理解數據倉庫是什麼困惑得很。 

宏觀一點講，數據倉庫就是堆放公司全部數據的地方，之因此把數據都堆在一塊兒，是爲了從中間找到有價值的東西。 

數據倉庫更多的是一個概念，不要把數據倉庫想成那些號稱是數據倉庫的軟件產品們。 

數據倉庫的物理上就是數據庫。相對業務系統數據庫叫OLTP數據庫（用於業務處理），這種數據庫叫OLAP數據庫（用於業務分析）。 

數據倉庫的概念是針對如下基本需求產生的： 
公司的業務系統不少，業務系統的歷史數據不方便查詢。不一樣的業務系統每每管理部門不一樣，地域不一樣。能不能將全部這些數據集中起來，再淘淘有沒有有意義的業務規律­。 

數據倉庫數據庫每每很大，由於公司全部的數據集中得越多，越能淘到有價值的發現。例如隨便就100G以上。 

數據倉庫的組成十分繁雜，既有業務系統的歷史數據，又有人事、財務數據，還要本身建一些基礎性的數據，例如，公共假期數據、地理信息、國家信息等等。 

數據倉庫概念包含從業務生產系統採集數據的程序，這個程序還不能影響業務系統的運行。（屬於所謂「ETL」過程） 

數據倉庫包括業務系統長期的歷史數據，例如5年，用來分析。（所謂「ODS」數據） 

數據倉庫包括針對某相業務值（例如銷售量）從新打上標籤的業務流水數據。（所謂「事實表」、「維度表」）。 

數據倉庫概念興許還包含報表生成工具（所謂「BI」工具）。這些工具可以達到幾年前所謂DSS（決策分析）的效果。 

數據倉庫的客戶歷史資量的分析，也許又與CRM系統粘點邊。 

總之，一點，一個公司想針對已有的歷史業務數據，充分的利用它們，那麼就上數據倉庫項目。至於哪些嚇唬人的大寫字母的組合，只是達到這個目標的科學技術罷了。 

牢記住數據倉庫的基本需求，不要被供應商嚇着。 
數據倉庫能夠說是決策支持系統，能幫助老闆瞭解企業的總體全貌，看到數據倉庫提供的通過整理統計概括的數據後老闆憑本身的管理經驗能夠發現企業的問題或困難或成­功因素在哪一方面，而後能夠不斷的追溯數據，直到肯定到最具體的細節上，這樣可以不斷提高老闆或管理層的管理水平，不斷改善企業的管理。咱們知道的最好的一個例­子就是美國某大型超市啤酒和尿布的故事。 
沃爾瑪公司在美國的一位店面經理曾發現，每週，啤酒和尿布的銷量都會有一次同比攀升，一時卻搞不清是什麼緣由。後來，沃爾瑪運用商業智能（Business 
Intelligence，簡稱ＢＩ）技術發現，購買這兩種產品的顧客幾乎都是25歲到35歲、家中有嬰兒的男性，每次購買的時間均在週末。沃爾瑪在對相關數據­分析後得知，這些人習慣晚上邊看球賽、邊喝啤酒，邊照顧孩子，爲了圖省事而使用一次性的尿布。獲得這個結果後，沃爾瑪決定把這兩種商品擺放在一塊兒，結果，這兩種­商品的銷量都有了顯著增長。 
數據庫是數據倉庫的基礎。數據倉庫實際上也是由數據庫的不少表組成的。須要把存放大量操做性業務數據的數據庫通過篩選、抽取、概括、統計、轉換到一個新的數據庫­中。而後再進行數據展示。老闆關注的是數據展示的結果。 
數據倉庫(DATA WAREHOUSE/DATA 
MART)的另外一重要概念是數據從不一樣的數據庫(DATABASES) 
裏調出通過ETL工具(如POWERCENTRE，DECISIONSTREAM, SQL SERVER 
2000 DTS, SQL SERVER 2005 
SSIS)過程進行清理，確證，整合並設計成多維(dimensional 
framework)。以保證數據的正確、準確、完整, 
這是很是重要的一點。 
咱們如今的項目穩定運行了6年多，一直本身開發，最近慢慢開始使用datastage。不少大型項目之因此用工具，是由於工具的自己的特色是開發快，效率相對還­能夠，讓你更好地有精力用在業務、數據庫的優化以及數據測試上，和數據質量自己並無關係。 
而數據質量關係最密切的仍是從設計（架構、模型等）、業務關係的理解、項目管理（含和客戶的交流，以及聽從開發流程和測試流程）等一系列項目工程的過程。這也是­爲何不少項目使用了ETL工具，可是數據質量仍是提升不大的主要緣由。 

數據倉庫的做用重在數據的集中管理。集中管理的最終目的是爲了分析，預測。 
所謂的ETL。不過是數據倉庫的構建的一個必須過程。數據的抽取轉換與裝載，都是爲了集中管理所作的基礎工做，這些數據與動做的描述，都會有有響應的元數據進行­描述。 
在數據倉庫建模的過程，咱們通常都是採用多維模型，如星形，雪花型等等，這樣作最大的特色就是效率高，數據的冗餘度低。因此，把OLAP與數據倉庫混爲一談我認­爲是片面的解釋。 
咱們也能夠選擇業務邏輯模型創建數據倉庫，這是很早之前的作法了，特色就是效率不高，數據的冗餘度高，但他能實現很是難以表達的業務邏輯設計。 
基於數據倉庫最重要的是分析與預測，我認爲，歷史如今未來是數據倉庫的精華。。 
基於數據倉庫的DM，OLAP都是爲了分析與預測。爲了讓使用企業單位更好的把握如今，預測未來，所以他最實效的說法我認爲是給決策者與管理者進行決策管理提供­分析與預測的依據。 

另外，數據倉庫還會起到歷史數據分類歸檔的目的（就像圖書館同樣），屆時能夠經過檢索條件方便的查詢歷史信息；而同類信息在OLTP中早已被更新了。 
至於它的分析功能，就象氣象考古研究工做，在不一樣深度的冰川中保存着當時的氣象信息，不然拿什麼預測氣候變化趨勢呢！ 
不過，要有至關的管理及技術儲備以及管理層的強力支持才能夠。先有需求，並具有了必要條件纔可上馬，不然您的數據倉庫將不是超市而是個垃圾堆，「garbage 
in，then garbage out」！ 
因此，我認爲是企業信息化建設及科學管理水平的提升催生了數據倉庫的必然產生，不要趕時髦，炒概念，關鍵仍是冷靜分析本身企業的現實情況是否到了必須部署數據倉­庫的階段了！ 
至於如何說服管理者，則須要您的努力了，不要站在您技術人員的立場闡述問題，CEO對技術問題不感興趣，站在他們的角度考慮問題，回答諸如「咱們投入如此大的資­金、人力，同時面對升級系統的巨大風險，目的何在？」記住，CEO和CFO（甚至包括CIO）是更但願用數字說話的，您分析一下公司的管理決策流程，就能夠向他­們提出頗有價值的決策支持報表，而部門經理（或相似人員）每季度也沒必要頭大的製做相關分析報表了，節省的精力能夠作更多有價值的事情，這就是企業人力資源利用率­的巨大提高，能夠節省多少銀子，恐怕CEO不會用你提示了吧！ 

談談一年來關於數據倉庫好處的困惑、探索和感悟 
quote: 

最初由 maltig 發佈 
早期一直不理解數據倉庫是什麼困惑得很。 

宏觀一點講，數據倉庫就是堆放公司全部數據的地方，之因此把數據都堆在一塊兒，是爲了從中間找到有價值的東西。 

數據倉庫更多的是一個概念，不要把數據倉庫想成那些號稱是數據倉庫的軟件產品們。 

數據倉庫的物理上就是數據庫。相對業務系統數據庫叫OLTP數據庫（用於業務處理），這種數據庫叫OLAP數據庫（用於業務分析）。 

數據倉庫的概念是針對如下基本需求產生的： 
公司的業務系統不少，業務系統的歷史數據不方便查詢。不一樣的業務系統每每管理部門不一樣，地域不一樣。能不能將全部這些數據集中起來，再淘淘有沒有有意義的業務規律­。 

數據倉庫數據庫每每很大，由於公司全部的數據集中得越多，越能淘到有價值的發現。例如隨便就100G以上。 

數據倉庫的組成十分繁雜，既有業務系統的歷史數據，又有人事、財務數據，還要本身建一些基礎性的數據，例如，公共假期數據、地理信息、國家信息等等。 

數據倉庫概念包含從業務生產系統採集數據的程序，這個程序還不能影響業務系統的運行。（屬於所謂「ETL」過程） 

數據倉庫包括業務系統長期的歷史數據，例如5年，用來分析。（所謂「ODS」數據） 

數據倉庫包括針對某相業務值（例如銷售量）從新打上標籤的業務流水數據。（所謂「事實表」、「維度表」）。 

數據倉庫概念興許還包含報表生成工具（所謂「BI」工具）。這些工具可以達到幾年前所謂DSS（決策分析）的效果。 

數據倉庫的客戶歷史資量的分析，也許又與CRM系統粘點邊。 

總之，一點，一個公司想針對已有的歷史業務數據，充分的利用它們，那麼就上數據倉庫項目。至於哪些嚇唬人的大寫字母的組合，只是達到這個目標的科學技術罷了。 

牢記住數據倉庫的基本需求，不要被供應商嚇着。 

數據倉庫是幹什麼的，到如今，我終於看到了成果。 

一年半之前，我來到如今這家公司(一家證券公司)。跟全部2004年的證券公司同樣，「生」與「死」是當時考慮的惟一問題。爲得到證監會的「創新業務資格」(獲­得這個牌照就如同得到了免死金牌，不但可以生存並且能得到資助從而作大作強)，公司急需上馬一套集中監控系統，我就是爲了這個項目被招募到公司。 

背景： 
在證券行業中，全部公司的業務系統（所謂證券交易系統）有一個基本特徵：每個分支機構（所謂營業部）的交易系統都是獨立的（地理上、管理上），這樣總部沒辦法­在技術上對數十套這樣的系統的業務數據進行及時的分析與覈對。（固然這兩年幾乎全部公司都實現了交易系統的集中。）因而，幾乎全部的證券公司都上馬了一套集中監­控系統，它經過廣域網，把公司下屬的這幾十家營業部的數據實時或當天晚上採集到總部的數據庫中，白天實時的對資金存取、證券買賣等業務行爲進行監控，晚上再運算­一些覈對功能，看資金和證券是否賬實相符，再經過WEB界面將結果展現給公司審計部門。咱們公司在05年上半年上了這個系統。 

因爲手頭上的這個系統整合了公司全部的業務系統的數據(30多套分佈在全國各地的交易系統、30多套財務系統、集中清算系統、登記公司數據、等等)，因此象每一個­技術型IT員工同樣，我有一個天然而然的想法：能不能搞清楚公司全部業務信息的邏輯關係，本身建一個數據庫，搞一個數字虛擬證券公司，在個人這個數據庫中包含公­司每個業務細節的信息，業務部門無論要什麼，我都能很快提供出來（而不是依賴供應商）。 

OK。在我這個最樸素的想法的支配下，我開始學習數據庫（搞了若干年IT基礎設施的我，竟然在2004年末又開始學習數據庫！可見中國的IT崗位有多麼不清晰。­），向供應商請教底層數據結構，向他們請教業務邏輯關係。3個月後，我竟然已經可以對供應商提供的「監控功能」提供徹底的功能驗證，指出了無數的功能BUG，同­時也具有了證券交易、結算業務邏輯的徹底的知識。因而想着手搞一套表名字段名命名規則、再搞一套表對應關係（到後來才知道這叫創建「數據模型」），把證券公司的­業務描述得清清楚楚，但到底怎麼搞，朦朦濃濃的，不知如何下手。 

另外，我這我的最講究來龍去脈，因此十分想對證券業務信息中的因果關係搞清楚講明白。例如：統計出來的股票交易量的前提條件有不少：不一樣營業部、不一樣的委託方式­、不一樣的交易所、不一樣的幣種、不一樣的證券類別、不一樣的客戶規模、不一樣的客戶年齡段、不一樣的月份日期，等等，出來的交易量結果都不同。能夠用一個表來描述，前邊­都是因素字段，最後一個是一數值型的交易量字段。濛濛濃濃知道這裏邊有邏輯關係，但總說不清道不明。 

通常而言，越是本能的困惑，每每越是一門大學問。咱們在現實工做中遇到的不少問題，美國人早就遇到了，並造成了文字、理論（還起了一堆足以讓咱們愣住的大寫字母­組成的名次。）咱們缺少的是對咱們本身本質需求的理解，和與外國已有經驗（經驗通過概括後就叫理論），的鏈接。 

考慮到項目招標時，供應商如何描述「數據倉庫」「元數據」等等，搞不清的概念，因而想搞清楚到底什麼是「數據倉庫」。因而去圖書城，專門到數據倉庫、OLAP、­多維建模書籍區域去，挨個拿過來翻。注意：若是你沒有這方面的困惑和經驗，很難對這些書產生共鳴（或者理解），特別是翻譯這些專業書籍的人每每自己對這些東西不­懂，因此又誤導了一批讀者。因此，十幾本書裏，我只對2本里的一些描述產生強烈的共鳴。 

一、《維度建模徹底指南》（該書的做者自稱是「數據倉庫」的鼻祖）開篇對「數據倉庫項目經理」的本質作了描述：一個數據的收集者，一個數據的整理者，一個統計分­析數據的發佈者。OK。徹底與個人濛濛濃濃的對本身在公司裏的定位徹底一致！做者認爲，數據倉庫的本質就是收集儘量多的信息，用做公司的決策支持（中國人總認­爲作決策的人必定是領導，因此把「決策支持」等同於「領導查詢」，其實在美國，「決策」（decision）是分散到普通員工的（一般是普通的業務人員），並且­任何一項普通的業務決定也叫「決策」，並非「戰略決策」才叫決策。因此「決策支持」絕對不是什麼高深的東西）。通過清理的數據每每以一種特定的格式（所謂星型­結構）存放在數據庫中，整本書就是與讀者探討（注意是「探討」，而不是「傳授」，全部美國的這類權威書籍裏都極力強調不要按書裏的方法去實踐，這就是美國鼓勵自­主創新和中國服從權威的不一樣文化的典型體現）這方面的經驗。 

2《創建多維信息系統》，以一步步深刻的方式，解釋了維度的概念。所謂「維度」，就是前邊我理解的「因素字段」，影響誰呢？表結構中最後的那個數值型的字段。例­如證券交易量字段。交易量字段就是一個「事實」、fact。營業部、委託方式、交易所、幣種、證券類別、客戶規模、客戶年齡段、交易日期，都是因素字段，就是維­度！數數有多少？8個，就是8維。固然能夠更多。這就是多維的概念。在咱們本能的對平常事務的分析中，就蘊含了「多維」的概念，只是咱們沒把這種意識寫下來，出­書，辦研討會等等。美國人作事就是較真，咱們的朦朦濃濃的東西，到人家那裏就是幾萬人研究幾十年！ 

由於證券公司就靠着客戶作證券交易收取手續費，因此業務部門對交易量的統計報表需求很強烈。2年前，由每一個營業部發Email報報表，專門一我的彙總。如今有了­集中的業務數據，業務部門就開始使用供應商提供的業務統計報表。太多了，例如：以營業部爲行，證券類別爲列出一張報表；以月份爲單位出，以周爲單位出；算公司交­易量對證券交易所交易量的比例。等等。算了一下，不下30多張。還常常要變更。一以爲數據不正常，就找我，讓我找找緣由。因而，我就到數據庫裏去，這個字段加上­那個字段再按某個字段某段時間來彙總，哦，怎麼算出來跟供應商提供的報表的數值不對呢？因而打電話給供應商，讓他們找問題。次日給我一個升級補丁。好，報表好­了。反反覆覆，搞死了。 

總書j不是號召自主創新嗎？乾脆我本身搞一套。因而找出影響交易量的10個因素，建了一張表，前10個字段是（營業部、委託方式、交易所、幣種、證券類別、客戶­規模、客戶年齡段、交易性質、交易月份、交易周），最後一個是交易量。寫了個SQL過程，天天生成這張表（後來才知道，這張表就叫CUBE。術語害死人吶。），­再在EXECL裏寫了一些VBA（簡直把美國人10個崗位分工乾的活全包了），能夠把這個表下載到EXCEL中。再用EXCEL的「數據旋轉表」（正式中文譯名­爲「數據透視表」，但我以爲必定要用上「旋轉」這兩個點睛的字）的功能，就能夠靈活的配置與這10個因素字段相關的全部報表。（咱們公司根本沒人用過「數據旋轉­表」這個功能，甚至連「自動篩選」的功能都沒用過。）本身挺得意的。但跟後面用MicroStrategy作出來的報表比起來就差得太遠了！ 

日本母公司有一套MicroStratey，對中國區總裁說如何如何好，因而2005年初買了一套，作管理財務數據分析。由另外一個同事負責。（當時我很奇怪，這­種商業智能、BI、決策支持、數據倉庫、OLAP、多維的工具應該由我來管理纔對。）一直擱置在那裏，直到05年末。業務部門提出對營業部每個月新增底有效客戶進­行分析，纔想起讓我用MicroStrategy做爲平臺。正中下懷。因而，構建一個徹底獨立於供應商數據結構體系的數據倉庫（這裏指狹義的數據倉庫，或者叫數­據倉庫展現區）成了一項現實的工做。 

開始着手設計表結構。（設計一套完整的證券公司業務數據倉庫可不是一件好玩的事情。）徹底是瀑布方法進行設計，不斷的嘗試，修改，從頭再來。幾個月前曾沿用供應­商的字段命名規則，維度表不使用代理鍵，試着作了套數據倉庫模型，用MicroStrategy作作報表，還能夠。到了春節，下決心徹底從新設計這個數據倉庫。­這下可好，好多個晚上睡很差，腦子裏徹底是這個表應該是什麼字段，時間維度如何劃分層次，如何來劃分事實，搞幾個大的事實範疇，粒度到什麼級別，那些事實是一個­粒度，這些事實須要不一樣的事實表描述嗎，維度表直接的關係，怎樣設計維度最能保證未來的擴充性，如何避免雪花型。不斷的返工。整個模型，愈來愈清晰。最終，本身­以爲滿意了，既能知足最基本的需求，也能保證未來對這個模型的擴充。又開始寫SQL存儲過程，驗證數據轉換的準確性，不斷的修改，不斷的擴充。不斷的告誡本身，­不要過於最求完美，告誡本身適度的缺陷是項目前進的保證。總之，有了一套徹底自主知識產權的東西，而且自認爲仍是比較完備、復扎和嚴謹的，沒有足夠的思索是難以­得到這個東西的。 

開始設置MicroStrategy，從沒系統的用過，什麼都是摸石頭過河。但在使用這個OLAP工具的時候，徹底體會到它的好處。由於，我爲業務部門作過太多­的SQL統計，多到我本身都想要搞一套SELECT語句的自動生成工具。結果發現，MICROSTRATEGY徹底就是我想要的東西！設置好什麼實體、事實、度­量、層系、上下級關係之類的東西，而後不斷的試這作一些報表，找到自動生成的SELECT語句跟以前設置的那些東西究竟是什麼關係。沒多久就摸熟了。（由於關於­如何使用SELECT語句生成各類報表，我有太多的經驗和苦悶。） 

出來的效果出奇的好，靈活的實體配置，行列擡頭的隨意旋轉，各類方向的鑽取，彙總表的自動選取。從沒以爲OLAP工具這麼好用。有了它，我甚至不再用去寫SE­LECt語句，不用在不一樣的表直接Join來join去。3分鐘就能作一張所謂的報表。 

到如今，能夠說，我已經徹底領悟到數據倉庫的好處。雖然這些好處只是冰山一角。 
可是話說回來，若是甲方沒有我這個「人」，沒有對數據倉庫的理解人，沒有願意對數據分析的人，公司沒有精細化管理的意識，沒有較真的社會風氣，「數據倉庫」這個­概念還不是廢物一堆，或者是外國供應商騙錢的口實？ 

通常人只看到數據倉庫好處的表皮，其實還有一個重要做用是，數據倉庫經過分析數據（包括報表、OLAP、挖掘），能把分析出來的東西找出來，就能夠對症下藥，採­取措施。好比某品牌產品，在某代理商代理的銷售中，在某地區某季度業績不好，因而在下鑽分析，分析出銷售中第幾步出了問題，分析出問題是質量很差，服務很差，還­是其餘緣由。分析好了後，在即席查詢中將全部條件列出，查詢出具體的狀況，公司相關部門負責人去處理，解決好具體環節。 

這纔是數據倉庫解決實際具體狀況的深刻應用，不只僅是給老總決策參考，而是給老總及部門負責人具體的，詳細的信息，指導如何去處理。 

這樣講不知道你是否是好理解一點： 

數據倉庫的概念是美國傳進來的。講講在美國，數據倉庫這個概念是怎麼興起的。 

30年前，全部的美國的任何行業都轟轟烈烈的進行着信息化的活動。各類業務活動都由電腦處理，叫作「業務系統」。 
必然的，全部業務系統裏都有查詢統計功能。 

20年前，隨着電腦化的業務系統裏存儲的歷史數據逐漸增長，他們發現查詢歷史數據或者作業務統計的速度愈來愈慢。對業務數據統計分析的需求也愈來愈複雜。業務系­統已經不堪重負。 

因而不少公司就把，業務系統裏的歷史數據拿出來，放在另外一個地方，專門負責對歷史數據的查詢統計分析。這個工做顯得愈來愈重要，也愈來愈有企業肯花錢來作，也越­來越有人認真的研究怎麼把查詢統計分析的工做作好。 

10多年前，開始美國人開始有人起名字，就叫「數據倉庫」。 

這就是「數據倉庫」這個名詞的由來。固然，在這個領域術語極不規範，說白了就是專門用來查詢分析統計業務數據的數據庫。