數(shù)據(jù)倉庫的含義,數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別？一直都想收拾好下這塊內(nèi)容，要是是漫談，就想起什么說什么吧。我始終是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來說。先大致列幫一下忙互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)平臺的用途：重新整合

數(shù)據(jù)倉庫的含義,數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別？

一直都想收拾好下這塊內(nèi)容，要是是漫談，就想起什么說什么吧。我始終是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來說。先大致列幫一下忙互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)平臺的用途：

重新整合公司所有業(yè)務(wù)數(shù)據(jù)，成立統(tǒng)一的數(shù)據(jù)中心；

能提供各種報表，有給高層的，有給各個業(yè)務(wù)的；

為網(wǎng)站運營提供給運營上的數(shù)據(jù)支持，那是按照數(shù)據(jù)，讓自主運營及時清楚網(wǎng)站和產(chǎn)品的運營效果；

為各個業(yè)務(wù)可以提供線上或線下的數(shù)據(jù)支持，下一界公司統(tǒng)一的數(shù)據(jù)交換與需要提供平臺；

分析用戶行為數(shù)據(jù)，按照數(shù)據(jù)挖掘來會降低投入成本，增強(qiáng)耗去效果；比如廣告代培生定向投放、用戶個性化推薦等；

開發(fā)數(shù)據(jù)產(chǎn)品，直接間接為公司贏利；

規(guī)劃和建設(shè)開放數(shù)據(jù)平臺，剛剛開放公司數(shù)據(jù)；

。。。。。。

上面列出來的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉庫用途應(yīng)該差不多，因此都那些要求數(shù)據(jù)倉庫/數(shù)據(jù)平臺有挺好的的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除開數(shù)據(jù)量大之外，越來越多的業(yè)務(wù)具體的要求時效性，甚至很多是要求實時動態(tài)的，另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化相當(dāng)快，不可能像傳統(tǒng)行業(yè)一樣的，可以可以使用自頂往上的方法建立數(shù)據(jù)倉庫，兩全齊美，它沒有要求新的業(yè)務(wù)馬上能融合在一起數(shù)據(jù)倉庫中來，老的下線的業(yè)務(wù)，能很方便些的從可以做到的數(shù)據(jù)倉庫中登陸游戲；

不過，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉庫是有所謂的敏捷數(shù)據(jù)倉庫，不僅僅沒有要求能快速的響應(yīng)數(shù)據(jù)，也沒有要求能飛速的響應(yīng)業(yè)務(wù)；

建成耐力數(shù)據(jù)倉庫，除開對架構(gòu)技術(shù)上的要求之外，另外一個很有用的方面，是數(shù)據(jù)建模，要是一進(jìn)來就尋思確立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，的話又又回到比較傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很容易滿足對業(yè)務(wù)變化的快速響應(yīng)。躲避這個，就像是先將核心的持久化的業(yè)務(wù)進(jìn)行深多少建模（.例如：基于組件網(wǎng)站日志成立的網(wǎng)站統(tǒng)計分析模型和用戶網(wǎng)頁軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)象都按結(jié)構(gòu)維度寬表的來建立數(shù)據(jù)模型。這塊是后話。

整體架構(gòu)下面的圖是我們目前不使用的數(shù)據(jù)平臺架構(gòu)圖，反正大多公司應(yīng)該都不多：

邏輯上，像是也有數(shù)據(jù)采集層、數(shù)據(jù)存儲與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層?？赡芙蟹ㄓ兴耆煌?，本質(zhì)上的角色都還不錯。

我們向下看：

數(shù)據(jù)采集數(shù)據(jù)采集層的任務(wù)那是把數(shù)據(jù)從各種數(shù)據(jù)源中再采集和存儲文件到數(shù)據(jù)存儲上，期間有可能會做一些簡單的擦洗。

數(shù)據(jù)源的種類比較比較多：

網(wǎng)站日志：

以及互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲位置在多臺網(wǎng)站日志服務(wù)器上，

