dfs.datanode.synconclose set to false in hdfs-site.xml: data loss is possible on hard system reset or power loss

設置為true，在數據寫入完成之後，datanode會要求作業系統將數據直接同步到磁碟

避免讀寫declared dead的datanode，datanode會發送心跳給namenode,如果超過了dfs.namenode.stale.datanode.interval的時間還未接收到datanode的心跳，則認為該datanode為stale狀態，也就會將datanode declare成dead。默認情況下，namenode仍然會對stale狀態的datanode讀

keep DN running with some failed disks,tolerate losing this many disks，根據磁碟實際配置數量調整

啟用短路徑讀取(short-circuit)：  當client請求數據時，datanode會讀取數據然後通過TCP協議發送給client，short-circuit繞過了datanode直接讀取數據。  short-circuit的前提是client和數據在同一個節點上，所以集群hbase regionserver和hdfs datanode的數量上一般都是1:1，並且datanode和regionserver共處一個節點。  除此之後，指標Locality（數據本地性）需要額外關注，因為更高的數據本地性，可以使短路徑發揮更好的性能

Specifies the maximum number of threads to use for transferring data in and out of the DN.  An HDFS DataNode has an upper bound on the number of files that it will serve at any one time
詳見：https://hbase.apache.org/book.html#dfs.datanode.max.transfer.threads
http://www.larsgeorge.com/2012/03/hadoop-hbase-and-xceivers.html

The number of Namenode RPC server threads that listen to requests from clients. If dfs.namenode.servicerpc-address is not configured then Namenode RPC server threads listen to requests from all nodes.

The number of server threads for the datanode.

如果storefile的數量超過了10個，就會阻塞flush，compact執行緒進行合併（如果觀察日誌，你會看到類似"Too many HFiles, delaying flush"之類的輸出），如果想讓數據寫入更加平滑或者業務寫入量巨大，可以考慮增大該值。
另外，在達到了blockingStoreFiles閥值的時候，開始阻塞flush，那麼memstore就會膨脹，當memstore膨脹到 flush size 乘於 multiplier（flush size X multiplier）的時候，這個列簇的
寫操作就會被阻塞，一直到flush完成（可以關注日誌，會有相關日誌輸出）。
所以如果寫入量巨大，建議同時增加multiplier大小，至於flush size的大小，一般默認即可

每個regionserver啟動的RPC Listener實例個數，hbase.master.handler.count參數意思跟它基本一樣。handler個數並非越多越好，如果設置了過多的handler可能得到一個適得其反的結果
。如果是read-only的場景，handler的個數接近與cpu個數比較好。在調整該參數時候，建議設置為cpu個數的倍數，從兩倍cpu個數開始調整。

控制region split的閥值，需要注意：如果有多個列簇，不管哪個列簇達到了該值，就會觸發split，並且是region級別的，哪怕其他的列簇的hfile值還很小
目前來說，推薦的最大region size為10-20G，當然也可以設置的更大，比如50G（如果設置了壓縮，該值指的是壓縮之後的大小）

split演算法有多種，不一一介紹了。默認是SteppingSplitPolicy演算法，可以根據實際場景情況選擇更為合適的，比如對於已知數據大小的歷史數據，可以將表的split演算法設置為org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy，以實現更好的控制region數目

regionserver與zookeeper建立session，zookeeper通過session來確認regionserver的狀態，每個regionserver在zookeeper中都有自己的臨時znode。如果建立的session斷開了或者超時了（比如gc或者網路問題），那麼zk中的這個regionserver的臨時znode將被刪除，並且該regionserver標記為crashed。    1.在設置該參數值需要注意，要關注zookeeper server的Minimum session timeout和Maximum session timeout，zookeeper默認Minimum session timeout 為 2 X tick time，Maximum session timeout 為 20 x tick time，tick time為心跳間隔（默認2秒）。  也就是說你在hbase側設置的最大會話超時時間在是以client的身份設置的，所以最終還是以zookeeper server為主。（在cdh集群中，如果hbase的該參數值大於zk server的最大會話超時時間，會提示你修改）,比如你在hbase側設置最大超時時間為90s,但是zk的最大超時時間是40s，那麼最終還是如果超過40s便視為超時。    2.如果想增加hbase超時時間限制，可以提高tick time的值，但是建議不要超過5秒，超過5秒不利於zookeeper集群的正常運行    3.對於那種failing quickly is better than waiting的應用，可以將超時時間限定小一些（建議值20秒-30秒），但是在此之前，你需要對GC的時間有一個良好的控制。否則會因為GC導致regionserver頻繁被標記為crashed