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

而我們所遇到的最大挑戰是平衡數據本地化與規模效率，這是一個(gè)魚(yú)與熊掌兼得的話(huà)題。

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

1.分布式存儲

傳統化集中式存儲存在已有一段時(shí)間。但大數據并非真的適合集中式存儲架構。Hadoop設計用于將計算更接近數據節點(diǎn)，同時(shí)采用了HDFS文件系統的大規模橫向擴展功能。

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

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

2.超融合VS分布式

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

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

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

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

4.刪重和壓縮

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

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

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

6.虛擬化Hadoop

虛擬化已經(jīng)席卷企業(yè)級市場(chǎng)。很多地區超過(guò)80%的物理服務(wù)器現在是虛擬化的。但也仍有很多企業(yè)因為性能和數據本地化問(wèn)題對虛擬化Hadoop避而不談。

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

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

不幸的是，傳統架構和應用(也就是非分布式)并不盡如人意。隨著(zhù)數據集越來(lái)越大，將應用遷移到數據不可避免，而因為延遲太長(cháng)也無(wú)法倒置。

理想的數據湖基礎架構會(huì )實(shí)現數據單一副本的存儲，而且有應用在單一數據資源上執行，無(wú)需遷移數據或制作副本

8.整合分析

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

9. 大數據遇見(jiàn)大視頻

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

10.沒(méi)有絕對的贏(yíng)家

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

比如，基于SAN的傳統架構在短期內不可取代，因為它們擁有OLTP，100%可用性需求的內在優(yōu)勢。所以最理想的辦法是將超融合平臺與分布式文件系統和分析軟件整合在一起。而成功的最主要因素則是存儲的可擴展性因素。