hbase日誌存儲
⑴ hbase里的hlog存在哪regionserver里還是zookeeper里
看一下下圖就知道了吧。
對於用戶的一個表比如Blog，可能包括數據多達億級
該表的數據可以分布在多個HRegion
而每個HRegion保存表的某一段數據
UserTable(1)------HRegion(*)
對於多個的HRegion則有HRegionServer來維護
每個HRegion唯一對應一個HRegionServer
通過HRegionServer才能夠訪問對應的HRegion
而一個HRegion從物理上分為如下幾個部分
HMemCache(內存緩存),HLog(日誌),HStore(持久化存儲)
三：HBase的數據操作流程
a:讀數據
優先從HMemcache中讀取，如果沒有讀到從HStore中讀取
當然這里需要關註：讀、寫同步的問題，HBase如何解決，還有第一個客戶端讀取數據從HStore讀取後，是否會載入到HMemCache中；後續的客戶端，讀取時直接從HMemCache中讀取，以及MemCache中數據的過期化演算法
b:寫數據
HBase寫入數據會寫到HMemcache和Hlog中，HMemcache建立緩存，Hlog同步Hmemcache和Hstore的事務日誌，發起FlushCache時，數據持久化到Hstore中，並清空HMemecache。
此處需要關註：
HBase寫數據，首先寫入Memcache，並計入Log中，最後寫入HStore中，如果在寫入HStore是發生系統異常，就可以從Log中恢復數據，重新寫入HStore中。【該機制跟BigTable中的SSTabl,MemTable和CommitLog的作用一樣】
c:客戶端操作數據流程
客戶端訪問這些數據的時候通過Hmaster，每個Hregion伺服器都會和Hmaster伺服器保持一個長連接，Hmaster是HBase分布式系統中的管理者，他的主要任務就是要告訴每個Hregion伺服器它要維護哪些Hregion。用戶的這些都數據可以保存在Hadoop分布式文件系統上
如果一個HMaster掛了，SecondaryNameNode會自動替代HMaster
但是對應的失效轉發的效率還需要進一步嘗試，可能依賴ZooKeeper的相關配置項
⑵ Hbase安全基線中日誌存儲最少保留多少人
10人
WAL意為write ahead log，HBase中的預寫日誌，用來做災難恢復使用，底層實現是HLog，HLog記錄數據的所有變更。使用WAL的原因：因為MemStore存儲的數據是駐留在內存中的，是不穩定的(比如宕機時)，所以採用了WAL預寫日誌來解決這個問題。(運行MApRece作業時，可以通過關閉WAL功能來獲得性能的提升——setWriteToWAL(boolean))。其實HLog文件就是一個普通的Hadoop Sequence File，Sequence File的key是HLogKey對象，其中記錄了寫入數據的歸屬信息，除了table和region名字外，還同時包括sequence number和timestamp，timestamp是寫入時間，sequence number的起始值為0，或者是最近一次存入文件系統中的sequence number。Sequence File的value是HBase的KeyValue對象，即對應HFile中的KeyValue。
隨著用戶的增多，網站功能勢必增加，業務功能都會使用sql語句進行查詢，而表數據過多會導致join操作變慢，所以會不得不採用一些逆範式的方式來設計資料庫，這樣導致無法使用存儲過程。而且，數據過大時，索引的效果也沒那麼強了。因為索引也會變得很大。
⑶ hbase和hive的差別是什麼，各自適用在什麼場景中
1. Hive中的表是純邏輯表，就只是表的定義等，即表的元數據。Hive本身不存儲數據，它完全依賴HDFS和MapRece。這樣就可以將結構化的數據文件映射為為一張資料庫表，並提供完整的SQL查詢功能，並將SQL語句最終轉換為MapRece任務進行運行。 而HBase表是物理表，適合存放非結構化的數據。
2. Hive是基於MapRece來處理數據,而MapRece處理數據是基於行的模式；HBase處理數據是基於列的而不是基於行的模式，適合海量數據的隨機訪問。
3. HBase的表是疏鬆的存儲的，因此用戶可以給行定義各種不同的列；而Hive表是稠密型，即定義多少列，每一行有存儲固定列數的數據。
4. Hive使用Hadoop來分析處理數據，而Hadoop系統是批處理系統，因此不能保證處理的低遲延問題；而HBase是近實時系統，支持實時查詢。
5. Hive不提供row-level的更新，它適用於大量append-only數據集（如日誌）的批任務處理。而基於HBase的查詢，支持和row-level的更新。
6. Hive提供完整的SQL實現，通常被用來做一些基於歷史數據的挖掘、分析。而HBase不適用與有join，多級索引，表關系復雜的應用場景。
⑷ 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結構性膨脹而提供的內部編碼機制。
⑸ hbase安全提現中日誌存儲最少保留多少天
7天，
日誌默認保留7 天，對於 SSD 作為存儲介質，隨著業務增長，存儲成本過於高昂。
⑹ 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對日誌存儲要求最少保留兩個人，只保留一個人時不能夠完成日常存儲，力量過於單薄，安全基線要求高追求品質第一。
⑻ hbase寫日誌為什麼比寫hfile快
在HBase的根目錄下面，有兩個跟日誌相關的目錄，.logs和.oldlogs。.logs保存的是所有Regionserver上當前在寫入的HLog，可以看到每個RegionServer對應一個文件，所以HLog是對應RegionServer的。
HLog默認情況下每個小時會滾動，這是通過參數hbase.regionserver.logroll.period控制的，這個參數的默認值是1小時。
此外，hbase.regionserver.hlog.blocksize和fs_local.block.size控制當HLog的大小超過32M的時候，會滾動。
Hbase.regionserver.logroll.multiplier，默認值是95%，表示日誌達到95%的時候，也會進行滾動。
日誌文件的滾動操作，就是檢查HFile中的序列號，確認日誌中所有的序列號都小於HFile的序列號，確保所有的日誌內容都已經固化到HFile中，確認後將當前的日誌挪到.oldlog目錄下。
這里有個問題還有些疑惑，書里寫的是檢查寫入存儲文件中最大的序列號是多少，小於這個序列號的所有修改都已經固化了，只要確保日誌中的最大序列號比這個序列號小，就可以確認這個日誌已經固化，可以挪到.oldlog下。
但是memstore刷新到HFile是對HStore的，對表的，可能有的表更新比較多，刷新的快，已經固化到HFile，但有的表修改少，還沒有刷新到HFile，這和序列號的順序應該是沒有必然的關系的，後續應該可以做個測試來驗證一下。
當前日誌的文件，在寫滿一個塊之前，都顯示的是0位元組，但實際上可能已經有數據，只是顯示的問題而已。
現在插入幾條記錄，做些修改的操作，查看日誌的內容：
hbase(main):001:0> put't_lisa','lisa5','cf_1:w1','10d2'
0 row(s) in 0.4590 seconds
hbase(main):002:0> put't_lisa','lisa6','cf_1:w1','1032'
0 row(s) in 0.0050 seconds
hbase(main):003:0> put't_lisa','lisa7','cf_1:w1','10z2'
0 row(s) in 0.0040 seconds
hbase(main):004:0> put't_lisa','lisa8','cf_1:w1','10e2'
0 row(s) in 0.0040 seconds
hbase(main):002:0> delete 't_lisa','lisa5','cf_1'
0 row(s) in 0.4270 seconds
查看日誌文件，雖然大小為0，但是實際上寫操作是先寫了WAL，才寫memstore的，這里只是文件大小顯示的問題。
每個regionserver最初都會有一個HLog，不管是不是有更新操作。
[root@a01 hbase]# hadoop fs -ls /hbase_root/.logs
查看日誌文件的內容，-p表示查看對應的value：
[root@a01 hbase]# bin/hbase hlog /hbase_root/.logs/*,60020,1385442023669/*%2C60020%2C1385442023669.1385449225598 -p
Sequence 2316016 from region in table t_lisa
Action:
row: lisa5
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10d2
Sequence 2316017 from region in table t_lisa
Action:
row: lisa6
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 1032
Sequence 2316018 from region in table t_lisa
Action:
row: lisa7
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10z2
Sequence 2316019 from region in table t_lisa
Action:
row: lisa8
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10e2
Sequence 2316020 from region in table t_lisa
Action:
row: lisa5
column: cf_1:
at time: Tue Nov 26 15:31:49 CST 2013
value:
截取其中的一小段進行分析：
Sequence 2316016 from region in table t_lisa
Action:
row: lisa5
column: cf_1:w1
at time: Tue Nov 26 15:17:04 CST 2013
value: 10d2
Sequence 2316016 ：序列號，在恢復的時候，會判斷這個id和HFile中序列ID的大小，小於HFile序列ID（MAX_SEQ_ID_KEY）的操作不用再重做，因為已經固化到數據文件中了。
region ：region name中按照前面部分的MD5散列值
table t_lisa： 表名
row: lisa5：行鍵
column: cf_1:w1：列族和列標識符
value: 10d2：值
Delete 和 insert操作的日誌並沒有明顯寫明action
查看HFile的信息，這里可以看到HFile中的kv數據、壓縮、起始rowkey等非常詳細的信息：
[root@a01 ~]# cd /home/hbase
[root@a01 hbase]# bin/hbase org.apache.hadoop.hbase.io.hfile.HFile -f /hbase_root/t_lisa1//cf_1/ -v -m -p
K: lisa1/cf_1:a/1384389531130/Put/vlen=1/ts=0 V: 1
K: lisa1/cf_1:b/1384390435899/Put/vlen=1/ts=0 V: 6
K: lisa1/cf_1:b/1384389531157/Put/vlen=1/ts=0 V: 5
K: lisa1/cf_1:b1/1384390714903/Put/vlen=2/ts=0 V: 61
firstKey=lisa1/cf_1:a/1384389531130/Put,
lastKey=lisa1/cf_1:b1/1384390714903/Put,
MAX_SEQ_ID_KEY = 2309244