金融公司的數據倉庫的結構

1. 數據倉庫的技術結構有哪些

? （一）數據源 是數據倉庫系統的基礎，是整個系統的數據源泉。通常包括企業內部信息和外部信息。內部信息包括存放於 RDBMS 中的各種業務處理數據和各類文檔數據。外部信息包括各類法律法規、市場信息和競爭對手的信息等等； （二）數據的存儲與管理 是整個數據倉庫系統的核心。數據倉庫的真正關鍵是數據的存儲和管理。數據倉庫的組織管理方式決定了它有別於傳統資料庫，同時也決定了其對外部數據的表現形式。要決定採用什麼產品和技術來建立數據倉庫的核心，則需要從數據倉庫的技術特點著手分析。針對現有各業務系統的數據，進行抽取、清理，並有效集成，按照主題進行組織。數據倉庫按照數據的覆蓋范圍可以分為企業級數據倉庫和部門級數據倉庫（通常稱為數據集市）。 （三）OLAP(聯機分析處理)伺服器 對分析需要的數據進行有效集成，按多維模型予以組織，以便進行多角度、多層次的分析，並發現趨勢。其具體實現可以分為：ROLAP（關系型在線分析處理）、MOLAP（多維在線分析處理）和 HOLAP（混合型線上分析處理）。ROLAP 基本數據和聚合數據均存放在 RDBMS 之中；MOLAP 基本數據和聚合數據均存放於多維資料庫中；HOLAP 基本數據存放於RDBMS 之中，聚合數據存放於多維資料庫中。 （四）前端工具 主要包括各種報表工具、查詢工具、數據分析工具、數據挖掘工具以數據挖掘及各種基於數據倉庫或數據集市的應用開發工具。其中數據分析工具主要針對 OLAP 伺服器，報表工具、數據挖掘工具主要針對數據倉庫。 ----------------------------- 由安信公司歷經 4 年研發的監測數據管理平台，採用獨創的技術架構，在 B/S 架構上融入 C/S 模式，囊括了實驗室管理系統、監測站辦公自動化、監測站綜合業務管理系統、監測數據上報系統等諸多系統，把各個系統有機融合在一起，不同的業務科室展現不同工作頁面，內部卻又實現了數據共享。 系統頁面簡單大方，操作輕松方便，在不增加實驗室工作量的情況下，能夠讓監測數據進入系統中，原始記錄單等諸多實驗室報表可協助生成（不完全生成，需人工簽字），隨後科室比如質控、綜合、主管領導即可對數據進行多層次利用查詢，並自動生成各類監測報表。 系統採用流程化工作模式，對不同監測任務實施不同工作流，保證工作的科學和嚴謹，對於單位內部職工每天待辦事宜清晰顯示，讓內部職工對每天工作都一目瞭然。系統工作流程可自由配置，工作單可根據按照配置流轉相應單位，並且可以對工作流程進行追蹤查詢，作為領導可以查看到每一項安排工作的流轉情況、完成情況和監測結果。 系統支持簡訊功能，對於領導等科室一些緊急任務可在系統下達後，立刻用簡訊通知相應工作人員，對於單位緊急通知等也可以進行簡訊通知，讓監測站的工作更加快捷高效。 系統提供深層次數據挖掘功能，能夠根據監測數據，快速提供某監測點的多方位數據，比如歷年來某月COD 的監測數據變化，幾年來某項監測數據的月平均值變化等等，為監測站領導決策提供科學依據。 系統生成報表功能強大，除自身已包含眾多報表外，可迅速生成 WORD 下各種客戶要求的監測報表，並且查閱維護方便。 系統作為平台拓展性強，可以融合其他系統與平台上，並且後期功能升級方便不影響前期功能。 目前系統已經在多個地 方監測站運行，從使用效果來看是比較實用的。

2. 典型的數據倉庫系統包括哪幾部分

典型的數據倉庫系統包括以下幾個部分：
數據源
ETL(數據抽取、轉換和載入)
數據倉庫
數據集市
前端展示（包括報表、多維展示等）

3. 怎樣的架構設計才是真正的數據倉庫架構

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。



• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；


• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；


• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。


• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：


• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。


• 我們從下往上看：


• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。



• 數據源的種類比較多：



• 網站日誌：



• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，


• 一般是在每台網站日誌伺服器上部署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開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。

4. 哪種數據倉庫架構最成功

