資料倉庫是什麼

根據統計，每個企業的資料量每2～3年時間就會成倍增長，這些資料蘊含著巨大的商業價值，而企業所關注的通常只佔在總資料量的2%～4%左右。
因此，企業仍然沒有最大化地利用已存在的資料資源，以至於浪費了更多的時間和資金，也失去制定關鍵商業決策的最佳契機。
於是，企業如何通過各種技術手段，並把資料轉換為資訊、知識避免各種無知狀態和瞎猜行為，已經成了提高其核心競爭力的主要瓶頸。
資料倉庫是把資料轉換為資訊、知識的一種主要技術手段。
資料倉庫是面向分析的儲存系統
資料倉庫，是為企業所有級別的決策制定過程，提供所有型別資料支援的資料集合。
這些資料集合出於分析性報告和決策支援目的而建立，用於支援研究管理決策。
一是為調查研究作資料支撐，二是為實現需要業務智慧的企業，提供指導業務流程改進、監視時間、成本、量以及控制。
資料倉庫是一個過程而不是一個專案；資料倉庫是一個環境，而不是一件產品。
資料倉庫提供使用者用於決策支援的當前和歷史資料，這些資料在傳統的操作型資料庫中很難或不能得到。

目標和DEMO

將聯機事務處理(OLTP)經年累月所累積的大量資料資料，透過資料倉庫理論所特有的資料儲存架構，做資料的清理儲存，提供給各種分析方法使用，如聯機分析處理(OLAP)、資料探勘(Data Mining)，並進而建立 決策支援系統(DSS)、主管資訊系統(EIS)、研究支援系統，幫助決策者研究者快速有效的自大量資料中，分析出有價值的資訊，能夠快速回應外在環境變動，幫助建構商業智慧(BI)，挖掘內部資料價值，產生更多高質量的內容。

資料倉庫給組織帶來了巨大的變化。資料倉庫的建立給企業帶來了一些新的工作流程，其他的流程也因此而改變。

資料倉庫為企業帶來了一些“以資料為基礎的知識”，它們主要應用於對市場戰略的評價，和為企業發現新的市場商機，同時，也用來控制庫存、檢查生產方法和定義客戶群。

通過資料倉庫，可以建立企業的資料模型，這對於企業的生產與銷售、成本控制與收支分配有著重要的意義，極大的節約了企業的成本，提高了經濟效益，同時，用資料倉庫可以分析企業人力資源與基礎資料之間的關係，可以用於返回分析，保障人力資源的最大化利用，亦可以進行人力資源績效評估，使得企業管理更加科學合理。資料倉庫將企業的資料按照特定的方式組織，從而產生新的商業知識，併為企業的運作帶來新的視角。

國外知名的Garnter關於資料集市產品報告中，位於第一象限的敏捷商業智慧產品有QlikView, Tableau和SpotView，都是全記憶體計算的資料集市產品，在大資料方面對傳統商業智慧產品巨頭形成了挑戰。

國內BI產品起步較晚，知名的敏捷型商業智慧產品有PowerBI, 永洪科技的Z-Suite，SmartBI，FineBI商業智慧軟體等，其中永洪科技的Z-Data Mart是一款熱記憶體計算的資料集市產品。

國內的德昂資訊也是一家資料集市產品的系統整合商。

資料倉庫的特點

資料倉庫是一個面向主題的（Subject Oriented）、整合的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的資料集合

1、面向主題

操作型資料庫的資料組織面向事務處理任務，各個業務系統之間各自分離，而資料倉庫中的資料是按照一定的主題域進行組織的。

2、整合的

資料倉庫中的資料是在對原有分散的資料庫資料抽取、清理的基礎上經過系統加工、彙總和整理得到的，必須消除源資料中的不一致性，以保證資料倉庫內的資訊是關於整個企業的一致的全域性資訊。

3、相對穩定的

資料倉庫的資料主要供企業決策分析之用，所涉及的資料操作主要是資料查詢，一旦某個資料進入資料倉庫以後，一般情況下將被長期保留，也就是資料倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、重新整理。

4、反映歷史變化

資料倉庫中的資料通常包含歷史資訊，系統記錄了企業從過去某一時點(如開始應用資料倉庫的時點)到目前的各個階段的資訊，通過這些資訊，可以對企業的發展歷程和未來趨勢做出定量分析和預測。

