數(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ù)支持，應(yīng)該是通過(guò)數(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ù)，通過(guò)數(shù)據(jù)挖掘來(lái)會(huì)降低投入成本，增加耗去效果；比如廣告代培生精準(zhǔn)投放、用戶個(gè)性化推薦等；

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

建設(shè)和發(fā)展開(kāi)放數(shù)據(jù)平臺(tái)，開(kāi)放公司數(shù)據(jù)；

。。。。。。

上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉(cāng)庫(kù)用途也差不多，因此都那些要求數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)有很好的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除此之外數(shù)據(jù)量大之外，越來(lái)越多的業(yè)務(wù)具體的要求時(shí)效性，甚至于很多是特別要求實(shí)時(shí)的，同時(shí)，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化太快，不可能像傳統(tǒng)行業(yè)完全不一樣，這個(gè)可以不使用自頂往上的方法確立數(shù)據(jù)倉(cāng)庫(kù)，一勞永逸，它那些要求新的業(yè)務(wù)迅速能融入數(shù)據(jù)倉(cāng)庫(kù)中來(lái)，老的下線的業(yè)務(wù)，能很方便的從現(xiàn)有的數(shù)據(jù)倉(cāng)庫(kù)中登陸游戲；

總之，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉(cāng)庫(kù)就是所謂的敏捷數(shù)據(jù)倉(cāng)庫(kù)，而且沒(méi)有要求能急速的響應(yīng)數(shù)據(jù)，也特別要求能急速的響應(yīng)業(yè)務(wù)；

大力建設(shè)敏捷數(shù)據(jù)倉(cāng)庫(kù)，除了對(duì)架構(gòu)技術(shù)上的要求之外，另外一個(gè)很最重要的方面，那是數(shù)據(jù)建模，如果沒(méi)有一上去就尋思確立一套能兼容性問(wèn)題所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到民間數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)上了，很難滿足的條件對(duì)業(yè)務(wù)變化的快速響應(yīng)。應(yīng)對(duì)這個(gè)，好象是先將核心的不持久化的業(yè)務(wù)接受深度適宜建模（例如：實(shí)現(xiàn)網(wǎng)站日志成立的網(wǎng)站統(tǒng)計(jì)分析模型和用戶打開(kāi)瀏覽器軌跡模型；基于條件公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)像是都需要維度寬表的來(lái)建立起數(shù)據(jù)模型。這塊是后話。

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

邏輯上，一般都有吧數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層。可能叫法有所有所不同，本質(zhì)上的角色都基本上。

我們向下看：

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

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

網(wǎng)站日志：

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

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

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

業(yè)務(wù)數(shù)據(jù)庫(kù)的種類也多種多樣，有Mysql、Oracle、SqlServer等，這時(shí)候，我們急迫的需要有一種能從各種數(shù)據(jù)庫(kù)中將快速同步到HDFS上的工具，Sqoop是一種，不過(guò)Sqoop極為繁重，但論數(shù)據(jù)量大小，都不需要啟動(dòng)MapReduce來(lái)執(zhí)行，不過(guò)必須Hadoop集群的每臺(tái)機(jī)器都能不能訪問(wèn)業(yè)務(wù)數(shù)據(jù)庫(kù)；如何應(yīng)付此場(chǎng)景，淘寶開(kāi)源的DataX，是另一個(gè)非常好的解決方案（可參考文章《異構(gòu)數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，這個(gè)可以基于組件DataX之上做二次開(kāi)發(fā)，就能相當(dāng)好的解決，我們目前可以使用的DataHub也是。

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

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

有可能一些合作伙伴提供的數(shù)據(jù)，需要按照Ftp/Http等設(shè)置定時(shí)查看，DataX也可以不不滿足該需求

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

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

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

自動(dòng)更新數(shù)據(jù)分析與計(jì)算，也就是對(duì)實(shí)時(shí)性要求不高的部分，在我現(xiàn)在看來(lái)，Hive那就隨后而來(lái)的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比太高的ORC文件存儲(chǔ)格式；非常方便的SQL支持什么，使得Hive在設(shè)計(jì)和實(shí)現(xiàn)結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)不如比MapReduce要又高效的多，一句SQL可以結(jié)束的需求，的新MR可能要上百行代碼；

當(dāng)然了，建議使用Hadoop框架很自然也提供給了MapReduce接口，如果沒(méi)有真有很不樂(lè)意開(kāi)發(fā)Java，也可以對(duì)SQL不熟，那么也這個(gè)可以使用MapReduce來(lái)做分析與計(jì)算；Spark是這兩年太火的，在實(shí)踐，它的性能雖然比MapReduce好多了很多，而且和Hive、Yarn特點(diǎn)的越來(lái)越好，并且，必須允許不使用Spark和SparkSQL來(lái)做分析和計(jì)算。只不過(guò)早就有HadoopYarn，使用Spark不過(guò)是更加很難的，不用什么分開(kāi)來(lái)重新部署Spark集群，關(guān)于Spark On Yarn的相關(guān)文章，可可以參考：《Spark On Yarn系列文章》

實(shí)時(shí)計(jì)算部分，后面單獨(dú)說(shuō)。

