接觸hbase已經兩年之久，但是真正的在實際專案中使用卻只有半年的時間，使用過程中，一方面在在為hbase強大的效能興奮之餘，另一方面卻也給我和我的團隊造成了很多的麻煩，起初在使用我的水平也就停留在會用而已，根本談不上優化，但是後來發現，如果想要把它用好，讓它在你的業務中不出問題，那麼就需要你針對自己的業務去進行優化，下面是我認為在使用中應當注意的幾點問題：
如果你希望hadoop集群上做hdfs 客戶端配置 ，例如你的hdfs客戶端的配置和服務端的不一樣。按照如下的方法配置，hbase就能看到你的配置資訊:
例如hdfs的配置dfs.replication你希望複製5份，而不是預設的3份。如果你不照上面的做的話，hbase只會複製3份。
以下引數來自apache的hbase版本，如果你使用的其他廠商的hbase，有可能預設值不一樣。
當 mapreduce job的hbase table 使用tableinputformat為資料來源格式的時候,他的splitter會給這個table的每個region乙個map。因此，如果乙個table有100個region，就有100個map-tasks，不論需要scan多少個column families 。
通常建議關掉針對hbase的mapreduce job的**執行(speculative execution)功能。這個功能也可以用每個job的配置來完成。對於整個集群，使用**執行意味著雙倍的運算量。這可不是你所希望的，因此我們需要進行如下配置：
mapreduce任務的**執行預設是開啟的，hbase集群一般建議在系統級關閉**執行，除非在某種特殊情況下需要開啟，此時可以每任務配置。設定mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution 為 false，可以在job執行的時候設定，也可以直接配置的集群中。
flush和compaction操作是針對乙個region。
compaction操作現在是根據乙個column family下的全部檔案的數量觸發的，而不是根據檔案大小觸發的。當很多的column families在flush和compaction時,會造成很多沒用的i/o負載(要想解決這個問題，需要將flush和compaction操作只針對乙個column family)
行的版本的數量是hcolumndescriptor設定的，每個column family可以單獨設定，預設是3。
1、長時間gc停頓
hbase中常見的兩種stop-the-world的gc操作：
要想定位第一種，只要將cms執行的時間提前就可以了，加入-xx:cmsinitiatingoccupancyfraction引數，把值調低。可以先從60%和70%開始(這個值調的越低，觸發的gc次數就越多，消耗的cpu時間就越長)。要想定位第二種錯誤，todd加入了乙個實驗性的功能，將你的configuration中的hbase.hregion.memstore.mslab.enabled設定為true。
2、使用壓縮
3、設定合理的版本
4、控制split和compaction
使用namespace需要注意的一些東西
使用c 標準庫的任何識別符號，一般來說有三種選擇，但是using directive有時候會出現問題。首先using namespace std這種用法並不會導致效能上的變化。而是在程式比較大的時候，會出現意外的名稱衝突。例如使用如下的形式 using namespace a using names...
使用SQL SERVER需要注意的一些細節
養成寫注釋的習慣。比如儲存過程，我們不僅在建立儲存過程的時候寫注釋，而且是以後的開發版本中修改了儲存過程，那麼也要寫注釋。儲存過程不要以sp 開頭，因為系統儲存過程都是以sp 開頭的。而且在執行sp 開關的儲存過程時資料庫引擎首先在master資料庫中查詢這個儲存過程，如果找不到，再去其它資料庫查詢...
ARM BL或中斷返回需要注意的一些細節問題
上圖為arm處理器的各個狀態下的暫存器示意圖 1 arm3級流水線 由arm7 tdmi s技術參考手冊p2可知，arm的流水線結構為 取指 解碼 執行 arm pc pc 4 pc 8 0x1008 0x1004 0x1000 在此頁，還註明，pc是指向被取指的指令，而不是正在執行的指令。也就是說...