在1990年，每一臺(tái)應(yīng)用服務(wù)器都傾向擁有直連式系統(tǒng)(DAS)。SAN的構(gòu)建則是為了更大的規(guī)模和更高的效率提供共享的池存儲(chǔ)。Hadoop已經(jīng)逆轉(zhuǎn)了這一趨勢(shì)回歸DAS。每一個(gè)Hadoop集群都擁有自身的——雖然是橫向擴(kuò)展型——直連式存儲(chǔ)，這有助于Hadoop管理數(shù)據(jù)本地化，但也放棄了共享存儲(chǔ)的規(guī)模和效率。如果你擁有多個(gè)實(shí)例或Hadoop發(fā)行版，那么你就將得到多個(gè)橫向擴(kuò)展的存儲(chǔ)集群。

[[173274]]

而我們所遇到的***挑戰(zhàn)是平衡數(shù)據(jù)本地化與規(guī)模效率，這是一個(gè)魚與熊掌兼得的話題。

數(shù)據(jù)本地化是為了確保大數(shù)據(jù)集存儲(chǔ)在計(jì)算節(jié)點(diǎn)附近便于分析。對(duì)于Hadoop，這意味著管理數(shù)據(jù)節(jié)點(diǎn)，向MapReduce提供存儲(chǔ)以便充分執(zhí)行分析。它實(shí)用有效但也出現(xiàn)了大數(shù)據(jù)存儲(chǔ)集群的獨(dú)立操作問題。以下十項(xiàng)是Hadoop環(huán)境中管理大數(shù)據(jù)存儲(chǔ)技巧。

1.分布式存儲(chǔ)

傳統(tǒng)化集中式存儲(chǔ)存在已有一段時(shí)間。但大數(shù)據(jù)并非真的適合集中式存儲(chǔ)架構(gòu)。Hadoop設(shè)計(jì)用于將計(jì)算更接近數(shù)據(jù)節(jié)點(diǎn)，同時(shí)采用了HDFS文件系統(tǒng)的大規(guī)模橫向擴(kuò)展功能。

雖然，通常解決Hadoop管理自身數(shù)據(jù)低效性的方案是將Hadoop 數(shù)據(jù)存儲(chǔ)在SAN上。但這也造成了它自身性能與規(guī)模的瓶頸。現(xiàn)在，如果你把所有的數(shù)據(jù)都通過集中式SAN處理器進(jìn)行處理，與Hadoop的分布式和并行化特性相悖。你要么針對(duì)不同的數(shù)據(jù)節(jié)點(diǎn)管理多個(gè)SAN，要么將所有的數(shù)據(jù)節(jié)點(diǎn)都集中到一個(gè)SAN。

但Hadoop是一個(gè)分布式應(yīng)用，就應(yīng)該運(yùn)行在分布式存儲(chǔ)上，這樣存儲(chǔ)就保留了與Hadoop本身同樣的靈活性，不過它也要求擁抱一個(gè)軟件定義存儲(chǔ)方案，并在商用服務(wù)器上運(yùn)行，這相比瓶頸化的Hadoop自然更為高效。

2.超融合VS分布式

注意，不要混淆超融合與分布式。某些超融合方案是分布式存儲(chǔ)，但通常這個(gè)術(shù)語意味著你的應(yīng)用和存儲(chǔ)都保存在同一計(jì)算節(jié)點(diǎn)上。這是在試圖解決數(shù)據(jù)本地化的問題，但它會(huì)造成太多資源爭用。這個(gè)Hadoop應(yīng)用和存儲(chǔ)平臺(tái)會(huì)爭用相同的內(nèi)存和CPU。Hadoop運(yùn)行在專有應(yīng)用層，分布式存儲(chǔ)運(yùn)行在專有存儲(chǔ)層這樣會(huì)更好。之后，利用緩存和分層來解決數(shù)據(jù)本地化并補(bǔ)償網(wǎng)絡(luò)性能損失。

3.避免控制器瓶頸(Controller Choke Point)

實(shí)現(xiàn)目標(biāo)的一個(gè)重要方面就是——避免通過單個(gè)點(diǎn)例如一個(gè)傳統(tǒng)控制器來處理數(shù)據(jù)。反之，要確保存儲(chǔ)平臺(tái)并行化，性能可以得到顯著提升。

此外，這個(gè)方案提供了增量擴(kuò)展性。為數(shù)據(jù)湖添加功能跟往里面扔x86服務(wù)器一樣簡單。一個(gè)分布式存儲(chǔ)平臺(tái)如有需要將自動(dòng)添加功能并重新調(diào)整數(shù)據(jù)。

4.刪重和壓縮

