hbase開發源碼

1. hbase源代碼 純java開發的嗎

是的，純java開發的nosql

2. 如何搭建Hbase源碼閱讀環境，並能進行編譯運行

hbase源碼導入eclipse分三步：
1.svn下載源碼
2.mvn package -Dmaven.test.skip.exec=true編譯源碼
3.導入eclipse，可以用插件，用mvn eclipse:eclipse生成eclipse文件，導入eclipse。

3. hbase源碼怎麼導入eclipse

hbase源碼導入eclipse分三步：
1.svn下載源碼
2.mvn package -Dmaven.test.skip.exec=true編譯源碼
3.導入eclipse，可以用插件，用mvn eclipse:eclipse生成eclipse文件，導入eclipse。

4. 【HBase】HBase 自動拆分和預分區

[TOC]

HBase 中，表會被劃分為1...n 個 Region，被託管在 RegionServer 中。

Region 二個重要的屬性：StartKey 與 EndKey 表示這個 Region 維護的 RowKey 范圍，當讀/寫數據時，如果 RowKey 落在某個 start-end key 范圍內，那麼就會定位到目標region並且讀/寫到相關的數據。

默認，HBase 在創建表的時候，會自動為表分配一個 Region，正處於混沌時期，start-end key 無邊界，所有 RowKey 都往這個 Region里分配。

當數據越來越多，Region 的 size 越來越大時，達到默認的閾值時（根據不同的拆分策略有不同的閾值），HBase 中該 Region 將會進行 split，會找到一個 MidKey 將 Region 一分為二，成為 2 個 Region。而 MidKey 則為這二個 Region 的臨界，左為 N 無下界，右為 M 無上界。< MidKey 被分配到 N 區，> MidKey 則會被分配到 M 區。

隨著數據量進一步擴大，分裂的兩個 Region 達到臨界後將重復前面的過程，分裂出更多的 Region。

Region 的分割操作是不可見的，Master 不會參與其中。RegionServer 拆分 Region的步驟是：先將該 Region 下線，然後拆分，將其子 Region 加入到 META 元信息中，再將他們加入到原本的 RegionServer 中，最後匯報 Master。

執行 split 的線程是 CompactSplitThread。

在 2.0.5 版本中，HBase 提供了 7 種自動拆分策略：

他們之間的繼承關系如下：

有三種配置方法：

0.94.0 之前的默認拆分策略，這種策略非常簡單，只要 Region 中的任何一個 StoreFile 的大小達到了 hbase.hregion.max.filesize 所定義的大小 ，就進行拆分。

1）相關參數：

hbase.hregion.max.filesize

2）部分源碼 ：

拆分的閾值大小可在創建表的時候設置，如果沒有設置，就取 hbase.hregion.max.filesize 這個配置定義的值，如果這個配置也沒有定義，取默認值 10G。

3）拆分效果：

經過這種策略的拆分後，Region 的大小是均勻的，例如一個 10G 的Region，拆分為兩個 Region 後，這兩個新的 Region 的大小是相差不大的，理想狀態是每個都是5G。

**ConstantSizeRegionSplitPolicy **切分策略對於大表和小表沒有明顯的區分，閾值（hbase.hregion.max.filesize）：

4）創建表時配置：

該策略繼承自 ConstantSizeRegionSplitPolicy，是 0.94.0 到 2.0.0 版本的默認策略，其 優化了原來 ConstantSizeRegionSplitPolicy 只是單一按照 Region 文件大小的拆分策略，增加了對當前表的分片數作為判斷因子 。當Region中某個 Store Size 達到 sizeToCheck 閥值時進行拆分，sizeToCheck 計算如下：

如果表的分片數為 0 或者大於 100，則切分大小還是以設置的單一 Region 文件大小為標准。如果分片數在 1~99 之間，則由 min(單一 Region 大小， Region 增加策略的初始化大小 * 當前 Table Region 數的3次方) 決定 。

Region 增加策略的初始化大小計算如下：

