hbase存儲數據結構
A. 做一個網站，把數據保存在xml文件中，跟把數據保存在資料庫中，區別有多大
實話實說，個人接觸到使用Xml文件方式來保存數據的場景少之又少。除去求學期間根據課堂要求做靜態網站時用於存儲一些展示性數據，還有就是在WPF開發中保存一些常用但又不經常變化的離線數據。反而常使用Xml來做配置文件（例如SpringMvc、MyBatis和LogBack）網路數據傳輸和交互標准（例如WebService）、工作流設計（例如Activiti6）等情況較為常見。
Xml用於單設備數據存儲的情況還說得過去，例如離線數據同步可以放在Xml數據文件中。在傳統行業電商平台的規格，材質，產區等屬性相對固定，Xml文件能很好勝任。再比如做一個內部使用的抽獎程序，將潛在用戶群體以Xml方式保存也是不錯的選擇吧。所以Xml文件充當小型離線資料庫還行。
而資料庫的范圍就比較寬泛，大致可以分為關系型資料庫和非關系型資料庫兩大類。
關系型資料庫以Oracle和Mysql最為流困念渣行，學過編程的朋友應該耳熟能詳，也是職場面試經久不衰的考察重點。
而NoSql算是後起之秀。在業務繁多復雜的當下，一些場景下關系型資料庫應付起來相當吃力，有著更為復雜分類的非關系型資料庫孕育而生。NoSql在搜索引擎（ElasticSearch）、鍵值（redis）、面向文檔（Mongodb）和列存儲（Hbase）等方面都能做高拆到得心應手。這些就讓其有著更強的業務針對性，相比傳統關系型資料庫有著質的提升。下面簡單列舉幾個應用場景。
Redis可用於計數、分布式鎖實現、單點登錄、限流和緩存數據等；
在復雜頁面的數據不便以表數據結構保存時，使用Mongodb整頁存儲方便又簡單；
Elasticsearch就是以空間換時間典型代表，在做搜索引擎和日誌記錄（ELK）等方面有很大優勢；
Hbase不必再像關系型資料庫那樣以行為存儲單元，而是以列為基準，非常便於數據結構拓展。
當下流行徽服務和各種解耦，連關系型資料庫都不再設計外鍵關系，非關系型資料庫大行其道，Xml文件用來汪悄保存數據顯然已經不合時宜，當然也不能否認關系型資料庫的地位和Xml的作用。重要數據或某些行業的特殊性還是要以關系型資料庫為根基，畢竟事務、穩定性、安全性和技術恢復支持等方面需要考慮的重點。
B. HBase是什麼為什麼要使用HBase
HBase在產品中還包含了Jetty，在HBase啟動時採用嵌入式的方式來啟動Jetty，因此可以通過web界面對HBase進行管理和查看當前運行的一些狀態，非常輕巧。為什麼採用HBase？HBase 不同於一般的關系資料庫,它是一個適合於非結構化數據存儲的資料庫.所謂非結構化數據存儲就是說HBase是基於列的而不是基於行的模式，這樣方面讀寫你的大數據內容。 HBase是介於Map Entry(key & value)和DB Row之間的一種數據存儲方式。就點有點類似於現在流行的Memcache，但不僅僅是簡單的一個key對應一個 value，你很可能需要存儲多個屬性的數據結構，但沒有傳統資料庫表中那麼多的關聯關系，這就是所謂的鬆散數據。 簡單來說，你在HBase中的表創建的可以看做是一張很大的表，而這個表的屬性可以根據需求去動態增加，在HBase中沒有表與表之間關聯查詢。你只需要 告訴你的數據存儲到Hbase的那個column families 就可以了，不需要指定它的具體類型：char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事務此類的功 能。 Apache HBase 和Google Bigtable 有非常相似的地方，一個數據行擁有一個可選擇的鍵和任意數量的列。表是疏鬆的存儲的，因此用戶可以給行定義各種不同的列，對於這樣的功能在大項目中非常實用，可以簡化設計和升級的成本。
C. hbase的核心數據結構是什麼
hbase的核心數據結構為LSM樹。
LSM樹分為內存部分和磁碟部分。
內存部分是一個維護有序數據集合的數據結構。一般來講，內存數據結構可以選擇平衡二叉樹、紅黑樹、跳躍表（SkipList）等維護有序集的數據結構，由於考慮並發性能，HBase選擇了表現更優秀的跳躍表。
磁碟部渣扒分是由一個個獨立的文件組成敗梁困，每一個文件又是由一個個數據塊組成。對於數據存儲在磁碟上的資料庫系統來說，磁碟尋道以及數據讀取都是非常耗時的操作（簡稱IO耗時）。為了避免不必要的IO耗時，可以在磁碟中存儲一些額外的二進制數據，這些數據用來判斷對於給定的key是否有可能存儲在這個數據塊中，這個數據結構稱為布隆過濾器（察念BloomFilter）。
LSM樹介紹：
LSM樹是一種磁碟數據的索引結構。LSM樹的索引對寫入請求更友好。因為無論是何種寫入請求，LSM樹都會將寫入操作處理為一次順序寫，而HDFS擅長的正是順序寫（且HDFS不支持隨機寫）。
一個LSM樹的索引內存部分是一個ConcurrentSkipListMap，Key是rowkey、column family、qualifier、type以及timestamp， Value是位元組數組。隨著數據不斷寫入MemStore，一旦內存超過閾值會將數據flush到磁碟，生產HFile；多個小HFile文件會compact成一個大HFile。
D. 為什麼hbase當中不要索引
實際上，HBase中也有索引機制，比如可以通過建立二級索引來提高數據的查詢效率。但是，HBase中的索引機制與傳統的關系型資料庫的索引機制有所不同。
傳統的關系型資料庫索引機制通常使用B樹等數據結構來實現，姿數這種索引機制的優點是查詢效率較高，缺點是索引數據量大時，維護索引的開銷也會隨之增加。而HBase中的數據存儲是友察基於列族（column family）和行鍵（row key）的，HBase的數據存儲結構是按行鍵排序的有序映射表，可以通過行鍵的前綴匹配來檢索數據。因此，在HBase中，使用行鍵來查詢數據的效率很高，而使用列來查詢數據的效率相對較低。因此，為了提高查詢效率，通常需要在設計HBase數據模型時，合理設置行鍵和列族，而跡告首不是使用傳統關系型資料庫中常用的各種索引。
另外，如果在HBase中使用過多的索引，會增加存儲和維護的成本，可能會對HBase的性能和可伸縮性產生負面影響。因此，在使用HBase時，需要根據實際情況合理使用索引，權衡索引的優劣和使用成本。
E. 怎麼形象的理解Hbase數據結構
聯系：視圖（view）是在基本表之上建立的表，它的結構（即所定義的列）和內容（即所有數據行）都來自基本表，它依據基本表存在而存在。一個視圖可以對應一個基本表，也可以對應多個基本表。視圖是基本表的抽象和在邏輯意義上建立的新關系區別：1、視圖是已經編譯好的扮旦sql語句。而表不是2、視圖沒有實際的物理記錄。而表有。3、表是內容，視圖是窗口4、表只用物理空間而視圖不佔用物理空間雹基，視圖只是邏輯概念的存在，表可以及時四對它進行修改，但視圖只能有創建的語句來修改5、表是內模式，視圖是外模式6、視圖是查看數據表的一種方法，可以查詢數據表中某些欄位構成的數據，只是一些SQL語句的集合。從安全的角廳肆擾度說，視圖可以不給用戶接觸數據表，從而不知道表結構。7、表屬於全局模式中的表，是實表；視圖屬於局部模式的表，是虛表。8、視圖的建立和刪除隻影響視圖本身，不影響對應的基本表。
F. hbase不適合哪些應用場景
數據量較小、數據結構復雜、需要高度事務性、需要高度事務性等場景。
1、如果數據謹旁賀量較小，使用HBase可能會增加系統的復雜性和成本，不如使用傳統的關系型資料庫或其他輕量級的NoSQL資料庫。
2、祥派HBase適合存儲結構化數據，但是如果數據結構非常復雜，例如包含大量的嵌套數據結構或非常深的層次結構，使用HBase可能會增加數據處理啟態的復雜性和難度。
3、HBase雖然支持ACID事務，但是相比傳統的關系型資料庫，HBase的事務性能和可靠性可能會有所降低。
4、HBase雖然支持基本的查詢操作，但是相比傳統的關系型資料庫，HBase的查詢靈活性可能會有所降低。
G. HBase數據結構是什麼
RowKey
與nosql資料庫們一樣,RowKey是用來檢索記錄的主鍵。訪問HBASE table中的行，只有三種方式：
通過單個RowKey訪問(get)
通過RowKey的range（正則）(like)
全表掃描(scan)
RowKey行鍵 (RowKey)可以是任意字元串(最大長度是64KB，實際應用中長度一般為 10-100bytes)，在HBASE內部，RowKey保存為位元組數組。存儲時，數據按照RowKey的字典序(byte order)排序存儲。設計RowKey時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。(位置相關性)Table：表，所有的表都是命名空間的成員，即表必屬於某個命名空間，如果沒有指定，則在default默認的命名空間中。
RegionServer group：一個命名空間包含了默認的RegionServer Group。
Permission：許可權，命名空間能夠讓我們來定義訪問控制列表ACL（Access Control List）。例如，創建表，讀取表，刪除，更新等等操作。
Quota：限額，可以強制一個命名空間可包含的region的數量。
Column Family
列族：HBASE表中的每個列，都歸屬於某個列族。列族是表的schema的一部 分(而列不是)，必須在使用表之前定義。列名都以列族作為前綴。例如 courses:history，courses:math都屬於courses 這個列族。
Cell
由{rowkey, column Family:columu, version} 唯一確定的單元。cell中的數據是沒有類型的，全部是位元組碼形式存貯。
關鍵字：無類型、位元組碼
Time Stamp
HBASE 中通過rowkey和columns確定的為一個存貯單元稱為cell。每個 cell都保存 著同一份數據的多個版本。版本通過時間戳來索引。時間戳的類型是 64位整型。時間戳可以由HBASE(在數據寫入時自動 )賦值，此時時間戳是精確到毫秒 的當前系統時間。時間戳也可以由客戶顯式賦值。如果應用程序要避免數據版 本沖突，就必須自己生成具有唯一性的時間戳。每個 cell中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。
為了避免數據存在過多版本造成的的管理 (包括存貯和索引)負擔，HBASE提供 了兩種數據版本回收方式。一是保存數據的最後n個版本，二是保存最近一段 時間內的版本（比如最近七天）。用戶可以針對每個列族進行設置。
命名空間
命名空間的結構:
H. hbase的核心數據結構
hbase的核心數據結構如下：
Hadoop是大數據開發的重要框架，其核心是HDFS和MapRece，HDFS為海量的數據提供了存陪備段儲，MapRece為海量的數據提供了計算，因此，需要重點掌握，除此之外，還需要掌握Hadoop集群、Hadoop集群管理、YARN以及Hadoop高級管理等相關技術與操作!
其他數據結構：
1、Java編程技術
Java編程技術是大數據學習的基礎，Java是一種強類型語言，擁有極高的跨平台滾租能力，可以編寫桌面應用程序、Web應用程序、分布式系統和嵌入式系統應用程序等，是大數據工程師最喜歡的編程工具，因此，想學好大數據，掌握Java基礎是必不可少的!
2、Linux命令
對於大數據開發通常是在Linux環境下進行的，相比Linux操作系統，Windows操作系統是封閉的操作系統，開源的大數據軟體很受限制，因此，想從事大數據開發相關工作，還需掌握Linux基礎操作命令蘆譽。
I. HBase數據結構運行原理是什麼
HBase是一個高可靠、高性能、面枝余向列、可伸縮的分布式猛瞎滾資料庫，主要用來儲神大存非結構化和半結構化的鬆散數據。
J. 深入理解HBASE（3.4）RegionServer-Memstore
Region內每個ColumnFamily的數據組成一個Store。每個Store內包括一個MemStore和若干個StoreFile(HFile)組成。
HBase為了方便按照RowKey進行檢索，要求HFile中數據都按照RowKey進行排序，Memstore數據在flush為HFile之前會進行一次排序
為了減少flush過程對讀寫的影響，HBase採用了類似於兩階段提交的方式，將整個flush過程分為三個階段：
要避免「寫阻塞」，貌似讓Flush操作盡量的早於達到觸發「寫操作」的閾值為宜。但是，這將導致頻繁的Flush操作，而由此帶來的後果便是讀性能下降以及額外的負載。
每次的Memstore Flush都會為每個CF創建一個HFile。頻繁的Flush就會創建大量的HFile。這樣HBase在檢索的時候，就不得不讀取大量的HFile，讀性能會受很大影響。
為預防打開過多HFile及避免讀性能惡化，HBase有專門的HFile合並處理(HFile Compaction Process)。HBase會周期性的合並數個小HFile為一個大的HFile。明顯的，有Memstore Flush產生的HFile越多，集群系統就要做更多的合並操作(額外負載)。更糟糕的是：Compaction處理是跟集群臘搏上的其他請求並行進行的。當HBase不能夠跟上Compaction的時候(同樣有閾值設置項)，會在RS上出現「寫阻塞」。像上面說到的，這是最最不希望的。
提示 ：嚴重關切RS上Compaction Queue 的size。要在其引起問題前，阻止其持續增大。
想了解更多HFile 創建和合並，可參看 Visualizing HBase Flushes And Compactions 。
理想情況下，在不超過hbase.regionserver.global.memstore.upperLimit的情況下，Memstore應該盡可能多的使用內存(配置給Memstore部分的，而不是真個Heap的)。下圖展示了一張「較好」的情況：
hbase使用的是jdk提供的ConcurrentSkipListMap，並對其進行了的封裝，Map結構是<KeyValue,KeyValue>的形式。Concurrent表示線程安全。
SkipList是一種高效的數據結構，之前專門寫過文章，這里就不表了
寫入MemStore中的KV，被記錄在kvset中。根據JVM內存的垃圾回收策略，在如下條件會觸發Full GC。 1、內存滿或者觸發閾值。 2、內存碎片過多，造成新的分配找不到合適的內存敬好空間。 RS上服務多個Region，如果不對KV的分配空間進行控制的話，由於訪問的無序性以及KV長度的不同，每個Region上的KV會無規律地分散在內存上。Region執行了MemStore的Flush操作，再經過JVM GC之後就會出現零散的內存碎片現象，而進一步數據大量寫入，就會觸發Full-GC。
為了解決因為內存碎片造成的Full-GC的現象，RegionServer引入了MSLAB（HBASE-3455）。MSLAB全稱是MemStore-Local Allocation Buffers。它通過預先分配連續的內輪稿祥存塊，把零散的內存申請合並，有效改善了過多內存碎片導致的Full GC問題。 MSLAB的工作原理如下： 1、在MemStore初始化時，創建MemStoreLAB對象allocator。 2、創建一個2M大小的Chunk數組，偏移量起始設置為0。Chunk的大小可以通過參數hbase.hregion.memstore.mslab.chunksize調整。 3、 當MemStore有KeyValue加入時，maybeCloneWithAllocator(KeyValue)函數調用allocator為其查找KeyValue.getBuffer()大小的空間，若KeyValue的大小低於默認的256K，會嘗試在當前Chunk下查找空間，如果空間不夠，MemStoreLAB重新申請新的Chunk。選中Chunk之後，會修改offset=原偏移量+KeyValue.getBuffer().length。chunk內控制每個KeyValue大小由hbase.hregion.memstore.mslab.max.allocation配置。 4、 空間檢查通過的KeyValue，會拷貝到Chunk的數據塊中。此時，原KeyValue由於不再被MemStore引用，會在接下來的JVM的Minor GC被清理。
MSLAB解決了因為碎片造成Full GC的問題，然而在MemStore被Flush到文件系統時，沒有reference的chunk，需要GC來進行回收，因此，在更新操作頻繁發生時，會造成較多的Young GC。 針對該問題，HBASE-8163提出了MemStoreChunkPool的解決方案，方案已經被HBase-0.95版本接收。它的實現思路： 1、 創建chunk池來管理沒有被引用的chunk，不再依靠JVM的GC回收。 2、 當一個chunk沒有引用時，會被放入chunk池。 3、chunk池設置閾值，如果超過了，則會放棄放入新的chunk到chunk池。 4、 如果當需要新的chunk時，首先從chunk池中獲取。 根據patch的測試顯示，配置MemStoreChunkPool之後，YGC降低了40%，寫性能有5%的提升。如果是0.95以下版本的用戶，可以參考HBASE-8163給出patch。