搭建私有云平臺：Hadoop還是選擇OpenStack？首先建議題主描述不清楚應(yīng)用場景，要不然別人做的方案很有可能都不符合需求。就Hadoop和OpenStack的糾結(jié)而言，支撐數(shù)據(jù)分析用前者，做資源

搭建私有云平臺：Hadoop還是選擇OpenStack？

首先建議題主描述不清楚應(yīng)用場景，要不然別人做的方案很有可能都不符合需求。

就Hadoop和OpenStack的糾結(jié)而言，支撐數(shù)據(jù)分析用前者，做資源管理用后者。

補(bǔ)充

題主的需求，實(shí)質(zhì)是壘建一個(gè)IoT實(shí)時(shí)自動(dòng)大數(shù)據(jù)平臺，而不是一般意義的私有云。IoTa大數(shù)據(jù)平臺之外數(shù)據(jù)采集和結(jié)果反饋，其余部分和好象的大數(shù)據(jù)平臺相應(yīng)該差不多。OpenStack兼通管理方面VM資源管理，Hadoop兼通批處理，不擅長實(shí)時(shí)自動(dòng)去處理，因此必須這里有一種更加完善的解決方案。這里幫我推薦考慮到Storm或是ApacheFlink。

OpenStack是一個(gè)開源的IaaS實(shí)現(xiàn)，由Nova、Cinder、Neutron、Swift、Glance等一系列相互影響的子項(xiàng)目分成，可以解釋為云計(jì)算領(lǐng)域的Linux。OpenStack架構(gòu)松耦合，高可擴(kuò)展，能適應(yīng)差別企業(yè)的需求，早就下一界IaaS私有云事實(shí)標(biāo)準(zhǔn)。國內(nèi)外各大廠都在OpenStack上有太大的投入。當(dāng)然了項(xiàng)目成長的同時(shí)，也受到大廠激烈博弈的一些影響，但項(xiàng)目本身就是大家求同存異的結(jié)果，我們相信OpenStack會(huì)在競合中有更幸福的未來。

大數(shù)據(jù)平臺可以不完全不鳥OpenStack，分布式文件系統(tǒng)有HDFS，資源調(diào)度和管理YARN就行。YARN都也接受Docker，只希望細(xì)粒度調(diào)度模式這個(gè)可以決定Mesos，Mesos可以提供良好的道德的API，支持很多成熟的框架，只不過Mesos在Hadoop生態(tài)中，這是一個(gè)缺憾。Apache Hadoop都能夠以低成本通過海量數(shù)據(jù)的多維統(tǒng)計(jì)分析，我還是很有優(yōu)勢。

核心流式計(jì)算部分，有Storm、Spark、Flink也可以中,選擇。

Storm編程模型簡單，毫秒級別延遲，容錯(cuò)性、擴(kuò)展性和可靠性都也很好，在國內(nèi)有很多團(tuán)隊(duì)常規(guī)。當(dāng)然了Storm只不過是流換算框架，且又不能直接借用YARN。

ApacheSpark是和Hadoop完全不一樣最流行開放源代碼大數(shù)據(jù)框架，社區(qū)亢奮狀態(tài)，在流可以計(jì)算、圖處理、機(jī)器學(xué)習(xí)方面都上繳很大，允許對SQL的優(yōu)化，很合適多種大數(shù)據(jù)平臺的需求，但SparkStreaming本質(zhì)還是批處理，把數(shù)據(jù)流可分解成一系列小的RDD，通過時(shí)間窗來再控制數(shù)據(jù)塊的大小，有測量說不能意見秒級可以計(jì)算。

ApacheFlink是可擴(kuò)展的批處理和流式數(shù)據(jù)處理的數(shù)據(jù)處理平臺，能基于組件同一個(gè)Flink啟動(dòng)時(shí)提供允許流處理和批處理兩種類型應(yīng)用的功能。不只是Spark，F(xiàn)link把批處理兩年前特珠的流一次性處理，而且允許增量迭代，這是非常贊的設(shè)計(jì)，這個(gè)可以飛快地全面處理數(shù)據(jù)密集型和迭代任務(wù)，性能很有保證。但是目前Flink用戶群和社區(qū)還沒有Spark這樣強(qiáng)橫。但Flink的未來很值得期待，可能會(huì)要時(shí)間的沉淀。