1）相關參數：

hbase.hregion.max.filesize

hbase.increasing.policy.initial.size

hbase.hregion.memstore.flush.size

2）部分源碼：

在默認情況，使用 策略拆分 Region 的過程是:

3）拆分效果：

和 ConstantSizeRegionSplitPolicy 一樣，也是均勻拆分。

不同的是， 切分策略彌補了ConstantSizeRegionSplitPolicy 的短板，能夠自適應大表和小表，並且在大集群條件下對於很多大表來說表現很優秀。

但並不完美，這種策略下很多小表會在大集群中產生大量小 Region，分散在整個集群中。而且在發生 Region 遷移時也可能會觸發 Region 分裂。

4）創建表時配置：

2.0 版本默認切分策略。SteppingSplitPolicy 是 的子類，其對 Region 拆分文件大小做了優化，如果只有1個 Region 的情況下，那第1次的拆分就是 256M，後續則按配置的拆分文件大小（10G）做為拆分標准。

1）相關參數：

同 。

2）全部源碼：

它的源碼只有一個方法，優化了 getSizeToCheck 方法，其他都是繼承 自 類。

3）拆分效果：

在 策略中，針對大表的拆分表現很不錯，但是針對小表會產生過多的 Region，SteppingSplitPolicy 則將小表的 Region 控制在一個合理的范圍，對大表的拆分也不影響。

4）創建表時配置：

KeyPrefixRegionSplitPolicy 是 的子類，該策略除了具備其父類自動調整 Region 拆分閾值大小、適應大小表的特點外，增加了對拆分點(splitPoint，拆分點就是 Region 被拆分處的 RowKey)的定義，可以保證有相同前綴的 RowKey不會被拆分到兩個不同的 Region 裡面。

1）相關參數：

在 的配置之上增加了一個參數。

KeyPrefixRegionSplitPolicy.prefix_length

2）部分源碼：

先從父類獲取拆分點，如果設置了 prefixLength > 0，就從父類拆分點中截取需要的前綴作為新的拆分點返回。

3）拆分效果：

KeyPrefixRegionSplitPolicy （SteppingSplitPolicy、、BusyRegionSplitPolicy (HBase-2.x Only)）按照 RowKey 的前綴去拆分 Region，但是什麼時候拆分，原 Region 容量的最大值是多少還是需要使用 的方法去計算 。

如果所有數據都只有一兩個前綴，那麼採用默認的策略較好。 如果前綴劃分的比較細，查詢就比較容易發生跨 Region 查詢的情況，此時採用KeyPrefixRegionSplitPolicy 較好。

所以這個策略適用的場景是：

4）創建表時配置：

繼承自 ，也是根據 RowKey 前綴來進行拆分的。不同就是：KeyPrefixRegionSplitPolicy 是根據 RowKey 的固定前幾位字元來進行判斷，而 是根據分隔符來判斷的。

1）相關參數：

在 的配置之上增加了一個參數。

.delimiter

2）部分源碼：

先找到分隔符下標位置，然後從父類的拆分點截取出來。

3）拆分效果：

根據 RowKey 中指定分隔字元做為拆分，顯得更加靈活，如 RowKey 的值為「userid_eventtype_eventid」，userId 不是定長的，則 可以取 RowKey 值中從左往右且第一個分隔字元串之前的字元做為拆分串，在該示例中就是「userid」。

4）創建表時配置：

之前的策略都未考慮 Region 熱點問題，考慮某些 Region 可能被頻繁訪問，負荷很大，BusyRegionSplitPolicy 策略同樣繼承自 ，但主要針對 Region 問題，是在 2.x 中新增加的拆分策略。

1）相關參數：

在 的配置之上增加了如下參數：

hbase.busy.policy.blockedRequests

hbase.busy.policy.minAge

hbase.busy.policy.aggWindow

2）部分源碼：