5、效率足夠高
資料倉庫的分析資料一般分為日、周、月、季、年等，可以看出，日為週期的資料要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的資料分析。由於有的企業每日的資料量很大，設計不好的資料倉庫經常會出問題，延遲1-3日才能給出資料，顯然不行的。

資料倉庫技術

資料倉庫技術是為了有效的把操作形資料整合到統一的環境中以提供決策型資料訪問的各種技術和模組的總稱。所做的一切都是為了讓使用者更快更方便查詢所需要的資訊，提供決策支援。

從功能結構劃分，資料倉庫系統至少應該包含資料獲取（Data Acquisition）、資料儲存（Data Storage）、資料訪問（Data Access）三個關鍵部分。

資料獲取

資料來源

資料來源是資料倉庫系統的基礎，是整個系統的資料來源泉。通常包括企業內部資訊和外部資訊。內部資訊包括存放於RDBMS中的各種業務處理資料和各類文件資料。外部資訊包括各類法律法規、市場資訊和競爭對手的資訊等等；

元資料

對業務資料本身及其執行環境的描述與定義的資料，稱之為元資料（metadata）。 元資料是描述資料的資料。 元資料的典型表現為物件的描述，即對資料庫、表、列、列屬性（型別、格式、約束等）以及主鍵/外部鍵關聯等等的描述。 特別是現行應用的異構性與分佈性越來越普遍的情況下，統一的元資料就愈發重要了。“資訊孤島”曾經是很多企業對其應用現狀的一種抱怨和概括，而合理的元資料則會有效地描繪出資訊的關聯性。 而元資料對於ETL的集中表現為：定義資料來源的位置及資料來源的屬性、確定從源資料到目標資料的對應規則、確定相關的業務邏輯、在資料實際載入前的其他必要的準備工作，等等，它一般貫穿整個資料倉庫專案，而ETL的所有過程必須最大化地參照元資料，這樣才能快速實現ETL。

資料轉換工具

1)資料轉換工具要能從各種不同的資料來源中讀取資料。 2)支援平面檔案、索引檔案、和legacyDBMS。 3)能以不同型別資料來源為輸入整合資料。 4)具有規範的資料訪問介面 5)最好具有從資料字典中讀取資料的能力 6)工具生成的程式碼必須是在開發環境中可維護的 7)能只抽取滿足指定條件的資料，和源資料的指定部分 8)能在抽取中進行資料型別轉換和字符集轉換 9)能在抽取的過程中計算生成衍生欄位 10)能讓資料倉庫管理系統自動呼叫以定期進行資料抽取工作，或能將結果生成平面檔案 11)必須對軟體供應商的生命力和產品支援能力進行仔細評估 主要資料抽取工具供應商：Prismsolutions. Carleton'sPASSPORT. InformationBuildersInc.'s EDA/SQL. SASInstituteInc.

資料清洗ETL

ETL分別代表：提取extraction、轉換transformation、載入load。

其中提取過程表示操作型資料庫蒐集指定資料，轉換過程表示將資料轉化為指定格式並進行資料清洗保證資料質量，載入過程表示將轉換過後滿足指定格式的資料載入進資料倉庫。

資料倉庫會週期不斷地從源資料庫提取清洗好了的資料，因此也被稱為"目標系統"；

實現ETL，首先要實現ETL轉換的過程。體現為以下幾個方面：
1、空值處理：可捕獲欄位空值，進行載入或替換為其他含義資料，並可根據欄位空值實現分流載入到不同目標庫。
2、規範化資料格式：可實現欄位格式約束定義，對於資料來源中時間、數值、字元等資料，可自定義載入格式。
3、拆分資料：依據業務需求對欄位可進行分解。例，主叫號 861082585313-8148，可進行區域碼和電話號碼分解。
4、驗證資料正確性：可利用Lookup及拆分功能進行資料驗證。例如，主叫號861082585313-8148，進行區域碼和電話號碼分解後，可利用Lookup返回主叫閘道器或交換機記載的主叫地區，進行資料驗證。
5、資料替換：對於因業務因素，可實現無效資料、缺失資料的替換。
6、Lookup：查獲丟失資料 Lookup實現子查詢，並返回用其他手段獲取的缺失欄位，保證欄位完整性。
7、建立ETL過程的主外來鍵約束：對無依賴性的非法資料，可替換或匯出到錯誤資料檔案中，保證主鍵唯一記錄的載入。