數(shù)據(jù)共享這里的數(shù)據(jù)共享，反正指的是前面數(shù)據(jù)分析與計(jì)算后的結(jié)果儲(chǔ)存時(shí)的地方，反正是關(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剛好相反，這里是需要一個(gè)從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，雖然，DataX也這個(gè)可以行最簡(jiǎn)形矩陣。

另外，一些實(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ù)，早存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問(wèn)再試一下；

報(bào)表

同業(yè)務(wù)產(chǎn)品，報(bào)表所使用的數(shù)據(jù)，好象也早匯總上報(bào)好的，貯存于數(shù)據(jù)共享層；

即席查詢

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

這種即席去查詢常見(jiàn)是可以做到的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并不能不能行最簡(jiǎn)形矩陣他們的需求，需要從數(shù)據(jù)存儲(chǔ)層再可以查詢。

即席查詢一般是通過(guò)SQL能夠完成，最大的難度只是相對(duì)而言響應(yīng)速度上，建議使用Hive稍微有點(diǎn)慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，但是能很好的與Hive兼容性。

其實(shí)，你也也可以在用Impala，要是不在乎平臺(tái)中再多一個(gè)框架的話。

OLAP

目前，很多的OLAP工具不能不能很好的支持從HDFS上然后資源數(shù)據(jù)，全是按照將是需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫(kù)中做OLAP，但要是數(shù)據(jù)量巨型的話，關(guān)系型數(shù)據(jù)庫(kù)顯然不行的話；

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

比如說(shuō)：據(jù)用戶在界面上中,選擇的不定的維度和指標(biāo)，按照開(kāi)發(fā)接口，從HBase中聲望兌換數(shù)據(jù)來(lái)展示更多。

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

這種接口有通用的，有訂制的。例如：一個(gè)從Redis中某些用戶屬性的接口是通用的，所有的業(yè)務(wù)都這個(gè)可以內(nèi)部函數(shù)這個(gè)接口來(lái)某些用戶屬性。

實(shí)時(shí)計(jì)算現(xiàn)在業(yè)務(wù)對(duì)數(shù)據(jù)倉(cāng)庫(kù)實(shí)時(shí)性的需求越來(lái)越密集，.例如：實(shí)時(shí)地的了解網(wǎng)站的構(gòu)造流量；實(shí)時(shí)的資源一個(gè)廣告的曝光和再點(diǎn)；在海量數(shù)據(jù)下，依靠悠久的傳統(tǒng)數(shù)據(jù)庫(kù)和傳統(tǒng)實(shí)現(xiàn)方法方法基本上結(jié)束不了，需要的是一種分布式的、高吞吐量的、連接時(shí)間低的、高可靠的實(shí)時(shí)計(jì)算框架；Storm在這塊是比較比較完全成熟了，但我你選SparkStreaming，原因很簡(jiǎn)單，不打算多化入一個(gè)框架到平臺(tái)中，同時(shí)，SparkStreaming比Storm顯示延時(shí)性高這樣一點(diǎn)點(diǎn)，那對(duì)此我們的需要可以遺漏掉。

我們目前在用SparkStreaming實(shí)現(xiàn)方法了實(shí)時(shí)地的網(wǎng)站流量統(tǒng)計(jì)、實(shí)時(shí)的廣告效果統(tǒng)計(jì)兩塊功能。

做法也很簡(jiǎn)單的，由Flume在前端日志服務(wù)器上收集到網(wǎng)站日志和廣告日志，實(shí)時(shí)動(dòng)態(tài)的你的郵箱給SparkStreaming，由SparkStreaming能完成統(tǒng)計(jì)，將數(shù)據(jù)存儲(chǔ)至Redis，業(yè)務(wù)實(shí)際訪問(wèn)Redis實(shí)時(shí)地聲望兌換。

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

這些任務(wù)除了有定時(shí)調(diào)度，還存在地更加急切的任務(wù)感情依賴關(guān)系，比如說(shuō)：數(shù)據(jù)分析任務(wù)需要等相對(duì)應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能結(jié)束；同步數(shù)據(jù)任務(wù)是需要等數(shù)據(jù)分析委托任務(wù)后才能結(jié)束；這就必須一個(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)控》,這里再次累贅。

總結(jié)歸納在我看樣子架構(gòu)并不是技術(shù)就會(huì)越新越好，完全是在可以滿足需求的情況下，越簡(jiǎn)單啊越很穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺(tái)中，開(kāi)發(fā)大量的是了解業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求搞清了，基本都只是需要做簡(jiǎn)單SQL開(kāi)發(fā)，接著配置到調(diào)度系統(tǒng)就可以了，如果沒(méi)有任務(wù)十分，會(huì)送來(lái)告警。這樣，可以使更多的資源專注于業(yè)務(wù)之上。

3年金融BI項(xiàng)目工作經(jīng)驗(yàn)，換工作去文思（原TD到東南到文思）團(tuán)隊(duì)做數(shù)據(jù)倉(cāng)庫(kù)好,還是去宇信易做風(fēng)險(xiǎn)集市好？

哪個(gè)方面更有發(fā)展呢？待遇咋樣啊？

東南工銀,文思,軟通我頂啊？這么大牛我上次從融通進(jìn)去,前期做數(shù)據(jù)倉(cāng)庫(kù)后來(lái)做JAVA了,義務(wù)加班都多,聽(tīng)他們說(shuō)文思好在點(diǎn)吧。我一個(gè)同事辭職跳槽過(guò)來(lái)了,華為外包都TDM得坑爹啊,做好不做外包吧。