【51CTO.com快譯】20世紀(jì)90年代，每臺(tái)應(yīng)用服務(wù)器往往都擁有直接連接存儲(chǔ)(DAS)。創(chuàng)建存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN)，是為了提供共享的存儲(chǔ)池，以獲得更大的規(guī)模和更高的效率。Hadoop逆轉(zhuǎn)了這股潮流，讓DAS重新流行起來。每個(gè)Hadoop集群都有自己的、橫向擴(kuò)展直接連接存儲(chǔ)。它有助于Hadoop管理數(shù)據(jù)局部性，但是犧牲了共享存儲(chǔ)的規(guī)模和效率。因此，如果你有Hadoop發(fā)行版的多個(gè)實(shí)例，就會(huì)有多個(gè)這種橫向擴(kuò)展的存儲(chǔ)孤島。

Hedvig公司的首席執(zhí)行官兼創(chuàng)始人阿維納什·拉克希曼(Avinash Lakshman)說：“我們遇到的最大挑戰(zhàn)就是，兼顧數(shù)據(jù)局部性與規(guī)模和效率。”

數(shù)據(jù)局部性是指確保大數(shù)據(jù)集存儲(chǔ)在執(zhí)行分析任務(wù)的計(jì)算資源附近。對(duì)于Hadoop來說，這就意味著管理數(shù)據(jù)節(jié)點(diǎn)(DataNode)，而數(shù)據(jù)節(jié)點(diǎn)為MapReduce擁有足夠好的性能提供了存儲(chǔ)資源。它可以高效地工作，但是導(dǎo)致了另一個(gè)操作問題：大數(shù)據(jù)存儲(chǔ)孤島。本文介紹的這些要點(diǎn)有助于管理Hadoop環(huán)境中的大數(shù)據(jù)存儲(chǔ)。

1. 分散式存儲(chǔ)

集中式存儲(chǔ)作為傳統(tǒng)架構(gòu)已有一段時(shí)間。但是大數(shù)據(jù)其實(shí)并不適合集中存儲(chǔ)架構(gòu)。Infogix的金融服務(wù)行業(yè)(FSI)戰(zhàn)略和運(yùn)營經(jīng)理森希爾·拉賈曼尼坎(Senthil Rajamanickam)表示，Hadoop旨在讓計(jì)算資源更接近數(shù)據(jù)，同時(shí)充分利用HDFS文件系統(tǒng)的大規(guī)模橫向擴(kuò)展功能。

然而，解決Hadoop管理自有數(shù)據(jù)的低效問題的常見方法，一向是將Hadoop數(shù)據(jù)存儲(chǔ)在SAN上。而這帶來了性能和規(guī)模方面的一系列瓶頸?，F(xiàn)在，你的所有數(shù)據(jù)都通過集中式SAN控制器來處理，而控制器破壞了Hadoop的分布式、并行化的特性。你需要為多個(gè)數(shù)據(jù)節(jié)點(diǎn)管理多個(gè)SAN，或者將所有數(shù)據(jù)節(jié)點(diǎn)保存到一個(gè)SAN上。

拉克希曼說：“由于Hadoop是一種分布式應(yīng)用系統(tǒng)，它應(yīng)該可以在分布式存儲(chǔ)上運(yùn)行，那樣你的存儲(chǔ)保持與Hadoop本身一樣的彈性。這需要你積極采用軟件定義存儲(chǔ)方法，在商用服務(wù)器上運(yùn)行，但是它比把Hadoop放在傳統(tǒng)SAN或NAS技術(shù)上高效得多，因?yàn)楹笳呓oHadoop造成了瓶頸。

2. 超融合vs分布式

不過要小心，別將超融合與分布式混為一談。某些超融合方法是分布式的，但這個(gè)術(shù)語通常意味著你的應(yīng)用程序和存儲(chǔ)可以共同駐留在同一個(gè)計(jì)算節(jié)點(diǎn)上。解決數(shù)據(jù)局部性問題很誘人，但是這會(huì)造成嚴(yán)重的資源爭奪現(xiàn)象。 Hadoop應(yīng)用和存儲(chǔ)平臺(tái)將爭奪同樣的內(nèi)存和處理器資源。拉克希曼表示，最好在專用的應(yīng)用層上運(yùn)行Hadoop，在專用的存儲(chǔ)層中運(yùn)行分布式存儲(chǔ)，從而充分利用緩存和分層技術(shù)，以解決數(shù)據(jù)局部性和網(wǎng)絡(luò)性能開銷。

