資料倉儲與運算元據庫有何聯絡和區別

1樓：默魚拉里

呃,簡單點說.

資料倉儲是乙個概念.是資料庫乙個應用方向,從現有乙個或者多個生產系統中抽取資料.經過所謂的"抽取,轉換,清洗"的過程.把資料整合在一起,同時利用多個生產系統的資料,來經營應用.

特點是對資料進行大量長時間的累積.從而滿足分析應用.

2樓：派可資料

首先我們來了解資料倉儲和資料庫分別是什麼：

1、資料庫:是一種邏輯概念，用來存放資料的倉庫，通過資料庫軟體來實現。資料庫由很多表組成，表是二維的，一張表裡面有很多字段。

字段一字排開，對資料就一行一行的寫入表中。資料庫的表，在於能夠用二維表現多維的關係。如：

oracle、db2、mysql、sybase、mssql server等。

2、資料倉儲：是資料庫概念的公升級。從邏輯上理解，資料庫和資料倉儲沒有區別，都是通過資料庫軟體實現存放資料的地方，只不過從資料量來說，資料倉儲要比資料庫更龐大德多。

資料倉儲主要用於資料探勘和資料分析，輔助領導做決策；

區別主要總結為以下幾點：

1.資料庫只存放在當前值，資料倉儲存放歷史值；

2.資料庫內資料是動態變化的，只要有業務發生，資料就會被更新，而資料倉儲則是靜態的歷史資料，只能定期新增、重新整理；

3.資料庫中的資料結構比較複雜，有各種結構以適合業務處理系統的需要，而資料倉儲中的資料結構則相對簡單；

4.資料庫中資料訪問頻率較高，但訪問量較少，而資料倉儲的訪問頻率低但訪問量卻很高；

5.資料庫中資料的目標是面向業務處理人員的，為業務處理人員提供資訊處理的支援，而資料倉儲則是面向高層管理人員的，為其提供決策支援；

6.資料庫在訪問資料時要求響應速度快，其響應時間一般在幾秒內，而資料倉儲的響應時間則可長達數幾小時

3樓：愛可生雲資料庫

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

整合公司所有業務資料，建立統一的資料中心；

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

為**運營提供運營上的資料支援，就是通過資料，讓運營及時了解**和產品的運營效果；

為各個業務提供線上或線下的資料支援，成為公司統一的資料交換與提供平台；

分析使用者行為資料，通過資料探勘來降低投入成本，提高投入效果；比如廣告定向精準投放、使用者個性化推薦等；

開發資料產品，直接或間接為公司盈利；

建設開放資料平台，開放公司資料；

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

其實，網際網路行業的資料倉儲就是所謂的敏捷資料倉儲，不但要求能快速的響應資料，也要求能快速的響應業務；

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

這塊是後話。

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

請點選輸入**描述

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

我們從下往上看：

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

資料來源的種模擬較多：

作為網際網路行業，**日誌佔的份額最大，**日誌儲存在多台**日誌伺服器上，

一般是在每台**日誌伺服器上部署flume agent，實時的收集**日誌並儲存到hdfs上；

業務資料庫：

當然，flume通過配置與開發，也可以實時的從資料庫中同步資料到hdfs。

來自於ftp/http的資料來源：

有可能一些合作夥伴提供的資料，需要通過ftp/http等定時獲取，datax也可以滿足該需求；

其他資料來源：

比如一些手工錄入的資料，只需要提供乙個介面或小程式，即可完成；

資料儲存與分析毋庸置疑，hdfs是大資料環境下資料倉儲/資料平台最完美的資料儲存解決方案。

離線資料分析與計算，也就是對實時性要求不高的部分，在我看來，hive還是首當其衝的選擇，豐富的資料型別、內建函式；壓縮比非常高的orc檔案儲存格式；非常方便的sql支援，使得hive在基於結構化資料上的統計分析遠遠比mapreduce要高效的多，一句sql可以完成的需求，開發mr可能需要上百行**；

實時計算部分，後面單獨說。

資料共享這裡的資料共享，其實指的是前面資料分析與計算後的結果存放的地方，其實就是關係型資料庫和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實時獲取。

任務排程與監控在資料倉儲/資料平台中，有各種各樣非常多的程式和任務，比如：資料採集任務、資料同步任務、資料分析任務等；

這些任務除了定時排程，還存在非常複雜的任務依賴關係，比如：資料分析任務必須等相應的資料採集任務完成後才能開始；資料同步任務需要等資料分析任務完成後才能開始；這就需要乙個非常完善的任務排程與監控系統，它作為資料倉儲/資料平台的中樞，負責排程和監控所有任務的分配與執行。

前面有寫過文章，《大資料平台中的任務排程與監控》,這裡不再累贅。

請點選輸入**描述

簡述資料倉儲與關聯式資料庫的區別與聯絡

4樓：路堯家的顧小言

區別：1、資料庫是面向事務的設計，資料倉儲是面向主題設計的。

4、資料庫設計是盡量避免冗餘，一般採用符合正規化的規則來設計，資料倉儲在設計是有意引入冗餘，採用反正規化的方式來設計。

5、資料庫是為捕獲資料而設計，資料倉儲是為分析資料而設計，它的兩個基本的元素是維表和事實表。

聯絡：資料倉儲，是在資料庫已經大量存在的情況下，為了進一步挖掘資料資源、為了決策需要而產生的，資料倉儲的出現，並不是要取代資料庫。目前，大部分資料倉儲還是用關聯式資料庫管理系統來管理的。

可以說，資料庫、資料倉儲相輔相成、各有千秋。

5樓：派可資料