在判斷是否需要進行拆分的時候，先調用父類的 shouldSplit 方法檢驗，如果需要則直接返回 true，否則需要判斷當前時間是否比開始時間大於 minAge 值，如果是的，則計算請求阻塞率 blockedReqRate，如果阻塞率大於設定的閾值，則進行拆分。

阻塞率的計算如下：

主要的計算邏輯是：請求的被阻塞率(aggBlockedRate) = curTime - prevTime 時間內新增的阻塞請求 / 這段時間的總請求。

3）拆分效果：

如果系統常常會出現熱點 Region，又對性能有很高的追求，那麼這種策略可能會比較適合。

它會通過拆分熱點 Region 來緩解熱點 Region 的壓力，但是根據熱點來拆分Region 也會帶來很多不確定性因素，因為不能確定下一個被拆分的 Region 是哪個。

4）創建表時配置：

DisabledRegionSplitPolicy 就是不使用 Region 拆分策略，將所有的數據都寫到同一個 Region 中。

1）全部源碼：

源碼很簡單，就是直接返回 false。

2）拆分效果：

這個策略極少使用。

即使在建表的時候合理的進行了預拆分，還沒有寫入的數據的時候就已經手動分好了 Region，但是隨著數據的持續寫入，我預先分好的 Region 的大小也會達到閾值，那時候還是要依靠 HBase 的自動拆分策略去拆分 Region。

但這種策略也有它的用途：

假如有一批靜態數據，一次存入以後不會再加入新數據，且這批數據主要是用於查詢，為了性能好一些，可以先進行預分區後，各個 Region 數據量相差不多，然後設置拆分策略為禁止拆分，最後導入數據即可。

3）創建表時配置：

已經有自動分區了，為什麼還需要預分區？

HBase 在創建表的時候，會自動為表分配一個Region，當一個 Region 達到拆分條件時（shouldSplit 為 true），HBase 中該 Region 將會進行 split，分裂為2個 Region，以此類推。表在進行 split 的時候，會耗費很多的資源，有大量的 io 操作，頻繁的分區對 HBase 的性能有很大的影響。

所以，HBase 提供了預分區功能，讓用戶可以在創建表的時候對表按照一定的規則分區。

假設初始 10 個 Region，那麼導入大量數據的時候，就會均衡到 10 個 Region 裡面，顯然比初始 1 個 Region 要好很多， 合理的預分區可以減少 Region 熱點問題，提升寫數據的性能和速度，而且也能減少後續的 split 操作 。

首先要明白數據的 RowKey 是如何分布的，然後根據 RowKey 的特點規劃要分成多少 Region，每個 Region 的 startKey 和 endKey 是多少，接著就可以預分區了。

比如，RowKey 的前幾位字元串都是從 0001~0010 的數字，這樣可以分成10個Region：

第一行為第一個 Region 的 stopKey。為什麼後面會跟著一個"|"，是因為在ASCII碼中，"|"的值是124，大於所有的數字和字母等符號。

shell中建分區表

也可以通過指定 SPLITS_FILE 的值指定分區文件，從文件中讀取分區值，文件格式如上述例子所示：

預分區後，可以從 HBase ui 頁面觀察到：

HBase API 建預分區表

為防止熱點問題，同時避免 Region Split 後，部分 Region 不再寫數據或者很少寫數據。也為了得到更好的並行性，希望有好的 load blance，讓每個節點提供的請求處理都是均等的，並且 Region 不要經常 split，因為 split 會使 server 有一段時間的停頓，隨機散列加上預分區是比較好的解決方式。

預分區一開始就預建好了一部分 Region，這些 Region 都維護著自已的 start-end keys，再配合上隨機散列，寫數據能均等地命中這些預建的 Region，就能通過良好的負載，提升並行，大大地提高了性能。

hash + 預分區

在 RowKey 的前面拼接通過 hash 生成的隨機字元串，可以生成范圍比較隨機的 RowKey，可以比較均衡分散到不同的 Region 中，那麼就可以解決寫熱點問題。

假設 RowKey 原本是自增長的 long 型，可以將 RowKey 先進行 hash，加上本身 id ，組成rowkey，這樣就生成比較隨機的 RowKey 。