Spark和Flink的對比，ApacheFlink現(xiàn)在在大數(shù)據(jù)處理方面還能夠和ApacheSpark相抗衡么這個(gè)問題的最佳的位置答案質(zhì)量很棒，如需轉(zhuǎn)載深悔乎，漢語翻譯的這篇文章：IntroductionneedApacheFlinkanySpark Developers:FlinkvsSpark

最后，上張網(wǎng)易猛犸大數(shù)據(jù)平臺架構(gòu)圖，供可以參考。

高級數(shù)據(jù)庫，數(shù)據(jù)倉庫有哪些關(guān)鍵技術(shù)？

一直想收拾好幫一下忙這塊內(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ù)中心；

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

為網(wǎng)站運(yùn)營提供運(yùn)營上的數(shù)據(jù)支持，是數(shù)據(jù)，讓運(yùn)營及時(shí)所了解網(wǎng)站和產(chǎn)品的運(yùn)營效果；

為各個(gè)業(yè)務(wù)能提供線上或線下的數(shù)據(jù)支持，藍(lán)月帝國公司統(tǒng)一的數(shù)據(jù)交換與提供給平臺；

分析什么用戶行為數(shù)據(jù)，按照數(shù)據(jù)挖掘來降低投入成本，增強(qiáng)耗去效果；例如廣告自選專業(yè)精準(zhǔn)投放、用戶個(gè)性化推薦等；

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

大力建設(shè)開放數(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ù)要求時(shí)效性，甚至還很多是具體的要求動(dòng)態(tài)實(shí)時(shí)的，至于，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化太快，不可能像傳統(tǒng)行業(yè)一般，這個(gè)可以使用自頂向下的方法組建數(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è)魔防數(shù)據(jù)倉庫，以外對架構(gòu)技術(shù)上的要求之外，還有一個(gè)很最重要的方面，那是數(shù)據(jù)建模，如果不是一上來就想著組建一套能兼容性問題所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那你又又回到現(xiàn)代數(shù)據(jù)倉庫的建設(shè)上了，很難滿足的條件對業(yè)務(wù)變化的快速響應(yīng)。防范狀況，像是是先將核心的持久度化的業(yè)務(wù)接受深度適宜建模（比如說：實(shí)現(xiàn)網(wǎng)站日志組建的網(wǎng)站統(tǒng)計(jì)分析模型和用戶打開瀏覽器軌跡模型；基于公司核心用戶數(shù)據(jù)成立的用戶模型），其它的業(yè)務(wù)好象都常規(guī)維度寬表的來建立起數(shù)據(jù)模型。這塊是后話。

整體架構(gòu)下面的圖是我們目前建議使用的數(shù)據(jù)平臺架構(gòu)圖，當(dā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ì)做一些簡單的可以清洗。

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

網(wǎng)站日志：

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

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

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

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

當(dāng)然，F(xiàn)lume配置與開發(fā)，也是可以實(shí)時(shí)地的從數(shù)據(jù)庫中網(wǎng)絡(luò)同步數(shù)據(jù)到HDFS

充斥于Ftp/Http的數(shù)據(jù)源：

有可能一些合作伙伴需要提供的數(shù)據(jù)，必須/Http等定時(shí)獲取，DataX也也可以行最簡形矩陣該需求

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

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

數(shù)據(jù)存儲(chǔ)與分析毋庸質(zhì)疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最完美的藝術(shù)品數(shù)據(jù)存儲(chǔ)解決方案。

自動(dòng)更新數(shù)據(jù)分析與計(jì)算，也就是對實(shí)時(shí)性要求不高的部分，在我現(xiàn)在看來，Hive那就緊隨其后的選擇，豐富地的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比的很高的ORC文件存儲(chǔ)格式；非常方便的SQL意見，以至于Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)遠(yuǎn)的比MapReduce要高效率的多，一句SQL可以成功的需求，變更土地性質(zhì)MR肯定必須上百行代碼；

