問答專欄Q & A COLUMN
首先建議題主描述清楚應用場景，否則別人做的方案可能都不符合需求。
就Hadoop和OpenStack的糾結(jié)而言，支撐數(shù)據(jù)分析用前者，做資源管理用后者。
=================補充=============
題主的需求，實質(zhì)是搭建一個IoT實時大數(shù)據(jù)平臺，而不是一般意義的私有云。IoTa大數(shù)據(jù)平臺除了數(shù)據(jù)采集和結(jié)果反饋，其余部分和一般的大數(shù)據(jù)平臺相差不多。OpenStack長于管理VM資源管理，Hadoop長于批處理，不擅長實時處理，所以需要尋找一種更加完善的解決方案。這里推薦考慮Storm或者Apache Flink。
OpenStack是一個開源的IaaS實現(xiàn)，由Nova、Cinder、Neutron、Swift、Glance等一系列相互關(guān)聯(lián)的子項目組成，可以理解為云計算領域的Linux。OpenStack架構(gòu)松耦合，高可擴展，能適應不同企業(yè)的需求，已經(jīng)成為IaaS私有云事實標準。國內(nèi)外各大廠都在OpenStack上有很大的投入。當然項目成長的同時，也受到大廠博弈的一些影響，但項目本身就是大家求同存異的結(jié)果，我們相信OpenStack會在競合中有更美好的未來。
大數(shù)據(jù)平臺可以完全不鳥OpenStack，分布式文件系統(tǒng)有HDFS，資源調(diào)度和管理YARN就行。YARN都已經(jīng)支持Docker，希望細粒度調(diào)度模式可以考慮Mesos，Mesos提供良好的API，支持很多成熟的框架，不過Mesos不在Hadoop生態(tài)中，這是一個缺憾。Apache Hadoop能夠以低成本進行海量數(shù)據(jù)的多維統(tǒng)計分析，還是很有優(yōu)勢。
核心流式計算部分，有Storm、Spark、Flink可以選擇。
Storm編程模型簡單，毫秒級延遲，容錯性、擴展性和可靠性都比較好，在國內(nèi)有很多團隊采用。不過Storm只是流計算框架，且不能直接利用YARN。
Apache Spark是和Hadoop一樣流行的開源大數(shù)據(jù)框架，社區(qū)活躍，在流計算、圖處理、機器學習方面都投入很大，支持對SQL的優(yōu)化，很適合多種大數(shù)據(jù)平臺的需求，不過Spark Streaming本質(zhì)還是批處理，把數(shù)據(jù)流分解成一系列小的RDD，通過時間窗來控制數(shù)據(jù)塊的大小，有測試說只能支持秒級計算。
Apache Flink是可擴展的批處理和流式數(shù)據(jù)處理的數(shù)據(jù)處理平臺，能夠基于同一個Flink運行時提供支持流處理和批處理兩種類型應用的功能。不同于Spark，F(xiàn)link把批處理當初特殊的流處理，并且支持增量迭代，這是非常贊的設計，可以快速地處理數(shù)據(jù)密集型和迭代任務，性能很有保證。不過目前Flink用戶群和社區(qū)還沒有Spark那么強大。但Flink的未來很值得期待，可能需要時間的沉淀。
Spark和Flink的對比，Apache Flink現(xiàn)在在大數(shù)據(jù)處理方面能夠和Apache Spark分庭抗禮么這個問題的最佳答案質(zhì)量很棒，轉(zhuǎn)載自知乎，翻譯的這篇文章：Introduction to Apache Flink for Spark Developers : Flink vs Spark
最后，上一張網(wǎng)易猛犸大數(shù)據(jù)平臺架構(gòu)圖，供參考。
評論0
加載中...
hadoop適合幾百臺電腦聯(lián)合處理數(shù)據(jù)的大型應用，電腦少時體現(xiàn)不出優(yōu)勢，反而耗費資源卻效率不高。
潤乾集算器是個不錯的大數(shù)據(jù)計算引擎，資源投入很少，性價比相當高，而且開發(fā)語言十分簡潔易懂。目前已在很多企業(yè)大數(shù)據(jù)計算中得到了應用，比如北京銀行、國家電網(wǎng)、油田環(huán)境監(jiān)測數(shù)據(jù)處理等
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答4
回答3
回答0
回答