根據以往資料倉庫專案的經驗，在一個數據倉庫專案中，ETL設計和實施的工作量一般要佔總專案工作量的40%-60%，而且資料倉庫專案一般會存在二次需求的問題，客戶在專案的實施過程中或者使用過程中會提出新的業務需求，而任何前端業務模型的改變都會涉及到ETL設計，因此ETL工具的選擇對於整個資料倉庫專案的成功是非常重要的。

選型

ETL工具的典型代表有:Informatica powercenter、Datastage、Oracle OWB(oracle warehouse builder)、ODI、微軟DTS、Beeload、Kettle、Talend 、DataSprider、Spark、等等……

開源的工具有eclipse的etl外掛:CloverETL和Octupus

在購買現成的工具之外，還有自己從頭開發ETL程式的。

ETL工作看起來並不複雜，特別是在資料量小、沒有什麼轉換邏輯的時候，自己開發似乎非常節省成本。的確，主流的ETL工具價格不菲，動輒幾十萬；而從頭開發無非就是費點人力而已，可以控制。至於效能，人大多是相信自己的，認為自己開發出來的東西知根知底，至少這些程式可以完全由自己控制。

就目前自主開發的ETL程式而言，有人用c語言編寫，有人用儲存過程，還有人用各種語言混雜開發，程式之間各自獨立。這很危險，雖然能夠讓開發者過足編碼的癮，卻根本不存在架構。

有位銀行的朋友，他們幾年前上的資料倉庫系統，就是整合商自己用c語言專門為他們的專案開發的。單從效能上看似乎還不賴，然而一兩年下來，專案組成員風雨飄零，早已物是人非，只有那套程式還在那裡；而且，按照國內目前的軟體工程慣例，程式註釋和文件是不全或者是不一致的，這樣的程式已經對日常業務造成很大阻礙。最近，他們已經開始考慮使用ETL工具重新改造了。

擴充套件閱讀

資料倉庫專案應該如何選擇ETL工具：ETL or E-LT? http://blog.csdn.net/mengdebin/article/details/41151533

資料儲存

資料集市（Data Marts）

為了特定的應用目的或應用範圍，而從資料倉庫中獨立出來的一部分資料，也可稱為部門資料或主題資料（subjectarea）。在資料倉庫的實施過程中往往可以從一個部門的資料集市著手，以後再用幾個資料集市組成一個完整的資料倉庫。需要注意的就是再實施不同的資料集市時，同一含義的欄位定義一定要相容，這樣再以後實施資料倉庫時才不會造成大麻煩。

資料倉庫管理

安全和特權管理；跟蹤資料的更新；資料質量檢查；管理和更新元資料；審計和報告資料倉庫的使用和狀態；刪除資料；複製、分割和分發資料；備份和恢復；儲存管理。

選型

在大資料時代，資料倉庫的重要性更勝以往。Hadoop平臺下的Hive，Spark平臺下的Spark SQL都是各自生態圈內應用最熱門的配套工具，而它們的本質就是開源分散式資料倉庫。

在國內最優秀的網際網路公司裡(如阿里、騰訊)，很多資料引擎是架構在資料倉庫之上的(如資料分析引擎、資料探勘引擎、推薦引擎、視覺化引擎等等)。不少員工認為，開發成本應更多集中在資料倉庫層，不斷加大資料建設的投入。因為一旦規範、標準、高效能的資料倉庫建立好了，在之上進行資料分析、資料探勘、跑推薦演算法等都是輕鬆愜意的事情。
反之如果業務資料沒梳理好，各種髒亂資料會搞得人焦頭爛額，苦不堪言。

資料訪問

資料倉庫通常需要提供具有直接訪問資料倉庫功能的前端應用，這些應用也被稱為BI(商務智慧)應用

有資料查詢和報表工具

應用開發工具

經理資訊系統（EIS）工具

聯機分析處理（OLAP）工具

資料倉庫建設好以後，使用者就可以編寫SQL語句對其進行訪問並對其中資料進行分析。但每次查詢都要編寫SQL語句的話，未免太麻煩，而且對維度建模資料進行分析的SQL程式碼套路比較固定。