其實(shí)，使用Hadoop框架很自然也提供了MapReduce接口，如果沒有是真的很領(lǐng)情變更土地性質(zhì)Java，也可以對SQL不熟，那么也可以不不使用MapReduce來做分析與計(jì)算；Spark是這兩年的很火的，當(dāng)經(jīng)過實(shí)踐，它的性能并不比MapReduce要強(qiáng)很多，不過和Hive、Yarn結(jié)合的越貼越好，而，需要意見在用Spark和SparkSQL來做分析和計(jì)算。是因?yàn)樵缇陀蠬adoopYarn，可以使用Spark不過是更加太容易的，不需要單獨(dú)防御部署Spark集群，關(guān)與Spark On Yarn的相關(guān)文章，可建議參考：《Spark On Yarn系列文章》

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

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

前面可以使用Hive、MR、Spark、SparkSQL總結(jié)和算出的結(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ù)源的工具，同時(shí)，DataX也這個(gè)可以柯西-黎曼方程。

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

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

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

業(yè)務(wù)產(chǎn)品所在用的數(shù)據(jù)，也存在地于數(shù)據(jù)寬帶共享層，他們就從數(shù)據(jù)共享層訪問即可；

報(bào)表

同業(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ù)分析人員、甚至于是部門老大，他們應(yīng)該有即席可以查詢數(shù)據(jù)的需求；

這種即席可以查詢大多數(shù)是可以做到的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并沒法行最簡形矩陣他們的需求，要從數(shù)據(jù)存儲(chǔ)層直接查詢。

即席查詢一般是按照SQL完成，比較大的難度取決于人響應(yīng)速度上，可以使用Hive有點(diǎn)兒慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，但能很好的與Hive兼容問題。

當(dāng)然，你也可以不可以使用Impala，假如不在乎平臺中再多一個(gè)框架的話。

OLAP

目前，很多的OLAP工具不能不能很好的支持從HDFS上就某些數(shù)據(jù)，大都是從將要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫中做OLAP，但假如數(shù)據(jù)量龐大無比的話，關(guān)系型數(shù)據(jù)庫顯然再不行；

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

比如：參照用戶在界面上選擇類型的只怕的維度和指標(biāo)，開發(fā)接口，從HBase中資源數(shù)據(jù)來可以展示。

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

這種接口有通用的，有定制的。諸如：一個(gè)從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務(wù)都也可以全局函數(shù)這個(gè)接口來某些用戶屬性。

實(shí)時(shí)計(jì)算現(xiàn)在業(yè)務(wù)對數(shù)據(jù)倉庫實(shí)時(shí)性的需求越來越密集，例如：動(dòng)態(tài)實(shí)時(shí)的了解網(wǎng)站的是一個(gè)整體流量；實(shí)時(shí)地的查看一個(gè)廣告的曝光和再點(diǎn)；在海量數(shù)據(jù)下，依靠現(xiàn)代數(shù)據(jù)庫和傳統(tǒng)實(shí)現(xiàn)方法基本結(jié)束不了，必須的是一種分布式的、高吞吐量的、顯示延遲低的、高可靠的實(shí)時(shí)計(jì)算框架；Storm在這塊是也很能成熟了，但我選擇類型SparkStreaming，原因很簡單，想多引入一個(gè)框架到平臺中，別外，SparkStreaming比Storm延時(shí)性高那你一點(diǎn)點(diǎn)，那對此我們的需要可以不遺漏掉。

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

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

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

這些任務(wù)以外按時(shí)調(diào)度，還必然的很古怪的任務(wù)依賴關(guān)系，比如說：數(shù)據(jù)分析任務(wù)要等相應(yīng)的數(shù)據(jù)采集任務(wù)內(nèi)容后才能開始；自動(dòng)同步任務(wù)是需要等數(shù)據(jù)分析任務(wù)失敗后才能又開始；這就不需要一個(gè)太完備的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它另外數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，你們負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運(yùn)行。

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

歸納在我很顯然架構(gòu)并不是技術(shù)到最后越新越好，反而在可以滿足自身需求的情況下，越簡單的越比較穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺中，的新一些的是查哈業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求弄清楚了，基本都只不需要做簡單的SQL開發(fā)，后再配置到調(diào)度系統(tǒng)就可以了，如果不是任務(wù)無比，會(huì)送來告警。這樣，是可以使更多的資源專注心于業(yè)務(wù)之上。