象是在每臺網(wǎng)站日志服務(wù)器上部署flumeagent，實時動態(tài)的收集網(wǎng)站日志并存儲位置到HDFS上；

業(yè)務(wù)數(shù)據(jù)庫：

業(yè)務(wù)數(shù)據(jù)庫的種類確實是形態(tài)不同，有Mysql、Oracle、SqlServer等，這時候，我們不安的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)實時同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過忙碌不堪，但是論數(shù)據(jù)量大小，都是需要啟動后MapReduce來不能執(zhí)行，并且不需要Hadoop集群的每臺機(jī)器都能ftp連接業(yè)務(wù)數(shù)據(jù)庫；防范此場景，淘寶開源的DataX，是個挺好的的解決方案（可參考文章《異構(gòu)數(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ù)存儲與分析毋庸質(zhì)疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最終極數(shù)據(jù)存儲解決方案。

離線數(shù)據(jù)分析與計算，也就是對實時性要求不高的部分，在我看樣子，Hive應(yīng)該最先的選擇，豐富地的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比的很高的ORC文件存儲格式；非常方便的SQL意見，令Hive在實現(xiàn)結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計分析遠(yuǎn)遠(yuǎn)比MapReduce要高效穩(wěn)定的多，一句SQL也可以完成的需求，開發(fā)完畢MR很有可能需要上百行代碼；

肯定，建議使用Hadoop框架漸漸也需要提供了MapReduce接口，如果真的很給面子開發(fā)Java，或則對SQL不熟，那你也這個可以建議使用MapReduce來做分析與計算；Spark是這兩年更加火的，在實踐，它的性能真的比MapReduce好多了很多，并且和Hive、Yarn生克制化的越來越好，而，需要支持可以使用Spark和SparkSQL來做分析和計算。是因為早就有HadoopYarn，不使用Spark不過是的很很容易的，你不不能作戰(zhàn)部署Spark集群，麻煩問下Spark On Yarn的相關(guān)文章，可相關(guān)參考：《Spark On Yarn系列文章》

實時計算部分，后面另外說。

數(shù)據(jù)共享這里的數(shù)據(jù)共享，不過指的是前面數(shù)據(jù)分析與計算后的結(jié)果貯存的地方，不過應(yīng)該是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；

前面不使用Hive、MR、Spark、SparkSQL講和可以計算的結(jié)果，我還是在HDFS上，但大部分業(yè)務(wù)和應(yīng)用不可能就從HDFS上獲取數(shù)據(jù)，這樣就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能比較方便的獲取數(shù)據(jù)；和數(shù)據(jù)采集層到HDFS就反過來，這里不需要一個從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以不滿足的條件。

至于，一些實時計算的結(jié)果數(shù)據(jù)很可能由實時計算模塊再寫入文件數(shù)據(jù)共享。

數(shù)據(jù)應(yīng)用

業(yè)務(wù)產(chǎn)品

業(yè)務(wù)產(chǎn)品所在用的數(shù)據(jù)，巳經(jīng)修真者的存在于數(shù)據(jù)共享層，他們真接從數(shù)據(jù)共享層訪問表就行；

報表

同業(yè)務(wù)產(chǎn)品，報表所不使用的數(shù)據(jù)，像是也早統(tǒng)計上報好的，存放于數(shù)據(jù)共享層；

即席查詢

即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員、網(wǎng)站和產(chǎn)品運營人員、數(shù)據(jù)分析人員、甚至連是部門老大，他們也有即席查詢數(shù)據(jù)的需求；

這種即席網(wǎng)上查詢通常是現(xiàn)有的報表和數(shù)據(jù)共享層的數(shù)據(jù)并肯定不能柯西-黎曼方程他們的需求，要從數(shù)據(jù)存儲層直接可以查詢。

即席查詢好象是是從SQL成功，大的的難度在于響應(yīng)速度上，在用Hive有點慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，但能非常好的與Hive兼容性問題。

