❶ 數據倉庫的定義
目前，大家公認的數據倉庫創始人W H.Inmon在他所著的《建立數據倉庫》一書中對數據倉庫所下的定義;數據倉庫就是面向主題的、集成的、穩定的、不同時間的數據集合，用以支持經營管理中的決策制定過程。數據倉庫中的數據面向主題與傳統的資料庫面向應用相對應。主題是一個在較高層次將數據歸類的標准，每一個主題對應一個宏觀的分析領域。數據倉庫的集成特性是指在數據進入數據倉庫之前，必須進行數據加丁一和集成，這是建立數據倉庫的關鍵步驟，首先要統一原始數據中的矛盾之處，還要將原始數據結構做一個從面向應用向面向主題的轉變，數據倉庫的穩定性是指數據倉庫反映的是歷史數據的內容，而不是日常事務處理產生的數據，數據經加工和集成進入數據倉庫後是很少修改或根本不修改的;數據倉庫是不同時間的數據集合，它要求數據倉庫中的數據保存時限能滿足進行決策分析的需要，而且數據倉庫中的數據都要標明該數據的歷史時期。
數據倉庫最根本的特點是物理地存放數據，而且這些數據並不是最新的、專有的，而是來源於其他資料庫，它要建立在一個較全面和完善的信息應用的基礎上，用於支持高層決策分析，而事務處理資料庫在企業的信息環境!!，承擔的是日常操作性的任務，數據倉庫是資料庫技術的一種新的應用，到目前為止，數據倉庫還是用資料庫管理系統來管理其中的數據。
❷ 什麼是數據倉庫，數據倉庫在哪裡保存數據。BI項目需要用到哪些技術
一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。先大概列一下互聯網行業數據倉庫、數據平台的用途：
整合公司所有業務數據，建立統一的數據中心；
提供各種報表，有給高層的，有給各個業務的；
為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；
為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；
分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發數據產品，直接或間接為公司盈利；
建設開放數據平台，開放公司數據；
。。。。。。
上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：
邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
我們從下往上看：
數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。
數據源的種類比較多：
網站日誌：
作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；
業務資料庫：
業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。
當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。
來自於Ftp/Http的數據源：
有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數據源：
比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；
數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；
當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
實時計算部分，後面單獨說。
數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
數據應用
業務產品
業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；
報表
同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
即席查詢
即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；
這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；
比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。
其它數據介面
這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。
實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。
我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。
做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。
任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；
這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。
前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。
總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。
❸ 什麼是數據倉庫
數據倉庫（DataWareHouse），簡稱為DW，是為給企業所有級別的決策制定過程，提供所有類型數據支持的戰略集合。被認為是商業智能的核心組件，由比爾·恩門於1990年提出。它是信息的中央存儲庫，出於分析性報告和決策支持目的而創建。
❹ 什麼是數據倉庫
1、面向主題。操作型資料庫的數據組織面向事務處理任務，各個業務系統之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織。主題是一個抽象的概念，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。
2、集成的。面向事務處理的操作型資料庫通常與某些特定的應用相關，資料庫之間相互獨立，並且往往是異構的。而數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
3、相對穩定的。操作型資料庫中的數據通常實時更新，數據根據需要及時發生變化。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、刷新。
4、反映歷史變化。操作型資料庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
企業數據倉庫的建設，是以現有企業業務系統和大量業務數據的積累為基礎。數據倉庫不是靜態的概念，只有把信息及時交給需要這些信息的使用者，供他們做出改善其業務經營的決策，信息才能發揮作用，信息才有意義。而把信息加以整理歸納和重組，並及時提供給相應的管理決策人員，是數據倉庫的根本任務。因此，從產業界的角度看，數據倉庫建設是一個工程，是一個過程。
❺ 數據倉庫的特點
1、數據倉庫是面向主題的；操作型資料庫的數據組織面向事務處理任務，而數據倉庫中的數據是按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。
2、數據倉庫是集成的，數據倉庫的數據有來自於分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合之後才能進入數據倉庫；
數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、刷新。
數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到當前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
3、數據倉庫是不可更新的，數據倉庫主要是為決策分析提供數據，所涉及的操作主要是數據的查詢；
4、數據倉庫是隨時間而變化的，傳統的關系資料庫系統比較適合處理格式化的數據，能夠較好的滿足商業商務處理的需求。穩定的數據以只讀格式保存，且不隨時間改變。
5、匯總的。操作性數據映射成決策可用的格式。
6、大容量。時間序列數據集合通常都非常大。
7、非規范化的。Dw數據可以是而且經常是冗餘的。
8、元數據。將描述數據的數據保存起來。
9、數據源。數據來自內部的和外部的非集成操作系統。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它並不是所謂的「大型資料庫」。數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫往往有如下幾點特點：
1.效率足夠高。數據倉庫的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。
2.數據質量。數據倉庫所提供的各種信息，肯定要准確的數據，但由於數據倉庫流程通常分為多個步驟，包括數據清洗，裝載，查詢，展現等等，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。
3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，未來不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
從上面的介紹中可以看出，數據倉庫技術可以將企業多年積累的數據喚醒，不僅為企業管理好這些海量數據，而且挖掘數據潛在的價值，從而成為通信企業運營維護系統的亮點之一。正因為如此，
廣義的說，基於數據倉庫的決策支持系統由三個部件組成：數據倉庫技術，聯機分析處理技術和數據挖掘技術，其中數據倉庫技術是系統的核心，在這個系列後面的文章里，將圍繞數據倉庫技術，介紹現代數據倉庫的主要技術和數據處理的主要步驟，討論在通信運營維護系統中如何使用這些技術為運營維護帶來幫助。
4.面向主題
操作型資料庫的數據組織面向事務處理任務，各個業務系統之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織的。主題是與傳統資料庫的面向應用相對應的，是一個抽象概念，是在較高層次上將企業信息系統中的數據綜合、歸類並進行分析利用的抽象。每一個主題對應一個宏觀的分析領域。數據倉庫排除對於決策無用的數據，提供特定主題的簡明視圖。
❻ 數據倉庫的技術發展
從資料庫到數據倉庫
企業的數據處理大致分為兩類：一類是操作型處理，也稱為聯機事務處理，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。另一類是分析型處理，一般針對某些主題的歷史數據進行分析，支持管理決策。
兩者具有不同的特徵，主要體現在以下幾個方面。
1、處理性能
日常業務涉及頻繁、簡單的數據存取，因此對操作型處理的性能要求是比較高的，需要資料庫能夠在很短時間內做出反應。
2、數據集成
企業的操作型處理通常較為分散，傳統資料庫面向應用的特性使數據集成困難。
3、數據更新
操作型處理主要由原子事務組成，數據更新頻繁，需要並行控制和恢復機制。
4、數據時限
操作型處理主要服務於日常的業務操作。
5、數據綜合
操作型處理系統通常只具有簡單的統計功能。
資料庫已經在信息技術領域有了廣泛的應用，我們社會生活的各個部門，幾乎都有各種各樣的資料庫保存著與我們的生活息息相關的各種數據。作為資料庫的一個分支，數據倉庫概念的提出，相對於資料庫從時間上就近得多。美國著名信息工程專家WilliamInmON博士在90年代初提出了數據倉庫概念的一個表述，認為：「一個數據倉庫通常是一個面向主題的、集成的、隨時間變化的、但信息本身相對穩定的數據集合，它用於對管理決策過程的支持。」
這里的主題，是指用戶使用數據倉庫進行決策時所關心的重點方面，如：收入、客戶、銷售渠道等；所謂面向主題，是指數據倉庫內的信息是按主題進行組織的，而不是像業務支撐系統那樣是按照業務功能進行組織的。
集成，是指數據倉庫中的信息不是從各個業務系統中簡單抽取出來的，而是經過一系列加工、整理和匯總的過程，因此數據倉庫中的信息是關於整個企業的一致的全局信息。
隨時間變化，是指數據倉庫內的信息並不只是反映企業當前的狀態，而是記錄了從過去某一時點到當前各個階段的信息。
資料庫安全
計算機攻擊、內部人員違法行為，以及各種監管要求，正促使組織尋求新的途徑來保護其在商業資料庫系統中的企業和客戶數據。
您可以採取八個步驟保護數據倉庫並實現對關鍵法規的遵從。
1. 發現
使用發現工具發現敏感數據的變化。
2.漏洞和配置評估
評估資料庫配置，確保它們不存在安全漏洞。這包括驗證在操作系統上安裝資料庫的方式(比如檢查資料庫配置文件和可執行程序的文件許可權)，以及驗證資料庫自身內部的配置選項(比如多少次登錄失敗之後鎖定帳戶，或者為關鍵表分配何種許可權)。
3. 加強保護
通過漏洞評估，刪除不使用的所有功能和選項。
4. 變更審計
通過變更審計工具加強安全保護配置，這些工具能夠比較配置的快照(在操作系統和資料庫兩個級別上)，並在發生可能影響資料庫安全的變更時，立即發出警告。
5. 資料庫活動監控(DAM)
通過及時檢測入侵和誤用來限制信息暴露，實時監控資料庫活動。
6. 審計
必須為影響安全性狀態、數據完整性或敏感數據查看的所有資料庫活動生成和維護安全、防否認的審計線索。
7.身份驗證、訪問控制和授權管理
必須對用戶進行身份驗證，確保每個用戶擁有完整的責任，並通過管理特權來限制對數據的訪問。
8. 加密
使用加密來以不可讀的方式呈現敏感數據，這樣攻擊者就無法從資料庫外部對數據進行未授權訪問。
如何應對監控需求
數據，作為企業核心資產，越來越受到企業的關注，一旦發生非法訪問、數據篡改、數據盜取，將給企業帶來巨大損失。資料庫作為數據的核心載體，其安全性就更加重要。
面對資料庫的安全問題，企業常常遇到以下主要挑戰：資料庫被惡意訪問、攻擊、甚至遭到數據偷竊，而您不能及時地發現這些惡意的操作； 不了解數據使用者對資料庫的訪問細節，從而不能保證您對數據安全的管理；
信息安全同樣會帶來審計問題，當今全球對合規/ 審計要求越來越嚴格，由於不滿足合規要求而導致處罰的事件屢見不鮮。美國《薩班斯法案》的強制性要求曾導致2007年7月5日中國第一家海外上市公司—華晨中國汽車控股有限公司從美國紐約證券交易所退市。
有關信息安全的合規/審計要求，中國政府也進行了大量的強化工作，例如，為了加強商業銀行信息科技風險管理，銀監會出台了《商業銀行信息科技風險管理指引》規則，中國政府——財政部、證監會、銀監會、保監會及審計署等五部委會聯合發布「中國版薩班尼斯－奧克斯利法案（以下簡稱『C-SOX法案』）」——《企業內部控制基本規范》。
面對合規/審計要求，企業往往面臨以下挑戰：
·不能做到持續性審計
用戶審計主要是針對資料庫、應用系統日誌做審計，這些日誌內容非常龐大，DBA（數
據庫管理員）和信息安全審計人員的審計工作就只能做事後分析，分析時間也長。不能做到持續性審計。
·審計並不規范
用戶審計的內容和表格主要是根據外部審計人員要求和內部安全管理要素來考慮，這些
審計工作的好壞基本上取決於DBA和信息安全審計人員的經驗和技能，這些不能有效成為公司規范和滿足外部審計要求。
·資料庫管理員權責沒有完全區分開，導致審計效果問題
資料庫管理和審計原始數據的收集實際上都是由DBA來做的，這就導致了DBA的權責不明確，DBA沒辦法客觀審計自己所做的工作，盡管用戶設置了信息安全審計人員，但該角色的審計工作的部分證據建立在DBA初步審計基礎上，因此審計效果與可靠性存問題。
·審計並不完整
人工審計需要面對海量的日誌，不可能對所有數據進行細致審計；審計報告就未必能滿足
100%可見性。
為了滿足企業的信息安全、合規、審計等需求，IBM公司推出了「CARS」企業信息架構，該架構主要從「法規遵從」（Compliance）、「信息可用」(Availability)、「信息保留」(Retention)、「信息安全」(Security) 四個方面進行了全面的滿足和保護。不僅如此，IBM Guardium資料庫安全、合規、審計、監控解決方案的推出，針對了「法規遵從」和「信息安全」進行了專項治理和加強。
Guardium資料庫安全、合規、審計、監控解決方案，以軟硬體一體伺服器的方式，大大增強資料庫安全性，滿足並方便審計工作，提升性能，並簡化了安裝部署工作。可以防止對資料庫的破壞、惡意訪問、偷竊數據，可幫助判斷客戶關鍵敏感的數據在什麼地方；誰在使用這些數據；控制對資料庫中數據的訪問，並可監控特權用戶；幫助企業強制執行安全規范；檢查薄弱環節、漏洞，防止對資料庫配置的改動；滿足合規/審計的要求，並可簡化內部和外部審計、合規的過程並使其自動化，增強運作效率；管理安全的復雜性。