架構(gòu)就像是一場進(jìn)化史業務指導，根據(jù)不同時(shí)期的需求改進措施，演變出不同的架構(gòu)，車輪滾滾還不大，到今天高產，移動(dòng)端框架百花齊放，讓人目不暇接發揮作用。但是其中的本質(zhì)是磨滅不了的數據，換言之根本沒有磨滅而是隱藏到了人們所看不到的地方，但是依舊發(fā)揮著不可或缺的作用發揮。

先大概列一下互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫顯著、數(shù)據(jù)平臺(tái)的用途：

上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉庫用途差不多，并且都要求數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)有很好的穩(wěn)定性開放以來、可靠性占；但在互聯(lián)網(wǎng)行業(yè)，除了數(shù)據(jù)量大之外，越來越多的業(yè)務(wù)要求時(shí)效性激發創作，甚至很多是要求實(shí)時(shí)的前景。

另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化非吃龇畲?？旃蚕響?，不可能像傳統(tǒng)行業(yè)一樣，可以使用自頂向下的方法建立數(shù)據(jù)倉庫標準，一勞永逸示範推廣，它要求新的業(yè)務(wù)很快能融入數(shù)據(jù)倉庫中來，老的下線的業(yè)務(wù)即將展開，能很方便的從現(xiàn)有的數(shù)據(jù)倉庫中下線大幅增加；

其實(shí)，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉庫就是所謂的靈敏數(shù)據(jù)倉庫傳承，不但要求能快速的響應(yīng)數(shù)據(jù)等特點，也要求能快速的響應(yīng)業(yè)務(wù)；

建設(shè)靈敏數(shù)據(jù)倉庫形式，除了對架構(gòu)技術(shù)上的要求之外建設應用，還有一個(gè)很重要的方面，就是數(shù)據(jù)建模日漸深入，假如一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型動力，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很難滿足對業(yè)務(wù)變化的快速響應(yīng)互動式宣講。

應(yīng)對這種情況效高性，一般是先將核心的持久化的業(yè)務(wù)進(jìn)行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計(jì)分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型）自動化，其它的業(yè)務(wù)一般都采用維度+寬表的方式來建立數(shù)據(jù)模型提升，這塊是后話。

下面的圖是某公司使用的數(shù)據(jù)平臺(tái)架構(gòu)圖意向，其實(shí)大多公司應(yīng)該都差不多：

邏輯上意料之外，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層形式、數(shù)據(jù)共享層置之不顧、數(shù)據(jù)應(yīng)用層，可能叫法有所不同數字化，本質(zhì)上的角色都大同小異方便。

我們從下往上看：

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

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

作為互聯(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ù)庫的種類也是多種多樣，有Mysql服務體系、Oracle說服力、SqlServer等，這時(shí)候分析，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種全面闡釋，但是Sqoop太過繁重非常激烈，而且不管數(shù)據(jù)量大小，都需要啟動(dòng)MapReduce來執(zhí)行引人註目，而且需要Hadoop集群的每臺(tái)機(jī)器都能訪問業(yè)務(wù)數(shù)據(jù)庫領域；應(yīng)對此場景，淘寶開源的DataX好宣講，是一個(gè)很好的解決方案註入新的動力，有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決雙重提升。

當(dāng)然，F(xiàn)lume通過配置與開發(fā)事關全面，也可以實(shí)時(shí)的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS表現明顯更佳。

有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/等定時(shí)獲取等形式，DataX也可以滿足該需求技術的開發；

比如一些手工錄入的數(shù)據(jù)，只需要提供一個(gè)接口或小程序飛躍，即可完成更高效；

毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)很完美的數(shù)據(jù)存儲(chǔ)解決方案重要部署。

離線數(shù)據(jù)分析與計(jì)算具體而言，也就是對實(shí)時(shí)性要求不高的部分，在筆者看來的過程中，Hive還是首當(dāng)其沖的選擇發展契機，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)促進進步；壓縮比非常高的ORC文件存儲(chǔ)格式發力；非常方便的SQL支持，使得Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)遠(yuǎn)比MapReduce要高效的多，一句SQL可以完成的需求共創美好，開發(fā)MR可能需要上百行代碼推動並實現；

當(dāng)然，使用Hadoop框架自然而然也提供了MapReduce接口覆蓋範圍，假如真的很樂意開發(fā)Java優化程度，或者對SQL不熟，那么也可以使用MapReduce來做分析與計(jì)算奮勇向前；

Spark是這兩年非巢粩嘭S富；鸬模?jīng)過實(shí)踐組建，它的性能的確比MapReduce要好很多各有優勢，而且和Hive、Yarn結(jié)合的越來越好重要的意義，因此持續，必須支持使用Spark和SparkSQL來做分析和計(jì)算。因?yàn)橐呀?jīng)有HadoopYarn再獲，使用Spark其實(shí)是非常簡單的產品和服務，不用單獨(dú)部署Spark集群。

這里的數(shù)據(jù)共享體驗區，其實(shí)指的是前面數(shù)據(jù)分析與計(jì)算后的結(jié)果存放的地方多樣性，其實(shí)就是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；

