建站
咨詢
售后
建站咨詢
新聞中心
請問數(shù)據(jù)倉庫都用什么建立？
1、首先你得搞清楚建設數(shù)倉的目的是什么
我們提供的服務有：做網(wǎng)站、成都網(wǎng)站建設、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、資源ssl等。為上1000家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的資源網(wǎng)站制作公司
是偏向于整合各系統(tǒng)數(shù)據(jù)，為數(shù)據(jù)分析決策服務，還是偏向于快速的完成分析決策需求？
如果是前者，那么在數(shù)據(jù)倉庫建模的時候一般會選擇ER建模方法；
如果是后者，一般會選擇維度建模方法。
ER建模：即實體關系建模，由數(shù)據(jù)倉庫之父BIll Inmon提出，核心思想是從全企業(yè)的高度去設計三范式模型，用實體關系描述企業(yè)服務。主張的是自上而下的架構，將不同的OLTP數(shù)據(jù)集中到面向主題的數(shù)據(jù)倉庫中。
維度建模：由Kimball提出，核心思想是從分析決策的需求出發(fā)構建模型。這種模型由事實表和維表組成，即星型模型和雪花模型。Kimball倡導自下而上的架構，可以針對獨立部門建立數(shù)據(jù)集市，再遞增的構建，匯總成數(shù)據(jù)倉庫。
2、其次你得進行深入的業(yè)務調(diào)研和數(shù)據(jù)調(diào)研
業(yè)務調(diào)研：深入的業(yè)務調(diào)研能使你更加明確數(shù)倉建設的目的；同時也利于后續(xù)的建模設計，隨著調(diào)研的開展，如何將實體業(yè)務抽象為數(shù)倉模型會更加明朗。
數(shù)據(jù)調(diào)研：各部門或各科室的數(shù)據(jù)現(xiàn)狀了解，包括數(shù)據(jù)分類、數(shù)據(jù)存儲方式、數(shù)據(jù)量、具體的數(shù)據(jù)內(nèi)容等等。這對后續(xù)的主數(shù)據(jù)串聯(lián)或者維度一致性處理等等都是必須的基礎。
3、然后是數(shù)據(jù)倉庫工具選型
傳統(tǒng)型數(shù)據(jù)倉庫：一般會選擇第三方廠家的數(shù)據(jù)庫和配套ETL工具。因為有第三方支持，相對有保障；但缺點也很明顯，受約束以及成本較高。
NoSQL型數(shù)據(jù)倉庫：一般是基于hadoop生態(tài)的數(shù)據(jù)倉庫。hadoop生態(tài)已經(jīng)非常強大，可以找到各種開源組件去支持數(shù)據(jù)倉庫。缺點是需要招聘專門人士去摸索，并且相對會存在一些未知隱患。
4、最后是設計與實施
設計：包括數(shù)據(jù)架構中的數(shù)據(jù)層次劃分以及具體的模型設計；也包括程序架構中的數(shù)據(jù)質(zhì)量管理、元數(shù)據(jù)管理、調(diào)度管理等；
實施：規(guī)范化的項目管理實施，但同時也需記住一點，數(shù)據(jù)倉庫不是一個項目，它是一個過程。
選擇什么樣的數(shù)據(jù)倉庫架構比較好？如何選擇呢
一直想整理一下這塊內(nèi)容，既然是漫談，就想起什么說什么吧。我一直是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來說。
先大概列一下互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)平臺的用途：
整合公司所有業(yè)務數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心；
提供各種報表，有給高層的，有給各個業(yè)務的；
為網(wǎng)站運營提供運營上的數(shù)據(jù)支持，就是通過數(shù)據(jù)，讓運營及時了解網(wǎng)站和產(chǎn)品的運營效果；
為各個業(yè)務提供線上或線下的數(shù)據(jù)支持，成為公司統(tǒng)一的數(shù)據(jù)交換與提供平臺；
分析用戶行為數(shù)據(jù)，通過數(shù)據(jù)挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發(fā)數(shù)據(jù)產(chǎn)品，直接或間接為公司盈利；
建設開放數(shù)據(jù)平臺，開放公司數(shù)據(jù)；
。。。。。。
上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉庫用途差不多，并且都要求數(shù)據(jù)倉庫/數(shù)據(jù)平臺有很好的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除了數(shù)據(jù)量大之外，越來越多的業(yè)務要求時效性，甚至很多是要求實時的 ，另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務變化非?？欤豢赡芟駛鹘y(tǒng)行業(yè)一樣，可以使用自頂向下的方法建立數(shù)據(jù)倉庫，一勞永逸，它要求新的業(yè)務很快能融入數(shù)據(jù)倉庫中來，老的下線的業(yè)務，能很方便的從現(xiàn)有的數(shù)據(jù)倉庫中下線；
其實，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉庫就是所謂的敏捷數(shù)據(jù)倉庫，不但要求能快速的響應數(shù)據(jù)，也要求能快速的響應業(yè)務；
建設敏捷數(shù)據(jù)倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數(shù)據(jù)建模，如果一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設上了，很難滿足對業(yè)務變化的快速響應。應對這種情況，一般是先將核心的持久化的業(yè)務進行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務一般都采用維度+寬表的方式來建立數(shù)據(jù)模型。這塊是后話。
整體架構下面的圖是我們目前使用的數(shù)據(jù)平臺架構圖，其實大多公司應該都差不多：
請點擊輸入圖片描述
邏輯上，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應用層。可能叫法有所不同，本質(zhì)上的角色都大同小異。
我們從下往上看：
數(shù)據(jù)采集數(shù)據(jù)采集層的任務就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲到數(shù)據(jù)存儲上，期間有可能會做一些簡單的清洗。
數(shù)據(jù)源的種類比較多：
網(wǎng)站日志：
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲在多臺網(wǎng)站日志服務器上，
一般是在每臺網(wǎng)站日志服務器上部署flume agent，實時的收集網(wǎng)站日志并存儲到HDFS上；
業(yè)務數(shù)據(jù)庫：
業(yè)務數(shù)據(jù)庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動MapReduce來執(zhí)行，而且需要Hadoop集群的每臺機器都能訪問業(yè)務數(shù)據(jù)庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決，我們目前使用的DataHub也是。
當然，F(xiàn)lume通過配置與開發(fā)，也可以實時的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS。
來自于Ftp/Http的數(shù)據(jù)源：
有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數(shù)據(jù)源：
比如一些手工錄入的數(shù)據(jù)，只需要提供一個接口或小程序，即可完成；
數(shù)據(jù)存儲與分析毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最完美的數(shù)據(jù)存儲解決方案。
離線數(shù)據(jù)分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基于結構化數(shù)據(jù)上的統(tǒng)計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發(fā)MR可能需要上百行代碼；
當然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發(fā)Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算；Spark是這兩年非?；鸬?，經(jīng)過實踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經(jīng)有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關于Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
實時計算部分，后面單獨說。
數(shù)據(jù)共享這里的數(shù)據(jù)共享，其實指的是前面數(shù)據(jù)分析與計算后的結果存放的地方，其實就是關系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業(yè)務和應用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務和產(chǎn)品能方便的獲取數(shù)據(jù)；?和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個從HDFS將數(shù)據(jù)同步至其他目標數(shù)據(jù)源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數(shù)據(jù)可能由實時計算模塊直接寫入數(shù)據(jù)共享。
數(shù)據(jù)應用
業(yè)務產(chǎn)品
業(yè)務產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問即可；
報表
同業(yè)務產(chǎn)品，報表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計匯總好的，存放于數(shù)據(jù)共享層；
即席查詢
即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員、網(wǎng)站和產(chǎn)品運營人員、數(shù)據(jù)分析人員、甚至是部門老大，他們都有即席查詢數(shù)據(jù)的需求；
這種即席查詢通常是現(xiàn)有的報表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在于響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
當然，你也可以使用Impala，如果不在乎平臺中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過將需要的數(shù)據(jù)同步到關系型數(shù)據(jù)庫中做OLAP，但如果數(shù)據(jù)量巨大的話，關系型數(shù)據(jù)庫顯然不行；
這時候，需要做相應的開發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能；
比如：根據(jù)用戶在界面上選擇的不定的維度和指標，通過開發(fā)接口，從HBase中獲取數(shù)據(jù)來展示。
其它數(shù)據(jù)接口
這種接口有通用的，有定制的。比如：一個從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務都可以調(diào)用這個接口來獲取用戶屬性。
實時計算現(xiàn)在業(yè)務對數(shù)據(jù)倉庫實時性的需求越來越多，比如：實時的了解網(wǎng)站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫和傳統(tǒng)實現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那么一點點，那對于我們的需要可以忽略。
我們目前使用Spark Streaming實現(xiàn)了實時的網(wǎng)站流量統(tǒng)計、實時的廣告效果統(tǒng)計兩塊功能。
做法也很簡單，由Flume在前端日志服務器上收集網(wǎng)站日志和廣告日志，實時的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計，將數(shù)據(jù)存儲至Redis，業(yè)務通過訪問Redis實時獲取。
任務調(diào)度與監(jiān)控在數(shù)據(jù)倉庫/數(shù)據(jù)平臺中，有各種各樣非常多的程序和任務，比如：數(shù)據(jù)采集任務、數(shù)據(jù)同步任務、數(shù)據(jù)分析任務等；
這些任務除了定時調(diào)度，還存在非常復雜的任務依賴關系，比如：數(shù)據(jù)分析任務必須等相應的數(shù)據(jù)采集任務完成后才能開始；數(shù)據(jù)同步任務需要等數(shù)據(jù)分析任務完成后才能開始；?這就需要一個非常完善的任務調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，負責調(diào)度和監(jiān)控所有任務的分配與運行。
前面有寫過文章，《大數(shù)據(jù)平臺中的任務調(diào)度與監(jiān)控》,這里不再累贅。
總結在我看來架構并不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺中，開發(fā)更多的是關注業(yè)務，而不是技術，他們把業(yè)務和需求搞清楚了，基本上只需要做簡單的SQL開發(fā)，然后配置到調(diào)度系統(tǒng)就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注于業(yè)務之上。
請點擊輸入圖片描述
什么是數(shù)據(jù)倉庫，數(shù)據(jù)倉庫在哪里保存數(shù)據(jù)。BI項目需要用到哪些技術
數(shù)據(jù)倉庫還是數(shù)據(jù)庫,數(shù)據(jù)還是在數(shù)據(jù)庫里放著呢,不過是按照數(shù)據(jù)倉庫的理念去設計架構和開發(fā)數(shù)據(jù)庫.BI項目主要運用數(shù)據(jù)倉庫,OLAP,和數(shù)據(jù)挖掘的技術,細分下來又有主流數(shù)據(jù)庫的開發(fā),如oracle,db2,sqlserver, java,cognos,bo,biee,sas,spss,clementine,weka等等
數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別
數(shù)據(jù)庫是面向事務的設計，數(shù)據(jù)倉庫是面向主題設計的。數(shù)據(jù)庫一般存儲在線交易數(shù)據(jù)，數(shù)據(jù)倉庫存儲的一般是歷史數(shù)據(jù)。
“與時間相關”：數(shù)據(jù)庫保存信息的時候，并不強調(diào)一定有時間信息。數(shù)據(jù)倉庫則不同，出于決策的需要，數(shù)據(jù)倉庫中的數(shù)據(jù)都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產(chǎn)品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對于決策者意義是不同的。
“不可修改”：數(shù)據(jù)倉庫中的數(shù)據(jù)并不是最新的，而是來源于其它數(shù)據(jù)源。數(shù)據(jù)倉庫反映的是歷史信息，并不是很多數(shù)據(jù)庫處理的那種日常事務數(shù)據(jù)（有的數(shù)據(jù)庫例如電信計費數(shù)據(jù)庫甚至處理實時信息）。因此，數(shù)據(jù)倉庫中的數(shù)據(jù)是極少或根本不修改的；當然，向數(shù)據(jù)倉庫添加數(shù)據(jù)是允許的。
拓展資料：
數(shù)據(jù)倉庫的出現(xiàn)，并不是要取代數(shù)據(jù)庫。數(shù)據(jù)倉庫，是在數(shù)據(jù)庫已經(jīng)大量存在的情況下，為了進一步挖掘數(shù)據(jù)資源、為了決策需要而產(chǎn)生的，它決不是所謂的“大型數(shù)據(jù)庫”。
目前，大部分數(shù)據(jù)倉庫還是用關系數(shù)據(jù)庫管理系統(tǒng)來管理的?？梢哉f，數(shù)據(jù)庫、數(shù)據(jù)倉庫相輔相成、各有千秋。
teradata與SQL server有什么區(qū)別
一、指代不同
1、teradata：Teradata數(shù)據(jù)倉庫擁有全球領先的技術，其主要軟件和硬件產(chǎn)品包括：Teradata數(shù)據(jù)庫、Teradata數(shù)據(jù)倉庫軟件、企業(yè)數(shù)據(jù)倉庫、動態(tài)企業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)倉庫專用平臺。
2、SQL server：是由Microsoft開發(fā)和推廣的關系數(shù)據(jù)庫管理系統(tǒng)（DBMS）。
二、功能不同
1、teradata：配備性能最高、最可靠的大規(guī)模并行處理 (MPP) 平臺，能夠高速處理海量數(shù)據(jù)。使得企業(yè)可以專注于業(yè)務，無需花費大量精力管理技術，因而可以更加快速地做出明智的決策，實現(xiàn) ROI 最大化。
2、SQL server：SQL Server與Windows NT完全集成，利用了NT的許多功能，如發(fā)送和接受消息，管理登錄安全性等。SQL Server也可以很好地與Microsoft BackOffice產(chǎn)品集成。
三、優(yōu)勢不同
1、teradata：通過將 MPP 數(shù)據(jù)倉庫的優(yōu)勢與 MapReduce 引擎相結合， Aster 大數(shù)據(jù)探索平臺成為數(shù)據(jù)分析領域的殺手锏，為用戶提供交互分析功能，快速挖掘、處理潛藏于數(shù)據(jù)中的商業(yè)價值。
2、SQL server：SQL Server提供數(shù)據(jù)倉庫功能，這個功能只在Oracle和其他更昂貴的DBMS中才有。對Web技術的支持，使用戶能夠很容易地將數(shù)據(jù)庫中的數(shù)據(jù)發(fā)布到Web頁面上。
參考資料來源：百度百科-Teradata
參考資料來源：百度百科-SqlServer
分享文章：sqlserver數(shù)倉的簡單介紹
URL分享：http://www.dlmjj.cn/article/dsijjjg.html
