使用hbase的目的是為了海量數據的隨機讀寫，但是在實際使用中卻發現針對隨機讀的優化和gc是一個很大的問題，而且hbase的數據是存儲在Hdfs，而Hdfs是面向流失數據訪問進行設計的，就難免帶來效率的下降。下面介紹一下Facebook Message系統在HBase online storage場景下的一個案例（《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011），最近他們在存儲領域頂級會議FAST2014上發表了一篇論文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他們在使用HBase中遇到的一些問題和解決方案。該論文首先講了Facebook的分析方法包括tracing/analysis/simulation，FM系統的架構和文件與數據構成等，接下來開始分析FM系統在性能方面的一些問題，并提出了解決方案。

FM系統的主要讀寫I/O負載

Figure 2描述了每一層的I/O構成，解釋了在FM系統對外請求中讀占主導，但是由于logging/compaction/replication/caching導致寫被嚴重放大。

• HBase的設計是分層結構的，依次是DB邏輯層、FS邏輯層、底層系統邏輯層。DB邏輯層提供的對外使用的接口主要操作是put()和get()請求，這兩個操作的數據都要寫到HDFS上，其中讀寫比99/1（Figure 2中第一條）。
• 由于DB邏輯層內部為了保證數據的持久性會做logging，為了讀取的高效率會做compaction，而且這兩個操作都是寫占主導的，所以把這兩個操作（overheads）加上之后讀寫比為79/21（Figure 2中第二條）。
• 相當于調用put()操作向HBase寫入的數據都是寫入了兩份：一份寫入內存Memstore然后flush到HFile/HDFS，另一份通過logging直接寫HLog/HDFS。Memstore中積累一定量的數據才會寫HFile，這使得壓縮比會比較高，而寫HLog要求實時append record導致壓縮比（HBASE-8155）相對較低，導致寫被放大4倍以上。??? Compaction操作就是讀取小的HFile到內存merge-sorting成大的HFile然后輸出，加速HBase讀操作。Compaction操作導致寫被放大17倍以上，說明每部分數據平均被重復讀寫了17次，所以對于內容不變的大附件是不適合存儲在HBase中的。由于讀操作在FM業務中占主要比例，所以加速讀操作對業務非常有幫助，所以compaction策略會比較激進。
  HBase的數據reliable是靠HDFS層保證的，即HDFS的三備份策略。那么也就是上述對HDFS的寫操作都會被轉化成三倍的local file I/O和兩倍的網絡I/O。這樣使得在本地磁盤I/O中衡量讀寫比變成了55/45。
• 然而由于對本地磁盤的讀操作請求的數據會被本地OS的cache緩存，那么真正的讀操作是由于cache miss引起的讀操作的I/O量，這樣使得讀寫比變成了36/64，寫被進一步放大。??? 另外Figure 3從I/O數據傳輸中真正業務需求的數據大小來看各個層次、各個操作引起的I/O變化。除了上面說的，還發現了整個系統最終存儲在磁盤上有大量的cold data（占2/3），所以需要支持hot/cold數據分開存儲。

總的來說，HBase stack的logging/compaction/replication/caching會放大寫I/O，導致業務邏輯上讀為主導的HBase系統在地層實際磁盤I/O中寫占據了主導。
FM系統的主要文件類型和大小??

FM系統的幾種文件類型如Table 2所示，這個是純業務的邏輯描述。在HBase的每個RegionServer上的每個column family對應一個或者多個HFile文件。FM系統中有8個column family，由于每個column family存儲的數據的類型和大小不一樣，使得每個column family的讀寫比是不一樣的。而且很少數據是讀寫都會請求的，所以cache all writes可能作用不大（Figure 4）。??

對于每個column family的文件，90%是小于15M的。但是少量的特別大的文件會拉高column family的平均文件大小。例如MessageMeta這個column family的平均文件大小是293M。從這些文件的生命周期來看，大部分FM的數據存儲在large,long-lived files，然而大部分文件卻是small, short-lived。這對HDFS的NameNode提出了很大的挑戰，因為HDFS設計的初衷是為了存儲少量、大文件準備的，所有的文件的元數據是存儲在NameNode的內存中的，還有有NameNode federation。
FM系統的主要I/O訪問類型

下面從temporal locality, spatial locality, sequentiality的角度來看。
73.7%的數據只被讀取了一次，但是1.1%的數據被讀取了至少64次。也就是說只有少部分的數據被重復讀取了。但是從觸發I/O的角度，只有19%的讀操作讀取的是只被讀取一次的數據，而大部分I/O是讀取那些熱數據。
在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%的成本，比加內存性價比高很多。
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的原理。現在HBase的多個RS會向同一個DataNode發送寫log請求，而目前DataNode端會把來自這三個RS的log分別寫到不同的文件/塊中，會導致該DataNode磁盤seek操作較多（不再是磁盤順序I/O，而是隨機I/O）。Combined logging就是把來自不同RS的log寫到同一個文件中，這樣就把DataNode的隨機I/O轉化成了順序I/O。

總結

以上是生活随笔為你收集整理的hbase 学习（十四）Facebook针对hbase的优化方案分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。