雲計算的時代，出現分散式存儲和分散式資料庫的解決方案

資料存儲主要有兩種方式：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這樣的物件導向存儲是目前非常火的一種非結構化資料存儲方式。 這是順應雲計算大潮的一種存儲方式，使用者存儲提供的不再是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生態系統就是真正意義的統一資料存儲和處理平臺了。

(責任編輯：蒙遺善)