其實，你也也可以可以使用Impala，如果沒有不在乎平臺中再多一個框架的話。

OLAP

目前，很多的OLAP工具又不能很好的支持從HDFS上然后查看數(shù)據(jù)，全是將必須的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫中做OLAP，但假如數(shù)據(jù)量龐大無比的話，關(guān)系型數(shù)據(jù)庫看來再不行；

這時候，需要做你所選的開發(fā)，從HDFS或者HBase中資源數(shù)據(jù)，完成OLAP的功能；

比如：依據(jù)用戶在界面選擇的若是的維度和指標(biāo)，按照開發(fā)接口，從HBase中獲取數(shù)據(jù)來展示更多。

其它數(shù)據(jù)接口

這種接口有通用的，有定做的。比如說：一個從Redis中資源用戶屬性的接口是通用的，所有的業(yè)務(wù)都這個可以動態(tài)鏈接庫這個接口來聲望兌換用戶屬性。

實時計算現(xiàn)在業(yè)務(wù)對數(shù)據(jù)倉庫實時性的需求更多，例如：動態(tài)實時的了解網(wǎng)站的橫向流量；實時自動的獲取一個廣告的曝光和點擊；在海量數(shù)據(jù)下，憑借民間數(shù)據(jù)庫和傳統(tǒng)基于方法都差不多成功不了，不需要的是一種分布式的、高吞吐量的、顯示延時低的、高可靠的實時計算框架；Storm在這塊是比較能成熟了，但我選擇SparkStreaming，原因很簡單，并不想多化入一個框架到平臺中，另外，SparkStreaming比Storm延時性高那你一點點，那對此我們的需要可以忽略。

我們目前在用SparkStreaming基于了實時地的網(wǎng)站流量統(tǒng)計、實時自動的廣告效果統(tǒng)計兩塊兒功能。

做法也很簡單點，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實時自動的發(fā)送中給SparkStreaming，由SparkStreaming能完成統(tǒng)計，將數(shù)據(jù)存儲至Redis，業(yè)務(wù)是從ftp訪問Redis實時動態(tài)查看。

任務(wù)調(diào)度與監(jiān)控在數(shù)據(jù)倉庫/數(shù)據(jù)平臺中，有數(shù)不清太多的程序和任務(wù)，諸如：數(shù)據(jù)采集任務(wù)、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等；

這些任務(wù)之外有定時調(diào)度，還存在的很奇怪的任務(wù)依戀關(guān)系，比如說：數(shù)據(jù)分析任務(wù)可以等相應(yīng)的數(shù)據(jù)采集委托任務(wù)后才能就開始；快速同步任務(wù)需要等數(shù)據(jù)分析任務(wù)失敗后才能又開始；這就必須一個太完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，你們負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運行。

前面有寫過文章，《大數(shù)據(jù)平臺中的任務(wù)調(diào)度與監(jiān)控》,這里不再累贅。

學(xué)習(xí)總結(jié)在我看樣子架構(gòu)并不是技術(shù)就會越新越好，只不過是在可以不能夠滿足需求的情況下，越簡單點越穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺中，變更土地性質(zhì)大量的是關(guān)注業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求弄明白了，大部分只是需要做很簡單SQL開發(fā)，然后把配置到調(diào)度系統(tǒng)就可以了，如果任務(wù)異常，會送來告警。這樣，這個可以使更多的資源踏實專注于業(yè)務(wù)之上。

Hive數(shù)據(jù)庫是哪個公司開發(fā)的？

Hive是由Facebook開源軟件主要用于解決海量藏書結(jié)構(gòu)化日志的數(shù)據(jù)統(tǒng)計工具。在普遍的大數(shù)據(jù)應(yīng)用當(dāng)中，Hive是作為Hadoop的一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張表，并提供給類SQL查詢功能。Hive的本質(zhì)是將HQL轉(zhuǎn)化成成MapReduce程序。