不同大數(shù)據(jù)分析的存儲選擇

近來大數(shù)據(jù)分析這個詞正逐漸成為IT界流行的一個術(shù)語，以代指有關(guān)大數(shù)據(jù)本身的猜想，通俗說來即成堆數(shù)據(jù)背后問題的答案。然而，如果我們能夠從足夠的數(shù)據(jù)點入手比對及交叉分析，或許能幫助我們找到一些有用的數(shù)據(jù)，甚至可能幫助避免災(zāi)難。
    問題是顯而易見的，所有的分析都需要大量甚至海量的數(shù)據(jù)，這便給當今的IT管理人員帶來了更新的挑戰(zhàn)，即如何捕獲、存取、以及分析這些數(shù)據(jù)并將從中得到的分析用于后續(xù)任務(wù)的執(zhí)行？
   大數(shù)據(jù)分析應(yīng)用通常會使用例如網(wǎng)絡(luò)流量、金融交易記錄以及敏感數(shù)據(jù)來替代傳統(tǒng)形式的內(nèi)容。數(shù)據(jù)本身的價值在于數(shù)據(jù)間的比對、關(guān)聯(lián)或者引用。對大數(shù)據(jù)的分析通常會意味著與大量的小數(shù)據(jù)對象打交道，而這些小數(shù)據(jù)對象往往對響應(yīng)延時要求非常之高。
    當前業(yè)界主要有兩種大數(shù)據(jù)分析場景，而它們通常是根據(jù)數(shù)據(jù)處理的形式而區(qū)分：
    在實時使用場景下，響應(yīng)效率是最為關(guān)鍵的 ,因此大數(shù)據(jù)存儲架構(gòu)本身的設(shè)計需要滿足最小延時的功能。
    同步，即實時的或者近乎于實時的；另外一種就是異步的方式，這種方式下，數(shù)據(jù)首先會被獲取，記錄下來然后再用批處理進程進行分析。
   同步分析
    可以想到的近乎于實時的大數(shù)據(jù)分析的最早的例子就是超級市場里的工作人員是如何統(tǒng)計消費者行為習慣以便于提供相應(yīng)的優(yōu)惠促銷券的。事實上是，消費者購買行為計算很可能在用戶收銀前就已經(jīng)完成，但是概念本身是非常類似的。另外一個相關(guān)的例子是在線社交網(wǎng)站可以通過訪問用戶的行為建立屬于他們的行為數(shù)據(jù)庫，這樣就可以根據(jù)各自不同的消費習慣提供不同的點對點廣告植入。
    在零售行業(yè)，一些大型商鋪正開始在停車場對前來購物的消費者使用面部識別技術(shù)，這樣一旦他們路過或者經(jīng)過對應(yīng)的商鋪與之相應(yīng)的促銷信息便隨之而來。因此，在這樣一類的實時大數(shù)據(jù)分析場景中，速度是第一要素，故而大數(shù)據(jù)存儲架構(gòu)需要建設(shè)成為低延時的場景。
   針對同步大數(shù)據(jù)分析的存儲
    實時分析應(yīng)用通常會運行在例如NoSQL之類的數(shù)據(jù)庫上，通常都能支持海量可擴展的商用硬件上。Hadoop,從另一角度考慮，非常適合批量的數(shù)據(jù)處理，這種技術(shù)非常合適于異步大數(shù)據(jù)分析。由于在很多場合下，存儲本身會成為延時問題的瓶頸，那么固態(tài)存儲設(shè)備對于實時數(shù)據(jù)分析是很有幫助的。閃存存儲可以以多種形式進行部署：作為傳統(tǒng)存儲磁盤陣列的一層，以NAS系統(tǒng)的方式，再或者以應(yīng)用服務(wù)器本身的方式都可以實現(xiàn)。
    這種服務(wù)器端的閃存實施方式廣受用戶歡迎，之所以這樣是由于它能夠?qū)崿F(xiàn)最低程度的延時（因該方式下的存儲最為接近CPU），并且提供了很靈活的容量選擇，幾百GB容量就可以實現(xiàn)。SAS/SATA接口的固態(tài)硬盤本身就是個選擇，但是近來我們看到PCIe板卡為接口的固態(tài)設(shè)備逐漸成了性能應(yīng)用（比如實時分析）的標準，因為相對于前者，其延時更低。
    如今，業(yè)界有許多提供PCIe閃存存儲的公司，包括Fusion-io、LSI、Micron Technology、SanDisk、sTec（現(xiàn)在是HGST的一部分，作為Western DigITal的一個部門）、Violin Memory以及Virident （也被Western DigITal收購）。其它所有主流服務(wù)器及存儲廠商們也都提供PCIe解決方案，大多數(shù)是與這些公司通過了OEM協(xié)議。
    盡管PCIe卡最大容量已經(jīng)近乎于10 TB,但仍無法滿足用戶的需求，因此一個共享的存儲資源池也是需要考慮的。一個解決方案是使用Virident的FlashMAX Connect software,這種軟件可以實現(xiàn)將PCIe卡的資源通過服務(wù)器上的InfiniBand,進行資源池化。
    這對擴展閃存容量會非常有幫助，尤其是對于那些PCIe插槽不足的服務(wù)器或者需要使用VMware vSphere的Storage vMotion功能的時候。通過在不同服務(wù)器之間實現(xiàn)閃存的池化，這些解決方案可以提供冗余以及高可用性方面的支持。
    另外一個選擇是通過InfiniBand、光纖通道或者甚至PCIe的連接方式使用全閃存陣列。全閃存陣列的容量從10 TB到100 TB之間，可以以模塊的方式進行擴容。以全閃存陣列這類的高端解決方案可以提供至少100萬IOPS,相對應(yīng)到百萬微秒級別。大多數(shù)主流的存儲廠商都有相應(yīng)的全閃存陣列類別，除了IBM對Texas Memory的收購，小廠商都有類似的產(chǎn)品并提供了更多的選擇，他們中有Kaminario、Nimbus Data Systems、Pure Storage、Tegile、即將被思科收購的Whiptail以及Violin Memory.
   異步大數(shù)據(jù)分析
    異步處理的大數(shù)據(jù)分析中遵守了捕獲、存儲加分析的流程，過程中數(shù)據(jù)由傳感器、網(wǎng)頁服務(wù)器、銷售終端、移動設(shè)備等獲取，之后再存儲到相應(yīng)設(shè)備上，之后再進行分析。由于這些類型的分析都是通過傳統(tǒng)的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）進行的，數(shù)據(jù)形式都需要轉(zhuǎn)換或者轉(zhuǎn)型成為RDBMS能夠使用的結(jié)構(gòu)類型，例如行或者列的形式，并且需要和其它的數(shù)據(jù)相連續(xù)。
    處理的過程被稱之為提取、變形、加載或者稱為ETL.首先將數(shù)據(jù)從源系統(tǒng)中提取處理，再將數(shù)據(jù)標準化處理且將數(shù)據(jù)發(fā)往相應(yīng)的數(shù)據(jù)倉儲等待進一步分析。在傳統(tǒng)數(shù)據(jù)庫環(huán)境中，這種ETL步驟相對直接，因為分析的對象往往是為人們熟知的金融報告、銷售或者市場報表、企業(yè)資源規(guī)劃等等。然而在大數(shù)據(jù)環(huán)境下，ETL可能會變得相對復(fù)雜，因此轉(zhuǎn)型過程對于不同類型的數(shù)據(jù)源之間處理方式是不同的。
    當分析開始的時候，數(shù)據(jù)首先從數(shù)據(jù)倉儲中會被抽出來，被放進RDBMS里以產(chǎn)生需要的報告或者支撐相應(yīng)的商業(yè)智能應(yīng)用。在大數(shù)據(jù)分析的環(huán)節(jié)中，裸數(shù)據(jù)以及經(jīng)轉(zhuǎn)換了的數(shù)據(jù)大都會被保存下來，因為可能在后面還需要再次轉(zhuǎn)換。
   適用于異步大數(shù)據(jù)分析的存儲設(shè)備
    在異步大數(shù)據(jù)場景下對于存儲的調(diào)整主要來自于容量、可擴展性、可預(yù)見性，尤其是提供這些功能的成本。當數(shù)據(jù)倉庫產(chǎn)生大量數(shù)據(jù)集的時候，磁帶存儲的延時會顯得非常大以至于無法滿足業(yè)務(wù)需求。換而言之，傳統(tǒng)的向上擴展的磁盤存儲架構(gòu)在相同容量標準下，往往并不能做到節(jié)約成本。
    橫向擴展存儲。橫向擴展存儲是使用模塊或者節(jié)點以群集的方式將資源池化，以文件系統(tǒng)的形式作為接口為大數(shù)據(jù)分析服務(wù)。例如有Dell EqualLogic、EMC Isilon、Exablox （also object-based）、Gridstore、HP StoreAll （之前叫Ibrix）以及IBM橫向擴展NAS （SONAS）。這些解決方案里，每個節(jié)點都包含有處理能力及磁盤容量，它們能實現(xiàn)容量與性能的并行擴展。
    Hadoop技術(shù)也被應(yīng)用于存儲架構(gòu)的方式，使得企業(yè)能夠以較低的硬件成本與較高的靈活性，搭建屬于它們自己的高可擴展性存儲系統(tǒng)。Hadoop運行在集群的不同節(jié)點上，每個節(jié)點都有自己的存儲及計算資源，尤其是在面對數(shù)據(jù)處理需求的時候。其它節(jié)點會協(xié)調(diào)這些處理任務(wù)并以分布式資源池的方式進行處理，通常是以Hadoop分布式文件系統(tǒng)HDFS的形式存在。
   為什么Hadoop對大數(shù)據(jù)意義重大
    Hadoop得以在大數(shù)據(jù)應(yīng)用中廣泛應(yīng)用得益于其自身在數(shù)據(jù)提取、變形和加載（ETL）方面上的天然優(yōu)勢。Hadoop的分布式架構(gòu)，將處理引擎盡可能的靠近存儲，對例如像ETL這樣的批處理操作相對合適，因為類似這樣操作的批處理結(jié)果可以直接走向存儲。Hadoop的MapReduce功能實現(xiàn)了將單個任務(wù)打碎，并將碎片任務(wù)發(fā)送（Map）到多個節(jié)點上，之后再以單個數(shù)據(jù)集的形式加載（Reduce）到數(shù)據(jù)倉庫里。
    但是對于Hadoop,特別是Hadoop分布式文件系統(tǒng)（HDFS）來說，數(shù)據(jù)至少需要三份以支持數(shù)據(jù)的高可用性。對于TB級別的數(shù)據(jù)來說，HDFS看起來還是可行的，但當達到PB級別海量數(shù)據(jù)的時候，其帶來的存儲成本壓力不可小覷。即便是可橫向擴展存儲亦不能避免壓力本身，一些廠商選擇了使用RAID技術(shù)實現(xiàn)卷級別的保護，而在系統(tǒng)級別則使用了復(fù)制的方式。對象存儲技術(shù)可以提供面對大型環(huán)境的數(shù)據(jù)冗余問題的解決方案。
    對象存儲。基于對象的存儲架構(gòu)可以通過替代分層存儲架構(gòu)的方式，極大程度上提升可橫向擴展存儲的優(yōu)勢，它使用的方式則是以單一索引來關(guān)聯(lián)靈活的數(shù)據(jù)對象。這將解決無限制擴展問題，從而提升了性能本身。對象存儲系統(tǒng)包含了無需RAID或者復(fù)制作為數(shù)據(jù)保護的糾刪碼，極大程度上提升了存儲的使用效率。
    不像HDFS方式下需要兩份或者三份多余數(shù)據(jù)拷貝以及額外的RAID機制，對象存儲系統(tǒng)的糾刪碼可僅以50%-60%的額外容量就能達到更高的數(shù)據(jù)保護級別。在大數(shù)據(jù)存儲級別，對于存儲本身的節(jié)省將是非常重大的。許多對象存儲系統(tǒng)亦可選擇，包括Caringo、DataDirect Networks Web Object Scaler、NetApp StorageGRID、Quantum Lattus以及開源的 OpenStack Swift和 Ceph.
    一些對象存儲系統(tǒng)，比如Cleversafe的，甚至可以做到與Hadoop兼容。在這些項目的實施中，Hadoop軟件組件可以運行在這些對象存儲節(jié)點的CPU上，對象存儲系統(tǒng)將替換存儲節(jié)點的Hadoop分布式文件系統(tǒng)。
   大數(shù)據(jù)存儲的底線
   大數(shù)據(jù)分析逐漸在IT行業(yè)成為了一個熱門的話題，越來越多的企業(yè)相信它將引領(lǐng)企業(yè)走向成功。然而任何事情都有兩個方面。這件事情上來看，就是現(xiàn)有存儲技術(shù)本身。傳統(tǒng)存儲系統(tǒng)不管是在需要極低延時響應(yīng)、實時大數(shù)據(jù)應(yīng)用或者還是面對海量數(shù)據(jù)倉儲的數(shù)據(jù)挖掘應(yīng)用的時候都會遇到瓶頸。為了保證大數(shù)據(jù)分析業(yè)務(wù)能正常運行，相應(yīng)的存儲系統(tǒng)需要足夠快，可擴展并且性價比有優(yōu)勢。
    對于閃存解決方案來說，不管是以服務(wù)器端flash卡的形式還是以全閃存陣列的形式，都提供了一些對于高性能、低延時、大容量存儲的替代解決方案。基于對象的帶有擦寫功能編程的可橫向擴展架構(gòu)為使用傳統(tǒng)RAID以及復(fù)制方式的存儲結(jié)構(gòu)提供了一種能具備更高效率和更低價格的選擇。