」的爭論一直沒有休止，這個問題同時也是企業在建立DW時需要決策的關鍵問題。Bill Inmon的集線器架構/企業信息工廠架構（Hub and Spoke / CIF – Corporate Information Factory）與Ralph Kimball的數據集市/數據倉庫匯流排架構（Data Mart Bus Architecture/Data Warehouse Bus Architecture）則是DW架構的爭論焦點。但是，這些爭論一直無法形成統一的結論。到底哪種DW架構最好，不同的BI/DW從業者在不同的項目中，面對不同企業的不同情況時，往往持有不同的說法。2005 年，Thilini Ariyachandra 與Hugh Watson針對DW架構做了一個深入的調查，調查題目為「哪種數據倉庫最成功？」，受訪者由454位曾在各種不同規模的企業（絕大多數是美國企業）中參與了DW規劃與實施的人員組成，受訪者根據DW應用實際情況及經驗體會做出回答。為了合理設計調查問卷，在調查問卷中合理設置調查對象（參與調查的DW架構）和評判標准（影響DW架構選擇的因素及判斷DW架構成功的因素等）等內容，Watson和Ariyachandra邀請了20位專家組成專家組設計調查問卷及判斷標准等，這20位專家包括了DW領域的兩位先驅——赫赫有名的Bill Inmon和Ralph Kimball。因此我們可以認為這份調查的結果是權威可信的。

5. 數據倉庫的技術結構有哪些

是這個么
不懂哎
O(∩_∩)O~
(一)
數據源
是
數據倉庫
系統的
基礎
，是整個系統的數據源泉。通常包括企業
內部信息
和
外部信息
。內部信息包括存放於RDBMS中的各種業務處理數據和各類
文檔
數據。外部信息包括各類法律法規、
市場信息
和
競爭對手
的信息等等;
(二)數據的存儲與管理
是整個數據倉庫系統的
核心
。數據倉庫的真正
關鍵
是數據的存儲和管理。數據倉庫的組織管理方式決定了它有別於
傳統資料庫
，
同時
也決定了其對
外部數據
的表現形式。要決定採用什麼產品和技術來建立數據倉庫的核心，則需要從數據倉庫的技術特點著手分析。針對現有各業務系統的數據，進行抽取、清理，並有效集成，按照主題進行組織。數據倉庫按照數據的
覆蓋范圍
可以分為
企業級數據倉庫
和部門級數據倉庫(通常稱為
數據集市
)。
(三)OLAP(聯機分析處理)
伺服器
對分析需要的數據進行有效集成，按多維
模型
予以組織，以便進行
多角度
、多層次的分析，並發現
趨勢
。其具體實現可以分為:ROLAP(關系型在線分析處理)、MOLAP(多維在線分析處理)和HOLAP(混合型線上分析處理)。ROLAP基本數據和
聚合數據
均存放在RDBMS之中;MOLAP基本數據和聚合數據均存放於
多維資料庫
中;HOLAP基本數據存放於RDBMS之中，聚合數據存放於多維資料庫中。
(四)
前端
工具
主要包括各種
報表工具
、查詢工具、數據分析工具、
數據挖掘工具
以數據挖掘及各種基於數據倉庫或數據集市的應用開發工具。其中數據分析工具主要針對OLAP伺服器，報表工具、數據挖掘工具主要針對數據倉庫。

6. 如何建立企業級數據倉庫