3. 避免控制器阻塞點(diǎn)

他強(qiáng)調(diào)了做到這一點(diǎn)的一個(gè)重要方面――避免通過單一(或可能兩個(gè))點(diǎn)(比如傳統(tǒng)控制器)來處理數(shù)據(jù)。通過改而確保存儲(chǔ)平臺(tái)并行化，就能顯著提高性能。

此外，這種方法提供了增量可擴(kuò)展性。為數(shù)據(jù)湖添加容量就跟添加幾臺(tái)內(nèi)置閃存或旋轉(zhuǎn)磁盤的x86服務(wù)器一樣簡單。分布式存儲(chǔ)平臺(tái)可在必要時(shí)自動(dòng)添加容量、重新均衡數(shù)據(jù)。

4. 重復(fù)數(shù)據(jù)刪除和壓縮

駕馭大數(shù)據(jù)的一個(gè)關(guān)鍵部分是重復(fù)數(shù)據(jù)刪除和壓縮。Hedvig看到常見的大數(shù)據(jù)集可以縮減70%-90%。在PB級(jí)規(guī)模下，這意味著可節(jié)省數(shù)萬美元的磁盤成本。

拉克希曼說：“現(xiàn)代平臺(tái)提供了內(nèi)聯(lián)式(而不是處理后)重復(fù)數(shù)據(jù)刪除和壓縮。這意味著，如果不先以某種方式來縮減數(shù)據(jù)，數(shù)據(jù)永遠(yuǎn)不會(huì)進(jìn)入到磁盤，這大大減少了存儲(chǔ)數(shù)據(jù)所需的容量。”

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

許多大組織都有多個(gè)Hadoop發(fā)行版?？赡苁怯捎陂_發(fā)人員需要訪問多個(gè)“版本”，或者業(yè)務(wù)部門久而久之采用了不同的版本。不管怎樣，IT總部常常最終負(fù)責(zé)這些集群的日常維護(hù)和操作。大數(shù)據(jù)數(shù)量真正開始影響業(yè)務(wù)時(shí)，存在多個(gè)Hadoop發(fā)行版會(huì)導(dǎo)致效率低下。

拉克希曼說：“你可以創(chuàng)建一個(gè)單一、經(jīng)過重復(fù)數(shù)據(jù)刪除的壓縮數(shù)據(jù)湖，然后它可以為Hadoop的多個(gè)實(shí)例提供數(shù)據(jù)，從而獲得數(shù)據(jù)效率。”

6. 對(duì)Hadoop虛擬化處理

虛擬化技術(shù)在企業(yè)界刮起了一場(chǎng)風(fēng)暴。在許多地方，如今超過80%的物理服務(wù)器已虛擬化。不過由于性能和數(shù)據(jù)局部性問題，許多人避免了對(duì)Hadoop進(jìn)行虛擬化處理。

拉克希曼說：“你可以對(duì)Hadoop或Spark進(jìn)行虛擬化處理。”

7. 構(gòu)建彈性數(shù)據(jù)湖

構(gòu)建數(shù)據(jù)湖并非易事，但大數(shù)據(jù)存儲(chǔ)的需求可能需要數(shù)據(jù)湖。有許多方法可以著手構(gòu)建，可是哪一種才是合適的方法?合適的架構(gòu)有望構(gòu)建一個(gè)活躍、彈性的數(shù)據(jù)湖，可以存儲(chǔ)來自所有數(shù)據(jù)源、采用多種格式的數(shù)據(jù)，包括結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)。更重要的是，它必須支持就在數(shù)據(jù)源處執(zhí)行應(yīng)用程序，而不是從遠(yuǎn)程源處執(zhí)行，那樣需要移動(dòng)數(shù)據(jù)。

遺憾的是，傳統(tǒng)的架構(gòu)和應(yīng)用程序(即非分布式)并不令人滿意。由于數(shù)據(jù)集變得更龐大，必須將應(yīng)用程序移到數(shù)據(jù)，而不是將數(shù)據(jù)移到應(yīng)用程序，因?yàn)槟菢友舆t太長。而有了Hadoop/Spark，分析工作流變得更具破壞性了，因?yàn)閿?shù)據(jù)和應(yīng)用程序從不同的孤島來執(zhí)行，迫使數(shù)據(jù)移動(dòng)并存儲(chǔ)到多個(gè)平臺(tái)上。

