【HBase學習之一】HBase簡介
目錄
一、簡介
HBase - Hadoop Database,是一個高可靠性、高效能、面向列、可伸縮的分散式儲存系統,利用HBase技術可在廉價PC Server上搭建起大規模結構化儲存叢集。
HBase是Google BigTable的開源實現,類似Google BigTable利用GFS作為其檔案儲存系統,HBase利用Hadoop HDFS作為其檔案儲存系統;Google執行MapReduce來處理Bigtable中的海量資料,HBase同樣利用Hadoop MapReduce來處理HBase中的海量資料;Google Bigtable利用Chubby作為協同服務,HBase利用Zookeeper作為對應。
優勢:
>寫入效能高,且幾乎可以無限擴充套件。
>海量資料下(100TB級別表)的查詢依然能保持在5ms級別。
>儲存容量大,不需要做分庫分表,切勿維護簡單。
>表的列可以靈活配置,1行可以有多個非固定的列。
劣勢:
>並不能保證100%時間可用,宕機回覆時間根據寫入流量不同在幾秒到幾十秒內。
>查詢便利性上缺少支援sql語句。
>無索引,查詢必須按照RowKey嚴格查詢,不帶RowKey的filter效能較低。
>對於查詢會有一些毛刺,特別是在compact時,平均查詢延遲在2~3ms,但是毛刺時會升高到幾十到100多毫秒。
二、HBase使用場景
2.1 歷史資料儲存類應用(約佔七成)
這類應用範圍比較廣,特別對於歷史訂單、歷史記錄、日誌類的業務比較友好。由於以上這些業務的資料量巨大,傳統的書庫很難hold住,而這類應用往往查詢量相對較少,查詢隨機性較大(無熱點訪問),對於mysql,redis來說儲存成本太高,hbase用在這裡非常合適。
2.2 分析型應用(約佔兩成)
主要是指配合spark,MapReduce,storm等來做資料分析。由於以上這些計算元件對於中間狀態的儲存具有侷限性,當然spark內也有全域性變數的概念,但是畢竟不是儲存,不可能快取一年的中間結果做cache。二有些應用又需要用到可能很長一段時間的資料做訓練或者比對,這個時候hbase的優勢就可以發揮出來了。
2.3 線上讀寫型應用(約佔一成)
可以理解為對mysql或者redis的一種替換做法,但是這類應用比較在意可用性、穩定性以及sql、索引等支援。hbase的劣勢較大,應用範圍較窄。只有在一種情況下會是用--mysql或者redis的容量實在無法支撐資料量了,而應用對可用性的要求可以有一定成都的容忍。
三、HBase資料模型
Column Family | |||
---|---|---|---|
RowKey | Timestamp | Column1 | Column2 |
r1 | t3 | c1 | |
t2 | c2 | ||
t1 | c3 | ||
r2 | t5 | c4 | c5 |
t4 | c6 |
RowKey:
行鍵,Table的主鍵,用來檢測記錄。RowKey決定一行資料,rowKey可以是任意字串(最大長度是64KB,實際應用中長度一般為10-100bytes左右), 在HBase內部,rowKey儲存為位元組資料。資料按照RowKey的字典序(byte order)排序儲存,因此設計key時要充分排序儲存這個特徵,將經常一起讀取的行儲存放到一起。
HBase支援單行事務,行的一次讀寫是原子操作(不論一次讀寫多少列),這個設計決策能夠使用使用者很容易的理解程式在對同一個行進行併發更新操作時的行為。
Column Family列族 & qualifier列:
>Hbase表中的每個列都屬於某個列族,列族必須作為表模式定義的一部分預先給出。如:create 'table', 'family'。
>列名以列族作為字首,每個"列簇"都可以是多個列成員,如course:math, course:english。
>許可權控制、儲存、調優都是在列簇層面進行。
>Hbase把同一列簇裡面的資料儲存在同一個目錄下,由幾個檔案儲存。
>Hbase currently does not do well with anything above two or three column families so keep the number of column families in your schema low。
Cell:
>由 {row key, column family, column qualifier, version} 唯一確定的單元。cell中的資料是沒有型別的,全部是位元組碼形式存貯。
四、HBase體系結構
Client:
HBase Client使用HBase的RPC機制與HMaster和HRegionServer進行通訊,對於管理類操作,Client與HMaster進行RPC;對於資料讀寫類操作,Client與HRegionServer進行RPC。Client會通過zk定位到.META.表,根據.MATA.查詢需要服務的RegionServer,連線RegionServer進行讀寫;Client會快取.META.表資訊,下次可以直接連到RegionServer中。
Zookeeper:
保證任何時候,叢集中只有一個master;儲存所有Region的定址入口;實時監控Region Server的上線和下線資訊,並實時通知Master;儲存HBase的schema和table元資料。
HMaster:
HMaster沒有單點問題,HBase中可以啟動多個HMaster,通過ZK的Master Election機制保證有且僅有一個Master執行,HMaster在功能上主要負責Table和Region的管理工作:
>管理使用者對Table的CRUD操作。
>管理HRegionServer的負載均衡,調整Region分佈
>在Region Split後,負責新Region的分配
>在HRegionServer停機後,負責失效HRegionServer上的Regions遷移
>HDFS的垃圾檔案回收
Client訪問HBase上資料的過程並不需要HMaster參與(定址訪問ZK,資料讀寫訪問HRegionServer),HMaster僅僅維護table和region的元資料資訊,負載很低。
HRegionServer:
HRegionServer主要負責響應使用者I/O請求,向HDFS檔案系統中讀寫資料,是HBase中最核心的模組。HRegionServer內部管理了一系列HRegion物件,每個HRegion對應了Table中的一個Region,HRegion中由多個HStore組成。每個HStore對應了Table中的一個Column Family的儲存,可以看出每個Column Family其實就是一個集中的儲存單元,因此最好將具備共同IO特性的column放在一個Column Family中,這樣最高效。
HRegion:
HBase自動把表水平劃分成多個區域(Region),每個region會儲存一個表裡面某段連續的資料;每個表一開始只有一個region,隨著資料不斷插入表,region不斷增大,當增大到一定閾值的時候,region就會等分為兩個新的region(裂變);當table中的行不斷增多,就會有越來越多的region。這樣一張完整的表被儲存在多個RegionServer上。
HStore: HStore是HBase儲存的核心,其中由兩部分組成:memstore 和 storefiles。
一個region由多個store組成,一個store對應一個CF(列族);store包括位於記憶體中的memcache和位於磁碟的storefile,寫操作先寫入memstore,當memstore中的資料達到某個閾值,hregionserver會啟動flashcache程序寫入storefile,每次寫入形成單獨的storefile;當storefile檔案的數量增長到一定閾值後,系統會進行合併(minor,major compaction),在合併過程中會進行版本合併和刪除工作(majar),形成更大的storefile;當一個region中所有的storefile的大小和數量超過一定閾值後,會把當前的region分割成為兩個,並由hmaster分配到相應regionserver伺服器,實現負載均衡;客戶端檢索資料,先在memstore裡面找,找不到在storefile裡面找。
HLog:
在分散式系統環境中,無法避免系統出錯或者宕機,因此一旦HRegionServer意外退出,MemStore中的記憶體資料將會丟失,這就需要引入HLog了。每個HRegionServer中都有一個HLog物件,HLog是一個實現Write Ahead Log的類,在每次使用者操作寫入MemStore的同時,也會寫一份資料到HLog檔案中(HLog檔案格式見後續),HLog檔案定期會滾動出新的,並刪除舊的檔案(已持久化到StoreFile中的資料)。當HRegionServer意外終止後,HMaster會通過Zookeeper感知到,HMaster首先會處理遺留的 HLog檔案,將其中不同Region的Log資料進行拆分,分別放到相應region的目錄下,然後再將失效的region重新分配,領取 到這些region的HRegionServer在Load Region的過程中,會發現有歷史HLog需要處理,因此會Replay HLog中的資料到MemStore中,然後flush到StoreFiles,完成資料恢復。
Author:憶之獨秀
Email:[email protected]
註明出處:https://blog.csdn.net/lavorange/article/details/82775275