hadoop依靠hbase實現儲存，hbase採用列儲存方案（典型nosql），加上lsm（log structured merge-tree）對資料緊縮，使得資料儲存效率不錯，很適合大資料環境下的讀操作，但是如果做刪除資料，由於列儲存和lsm固有的特點，這時的處理效率不高。
圖1 hbase列儲存，nosql環境的主流儲存方案，高效讀是最大優點。
lexst主要面向商業領域的大資料儲存，這一點與面向網際網路行業儲存有所不同，除了保證要保證大量的高效的讀操作，還要兼顧大量的寫處理（包括插入、刪除、更新，完全標準sql操作），以及資料的完整性、可靠性、安全性，所以在儲存方案選擇上採用了行儲存。行儲存特點是寫入效率高，更新和刪除容易實現，並且能夠有效保證資料的完整性和一致性，但是讀效率不如列儲存。為了解決這個問題，lexst通過以下方案加以改進：
1. 資料聚湊和有序的行排列布局
2. 可調的儲存結構
3. 資料平衡
4. build節點優化
1.先談談有序排列的問題。大資料讀取時，很少有關聯式資料庫讀取單條記錄的現象，普遍情況都是每次讀取一批同質的資料。利用這種情況，在寫入資料時，把相同或者相鄰的資料按照某種排列順序聚湊在一起時，在讀取時，就可以做到一次性順序讀完。避免磁頭在磁碟上的多次移動（機械硬碟的磁頭移動非常費時間），這樣就會顯著提高資料讀效率。但是每個使用者對資料排列規則可能又是不一樣的。比如一行資料預設的排列位置是「1，2，3」。在a使用者處可能希望的排列順序是「1，3，2」，到了b使用者處，可能又是「2，3，1」。對於這種情況，lexst使用「create layout」語句，允許使用者在執行時自由選擇自己的資料排列方案。順帶說一句，「create layout」需要在建表時確立，否則將以預設位置進行排列。
2.再說儲存結構，lexst的儲存結構保證資料可以極快的速度在記憶體中進行調整。比如，資料在磁碟上的儲存排列順序是「1，2，3」，但是當使用者需要以「3，1，2」顯示時，就要進行調整；或者使用者只需要「3，1」排列，這時必須刪除冗餘的「2」，也是需要改變。由於編碼上充分利用了x86 cpu上的sse指令集，這個調整效率非常高，在pentium4 2g單核晶元上的測試結果超過1，300，000行/秒。這是對讀過程的又一次改進。
3.還有資料平衡的問題。lexst是乙個分布式的網路儲存系統，資料的儲存量極大，如果把同質資料放在乙個儲存節點上，那麼這個單點上的資料壓力就會很大，嚴重的會造成磁碟損壞或者節點宕機。為避免這種現象的發生，採用了平衡資料的辦法，每個儲存節點布置了其中一部分資料，做到每個節點不超載。當資料儲存和計算時，通過資料分布演算法和各節點之間協同，共同完成處理任務。
4.最後是儲存優化。lexst的集群中，有一類節點專門負責資料優化工作，這就是build節點。優化主要針對兩種情況：
(1) 系統長時間執行，更新、刪除操作頻繁（刪除操作只對資料做刪除標記，並不從磁碟中移除），造成過期/冗餘資料堆積，需要清除時。
(2) 將一種資料格式轉化為另一種資料格式儲存，為讀操作提供更高的效能比。
提供資料優化的是marshal/educe演算法，build節點為使用者提供了這個演算法介面，可以熱發布到build節點上執行。關於演算法的詳細介紹和使用可見《lexst：大規模資料處理系統》一文。
圖2 lexst行儲存布局
lexst行儲存權衡了讀和寫的效率，並對行儲存做了多種優化。在保證資料完整性和一致性基礎上，通過crc32校驗和壓縮、加密等方法，進一步加強了資料的安全性和可靠性。
15 Hadoop壓縮和儲存
hadoop壓縮和儲存思維導圖 為了支援多種壓縮 解壓縮演算法，hadoop引入了編碼 解碼器，如下表所示 2 開啟mapreduce中map輸出壓縮功能 3 設定mapreduce中map輸出資料的壓縮方式 4 執行查詢語句 2 開啟mapreduce最終輸出資料壓縮 3 設定mapreduce最...
hadoop的HDFS檔案儲存
1 什麼是hdfs?hdfs適合做 儲存大檔案。上g t甚至p。一次寫入，多次讀取。並且每次作業都要讀取大部分的資料。搭建在普通商業機群上就可以了。雖然會經常宕機，但hdfs有良好的容錯機制。hdfs不適合做 實時資料獲取。如果有這個需求可以用hbase。很多小檔案。因為namenode要儲存hdf...
Hadoop檔案的儲存格式
純文字格式，若干行記錄。預設用字元編碼儲存 sequencefile格式 順序檔案格式，可進行切割 key value 格式進行儲存，最終形成的是乙個二進位制檔案，需用hadoop提供的api進行寫入儲存。編寫 寫入 seq檔案案例。configuration configuration new c...