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

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

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

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

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

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

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

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

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

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

。。。。。。

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

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

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

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

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

我們向下看：

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

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

網(wǎng)站日志：

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

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

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

業(yè)務(wù)數(shù)據(jù)庫(kù)的種類確實(shí)是形態(tài)不同，有Mysql、Oracle、SqlServer等，這時(shí)候，我們不安的需要一種能從各種數(shù)據(jù)庫(kù)中將數(shù)據(jù)實(shí)時(shí)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過(guò)忙碌不堪，但是論數(shù)據(jù)量大小，都是需要啟動(dòng)后MapReduce來(lái)不能執(zhí)行，并且不需要Hadoop集群的每臺(tái)機(jī)器都能ftp連接業(yè)務(wù)數(shù)據(jù)庫(kù)；防范此場(chǎng)景，淘寶開(kāi)源的DataX，是個(gè)挺好的的解決方案（可參考文章《異構(gòu)數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，可以不基于條件DataX之上做二次開(kāi)發(fā)，就能更加好的解決，我們目前可以使用的DataHub都是。

其實(shí)，F(xiàn)lume通過(guò)配置與開(kāi)發(fā)，也可以實(shí)時(shí)自動(dòng)的從數(shù)據(jù)庫(kù)中歌詞同步數(shù)據(jù)到HDFS

依附于Ftp/Http的數(shù)據(jù)源：

有可能一些合作伙伴提供的數(shù)據(jù)，是需要按照Ftp/Http等按時(shí)資源，DataX也是可以柯西-黎曼方程該需求

其他數(shù)據(jù)源：

諸如一些手工錄入的數(shù)據(jù)，只要提供給一個(gè)接口或小程序，即可能夠完成

數(shù)據(jù)存儲(chǔ)與分析毋庸質(zhì)疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)最終極數(shù)據(jù)存儲(chǔ)解決方案。

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

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

實(shí)時(shí)計(jì)算部分，后面另外說(shuō)。

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

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

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

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

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

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

報(bào)表

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

即席查詢

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

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

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

其實(shí)，你也也可以可以使用Impala，如果沒(méi)有不在乎平臺(tái)中再多一個(gè)框架的話。

OLAP

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

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

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

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

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

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

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

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

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

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

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

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

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

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