hbase存儲小文件
① hadoop有哪些優缺點
一、HDFS缺點：
1、不能做到低延遲：由於hadoop針對高數據吞吐量做了優化，犧牲了獲取數據的延遲，所以對於低延遲數據訪問，不適合hadoop，對於低延遲的訪問需求，HBase是更好的選擇，
2、不適合大量的小文件存儲：由於namenode將文件系統的元數據存儲在內存中，因此該文件系統所能存儲的文件總數受限於namenode的內存容量，根據經驗，每個文件、目錄和數據塊的存儲信息大約佔150位元組。
3、不適合多用戶寫入文件，修改文件：Hadoop2.0雖然支持文件的追加功能，但是還是不建議對HDFS上的 文件進行修改，因為效率低。
4、對於上傳到HDFS上的文件，不支持修改文件，HDFS適合一次寫入，多次讀取的場景。
5、HDFS不支持多用戶同時執行寫操作，即同一時間，只能有一個用戶執行寫操作。
二、HDFS優點：
1、高可靠性。Hadoop按位存儲和處理數據的能力值得人們信賴。
2、高擴展性。Hadoop是在可用的計算機集簇間分配數據並完成計算任務的，這些集簇可以方便地擴展到數以千計的節點中。
3、高效性。Hadoop能夠在節點之間動態地移動數據，並保證各個節點的動態平衡，因此處理速度非常快。
4、高容錯性。Hadoop能夠自動保存數據的多個副本，並且能夠自動將失敗的任務重新分配。
5、低成本。與一體機、商用數據倉庫以及QlikView、Yonghong Z-Suite等數據集市相比，hadoop是開源的，項目的軟體成本因此會大大降低。
6、Hadoop帶有用java語言編寫的框架，因此運行在 Linux 生產平台上是非常理想的。Hadoop 上的應用程序也可以使用其他語言編寫，比如 C++。
② 關於hbase的問題，開啟hbase後一會hmaster和hregionserver就沒了
一、通常向HBase批量導入數據有三種常用方式
1、使用HBase提供的TableOutputFormat，原理是通過一個Maprece作業將數據導入HBase
2、還有一種方式就是使用HBase原生Client API（put）
3、前兩種方式因為須要頻繁的與數據所存儲的RegionServer通信。一次性入庫大量數據時，特別佔用資源，所以都不是很有效。因為HBase在HDFS中是以HFile文件結構存儲的，所以高效便捷的方法就是直接生成HFile文件然後使用Bulk Load方法，即HBase提供的HFileOutputFormat類。
二、Bulk Load基本原理
Bulk Load處理由兩個主要步驟組成：
1、生成HFile文件
Bulk Load的第一步會執行一個Maprece作業，其中使用到了HFileOutputFormat輸出HBase數據文件：StoreFile。
HFileOutputFormat的作用在於使得輸出的HFile文件能夠適應單個region。使用TotalOrderPartitioner類將map輸出結果分區到各個不同的key區間中，每一個key區間都相應著HBase表的region。
2、導入HBase表
第二步使用completebulkload工具將第一步的結果文件依次交給負責文件相應region的RegionServer，並將文件move到region在HDFS上的存儲文件夾中。一旦完畢。將數據開放給clients。
假設在bulk load准備導入或在准備導入與完畢導入的臨界點上發現region的邊界已經改變，completebulkload工具會自己主動split數據文件到新的邊界上。可是這個過程並非最佳實踐，所以用戶在使用時須要最小化准備導入與導入集群間的延時，特別是當其它client在同一時候使用其它工具向同一張表導入數據。
Bulk Load常遇到的一個ERROR:」java.io.IOException: Retry attempted 10 times without completing, ling out」
錯誤解析：
我們使用的Hbase1.0.2版本下，如果Hfile文件 跨越多個region，bulkload會自動地將Hfile文件split，但是對於每次retry只會將指定的Hfile文件split一次。但是在hbase-site.xml配置文件里有個參數hbase.bulkload.retries.number控制了hbase對一個hfile最多plit多少次。這個參數默認是10，如果某個hfile跨越的region數超過10個就會報上述Exception。
解決方案：
將hbase.bulkload.retries.number這個參數設置為更大的值，比如目標表的region數量或者將這個參數設置成0，0表示不斷重試直到成功。設置之後問題解決。
③ HBase什麼時候作minor major compact
HBaseAdmin提供compact方法來手動合並小文件 public void compact(final byte [] tableNameOrRegionName) public void majorCompact(final byte [] tableNameOrRegionName) majorCompact會對所有的文件進行Compact，而compact會選取合適的進行co。
④ HBase支持的數據格式有哪些
HBase 通過 Put 操作和 Result 操作支持 「byte-in / bytes-out」 介面，所以任何可以轉換為位元組數組的內容都可以作為一個值存儲。輸入可以是字元串、數字、復雜對象、甚至可以是圖像，只要它們可以呈現為位元組。
值的大小有實際的限制（例如，在 HBase 中存儲 10-50MB 的對象可能太多了）。在郵件列表中搜索關於此主題的對話。HBase 中的所有行都符合數據模型，並包含版本控制。在進行設計時考慮到這一點，以及 ColumnFamily 的塊大小。
⑤ hbase的作用
HBase 是典型的 NoSQL 資料庫，通常被描述成稀疏的、分布式的、持久化的，由行鍵、列鍵和時間戳進行索引的多維有序映射資料庫，主要用來存儲非結構化和半結構化的數據。因為 HBase 基於 Hadoop 的 HDFS 完成分布式存儲，以及 MapRece 完成分布式並行計算，所以它的一些特點與 Hadoop 相同，依靠橫向擴展，通過不斷增加性價比高的商業伺服器來增加計算和存儲能力。
HBase 雖然基於 Bigtable 的開源實現，但它們之間還是有很多差別的，Bigtable 經常被描述成鍵值資料庫，而 HBase 則是面向列存儲的分布式資料庫。
下面介紹 HBase 具備的顯著特性，這些特性讓 HBase 成為當前和未來最實用的資料庫之一。
容量巨大
HBase 的單表可以有百億行、百萬列，可以在橫向和縱向兩個維度插入數據，具有很大的彈性。
當關系型資料庫的單個表的記錄在億級時，查詢和寫入的性能都會呈現指數級下降，這種龐大的數據量對傳統資料庫來說是一種災難，而 HBase 在限定某個列的情況下對於單表存儲百億甚至更多的數據都沒有性能問題。
HBase 採用 LSM 樹作為內部數據存儲結構，這種結構會周期性地將較小文件合並成大文件，以減少對磁碟的訪問。
擴展性強
HBase 工作在 HDFS 之上，理所當然地支持分布式表，也繼承了 HDFS 的可擴展性。HBase 的擴展是橫向的，橫向擴展是指在擴展時不需要提升伺服器本身的性能，只需添加伺服器到現有集群即可。
HBase 表根據 Region 大小進行分區，分別存在集群中不同的節點上，當添加新的節點時，集群就重新調整，在新的節點啟動 HBase 伺服器，動態地實現擴展。這里需要指出，HBase 的擴展是熱擴展，即在不停止現有服務的前提下，可以隨時添加或者減少節點。
高可靠性
HBase 運行在 HDFS 上，HDFS 的多副本存儲可以讓它在岀現故障時自動恢復，同時 HBase 內部也提供 WAL 和 Replication 機制。
WAL（Write-Ahead-Log）預寫日誌是在 HBase 伺服器處理數據插入和刪除的過程中用來記錄操作內容的日誌，保證了數據寫入時不會因集群異常而導致寫入數據的丟失；而 Replication 機制是基於日誌操作來做數據同步的。
⑥ HBase是什麼呢，都有哪些特點呢
Hbase是一種NoSQL資料庫，這意味著它不像傳統的RDBMS資料庫那樣支持SQL作為查詢語言。Hbase是一種分布式存儲的資料庫，技術上來講，它更像是分布式存儲而不是分布式資料庫，它缺少很多RDBMS系統的特性，比如列類型，輔助索引，觸發器，和高級查詢語言等待
那Hbase有什麼特性呢？如下：
強讀寫一致，但是不是「最終一致性」的數據存儲，這使得它非常適合高速的計算聚合
自動分片，通過Region分散在集群中，當行數增長的時候，Region也會自動的切分和再分配
自動的故障轉移
Hadoop/HDFS集成，和HDFS開箱即用，不用太麻煩的銜接
豐富的「簡潔，高效」API，Thrift/REST API，Java API
塊緩存，布隆過濾器，可以高效的列查詢優化
操作管理，Hbase提供了內置的web界面來操作，還可以監控JMX指標
首先資料庫量要足夠多，如果有十億及百億行數據，那麼Hbase是一個很好的選項，如果只有幾百萬行甚至不到的數據量，RDBMS是一個很好的選擇。因為數據量小的話，真正能工作的機器量少，剩餘的機器都處於空閑的狀態
其次，如果你不需要輔助索引，靜態類型的列，事務等特性，一個已經用RDBMS的系統想要切換到Hbase，則需要重新設計系統。
最後，保證硬體資源足夠，每個HDFS集群在少於5個節點的時候，都不能表現的很好。因為HDFS默認的復制數量是3，再加上一個NameNode。
存儲業務數據:車輛GPS信息，司機點位信息，用戶操作信息，設備訪問信息。。。
存儲日誌數據:架構監控數據（登錄日誌，中間件訪問日誌，推送日誌，簡訊郵件發送記錄。。。），業務操作日誌信息
存儲業務附件：UDFS系統存儲圖像，視頻，文檔等附件信息
什麼時候用Hbase？
Hbase不適合解決所有的問題：
Hbase在單機環境也能運行，但是請在開發環境的時候使用。
內部應用
不過在公司使用的時候，一般不使用原生的Hbase API，使用原生的API會導致訪問不可監控，影響系統穩定性，以致於版本升級的不可控。
HFile
HFile是Hbase在HDFS中存儲數據的格式，它包含多層的索引，這樣在Hbase檢索數據的時候就不用完全的載入整個文件。索引的大小(keys的大小，數據量的大小)影響block的大小，在大數據集的情況下，block的大小設置為每個RegionServer 1GB也是常見的。
探討資料庫的數據存儲方式，其實就是探討數據如何在磁碟上進行有效的組織。因為我們通常以如何高效讀取和消費數據為目的，而不是數據存儲本身。
Hfile生成方式
起初，HFile中並沒有任何Block，數據還存在於MemStore中。
Flush發生時，創建HFile Writer，第一個空的Data Block出現，初始化後的Data Block中為Header部分預留了空間，Header部分用來存放一個Data Block的元數據信息。
而後，位於MemStore中的KeyValues被一個個append到位於內存中的第一個Data Block中：
註：如果配置了Data Block Encoding，則會在Append KeyValue的時候進行同步編碼，編碼後的數據不再是單純的KeyValue模式。Data Block Encoding是HBase為了降低KeyValue結構性膨脹而提供的內部編碼機制。
⑦ 硬碟是如何存儲和讀取零碎的文件的
如果數據量不是很大（G級別以下），文件不是特別零碎，可以直接存在硬碟上。
但是如果數據量已經/可能超過T級別，或者文件小且零碎，建議還是放在HDFS等分布式文件系統上。
我存儲爬蟲的html以及圖片數據，是通過HDFS的MapFile格式存儲的。MapFile是個已排序的鍵值對文件格式，我的鍵採用的是url的hash+採集時間，值就是文件內容。並且封裝了原生的MapFile.Reader實現了讀取和一定程度的緩存（目前只用了LRU）。
在HDFS提倡一次寫入，多次讀取的前提下，文件的更新只能是通過失效舊，使用新的策略。即把舊的元數據標記為失效，插入新的元數據，並把更新的文件寫入HDFS。讀取是通過新的元數據定位到文件。同時，要定期的清除已失效的文件，即把未失效的元數據讀出來，將對應的文件寫到新的MapFile，刪除舊的MapFile，即可實現物理刪除。
當然還可以使用HBase。HBase是面向列的，二進制存儲的，可橫向拓展的NoSQL。可以把不大於64M的數據作為單元格數據直接寫進去。但是有一定的學習成本，而且對集群的硬體要求比較
⑧ hadoop框架是如何處理大量小文件的
hdfs不適合存小文件，要處理大量小文件，2個辦法。一 ，小文件合並成大文件再存。二，安裝hbase，以數據的形式存小文件。
⑨ hbase是什麼工具
將數據導入HBase中有如下幾種方式：使用HBase的API中的Put方法使用HBase 的bulk load 工具使用定製的MapRece Job方式 使用HBase的API中的Put是最直接的方法，用法也很容易學習。但針對大部分情況，它並非都是最高效的方式。當需要將海量數據在規定時間內載入HBase中時，效率問題體現得尤為明顯。待處理的數據量一般都是巨大的，這也許是為何我們選擇了HBase而不是其他資料庫的原因。在項目開始之前，你就該思考如何將所有能夠很好的將數據轉移進HBase，否則之後可能面臨嚴重的性能問題。 HBase有一個名為 bulk load的功能支持將海量數據高效地裝載入HBase中。Bulk load是通過一個MapRece Job來實現的，通過Job直接生成一個HBase的內部HFile格式文件來形成一個特殊的HBase數據表，然後直接將數據文件載入到運行的集群中。使用bulk load功能最簡單的方式就是使用importtsv 工具。importtsv 是從TSV文件直接載入內容至HBase的一個內置工具。它通過運行一個MapRece Job，將數據從TSV文件中直接寫入HBase的表或者寫入一個HBase的自有格式數據文件。盡管importtsv 工具在需要將文本數據導入HBase的時候十分有用，但是有一些情況，比如導入其他格式的數據，你會希望使用編程來生成數據，而MapRece是處理海量數據最有效的方式。這可能也是HBase中載入海量數據唯一最可行的方法了。當然我們可以使用MapRece向HBase導入數據，但海量的數據集會使得MapRece Job也變得很繁重。若處理不當，則可能使得MapRece的job運行時的吞吐量很小。在HBase中數據合並是一項頻繁執行寫操作任務，除非我們能夠生成HBase的內部數據文件，並且直接載入。這樣盡管HBase的寫入速度一直很快，但是若合並過程沒有合適的配置，也有可能造成寫操作時常被阻塞。寫操作很重的任務可能引起的另一個問題就是將數據寫入了相同的族群伺服器（region server），這種情況常出現在將海量數據導入到一個新建的HBase中。一旦數據集中在相同的伺服器，整個集群就變得不平衡，並且寫速度會顯著的降低。我們將會在本文中致力於解決這些問題。我們將從一個簡單的任務開始，使用API中的Put方法將MySQL中的數據導入HBase。接著我們會描述如何使用 importtsv 和 bulk load將TSV數據文件導入HBase。我們也會有一個MapRece樣例展示如何使用其他數據文件格式來導入數據。上述方式都包括將數據直接寫入HBase中，以及在HDFS中直接寫入HFile類型文件。本文中最後一節解釋在向HBase導入數據之前如何構建好集群。本文代碼均是以Java編寫，我們假設您具有基本Java知識，所以我們將略過如何編譯與打包文中的Java示例代碼，但我們會在示例源碼中進行注釋。
⑩ hbase是如何做到並發寫的和隨機寫的
閱讀數：9381
Hbase概述
hbase是一個構建在HDFS上的分布式列存儲系統。HBase是Apache Hadoop生態系統中的重要 一員，主要用於海量結構化數據存儲。從邏輯上講，HBase將數據按照表、行和列進行存儲。
如圖所示，Hbase構建在HDFS之上，hadoop之下。其內部管理的文件全部存儲在HDFS中。與HDFS相比兩者都具有良好的容錯性和擴展性，都可以 擴展到成百上千個節點。但HDFS適合批處理場景，不支持數據隨機查找，不適合增量數據處理且不支持數據更新。
Hbase是列存儲的非關系資料庫。傳統資料庫MySQL等，數據是按行存儲的。其沒有索引的查詢將消耗大量I/O 並且建立索引和物化視圖需要花費大量時間和資源。因此，為了滿足面向查詢的需求，資料庫必須被大量膨脹才能滿 足性能要求。
Hbase數據是按列存儲-每一列單獨存放。列存儲的優點是數據即是索引。訪問查詢涉及的列-大量降低系統I/O 。並且每一列由一個線索來處理，可以實現查詢的並發處理。基於Hbase數據類型一致性，可以實現資料庫的高效壓縮。
HBase數據模型
HBase是基於Google BigTable模型開發的， 典型的key/value系統。一個Row key對應很多Column Family，Column Family中有很多Column。其中，保存了不同時間戳的數據。
如圖所示，Rowkey cutting對應列簇info和roles。其中，info中有key-value對hight-9ft，state-CA。更清晰的結構如下圖所：
Hbase的所有操作均是基於rowkey的。支持CRUD（Create、Read、Update和Delete）和 Scan操作。 包括單行操作Put 、Get、Scan。多行操作包括Scan和MultiPut。但沒有內置join操作，可使用MapRece解決。
HBase物理模型
Hbase的Table中的所有行都按照row key的字典序排列。Table 在行的方向上分割為多個Region。、Region按大小分割的，每個表開始只有一個region，隨 著數據增多，region不斷增大，當增大到一個閥值的時候， region就會等分會兩個新的region，之後會有越來越多的 region。
Region是HBase中分布式存儲和負載均衡的最小單元。 不同Region分布到不同RegionServer上。
Region雖然是分布式存儲的最小單元，但並不是存儲 的最小單元。Region由一個或者多個Store組成，每個store保存一個 columns family。每個Strore又由一個memStore和0至多個StoreFile組成。memStore存儲在內存中，StoreFile存儲在HDFS上。
HBase基本架構
HBase構建在HDFS之上，其組件包括 Client、zookeeper、HDFS、Hmaster以及HRegionServer。Client包含訪問HBase的介面，並維護cache來加快對HBase的訪問。Zookeeper用來保證任何時候，集群中只有一個master，存貯所有Region的定址入口以及實時監控Region server的上線和下線信息。並實時通知給Master存儲HBase的schema和table元數據。HMaster負責為Region server分配region和Region server的負載均衡。如果發現失效的Region server並重新分配其上的region。同時，管理用戶對table的增刪改查操作。Region Server 負責維護region，處理對這些region的IO請求並且切分在運行過程中變得過大的region。
HBase 依賴ZooKeeper，默認情況下，HBase 管理ZooKeeper 實例。比如， 啟動或者停止ZooKeeper。Master與RegionServers 啟動時會向ZooKeeper注冊。因此，Zookeeper的引入使得 Master不再是單點故障。
Client每次寫資料庫之前，都會首先血Hlog日誌。記錄寫操作。如果不做日誌記錄，一旦發生故障，操作將不可恢復。HMaster一旦故障，Zookeeper將重新選擇一個新的Master 。無Master過程中，數據讀取仍照常進行。但是，無master過程中，region切分、負載均衡等無法進行。RegionServer出現故障的處理原理是定時向Zookeeper匯報心跳，如果一旦時 間內未出現心跳HMaster將該RegionServer上的Region重新分配到其他RegionServer上。失效伺服器上「預寫」日誌由主伺服器進行分割並派送給新的 RegionServer 。Zookeeper是一個可靠地服務，一般配置3或5個Zookeeper實例。
尋找RegionServer定位的順序是ZooKeeper --ROOT-(單Region) -.META. -用戶表 。如上圖所示。-ROOT- 表包含.META.表所在的region列表，該表只會有一 個Region。 Zookeeper中記錄了-ROOT-表的location。 .META. 表包含所有的用戶空間region列表，以及 RegionServer的伺服器地址。
HBase應用舉例
Hbase適合需對數據進行隨機讀操作或者隨機寫操作、大數據上高並發操作，比如每秒對PB級數據進行上千次操作以及讀寫訪問均是非常簡單的操作。
淘寶指數是Hbase在淘寶的一個典型應用。交易歷史紀錄查詢很適合用Hbase作為底層資料庫。