那麼對於這種方式的 RowKey 設計，如何去進行預分區？

partition + 預分區

partition 顧名思義就是分區式，這種分區有點類似於 maprece 中的 partitioner，將區域用長整數作為分區號，每個 Region 管理著相應的區域數據，在 RowKey 生成時，將 id 取模後，然後拼上 id 整體作為 RowKey 。

1. HBase Region 自動拆分策略
2. hbase預分區

5. HBase宕機恢復-SplitWAL

HBase檢測宕機是通過Zookeeper實現的， 正常情況下RegionServer會周期性向Zookeeper發送心跳，一旦發生宕機，心跳就會停止，超過一定時間（SessionTimeout,我們集群配置的是30s）Zookeeper就會認為RegionServer宕機離線，並將該消息通知給Master。

Master檢測到宕機之後會將宕機RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根據HLog進行丟失數據恢復，恢復完成之後就可以對外提供服務，整個過程都是自動完成的。

HBase切分HLog當前主要有兩種模式Distributed Log Splitting和Distributed Log Replay。
由於我們的集群沒有配置hbase.master.distributed.log.replay=true,所以這里主要研究Distributed Log Splitting流程。

Distributed Log Splitting
整體流程：

Regionserver作為實際工作的執行者，搶占任務以及搶占任務之後的工作流程：

源碼：

整個切分過程中可能出現的問題、解決方法：（持續更新）

1.RS節點假死後，DataNode進程處於存在但不可服務的狀態，會導致hbase split wal超時到幾乎無法進行，10分鍾後DataNode徹底下線才能恢復性能

處理：聯系SA關機、重啟機器，可以加速集群恢復

參考： http://hbasefly.com/2016/10/29/hbase-regionserver-recovering/

6. 大數據有什麼技術，大數據技術內容介紹

大數據是眾多學科與統計學交叉產生的一門新興學科。大數據牽扯的數據挖掘、雲計算一類的，所以是計算機一類的專業。分布比較廣，應用行業較多。

零售業：主要集中在客戶營銷分析上，通過大數據技術可以對客戶的消費信息進行分析。獲知客戶的消費習慣、消費方向等，以便商場做好更合理商品、貨架擺放，規劃市場營銷方案、產品推薦手段等。

金融業：在金融行業里頭，數據即是生命，其信息系統中積累了大量客戶的交易數據。通過大數據可以對客戶的行為進行分析、防堵詐騙、金融風險分析等。

醫療業：通過大數據可以輔助分析疫情信息，對應做出相應的防控措施。對人體健康的趨勢分析在電子病歷、醫學研發和臨床試驗中，可提高診斷准確性和葯物有效性等。

製造業：該行業對大數據的需求主要體現在產品研發與設計、供應鏈管理、生產、售後服務等。通過數據分析，在產品研發過程中免除掉一些不必要的步驟，並且及時改善產品的製造與組裝的流程。

7. hbase 源碼 什麼語言開發的

是用java開發的，hbase包含兩個核心服務，一個是HMaster，一個是HRegionServer，在hbase部署的伺服器上調用jps命令能查看到這兩個進程。

8. hbase單機模式下，使用java API遠程連接hbase的問題。

首先你應該看Master進程是否已經成功啟動，檢查下master的60010監控界面。這日誌報的是連接拒絕 ，或者關閉防火牆

極有可能是你PC機網路無法連接到虛擬機里邊，你可以從本機telnet下虛擬機上master的埠，看下能連上不

9. Hbase源代碼不開放

不開放。Hbase源代碼是進行過加密設置的，沒有進行對外開放，是為了更好的做好保密工作，有非常重要的信息技術類文件，各部門領導員工都非常重視。

10. java可以用來開發什麼軟體呀