日立公司大數(shù)據(jù)分析高級(jí)產(chǎn)品營銷經(jīng)理弗雷德·歐(Fred Oh)說：“理想的數(shù)據(jù)湖基礎(chǔ)設(shè)施能夠存儲(chǔ)單一數(shù)據(jù)副本，并且讓應(yīng)用程序針對(duì)單一數(shù)據(jù)源執(zhí)行，沒必要移動(dòng)數(shù)據(jù)或制作副本(比如在Linux、虛擬機(jī)和Hadoop之間)。”

8. 集成分析

分析不是一種新的功能，多年來它就存在于傳統(tǒng)的RDBMS環(huán)境中。不同之處在于，出現(xiàn)了基于開源的應(yīng)用程序，以及能夠?qū)?shù)據(jù)庫表與社交媒體和非結(jié)構(gòu)化數(shù)據(jù)源(比如維基百科)集成起來。關(guān)鍵在于，能夠把多種類型和格式的數(shù)據(jù)集成為一種標(biāo)準(zhǔn)的數(shù)據(jù)，那樣就能更輕松、更一致地完成可視化和報(bào)告。擁有完成這項(xiàng)工作的合適工具集是確保任何分析/商業(yè)智能項(xiàng)目成功的關(guān)鍵。

歐說：“說到分析，重要的是要明白真正的挑戰(zhàn)不在可視化，而在數(shù)據(jù)集成，尤其是集成來自多個(gè)數(shù)據(jù)源、采用多種格式的數(shù)據(jù)。一套全面的數(shù)據(jù)集成工具和基于GUI的集成控制臺(tái)可以克服企業(yè)在大數(shù)據(jù)方面的挑戰(zhàn)。”

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

大數(shù)據(jù)夠糟糕，大視頻更是為這個(gè)現(xiàn)象添加了壓力。比如說，企業(yè)日益使用視頻監(jiān)控，不僅僅出于安全性，還為了提高運(yùn)營和工業(yè)效率，簡化流量管理，支持監(jiān)管合規(guī)及另外幾種使用場(chǎng)合。很快，這些數(shù)據(jù)源會(huì)生成大量內(nèi)容。那些要處理大視頻的企業(yè)最好確保為此建立了合適類別的數(shù)據(jù)存儲(chǔ)系統(tǒng)，無論是不是基于Hadoop。

歐說：“這些應(yīng)用程序正在帶來大量的視頻數(shù)據(jù)，要是沒有合適的專用存儲(chǔ)解決方案，這些數(shù)據(jù)會(huì)帶來諸多問題，比如數(shù)據(jù)丟失和視頻質(zhì)量下降。”

10. 沒有贏家

最近Hadoop無疑攻下了許多地盤。所以，隨著數(shù)據(jù)存儲(chǔ)量急劇增長，它會(huì)是最終贏家，擊敗其他所有方法嗎?不太可能。

比如說，由于OLTP方面的固有優(yōu)點(diǎn)以及要求100%的可用性，基于SAN的傳統(tǒng)架構(gòu)不會(huì)在近期被取代。但是如果需要分析以及與非結(jié)構(gòu)化數(shù)據(jù)(比如社交媒體)集成，那么評(píng)估超融合平臺(tái)就有引人入勝的理由，因?yàn)槌诤掀脚_(tái)將服務(wù)器計(jì)算、分布式文件系統(tǒng)、Hadoop/Spark和更新穎的數(shù)據(jù)庫應(yīng)用軟件與基于開源的分析工具整合起來。

因此，最佳方法將超融合平臺(tái)與分布式文件系統(tǒng)整合起來，并集成了分析軟件?；贚inux的傳統(tǒng)RDBMS應(yīng)用(DWO和數(shù)據(jù)市場(chǎng)等)可滿足這個(gè)用途，Hadoop/Spark/MapReduce則應(yīng)對(duì)新的社交媒體挑戰(zhàn)，使用服務(wù)器虛擬化提供了靈活性和效率。但是這每種環(huán)境都可能形成不同的數(shù)據(jù)孤島。理想的方法就是同時(shí)支持這三種環(huán)境，并增添這種功能：可在數(shù)據(jù)源處執(zhí)行應(yīng)用程序，并減少分析工作流中的數(shù)據(jù)移動(dòng)。

歐說：“成功的關(guān)鍵在于實(shí)施的系統(tǒng)考慮到了可擴(kuò)展性、分析集成和專業(yè)知識(shí)。最終，存儲(chǔ)專業(yè)人員需要預(yù)料未來的要求，而不僅僅著眼于存儲(chǔ)。”

原文標(biāo)題：Big Data Storage: Top Ten Tips for Scaling Hadoop，作者：Drew Robb

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】