於是，便有了OLAP工具，它專用於維度建模資料的分析。而BI工具則是能夠將OLAP的結果以圖表的方式展現出來，它和OLAP通常出現在一起。(注：本文所指的OLAP工具均指代這兩者。)

這種情況下，OLAP不允許訪問中心資料庫。一方面中心資料庫是採取規範化建模的，而OLAP只支援對維度建模資料的分析；另一方面規範化資料倉庫的中心資料庫本身就不允許上層開發人員訪問。而在維度建模資料倉庫中，OLAP/BI工具和資料倉庫的關係則是這樣的：

在維度建模資料倉庫中，OLAP不但可以從資料倉庫中直接取數進行分析，還能對架構在其上的資料集市群做同樣工作。

資料探勘工具。

資訊釋出系統

把資料倉庫中的資料或其他相關的資料傳送給不同的地點或使用者。基於Web的資訊釋出系統是對付多使用者訪問的最有效方法。

資料視覺化選型

pentaho

FineBI

案例

facebook的ppt上了解到的是他們在hive上做大資料量的分析，計算結果放到oracle上做BI展示和計算 hadoop MR or hive上ETL計算完的結果表，同步到oracle中，連線傳統BI工具，呈現報表，阿里、騰訊、盛大都是這樣的

與傳統資料庫的對比

企業的資料處理大致分為兩類：
一類是操作型處理，也稱為聯機事務處理，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。
另一類是分析型處理，一般針對某些主題的歷史資料進行分析，支援管理決策。

資料庫：傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。

資料倉庫：資料倉庫系統的主要應用主要是OLAP（On-Line Analytical Processing），支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。

舉個最常見的例子，拿電商行業來說好了。基本每家電商公司都會經歷，從只需要業務資料庫到要資料倉庫的階段。

電商早期啟動非常容易，入行門檻低。找個外包團隊，做了一個可以下單的網頁前端 + 幾臺伺服器 + 一個MySQL，就能開門迎客了。這好比手工作坊時期。

第二階段，流量來了，客戶和訂單都多起來了，普通查詢已經有壓力了，這個時候就需要升級架構變成多臺伺服器和多個業務資料庫（量大+分庫分表），這個階段的業務數字和指標還可以勉強從業務資料庫裡查詢。初步進入工業化。

第三個階段，一般需要 3-5 年左右的時間，隨著業務指數級的增長，資料量的會陡增，公司角色也開始多了起來，開始有了 CEO、CMO、CIO，大家需要面臨的問題越來越複雜，越來越深入。

高管們關心的問題，從最初非常粗放的：“昨天的收入是多少”、“上個月的 PV、UV 是多少”，逐漸演化到非常精細化和具體的使用者的叢集分析，特定使用者在某種使用場景中，例如“20~30歲女性使用者在過去五年的第一季度化妝品類商品的購買行為與公司進行的促銷活動方案之間的關係”。這類非常具體，且能夠對公司決策起到關鍵性作用的問題，基本很難從業務資料庫從調取出來。

原因在於：業務資料庫中的資料結構是為了完成交易而設計的，不是為了而查詢和分析的便利設計的。

業務資料庫大多是讀寫優化的，即又要讀（檢視商品資訊），也要寫（產生訂單，完成支付）。

因此對於大量資料的讀（查詢指標，一般是複雜的只讀型別查詢）是支援不足的。而怎麼解決這個問題，此時我們就需要建立一個數據倉庫了，公司也算開始進入資訊化階段了。

資料倉庫的作用在於:資料結構為了分析和查詢的便利；只讀優化的資料庫，即不需要它寫入速度多麼快，只要做大量資料的複雜查詢的速度足夠快就行了。

那麼在這裡前一種業務資料庫（讀寫都優化）的是業務性資料庫，後一種是分析性資料庫，即資料倉庫。

最後總結一下：
資料庫 比較流行的有：MySQL, Oracle, SqlServer等
資料倉庫 比較流行的有：AWS Redshift, Greenplum, Hive等。
這樣把資料從業務性的資料庫中提取、加工、匯入分析性的資料庫就是傳統的 ETL 工作。