前面使用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也可以滿足。另外綠色化發展，一些實(shí)時(shí)計(jì)算的結(jié)果數(shù)據(jù)可能由實(shí)時(shí)計(jì)算模塊直接寫入數(shù)據(jù)共享至關重要。

業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層用上了，直接從數(shù)據(jù)共享層訪問即可提升行動；

同業(yè)務(wù)產(chǎn)品能力建設，報(bào)表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計(jì)匯總好的研究進展，存放于數(shù)據(jù)共享層無障礙；

即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員快速融入、網(wǎng)站和產(chǎn)品運(yùn)營人員認為、數(shù)據(jù)分析人員、甚至是部門老大增強，他們都有即席查詢數(shù)據(jù)的需求重要意義；

這種即席查詢通常是現(xiàn)有的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲(chǔ)層直接查詢置之不顧。

即席查詢一般是通過SQL完成不斷完善，很大的難度在于響應(yīng)速度上，使用Hive有點(diǎn)慢方便，可以用SparkSQL，它的響應(yīng)速度較Hive快很多深刻內涵，而且能很好的與Hive兼容傳遞。

當(dāng)然，你也可以使用Impala深入闡釋，假如不在乎平臺(tái)中再多一個(gè)框架的話相關性。

目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)物聯與互聯，都是通過將需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫中做OLAP穩定，但假如數(shù)據(jù)量巨大的話，關(guān)系型數(shù)據(jù)庫顯然不行供給；

這時(shí)候優勢與挑戰，需要做相應(yīng)的開發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)解決方案，完成OLAP的功能趨勢；比如：根據(jù)用戶在界面上選擇的不定的維度和指標(biāo)，通過開發(fā)接口上高質量，從HBase中獲取數(shù)據(jù)來展示一站式服務。

這種接口有通用的，有定制的深入交流。比如：一個(gè)從Redis中獲取用戶屬性的接口是通用的引領作用，所有的業(yè)務(wù)都可以調(diào)用這個(gè)接口來獲取用戶屬性。

現(xiàn)在業(yè)務(wù)對數(shù)據(jù)倉庫實(shí)時(shí)性的需求越來越多臺上與臺下，比如：實(shí)時(shí)的了解網(wǎng)站的整體流量用的舒心；實(shí)時(shí)的獲取一個(gè)廣告的曝光和點(diǎn)擊技術發展；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫和傳統(tǒng)實(shí)現(xiàn)方法基本完成不了深入開展，需要的是一種分布式的更為一致、高吞吐量的、延時(shí)低的技術的開發、高可靠的實(shí)時(shí)計(jì)算框架研究與應用；Storm在這塊是比較成熟了，但我選擇SparkStreaming更高效，原因很簡單全面協議，不想多引入一個(gè)框架到平臺(tái)中，另外具體而言，SparkStreaming比Storm延時(shí)性高那么一點(diǎn)點(diǎn)工具，那對于我們的需要可以忽略。

我們目前使用SparkStreaming實(shí)現(xiàn)了實(shí)時(shí)的網(wǎng)站流量統(tǒng)計(jì)發揮重要作用、實(shí)時(shí)的廣告效果統(tǒng)計(jì)兩塊功能醒悟。

做法也很簡單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志高質量，實(shí)時(shí)的發(fā)送給SparkStreaming也逐步提升，由SparkStreaming完成統(tǒng)計(jì)，將數(shù)據(jù)存儲(chǔ)至Redis註入了新的力量，業(yè)務(wù)通過訪問Redis實(shí)時(shí)獲取重要的作用。

在數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)中，有各種各樣非常多的程序和任務(wù)去創新，比如：數(shù)據(jù)采集任務(wù)足夠的實力、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等結構；

這些任務(wù)除了定時(shí)調(diào)度更適合，還存在非常復(fù)雜的任務(wù)依靠關(guān)系，比如：數(shù)據(jù)分析任務(wù)必須等相應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能開始規劃；數(shù)據(jù)同步任務(wù)需要等數(shù)據(jù)分析任務(wù)完成后才能開始擴大公共數據；

這就需要一個(gè)非常完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)的中樞帶動擴大，負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運(yùn)行核心技術體系。

這塊想要做好，非常復(fù)雜持續發展，我覺得是且價(jià)值小于成本必然趨勢，因此我們暫不考慮這塊。目前只有天天任務(wù)運(yùn)行的元數(shù)據(jù)擴大。

在筆者看來多樣性，架構(gòu)發揮效力，并不是技術(shù)越多越新越好，而是在可以滿足需求的情況下明顯，越簡單越穩(wěn)定越好安全鏈。目前在我們的數(shù)據(jù)平臺(tái)中，開發(fā)更多的是關(guān)注業(yè)務(wù)創新為先，而不是技術(shù)真正做到，他們把業(yè)務(wù)和需求搞清楚了，基本上只需要做簡單的SQL開發(fā)創新延展，然后配置到調(diào)度系統(tǒng)就可以了調整推進，假如任務(wù)異常，會(huì)收到告警機製性梗阻。這樣機製，可以使更多的資源專注于業(yè)務(wù)之上。