1、嵌入式領域
Java在嵌入式領域也有很大的應用。你只需要130KB就能夠使用Java技術（在一塊小的晶元或者感測器上），這顯示了這個平台是多麼的可靠。Java最初是為了嵌入式設備而設計的。
事實上，這也是Java最初的一項「立即編寫，隨處運行」主旨的一部分。
2、大數據技術
Hadoop和其他的大數據技術也在不同程度使用著Java，例如Apache的基於Java的Hbase，Accumulo（開源），以及ElasticSearch。 但是Java並沒有佔領整個領域，還有其他的大數據技術例如MongoDB就是使用C++編寫的.如果Hadoopor和ElasticSearch逐漸發展，那麼Java就能有潛力在大數據技術領域上得到更大的發展空間。
3、軟體工具
很多有用的軟體和開發工具都是運用Java編寫和開發的，例如Ecilpse，InetelliJIdea和NetbansIDE.。我認為這些都是最經常使用的用Java編寫的桌面應用程序。就如上面所說，Swing曾經在圖形用戶界面的客戶端開發非常流行，它們大多數應用在金融服務領域以及投資銀行。雖然現在JavaFx正在逐漸地流行起來，但仍然無法替代Swing，而且C#已經在大部分金融領域中代替了Swing。
4、網站應用
Java同樣也在電子商務和網站開發上有著廣泛的運用。你可以運用很多RESTfull架構，這些架構是用SpringMVC，Struts2.0和類似的框架開發出來的。 甚至簡單的Servlet，JSP和Struts在各種政府項目也是備受歡迎，許多政府，醫療，保險，教育，國防和其他部門的網站都是建立在Java之上的。
5、在金融服務行業的伺服器應用
Java在金融服務業有著很大應用。很多的全球性投資銀行例如GoldmanSachs（高盛投資公司），Citigroup（花旗集團），Barclays（巴克萊銀行），StandardCharted（英國渣打銀行）和一些其他銀行都用Java編寫前台和後台的電子交易系統，結算、信息確認系統，數據處理項目和以及其他的項目。
Java被運用於編寫服務端應用，但大多數沒有前端，都是從一個服務端（上一級）接受數據，處理數據後發向其他的處理系統（下一級）。 JavaSwing由於能開發出圖形用戶界面的客戶端供交易者使用而備受歡迎，但是現在C#正在快速地取代Swing的市場，這讓Swing倍有壓力。
6、交易系統
第三方交易系統，金融服務行業的一大部分，同樣也是使用Java編寫的。例如像Murex這種受歡迎的交易系統，運用於與許多的銀行前端鏈接，同樣也是用Java編寫的。
7、J2MEApps
雖然IOS和Android的到來幾乎扼殺了J2ME的市場，但是仍然有很多的低端諾基亞和三星手機在使用著J2ME。 曾經有段時間大部分的游戲,手機應用都是利用MIDP和CLDC,或者J2ME部分平台編寫的，以適用於Android系統。J2ME依然在藍光、磁卡、機頂盒等產品中流行著。app之所以如此流行是因為對於所有的諾基亞手機，app仍然適用於J2ME。
8、高頻交易領域
Java平台已經大大提高了性能特點和JITS，並且Java也擁有像C++級別的傳輸性能。因此，Java也流行於編寫高並發系統。 雖然Java的傳輸性能不比C++，但你可以不用考慮Java的安全性，可移植性和可維護性等問題（Java內部已經實現好了），而且Java有著更快的運行速度。安全性等問題會使一個沒有經驗的C++程序員編寫的應用程序變得更加緩慢和不可靠。
9、科學應用
現在Java經常是科學應用的默認選擇，包括了自然語言處理。這最主要的原因是因為Java比起C++或者其他語言有更加的安全，可移植，可維護，而且Java有著更好的高級並發工具。
10、安卓Apps
如果你想知道Java應用在哪裡，你離答案並不遠。打開你的安卓手機或者任何的App，它們完全是用有著谷歌AndroidAPI的Java編程語言編寫的，這個API和JDK非常相似。前幾年安卓剛開始起步而到今日已經很多Java程序員是安卓App的開發者。