近來大數據分析這個詞正逐漸成為IT界流行的一個術語，以代指有關大數據本身的猜想，通俗說來即成堆數據背后問題的答案。然而，如果我們能夠從足夠的數據點入手比對及交叉分析，或許能幫助我們找到一些有用的數據，甚至可能幫助避免災難。

[[110443]]

問題是顯而易見的，所有的分析都需要大量甚至海量的數據，這便給當今的IT管理人員帶來了更新的挑戰，即如何捕獲、存取、以及分析這些數據并將從中得到的分析用于后續任務的執行?

大數據分析應用通常會使用例如網絡流量、金融交易記錄以及敏感數據來替代傳統形式的內容。數據本身的價值在于數據間的比對、關聯或者引用。對大數據的分析通常會意味著與大量的小數據對象打交道，而這些小數據對象往往對響應延時要求非常之高。

當前業界主要有兩種大數據分析場景，而它們通常是根據數據處理的形式而區分：

在實時使用場景下，響應效率是最為關鍵的 ，因此大數據存儲架構本身的設計需要滿足最小延時的功能。

同步，即實時的或者近乎于實時的；另外一種就是異步的方式，這種方式下，數據首先會被獲取，記錄下來然后再用批處理進程進行分析。

同步分析

可以想到的近乎于實時的大數據分析的最早的例子就是超級市場里的工作人員是如何統計消費者行為習慣以便于提供相應的優惠促銷券的。事實上是，消費者購買行為計算很可能在用戶收銀前就已經完成，但是概念本身是非常類似的。另外一個相關的例子是在線社交網站可以通過訪問用戶的行為建立屬于他們的行為數據庫，這樣就可以根據各自不同的消費習慣提供不同的點對點廣告植入。

在零售行業，一些大型商鋪正開始在停車場對前來購物的消費者使用面部識別技術，這樣一旦他們路過或者經過對應的商鋪與之相應的促銷信息便隨之而來。因此，在這樣一類的實時大數據分析場景中，速度是***要素，故而大數據存儲架構需要建設成為低延時的場景。

針對同步大數據分析的存儲

實時分析應用通常會運行在例如NoSQL之類的數據庫上，通常都能支持海量可擴展的商用硬件上。Hadoop，從另一角度考慮，非常適合批量的數據處理，這種技術非常合適于異步大數據分析。由于在很多場合下，存儲本身會成為延時問題的瓶頸，那么固態存儲設備對于實時數據分析是很有幫助的。閃存存儲可以以多種形式進行部署：作為傳統存儲磁盤陣列的一層，以NAS系統的方式，再或者以應用服務器本身的方式都可以實現。

這種服務器端的閃存實施方式廣受用戶歡迎，之所以這樣是由于它能夠實現***程度的延時（因該方式下的存儲最為接近CPU），并且提供了很靈活的容量選擇，幾百GB容量就可以實現。SAS/SATA接口的固態硬盤本身就是個選擇，但是近來我們看到PCIe板卡為接口的固態設備逐漸成了性能應用（比如實時分析）的標準，因為相對于前者，其延時更低。

如今，業界有許多提供PCIe閃存存儲的公司，包括Fusion-io、LSI、Micron Technology、SanDisk、sTec（現在是HGST的一部分，作為Western Digital的一個部門）、Violin Memory以及Virident (也被Western Digital收購)。其它所有主流服務器及存儲廠商們也都提供PCIe解決方案，大多數是與這些公司通過了OEM協議。

盡管PCIe卡***容量已經近乎于10 TB，但仍無法滿足用戶的需求，因此一個共享的存儲資源池也是需要考慮的。一個解決方案是使用Virident的FlashMAX Connect software，這種軟件可以實現將PCIe卡的資源通過服務器上的InfiniBand，進行資源池化。

這對擴展閃存容量會非常有幫助，尤其是對于那些PCIe插槽不足的服務器或者需要使用VMware vSphere的Storage vMotion功能的時候。通過在不同服務器之間實現閃存的池化，這些解決方案可以提供冗余以及高可用性方面的支持。

另外一個選擇是通過InfiniBand、光纖通道或者甚至PCIe的連接方式使用全閃存陣列。全閃存陣列的容量從10 TB到100 TB之間，可以以模塊的方式進行擴容。以全閃存陣列這類的高端解決方案可以提供至少100萬IOPS，相對應到百萬微秒級別。大多數主流的存儲廠商都有相應的全閃存陣列類別，除了IBM對Texas Memory的收購，小廠商都有類似的產品并提供了更多的選擇，他們中有Kaminario、Nimbus Data Systems、Pure Storage、Tegile、即將被思科收購的Whiptail以及Violin Memory。

異步大數據分析

異步處理的大數據分析中遵守了捕獲、存儲加分析的流程，過程中數據由傳感器、網頁服務器、銷售終端、移動設備等獲取，之后再存儲到相應設備上，之后再進行分析。由于這些類型的分析都是通過傳統的關系型數據庫管理系統(RDBMS)進行的，數據形式都需要轉換或者轉型成為RDBMS能夠使用的結構類型，例如行或者列的形式，并且需要和其它的數據相連續。