掌握大數(shù)據(jù)的關(guān)鍵是刪重和壓縮技術(shù)。通常大數(shù)據(jù)集內(nèi)會(huì)有70%到90%的數(shù)據(jù)簡化。以PB容量計(jì)，能節(jié)約數(shù)萬美元的磁盤成本。現(xiàn)代平臺(tái)提供內(nèi)聯(lián)(對(duì)比后期處理)刪重和壓縮，大大降低了存儲(chǔ)數(shù)據(jù)所需能力。

5.合并Hadoop發(fā)行版

很多大型企業(yè)擁有多個(gè)Hadoop發(fā)行版本。可能是開發(fā)者需要或是企業(yè)部門已經(jīng)適應(yīng)了不同版本。無論如何最終往往要對(duì)這些集群的維護(hù)與運(yùn)營。一旦海量數(shù)據(jù)真正開始影響一家企業(yè)時(shí)，多個(gè)Hadoop發(fā)行版存儲(chǔ)就會(huì)導(dǎo)致低效性。我們可以通過創(chuàng)建一個(gè)單一，可刪重和壓縮的數(shù)據(jù)湖獲取數(shù)據(jù)效率

6.虛擬化Hadoop

虛擬化已經(jīng)席卷企業(yè)級(jí)市場(chǎng)。很多地區(qū)超過80%的物理服務(wù)器現(xiàn)在是虛擬化的。但也仍有很多企業(yè)因?yàn)樾阅芎蛿?shù)據(jù)本地化問題對(duì)虛擬化Hadoop避而不談。

7.創(chuàng)建彈性數(shù)據(jù)湖

創(chuàng)建數(shù)據(jù)湖并不容易，但大數(shù)據(jù)存儲(chǔ)可能會(huì)有需求。我們有很多種方法來做這件事，但哪一種是正確的?這個(gè)正確的架構(gòu)應(yīng)該是一個(gè)動(dòng)態(tài)，彈性的數(shù)據(jù)湖，可以以多種格式(架構(gòu)化，非結(jié)構(gòu)化，半結(jié)構(gòu)化)存儲(chǔ)所有資源的數(shù)據(jù)。更重要的是，它必須支持應(yīng)用不在遠(yuǎn)程資源上而是在本地?cái)?shù)據(jù)資源上執(zhí)行。

不幸的是，傳統(tǒng)架構(gòu)和應(yīng)用(也就是非分布式)并不盡如人意。隨著數(shù)據(jù)集越來越大，將應(yīng)用遷移到數(shù)據(jù)不可避免，而因?yàn)檠舆t太長也無法倒置。

理想的數(shù)據(jù)湖基礎(chǔ)架構(gòu)會(huì)實(shí)現(xiàn)數(shù)據(jù)單一副本的存儲(chǔ)，而且有應(yīng)用在單一數(shù)據(jù)資源上執(zhí)行，無需遷移數(shù)據(jù)或制作副本

8.整合分析

分析并不是一個(gè)新功能，它已經(jīng)在傳統(tǒng)RDBMS環(huán)境中存在多年。不同的是基于開源應(yīng)用的出現(xiàn)，以及數(shù)據(jù)庫表單和社交媒體，非結(jié)構(gòu)化數(shù)據(jù)資源(比如，維基百科)的整合能力。關(guān)鍵在于將多個(gè)數(shù)據(jù)類型和格式整合成一個(gè)標(biāo)準(zhǔn)的能力，有利于更輕松和一致地實(shí)現(xiàn)可視化與報(bào)告制作。合適的工具也對(duì)分析/商業(yè)智能項(xiàng)目的成功至關(guān)重要。

9. 大數(shù)據(jù)遇見大視頻

大數(shù)據(jù)存儲(chǔ)問題已經(jīng)讓人有些焦頭爛額了，現(xiàn)在還出現(xiàn)了大視頻現(xiàn)象。比如，企業(yè)為了安全以及操作和工業(yè)效率逐漸趨于使用視頻監(jiān)控，簡化流量管理，支持法規(guī)遵從性和幾個(gè)其它的使用案例。很短時(shí)間內(nèi)這些資源將產(chǎn)生大量的內(nèi)容，大量必須要處理的內(nèi)容。如果沒有專業(yè)的存儲(chǔ)解決方案很可能會(huì)導(dǎo)致視頻丟失和質(zhì)量降低的問題。

10.沒有絕對(duì)的贏家

Hadoop的確取得了一些進(jìn)展。那么隨著大數(shù)據(jù)存儲(chǔ)遍地開花，它是否會(huì)成為贏家，力壓其它方案，其實(shí)不然。

比如，基于SAN的傳統(tǒng)架構(gòu)在短期內(nèi)不可取代，因?yàn)樗鼈儞碛蠴LTP，100%可用性需求的內(nèi)在優(yōu)勢(shì)。所以最理想的辦法是將超融合平臺(tái)與分布式文件系統(tǒng)和分析軟件整合在一起。而成功的最主要因素則是存儲(chǔ)的可擴(kuò)展性因素。