數據存儲主要有兩種方式：Database和FileSystem,后面發展出了Object-oriented storage,但是總的來看就是存儲結構化和非結構化數據兩種。 DB開始是為了結構化數據存儲和共享而服務的。FileSystem存儲和共享的是大文件，非結構的數據，像圖片，文檔，影音等。隨著數據量的增大，單機存儲已經不能滿足結構化和非結構化數據的需求，那么在云計算的時代，就出現了分布式存儲和分布式數據庫的解決方案。
1，File System, Object-oriented storage
那么對于非結構化數據存儲就出現了分布式文件系統(Lustre)，分布式對象存儲系統(Ceph/S3)，P2P存儲系統(Oceanstore)等。
(1)像Lustre這類的分布式文件系統在HPC領域應用很廣，對于文件系統底層硬件的要求相對比較高，一般是SAN和磁盤陣列這樣的高端存儲。所以這類文件系統的IO性能會比較高，背后的代價就是成本比較高。這類存儲產品一般用在銀行、證券、石油、航天等領域。
(2)像Ceph/S3這樣的面向對象存儲是目前非?；鸬囊环N非結構化數據存儲方式。這是順應云計算大潮的一種存儲方式，用戶存儲提供的不再是 POSIX文件系統接口，而是通過REST等方式訪問云端數據的接口，用戶不需要維護和管理任何存儲設備。而且云計算服務提供商會提供相應的SLA來保證 IO性能和數據的reliability以及availability，所以這種方式對于用戶很受歡迎。在現在互聯網開放平臺的大潮中，各種各樣的API 就是用戶構建應用的基礎，而API背后的服務就是基于云提供商的。在各種云計算服務中，云存儲服務是其中最重要的。在云計算領域提倡數據和應用分離，例如 Amazon推薦使用EC2的用戶把數據存到S3中而不是存放在自己EC2 Instance的本地硬盤上。最近國內最像Amazon的云計算服務提供商盛大云出現了用戶數據丟失的情況，仔細研究了下發現是用戶云主機(類似于 EC2 Instance)上的數據丟失了，原來是云主機沒有備份機制，所以云主機磁盤出了問題就會導致數據丟失。從AWS(Amazon Web Service)和GCE(Google Compute Engine)的官網可以知道，這兩家頂級的云計算服務提供商都不提供云主機的本地磁盤備份機制。我們可以這樣理解，在這種計算模型下，云主機EC2 Instance相當于計算機的CPU和Memory，不具備持久化功能;而云存儲S3具備持久化存儲功能，相當于計算機的硬盤。所以可以把整個云看成是一個新型的計算機體系結構。
(3)像Oceanstore這種P2P存儲的方式，在大家共享影音文件方面的應用比較成熟。比較典型的包括當時的eMule,Maze等。影音文件一般比較大，我們相當于把它存放在廣域網/局域網的大的存儲池里，這樣用戶之間都可以就近下載東西，而且用戶自己也充當服務器的功能為別人提供下載的來源，省得每次都去中央服務器那下載，帶寬的bottleneck解決了。但是這類存儲一般不能保證延遲，用戶在下載一個電影可能需要幾分鐘，那么用戶不太關心中間的傳輸速度是不是有什么波峰波谷，只要總的帶寬比較高就行了，根據“文件大小/帶寬=傳輸時間”只要傳輸時間最小就行了。但是我覺得隨著云計算云存儲的普及，主要的云計算服務提供商會在全國鋪設多個存儲和計算的數據中心，這樣就可以分散主數據中心的帶寬壓力，形成粒度很大的類似P2P的存儲網絡。而且隨著CDN技術的發展，還有就是網絡帶寬的不斷提高，P2P這種模式的發展可能會受到制約。
2,Database, Data warehouse, Big Data
說完FileSystem，就該說DB了。RDBMS設計的初衷是為了存儲關系型數據，也就是存儲的數據之間存在著各種范式的嚴格要求。但是現實世界中的數據不是都那么嚴格規范化的，尤其是越來越多的機器和人類社會活動中產生的數據(如用戶瀏覽互聯網的日志數據，社交網絡數據，醫療診斷數據，交通數據，金融交易數據，電子商務交易數據等)是半結構化或者非結構化的。這些數據同樣有存儲和分析的需求，而且這些數據中往往蘊藏著極大的商業價值。對傳統 RDBMS中的關系型數據的分析是數據倉庫DW干的事，即分析的對象是各種關系型數據。那么對于這些非結構化數據的分析就不像DW那么簡單了，除了我們常見的DW的功能，我們在對這些“大數據”的分析中又出現了回歸，聚類，分類，關聯分析等機器學習的需求，那么在“大數據”時代的分析平臺就不像數據倉庫 DW那么簡單了。
那么對半結構化和非結構化數據存儲和分析的需求，催生了NoSQL數據庫的誕生。提到NoSQL數據庫，我們發現現在的NoSQL數據庫和RDBMS類似都有兩方面的需求：OLTP和OLAP。當然我覺得這兩個術語放在這不太合適，畢竟OLTP中的 T(Trasaction)現在大多數NoSQL數據庫是不提供的，所以這兩個詞只是形象的表示下，從嚴格意義上是不對的。通俗的解釋這兩方面的需求就是：用戶對數據的在線存儲訪問;離線分析型應用對數據的訪問。前者主要是對數據的CRUD操作，用戶在線訪問數據比較關心訪問延遲，同時盡可能高的提高吞吐。后者呢主要是對數據的一次寫多次讀操作，應用訪問數據不太關心延遲，只在乎吞吐量。那么我們可以把這兩種典型應用對應到以前的數據庫DB和數據倉庫 DW。同時在“大數據”時代，數據的分析型應用已經不僅僅局限在數據倉庫DW的范疇內，以聚類，分類，關聯分析為代表的機器學習應用也是重要的需求。
在“大數據”時代數據存儲和處理的事實標準Hadoop生態系統中，大多數人把它認為是數據倉庫DW在大數據領域替代品，更多的人也是把Hadoop用到以數據挖掘和機器學習為代表的分析型應用的場景中。但是我感覺從整個生態系統中還是能看到數據庫DB的影子的。下面這張圖是Hadoop生態系統的主要組件，從架構上看是面向分析型應用的。但是其中的HBase已經在一些大公司用在實時在線數據的存儲中了(Facebook的統一消息系統和Apple的 iCloud)。HBase作為一個在線數據存儲和訪問的數據庫主要的幾個問題是：底層HDFS的HA還沒有穩定下來;沒有一個保證數據完整性的機制(例如事務或者類似的機制);沒有一個統一的訪問接口(類似SQL)。相信這些問題解決了，以HBase為代表的NoSQL數據庫在在線數據存儲訪問方面會更進一步。
而在分析型應用市場，Hadoop可謂所向披靡，已經成為大數據分析的事實標準。目前用的最多的就是把RDBMS里面的關系型數據導入HDFS中，然后用MapReduce進行分析(淘寶會把用戶的交易數據從RDBMS中導入HDFS上然后用MR進行分析和挖掘);或者把日志數據放到HDFS用MapReduce進行分析(百度的搜索日志分析)。但是目前對于這些半結構化或者非結構化數據的元數據管理還不太成熟和統一，圖中的 HCatalog就是為了完善這一部分功能而開發的，有了它Hive和Pig的使用會更加便捷。另外一種就是在HBase中產生的數據，直接用基于 HBase的MapReduce進行處理和分析，這個就有點像Greenplum或者Teradata做的基于RDBMS的分布式數據庫產品了。由于基于 Hadoop的分析平臺有很多機器學習的計算需求，而很多機器學習的算法是計算密集型或者是計算數據雙密集型的，所以基于Hadoop的分析平臺也有計算密集型的需求。同時由于MapReduce是為了離線分析而設計的，那么對于實時分析來說沒有優勢。而有些數據的時效性是很重要的，分析的實時性就很關鍵，所以我們還需要實時計算引擎。
基于上述需求，在后面的Hadoop的版本YARN中會把MapReduce做成統一的資源管理和任務調度層，會支持OpenMPI,Storm,S4,Spark,MapReduce等多種計算模型，橫跨實時數據處理，離線數據處理，計算密集型和數據密集型應用。到那個時候整個Hadoop生態系統就是真正意義的統一數據存儲和處理平臺了。
