HBase性能優化案例分析(2)

　　在HDFS這一層，FM讀取數據沒有表現出sequentiality，也就是說明high-bandwidth, high-latency的機械磁盤不是服務讀請求的理想存儲介質。而且對數據的讀取也沒有表現出spatial locality，也就是說I/O預讀取也沒啥作用。

　　解決方案

　　1. Flash/SSD作為cache使用。

　　下面就考慮怎么架構能夠加速這個系統了。目前Facebook的HBase系統每個Node掛15塊100MB/s帶寬、10ms尋址時間的磁盤。Figure 9表明：a)增加磁盤塊數有點用;b)增加磁盤帶寬沒啥大用;c)降低尋址時間非常有用。

　　由于少部分同樣的數據會被經常讀取，所以一個大的cache能夠把80%左右的讀取操作攔截而不用觸發磁盤I/O，而且只有這少部分的hot data需要被cache。那么拿什么樣的存儲介質做cache呢?Figure 11說明如果拿足夠大的Flash做二級緩存，cache命中率會明顯提高，同時cache命中率跟內存大小關系并不大。

　　注：關于拿Flash/SSD做cache，可以參考HBase BucketBlockCache(HBASE-7404)

　　我們知道大家比較關心Flash/SSD壽命的問題，在內存和Flash中shuffling數據能夠使得最熱的數據被交換到內存中，從而提升讀性能，但是會降低Flash的壽命,但是隨著技術的發展這個問題帶來的影響可能越來越小。

　　說完加速讀的cache，接著討論了Flash作為寫buffer是否會帶來性能上的提升。由于HDFS寫操作只要數據被DataNode成功接收到內存中就保證了持久性(因為三臺DataNode同時存儲，所以認為從DataNode的內存flush到磁盤的操作不會三個DataNode都失敗)，所以拿Flash做寫buffer不會提高性能。雖然加寫buffer會使后臺的compaction操作降低他與前臺服務的I/O爭用，但是會增加很大復雜度，所以還是不用了。最后他們給出了結論就是拿Flash做寫buffer沒用。

　　然后他們還計算了，在這個存儲棧中加入Flash做二級緩存不但能提升性能達3倍之多，而且只需要增加5%的成本，比加內存性價比高很多(怎么感覺有點像SSD的廣告貼)。

　　2.分層架構的缺點和改進方案

　　如Figure 16所示，一般分布式數據庫系統分為三個層次：db layer/replication layer/local layer。這種分層架構的最大優點是簡潔清晰，每層各司其職。例如db layer只需要處理DB相關的邏輯，底層的存儲認為是available和reliable的。

　　HBase是圖中a)的架構，數據的冗余replication由HDFS來負責。但是這個帶來一個問題就是例如compaction操作會讀取多個三備份的小文件到內存merge-sorting成一個三備份的大文件，這個操作只能在其中的一個RS/DN上完成，那么從其他RS/DN上的數據讀寫都會帶來網絡傳輸I/O。

　　圖中b)的架構就是把replication層放到了DB層的上面，Facebook舉的例子是Salus，不過我對這個東西不太熟悉。我認為Cassandra就是這個架構的。這個架構的缺點就是DB層需要處理底層文件系統的問題，還要保證和其他節點的DB層協調一致，太復雜了。

　　圖中c)的架構是在a的基礎上的一種改進，Spark使用的就是這個架構。HBase的compaction操作就可以簡化成join和sort這樣兩個RDD變換。

　　Figure 17展示了local compaction的原理，原來的網絡I/O的一半轉化成了本地磁盤讀I/O，而且可以利用讀cache加速。我們都知道在數據密集型計算系統中網絡交換機的I/O瓶頸非常大，例如MapReduce Job中Data Shuffle操作就是最耗時的操作，需要強大的網絡I/O帶寬。加州大學圣迭戈分校(UCSD)和微軟亞洲研究院(MSRA)都曾經設計專門的數據中心網絡拓撲來優化網絡I/O負載，相關研究成果在計算機網絡頂級會議SIGCOMM上發表了多篇論文，但是由于其對網絡路由器的改動傷筋動骨，最后都沒有成功推廣開來。

　　Figure 19展示了combined logging的原理?，F在HBase的多個RS會向同一個DataNode發送寫log請求，而目前DataNode端會把來自這三個RS的log分別寫到不同的文件/塊中，會導致該DataNode磁盤seek操作較多(不再是磁盤順序I/O，而是隨機I/O)。Combined logging就是把來自不同RS的log寫到同一個文件中，這樣就把DataNode的隨機I/O轉化成了順序I/O。

原文轉自：http://www.infoq.com/cn/articles/hbase-casestudy-facebook-messages