隨著計算機應用的深入，大量數據存儲在計算機中，信息的存儲、管理、使用和維護顯得越來越重要，而傳統的資料庫管理系統很難滿足其要求。為了解決大數據量、異構數據集成以及訪問數據的響應速度問題，採用數據倉庫技術，為最終用戶處理所需的決策信息提供有效方法。
1 數據倉庫
數據倉庫是為管理人員進行決策提供支持的一種面向主題的、集成的、非易失的並隨時間而變化的數據集合。數據倉庫是一種作為決策支持系統和聯機分析應用數據源的結構化數據環境。
從目前數據倉庫的發展來講，數據可以存放於不同類型的資料庫中，數據倉庫是將異種數據源在單個站點以統一的模型組織的存儲，以支持管理決策。數據倉庫技術包括數據清理、數據集成、聯機分析處理（OLAP）和數據挖掘（DM）。OLAP是多維查詢和分析工具，支持決策者圍繞決策主題對數據進行多角度、多層次的分析。OLAP側重於交互性、快速的響應速度及提供數據的多維視圖，而DM則注重自動發現隱藏在數據中的模式和有用信息。OLAP的分析結果可以給DM提供分析信息，作為挖掘的依據；DM可以拓展OLAP分析的深度，可以發現OLAP所不能發現的更為復雜、細致的信息。OLAP是聯機分析處理，DM是通過對資料庫、數據倉庫中的數據進行分析而獲得知識的方法和技術，即通過建立模型來發現隱藏在組織機構資料庫中的模式和關系。這兩者結合起來可滿足企業對數據整理和信息提取的要求，幫助企業高層做出決策。在歐美發達國家，以數據倉庫為基礎的在線分析處理和數據挖掘應用，首先在金融、保險、證券、電信等傳統數據密集型行業取得成功。IBM、oracle、Teradata、Microsoft、Netezza和SAS等有實力的公司相繼推出了數據倉庫解決方案。
近幾年開始流行「分布式數據倉庫」，是在多個物理位置應用全局邏輯模型。數據被邏輯地分成多個域，但不同位置不會有重復的數據。這種分布式方法可以為不同的物理數據創建安全區域，或為全球不同時區的用戶提供全天候的服務。此外，有由Kognitio發起數據倉庫託管服務，即DBMS廠商為客戶開發和運行數據倉庫。這種最初出現在業務部門，業務部門購買託管服務，而不是使用企業內IT部門提供的數據倉庫。
2 數據挖掘技術
數據挖掘（DataMining），又稱資料庫中的知識發現（KnoWledge Discoveryin Database，KDD），是指從大型資料庫或數據倉庫中提取隱含的、未知的、非平凡的及有潛在應用價值並最終可為用戶理解的模式過程。它是資料庫研究中的很有應用價值的新領域，是人工智慧、機器學習、數理統計學和神經元網路等技術在特定的數據倉庫領域中的應用。數據挖掘的核心模塊技術歷經數十年的發展，其中包括數理統計、人工智慧、機器學習。從技術角度看，數據挖掘是從大量的、不完全的、有雜訊的、模糊的、隨機的實際數據中，提取隱含在其中的、人們所不知道的、但又是潛在有用的信息和知識的過程。從商業應用角度看，數據挖掘是嶄新的商業信息處理技術，其主要特點是對商業資料庫中的大量業務數據進行抽取、轉化、分析和模式化處理，從中提取輔助商業決策的關鍵知識。
從技術角度講，數據挖掘可應用於以下方面：
（1）關聯規則發現是在給定的事物集合中發現滿足一定條件的關聯規則，簡單來講，就是挖掘出隱藏在數據間的相互關系，為業務主題提供指導。
（2）序列模式分析和關聯規則發現相似，但其側重點在於分析數據間的前後關系。模式是按時間有序的。序列模式發現是在與時間有關的事物資料庫中發現滿足用戶給定的最小支持度域值的所有有序序列。
（3）分類分析與聚類分析，分類規則的挖掘實際上是根據分類模型從數據對象中發現共性，並把它們分成不同的類的過程。聚類時間是將d維空間的n個數據對象，劃分到k個類中，使得一個類內的數據對象間的相似度高於其他類中數據對象。聚類分析可以發現沒有類別標記的一組數據對象的特性，總結出一個類別的特徵。
（4）自動趨勢預測，數據挖掘能自動在大型資料庫裡面尋找潛在的預測信息。一個典型的利用數據挖掘進行預測的例子就是目標營銷。數據挖掘工具可以根據過去郵件推銷中的大量數據找出其中最有可能對將來的郵件推銷作出反應的客戶。
3 聯機分析（OLAP）處理技術
聯機分析（OLAP）是數據倉庫實現為決策提供支持的重要工具，是共享多維信息，針對特定問題的聯機數據訪問和分析的快速軟體技術。是使分析人員、管理人員或執行人員能夠從多種角度對從原始數據中轉化出來，能夠真正為用戶所理解，並真實反映企業維特性的信息進行快速、一致、交互地存取，從而獲得對數據的更深入了解的一類軟體技術（OLAP委員會的定義）。OLAP的特性包括：①快速性：系統應能在5s內對用戶的大部分分析要求做出反應；②可分析性：能處理與應用有關的任何邏輯分析和統計分析；⑨多維性：多維性是OLAP的關鍵屬性。系統必須提供對數據的多維視圖和分析，包括對層次維和多重層次維的完全支持；④信息性：系統應能及時獲得信息，並能管理大容量信息。
OLAP的數據結構是多維，目前存在方式：①超立方結構（Hypercube），指用三維或更多的維數來描述一個對象，每個維彼此垂直。數據的測量值發生在維的交叉點上，數據空間的各部分都有相同的維屬性（收縮超立方結構。這種結構的數據密度更大，數據的維數更少，並可加入額外的分析維）；②多立方結構（Multicube），即將超立方結構變為子立方結構。面向某特定應用對維分割，它具有強靈活性，提高了數據（特別是稀疏數據）的分析效率。分析方法包括：切片、切塊、旋轉、鑽取等。
OLAP也被稱為共享的多維數據的快速分析FASMI，應用在數據密集型行業，如市場和銷售分析、電子商務的分析、基於歷史數據的營銷、預算、財務報告與整合、管理報告、利益率、質量分析等。
4 小 結
採用數據倉庫的數據挖掘及聯機分析技術實現的決策支持系統，是彌補傳統輔助決策系統能力不足的有效途徑，具有重要的現實意義。

