首先介紹版本背景，hdfs爲2.7.1，hbase爲1.3.0，其它版本的配置可能存在變化。
HDFS相關配置：
dfs.datanode.synconclose 設爲true，當爲false時，系統重啓或斷電時有可能數據丟失，默認值是false。
當寫操作完成之後，緩存中的block不會立即被寫入磁盤，如果要同步將緩存的block寫入磁盤，用戶需要將“hdfs-site.xml”中的dfs.datanode.synconclose設置爲true。更改此設置後，對性能可能存在影響。
dfs.datanode.sync.behind.writes=FALSE 如果是true，寫之後，DN將指示操作系統把隊列中的數據全部立即寫磁盤。和常用的OS策略不同，它們可能在觸發寫磁盤之前等待30s
dfs.namenode.avoid.write.stale.datanode —— default: true
dfs.namenode.avoid.read.stale.datanode —— default: true
dfs.namenode.stale.datanode.interval —— default: 30 seconds默認是true，超過30s未收到heartbeat的datanode，namenode會將之判爲最低優先級的讀寫
關於stale的理解可以參看下面的鏈接：
https://community.hortonworks.com/questions/2474/how-to-identify-stale-datanode.html
dfs.qjournal.write-txns.timeout.ms 默認是20000ms
Namenode寫Journalnode的超時時間，默認是20s，當發生超時後，Namenode會觸發ExitUtil類的terminate方法，導致進程的System.exit()，超時原因可能是網絡也有可能是namenode fullGC。
dfs.qjournal.start-segment.timeout.ms 默認是20000ms
EditLog會被切割爲很多段，每一段稱爲一個segment，Namenode發起新寫入editlog的RPC調用，會使用startLogSegment方法，上述參數表示發起新segment的超時時間。
dfs.client.read.shortcircuit = true
dfs.client.read.shortcircuit.buffer.size = 131072
hdfs短路讀取，客戶端讀hdfs時，datanode會根據blockID從本地磁盤讀數據並通過TCP流發送給client端，但是，如果Client與Block位於同一節點，那麼client端直接讀取本地Block文件即可獲取數據，無需通過Datanode的TCP連接發送，這就是短路讀取（short-circuit）;
dfs.datanode.failed.volumes.tolerated = <N>
壞盤容忍，可以容忍的壞盤數量；
HDFS-5776 Heged Read
第一次讀取超時時，請求第二個DN，降低整體延遲；
dfs.client.hedged.read.threadpool.size ＝ 50
dfs.client.hedged.read.threshold.millis ＝ 100
dfs.datanode.fsdataset.volume.choosing.policy = AvailableSpaceVolumeChoosingPolicy
默認值是RoundRobinVolumeChoosingPolicy
datanode數據副本存放磁盤選擇策略，第一種RoundRobinVolumeChoosingPolicy是磁盤目錄輪詢方式，第二種方式是選擇選擇可用空間足夠多的磁盤方式存儲。
Hortonworks 建議使用默認的RoundRobin policy。
dfs.datanode.max.xcievers（新版已改名爲dfs.datanode.max.transfer.threads）
對於datanode來說，就如同linux上的文件句柄的限制，當datanode上面的連接數超過設置值時，datanode會拒絕連接；
默認值是4096；
ipc.server.tcpnodelay
默認值 false。
在 Hadoop server 是否啓動 Nagle’s 算法。設 true 會 disable 這個演算法，關掉會減少延遲，但是會增加小數據包的傳輸；
ipc.server.tcpnodelay和ipc.server.tcpkeepalive設置tcp連接處理方式（Nagle’s algorithm 和 keepalive）；
hbase相關配置：
hbase.hstore.compactionThreshold 表示開始compaction的最低文件數，默認是2，可考慮增大；
hbase.hstore.compaction.kv.max 默認10，可以考慮增大到20，flush或者compact時一個batch處理的kv數；
hbase.hstore.flusher.count 用於flush的線程數，默認爲2，可以調整爲6；
hbase.quota.enabled 默認是false，設置爲true；
hbase.region.replica.replication.enabled 和 hbase.replication 可以設爲true，表示支持region replica，默認是false；
hbase.regionserver.storefile.refresh.period 如果上面設置爲true，secondary region週期從primary region獲取region最新file列表，默認是0，表示不啓用，該設置表示secondary region掃描的週期，ms單位；
hbase.online.schema.update.enable
hbase regionserver配置在線熱調整，默認是true；
hbase多個wal支持，可以按如下設置：
<property>
<name>hbase.wal.provider</name>
<value>multiwal</value>
</property>
<property>
<name>hbase.wal.regiongrouping.strategy</name>
<value>bounded</value>
</property>
<property>
<name>hbase.wal.regiongrouping.numgroups</name>
<value>2</value>
</property>原始的hbase中，一個regionserver只有一個wal文件，所有region的walEntry都寫到這個wal文件中，在HBase-5699之後，一個regionserver可以配置多個wal文件，這樣可以提高寫WAL時的吞吐，進而降低數據寫延時，其中配置hbase.wal.regiongrouping.strategy決定了每個region寫入wal時的分組策略，默認是bounded，表示每個regiongroup寫入固定數量個wal；
注意的是hbase.regionserver.maxlogs，決定了一個regionserver中wal文件的最大數量，默認是32，在上述配置下，如果仍舊設置保持32，等價於不使用multiwal時的64；
hbase.hregion.memstore.mslab.enabled
啓動memstore的MemStore-Local Allocation Buffer，默認爲true，建議使用默認值，可以有效管理memstore的內存，減小write heavy場景下的內存碎片；
zookeeper.session.timeout
zookeeper超時時間，默認是90000ms，建議將該值增大，可以設置爲120000；