短短幾年時間，大數(shù)據(jù)這個詞便已家喻戶曉。但在大數(shù)據(jù)這個名詞被命名之前，人類對數(shù)據(jù)的搜集與分析已有著悠久的歷史。從人工統(tǒng)計分析到電腦/大型機再到今天的分布式計算平臺，數(shù)據(jù)處理速度飛速提高的背后則是整體架構(gòu)的不斷演進。今天大數(shù)據(jù)架構(gòu)最火熱的莫過于Hadoop，Spark和Storm這三種，而Spark和Storm這兩個后起之秀更是搶了不少Hadoop的風(fēng)頭，也讓網(wǎng)上逐漸開始有一種聲音說Hadoop的日子已經(jīng)快到頭了。但究竟這三者之間是什么關(guān)系，未來大數(shù)據(jù)架構(gòu)究竟該走向何方呢?

分布式計算架構(gòu)鼻祖Hadoop

所謂分布式計算過程就像螞蟻搬家一樣，將一個大型任務(wù)分割成很多部分，每一臺電腦相當(dāng)于一個小螞蟻將其中一部分搬走。Hadoop作為分布式系統(tǒng)的基礎(chǔ)架構(gòu)，其重要性不言而喻。Hadoop的數(shù)據(jù)處理工作在硬盤層面，借助HDFS(分布式文件系統(tǒng))，可以將架構(gòu)下每一臺電腦中的硬盤資源聚集起來，不論是存儲計算還是調(diào)用都可以視為一塊硬盤使用，就像以前電腦中的C盤，D盤，之后使用集群管理和調(diào)度軟件YARN，相當(dāng)于Windows，畢竟我們要進行編程首先需要一個操作系統(tǒng)，***利用Map/Reduce計算框架相當(dāng)于Virtual Studio，就可以在這上面進行計算編程。從而大幅降低了整體計算平臺的硬件投入成本。而這也就是最基礎(chǔ)的分布式計算架構(gòu)。

流數(shù)據(jù)處理雙雄Spark和Storm

所謂流數(shù)據(jù)處理其實不難理解，比如看網(wǎng)上視頻，都是下載一段看一段，然后快結(jié)束的時候自動下載下一段。由于Hadoop的計算過程放在硬盤，受制于硬件條件限制，數(shù)據(jù)的吞吐和處理速度明顯不如使用內(nèi)存來的快。于是Spark和Storm開始登上舞臺。Spark和Storm兩者***的區(qū)別在于實時性：Spark是準(zhǔn)實時，先收集一段時間的數(shù)據(jù)再進行統(tǒng)一處理，好比看網(wǎng)頁統(tǒng)計票數(shù)每隔幾秒刷新一次，而Storm則是完全實時，來一條數(shù)據(jù)就處理一條。當(dāng)然Storm實時處理方式所帶來的缺點也是很明顯的，不論離線批處理，高延遲批處理還是交互式查詢都不如Spark框架。不同的機制決定了兩者架構(gòu)適用的場景不同，比如炒股，股價的變化不是按秒計算的(Spark實時計算延遲度是秒級)，在高頻交易中，高頻獲利與否往往就在1ms(0.001秒)之間，而這恰好就是Storm的實時計算延遲度。

[[182797]]

混合架構(gòu)，各顯神通

今天大數(shù)據(jù)的混合架構(gòu)就像目前云計算市場中風(fēng)頭最勁的混合云一樣，成為大多數(shù)公司的***。每一種架構(gòu)都有其自身的獨特優(yōu)缺點，就像Hadoop，盡管數(shù)據(jù)處理的速度和難易度都遠(yuǎn)比不過Spark和Storm。但是由于硬盤斷電后數(shù)據(jù)可以長期保存，因此在處理需要長期存儲的數(shù)據(jù)時還是需要借助Hadoop。不過Hadoop由于具有非常好的兼容性，因此非常容易的同Spark和Storm進行結(jié)合，從而滿足公司的不同需求。

縱觀技術(shù)的發(fā)展史，我們可以看到，每一項新技術(shù)的問世都有著之前技術(shù)的身影，伴隨著大數(shù)據(jù)的需求增長，不同的架依然會不斷進化，并改進自身的缺點，從而使得自身架構(gòu)得到進一步的完善。就目前來看Hadoop，Spark和Storm目前遠(yuǎn)談不到誰取代誰。