7. 數據倉庫三層結構中的組成部分是

數據倉庫資料庫

是整個數據倉庫環境的核心，是數據存放的地方和提供對數據檢索的支持。相對於操縱型資料庫來說其突出的特點是對海量數據的支持和快速的檢索技術。

數據抽取工具

把數據從各種各樣的存儲方式中拿出來，進行必要的轉化、整理，再存放到數據倉庫內。對各種不同數據存儲方式的訪問能力是數據抽取工具的關鍵，應能生成COBOL程序、MVS作業控制語言（JCL）、UNIX腳本、和SQL語句等，以訪問不同的數據。數據轉換都包括，刪除對決策應用沒有意義的數據段；轉換到統一的數據名稱和定義；計算統計和衍生數據；給缺值數據賦給預設值；把不同的數據定義方式統一。

元數據

元數據是描述數據倉庫內數據的結構和建立方法的數據。可將其按用途的不同分為兩類，技術元數據和商業元數據。

技術元數據是數據倉庫的設計和管理人員用於開發和日常管理數據倉庫是用的數據。包括：數據源信息；數據轉換的描述；數據倉庫內對象和數據結構的定義；數據清理和數據更新時用的規則；源數據到目的數據的映射；用戶訪問許可權，數據備份歷史記錄，數據導入歷史記錄，信息發布歷史記錄等。

商業元數據從商業業務的角度描述了數據倉庫中的數據。包括：業務主題的描述，包含的數據、查詢、報表；

元數據為訪問數據倉庫提供了一個信息目錄（informationdirectory），這個目錄全面描述了數據倉庫中都有什麼數據、這些數據怎麼得到的、和怎麼訪問這些數據。是數據倉庫運行和維護的中心，數據倉庫伺服器利用他來存貯和更新數據，用戶通過他來了解和訪問數據。

訪問工具

為用戶訪問數據倉庫提供手段。有數據查詢和報表工具；應用開發工具；管理信息系統（EIS）工具；在線分析（OLAP）工具；數據挖掘工具。

數據集市（DataMarts）

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

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

信息發布系統：把數據倉庫中的數據或其他相關的數據發送給不同的地點或用戶。基於Web的信息發布系統是對付多用戶訪問的最有效方法。

8. 數據倉庫的構造設計

數據倉庫具有改變業務的威力。它能幫助公司深入了解客戶行為，預測銷售趨勢，確定某一組客戶或產品的收益率。盡管如此，數據倉庫的實現卻是一個長期的、充滿風險的過程。由 DM Review 發布的一項網路調查顯示， 51% 受訪者認為創建數據倉庫的頭號障礙是缺乏准確的數據。而其中最重要的一點是無法實時更新所有的數據。
有六項指導原則可幫助企業快速實現數據倉庫計劃並評估其過程：
·簡化需求收集和設計。
公司通常會難以確定，哪些數據重要，哪些使得他們無法利用有價值的非結構化信息來驅動關鍵業務流程。組織應該檢查一下 IT 經理是否深入理解業務計劃以及支持計劃所需的信息。例如源數據在哪裡？需要怎樣的轉換能讓其為關鍵應用程序所用？
·支持業務和 IT 用戶協作。
不完整、過時或不準確的數據會導致可信信息的缺乏。要注意公司是否有一個業務術語表供用戶查看、用於協作並根據他們集體業務視角進行調整？
·避免代價高昂的低級錯誤和返工。
明確公司是否擁有一個包含界定完善的數據模型的實施策略，應用程序提供信息？
·識別匹配信息，創建單一視圖。
同一事實的多個版本會導致在管理用戶、產品和合作夥伴關系方面出現問題——增加違反法規遵從性的風險。
·使用最快的、最具伸縮性的方法進行轉換和發布。
明確公司是否有能夠利用並行處理並重用之前轉換成果的自動化過程？公司系統能否及時按需將數據發布給用戶和應用程序？
·通過信息服務擴展信息可訪問性。
明確企業是否能真正將信息用作共有財產？IT 專家能否保存好這些財產並讓被授權者使用？信息能否在合適的時間發布到合適的地方和合適的場景下？