數(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ù)支持，應(yīng)該是通過數(shù)據(jù)，讓運營和管理及時處理所了解網(wǎng)站和產(chǎn)品的運營效果；

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

分析用戶行為數(shù)據(jù)，通過數(shù)據(jù)挖掘來會降低投入成本，增加耗去效果；比如廣告代培生精準投放、用戶個性化推薦等；

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

建設(shè)和發(fā)展開放數(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è)務(wù)具體的要求時效性，甚至于很多是特別要求實時的，同時，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化太快，不可能像傳統(tǒng)行業(yè)完全不一樣，這個可以不使用自頂往上的方法確立數(shù)據(jù)倉庫，一勞永逸，它那些要求新的業(yè)務(wù)迅速能融入數(shù)據(jù)倉庫中來，老的下線的業(yè)務(wù)，能很方便的從現(xiàn)有的數(shù)據(jù)倉庫中登陸游戲；

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)共享這里的數(shù)據(jù)共享，反正指的是前面數(shù)據(jù)分析與計算后的結(jié)果儲存時的地方，反正是關(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ù)同步至其他目標數(shù)據(jù)源的工具，雖然，DataX也這個可以行最簡形矩陣。

另外，一些實時計算的結(jié)果數(shù)據(jù)很可能由實時計算模塊就寫入到數(shù)據(jù)共享。

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

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

業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，早存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問再試一下；

報表

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

即席查詢

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

這種即席去查詢常見是可以做到的報表和數(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ù)用戶在界面上中,選擇的不定的維度和指標，按照開發(fā)接口，從HBase中聲望兌換數(shù)據(jù)來展示更多。

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

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

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

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

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

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

這些任務(wù)除了有定時調(diào)度，還存在地更加急切的任務(wù)感情依賴關(guān)系，比如說：數(shù)據(jù)分析任務(wù)需要等相對應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能結(jié)束；同步數(shù)據(jù)任務(wù)是需要等數(shù)據(jù)分析委托任務(wù)后才能結(jié)束；這就必須一個太體系的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，專門負責調(diào)度和監(jiān)控所有任務(wù)的分配與運行。

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

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

3年金融BI項目工作經(jīng)驗，換工作去文思（原TD到東南到文思）團隊做數(shù)據(jù)倉庫好,還是去宇信易做風險集市好？

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

東南工銀,文思,軟通我頂?。窟@么大牛我上次從融通進去,前期做數(shù)據(jù)倉庫后來做JAVA了,義務(wù)加班都多,聽他們說文思好在點吧。我一個同事辭職跳槽過來了,華為外包都TDM得坑爹啊,做好不做外包吧。