處理的過程被稱之為提取、變形、加載或者稱為ETL。首先將數據從源系統中提取處理，再將數據標準化處理且將數據發往相應的數據倉儲等待進一步分析。在傳統數據庫環境中，這種ETL步驟相對直接，因為分析的對象往往是為人們熟知的金融報告、銷售或者市場報表、企業資源規劃等等。然而在大數據環境下，ETL可能會變得相對復雜，因此轉型過程對于不同類型的數據源之間處理方式是不同的。

當分析開始的時候，數據首先從數據倉儲中會被抽出來，被放進RDBMS里以產生需要的報告或者支撐相應的商業智能應用。在大數據分析的環節中，裸數據以及經轉換了的數據大都會被保存下來，因為可能在后面還需要再次轉換。

適用于異步大數據分析的存儲設備

在異步大數據場景下對于存儲的調整主要來自于容量、可擴展性、可預見性，尤其是提供這些功能的成本。當數據倉庫產生大量數據集的時候，磁帶存儲的延時會顯得非常大以至于無法滿足業務需求。換而言之，傳統的向上擴展的磁盤存儲架構在相同容量標準下，往往并不能做到節約成本。

橫向擴展存儲。橫向擴展存儲是使用模塊或者節點以群集的方式將資源池化，以文件系統的形式作為接口為大數據分析服務。例如有Dell EqualLogic、EMC Isilon、Exablox (also object-based)、Gridstore、HP StoreAll (之前叫Ibrix)以及IBM橫向擴展NAS (SONAS)。這些解決方案里，每個節點都包含有處理能力及磁盤容量，它們能實現容量與性能的并行擴展。

Hadoop技術也被應用于存儲架構的方式，使得企業能夠以較低的硬件成本與較高的靈活性，搭建屬于它們自己的高可擴展性存儲系統。Hadoop運行在集群的不同節點上，每個節點都有自己的存儲及計算資源，尤其是在面對數據處理需求的時候。其它節點會協調這些處理任務并以分布式資源池的方式進行處理，通常是以Hadoop分布式文件系統HDFS的形式存在。

為什么Hadoop對大數據意義重大

Hadoop得以在大數據應用中廣泛應用得益于其自身在數據提取、變形和加載(ETL)方面上的天然優勢。Hadoop的分布式架構，將處理引擎盡可能的靠近存儲，對例如像ETL這樣的批處理操作相對合適，因為類似這樣操作的批處理結果可以直接走向存儲。Hadoop的MapReduce功能實現了將單個任務打碎，并將碎片任務發送(Map)到多個節點上，之后再以單個數據集的形式加載(Reduce)到數據倉庫里。

但是對于Hadoop，特別是Hadoop分布式文件系統（HDFS）來說，數據至少需要三份以支持數據的高可用性。對于TB級別的數據來說，HDFS看起來還是可行的，但當達到PB級別海量數據的時候，其帶來的存儲成本壓力不可小覷。即便是可橫向擴展存儲亦不能避免壓力本身，一些廠商選擇了使用RAID技術實現卷級別的保護，而在系統級別則使用了復制的方式。對象存儲技術可以提供面對大型環境的數據冗余問題的解決方案。

對象存儲。基于對象的存儲架構可以通過替代分層存儲架構的方式，極大程度上提升可橫向擴展存儲的優勢，它使用的方式則是以單一索引來關聯靈活的數據對象。這將解決無限制擴展問題，從而提升了性能本身。對象存儲系統包含了無需RAID或者復制作為數據保護的糾刪碼，極大程度上提升了存儲的使用效率。

不像HDFS方式下需要兩份或者三份多余數據拷貝以及額外的RAID機制，對象存儲系統的糾刪碼可僅以50%-60%的額外容量就能達到更高的數據保護級別。在大數據存儲級別，對于存儲本身的節省將是非常重大的。許多對象存儲系統亦可選擇，包括Caringo、DataDirect Networks Web Object Scaler、NetApp StorageGRID、Quantum Lattus以及開源的 OpenStack Swift和 Ceph。

一些對象存儲系統，比如Cleversafe的，甚至可以做到與Hadoop兼容。在這些項目的實施中，Hadoop軟件組件可以運行在這些對象存儲節點的CPU上，對象存儲系統將替換存儲節點的Hadoop分布式文件系統。

大數據存儲的底線

大數據分析逐漸在IT行業成為了一個熱門的話題，越來越多的企業相信它將***企業走向成功。然而任何事情都有兩個方面。這件事情上來看，就是現有存儲技術本身。傳統存儲系統不管是在需要極低延時響應、實時大數據應用或者還是面對海量數據倉儲的數據挖掘應用的時候都會遇到瓶頸。為了保證大數據分析業務能正常運行，相應的存儲系統需要足夠快，可擴展并且性價比有優勢。

對于閃存解決方案來說，不管是以服務器端flash卡的形式還是以全閃存陣列的形式，都提供了一些對于高性能、低延時、大容量存儲的替代解決方案。基于對象的帶有擦寫功能編程的可橫向擴展架構為使用傳統RAID以及復制方式的存儲結構提供了一種能具備更高效率和更低價格的選擇。

原文鏈接：http://www.36dsj.com/archives/6933