資料倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的儲存也較大。
為了更好地為前端應用服務，資料倉庫必須有如下幾點優點，否則是失敗的資料倉庫方案。
1.效率足夠高。
2.資料質量。
3.擴充套件性。

兩類資料庫的不同點：

1.資料組成差別 - 資料時間範圍差別

一般來講，操作型資料庫只會存放90天以內的資料，而分析型資料庫存放的則是數年內的資料。這點也是將操作型資料和分析型資料進行物理分離的主要原因。

2.資料組成差別 - 資料細節層次差別

操作型資料庫存放的主要是細節資料，而分析型資料庫中雖然既有細節資料，又有彙總資料，但對於使用者來說，重點關注的是彙總資料部分。

操作型資料庫中自然也有彙總需求，但彙總資料本身不儲存而只儲存其生成公式。這是因為操作型資料是動態變化的，因此彙總資料會在每次查詢時動態生成。

而對於分析型資料庫來說，因為彙總資料比較穩定不會發生改變，而且其計算量也比較大(因為時間跨度大)，因此它的彙總資料可考慮事先計算好，以避免重複計算。

3.資料組成差別 - 資料時間表示差別

操作型資料通常反映的是現實世界的當前狀態；而分析型資料庫既有當前狀態，還有過去各時刻的快照，分析型資料庫的使用者可以綜合所有快照對各個歷史階段進行統計分析。

4.技術差別 - 查詢資料總量和查詢頻度差別

操作型查詢的資料量少而頻率多，分析型查詢則反過來，資料量大而頻率少。要想同時實現這兩種情況的配置優化是不可能的，這也是將兩類資料庫物理分隔的原因之一。

5.技術差別 - 資料更新差別

操作型資料庫允許使用者進行增，刪，改，查；分析型資料庫使用者則只能進行查詢。

6.技術差別 - 資料冗餘差別

資料的意義是什麼？就是減少資料冗餘，避免更新異常。而如5所述，分析型資料庫中沒有更新操作。因此，減少資料冗餘也就沒那麼重要了。

例如Hive是一種資料倉庫，而資料倉庫和分析型資料庫的關係非常緊密。它只提供查詢介面，不提供更新介面，這就使得消除冗餘的諸多措施不需要被特別嚴格地執行了，可以保留冗餘。

7.功能差別 - 資料讀者差別

操作型資料庫的使用者是業務環境內的各個角色，如使用者，商家，進貨商等；分析型資料庫則只被少量使用者用來做綜合性決策。

8.功能差別 - 資料定位差別

這裡說的定位，主要是指以何種目的組織起來。操作型資料庫是為了支撐具體業務的，因此也被稱為"面向應用型資料庫"；分析型資料庫則是針對各特定業務主題域的分析任務建立的，因此也被稱為"面向主題型資料庫"。

怎麼做

1)收集和分析業務需求 確定指標

基礎資料的架構

關鍵問題
一般問題 (不完全是技術或文化，但很重要) 包括但不限於以下幾點:
業務使用者想要執行什麼樣的分析?
你現在收集的資料需要支援那些分析嗎?
資料在哪兒？
資料清洗範圍
資料的清潔度如何？
相似的資料有多個數據源嗎？
什麼樣的結構最適合核心資料倉庫 (例如維度或關係型)？
技術問題包括但不限於以下幾點:
在你的網路中要流通多少資料？它能處理嗎?
需要多少硬碟空間?
硬碟儲存需要多快？
你會使用固態還是虛擬化的儲存？

2)建立資料模型和資料倉庫的物理設計
3)定義資料來源
4)選擇資料倉庫技術和平臺
5)從操作型資料庫中抽取、淨化、和轉換資料到資料倉庫–ETL依照模型進行初始載入、增量載入、緩慢增長維、慢速變化維、事實表載入等資料整合
6)選擇訪問和報表工具
7)選擇資料庫連線軟體
8)選擇資料分析和資料展示軟體
9)更新資料倉庫–並根據業務需求制定相應的載入策略、重新整理策略、彙總策略、維護策略。

較之資料庫系統開發，資料倉庫開發只多出ETL工程部分。然而這一部分極有可能是整個資料倉庫開發流程中最為耗時耗資源的一個環節。
因為該環節要整理各大業務系統中雜亂無章的資料並協調元資料上的差別，所以工作量很大。在很多公司都專門設有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。