背景算法
做爲近期Hadoop社區的明星項目，Hadoop Ozone吸引了社區普遍的關注。它脫胎於HDFS，不只同時支持文件系統和對象語義，能原生對接HDFS和S3兩種訪問模式，也將集羣的讀寫性能和吞吐量視爲重中之重。2019年年中，騰訊大數據團隊開始上線Ozone集羣承接大數據存儲業務，數據湖小組也全力投入了Hadoop Ozone的開源項目中。在與Hadoop Ozone社區和Cloudera深度合做後，數據湖小組憑藉在開源界多年的深耕和數據平臺的業務對接實戰經驗，逐漸發現Ozone寫入性能顯現出了必定的波動和瓶頸，針對性設計了重點的新特性和優化來解決這些問題，同時也將這些特性回饋給了社區。這次介紹的Multi-Raft特性就是其中的重頭戲。sql
Ozone的結構中保留了原先HDFS中的 DataNode數據節點，不過將管理元數據的NameNode分拆成了Ozone Manager（處理用戶請求和響應）和Storage Container Manager（管理數據pipeline，container等資源）。數據節點上從原先的Block管理數據轉變成了Container管理，同時也採用了更爲輕量的Raft協議管理元數據和數據的一致性。Ozone Manager和Storage Container Manager放在了性能更好的RocksDB內管理，大大增長了集羣Scale Out的能力，在架構上突破了原先HDFS元數據瓶頸的限制，同時也經過Raft增長了元數據管理節點standBy的個數，加強了集羣可用性。apache
元數據管理的加強也意味着數據節點能夠被更好地利用，因而，在HDFS上爲人津津樂道的數據節點DataNode的吞吐量優化問題，在Ozone集羣上也成了焦點問題。互聯網各大廠對於HDFS DataNode數據吞吐量的優化各有十八般武藝：某大廠利用C++重寫了一套HDFS，不只擴展了DataNode吞吐量，也讓一個NameNode能夠管理超過7萬個DataNode；還有大廠選擇優化Linux的cache排隊機制，優化Linux底層分配內存時page allocation的效率，達到增大寫盤帶寬的效果，從而增大DataNode的吞吐量。性能優化
但這些方案都僅限於公司內部高度定製化的方案，不管是後期維護，仍是合入開源社區新的改動升級等方面都形成了新的障礙。騰訊做爲大面積使用Hadoop Ozone的第一家大廠，在選擇Ozone的優化方案時優先考慮了社區友好的策略。服務器
Ozone利用了Raft協議做爲集羣一致性協議，寫數據時經過DataNode Raft Leader同步到Follower的方式確保多副本寫入，讀數據時只須要讀到任意副本均可以返回結果，從而達到強一致的讀寫語義。在考慮調優DataNode性能時，咱們把目光集中到了Raft Pipeline上，在一系列的測試後，咱們發現以前Ozone對數據Pipeline和Raft的使用並無使得磁盤處於高效運轉的狀態，因而設計了Multi-Raft的功能，可讓單個數據節點上承載儘可能多個Raft Pipeline，達到用帶寬換時延的目的。網絡
本文將重點分享Ozone如何高效利用Multi-Raft的方案調優數據節點的吞吐量，從而達到寫性能優化。Multi-Raft的方案和實習也是Ozone社區在最近一次0.5.0版本發佈中重要的特性，筆者同時也在開源社區大廠Cloudera的官方Blog上發佈了一篇英文版的技術分享：架構
https://blog.cloudera.com/multi-raft-boost-up-write-performance-for-apache-hadoop-ozone/併發
有興趣的小夥伴也能夠移步參閱一下。app
Raft選舉機制異步
咱們先來簡單介紹下Raft機制，以及Ozone是如何利用Raft機制來實現多副本寫入的數據一致性的。分佈式系統的一致性問題是你們津津樂道的話題，分佈式系統因爲自己分佈式處理和計算的特色，須要協調各個服務器節點的服務狀態保持一致來保證系統的容錯能力，當某些節點出現故障的時候，不至於拖累整個集羣。尤爲對於Ozone這樣的強一致分佈式存儲系統，須要在節點間有普遍認可的協議來保證狀態一致，Ozone採用了Raft協議來維護集羣狀態和共享數據。
Raft協議中會有3個角色身份：Leader，Follower和Candidate。Split Vote投票過程會在Candidate中選出Leader和Follower的身份，Follower能夠變成Candidate競選Leader。
Raft一致性過程
Raft協議本質上是經過本地的RaftLog和在Leader與Follower之間同步狀態來保證數據的一致性，同時StateMachine會記錄集羣的狀態。RaftLog使用了write ahead log (WAL) 的理念，Leader將過程記錄在Log裏面，同時日誌的更新內容會同步到Follower上，而後日誌會apply log到StateMachine中記錄狀態，當有足夠的Quorum宣佈成功，總體操做就成功了。這樣能保證集羣全部節點的狀態機變化是相對同步的，同時RaftLog會在節點重啓時作replay回放操做，從新創建起重啓前的StateMachine狀態，讓節點恢復到與重啓前相對同步的狀態。
從Ozone寫入過程的container流程中，爲了保證當前三副本的冗餘機制，container須要在3個數據節點DataNode上分配空間並保證多數節點寫成功。Raft協議中的日誌機制能夠保證在Leader寫完成後，Replicate數量到follower上去，三副本中有一個follower寫完成後，數據就持久化成功了。這個大多數數據寫成功的操做能夠直接由Raft協議幫助完成，同時能夠保證讀寫強一致。
Multi-Raft實現寫入吞吐量優化
Ozone利用Raft機制管理數據和元數據的寫入流程，數據寫入DataNode上的磁盤前，Leader節點須要利用RaftLog的複製功能將數據同步到Follower節點上。因爲Raft協議依賴RaftLog做爲其WAL（寫前日誌），那麼在數據節點上寫入數據時也受到了RaftLog持久化時延的影響，隨着線上環境支撐的數據量愈來愈大，Ozone寫性能的波動和瓶頸愈來愈明顯。
通過一系列的benchmark測試後，咱們將目光投向瞭如何利用Raft Log加強DataNode上寫盤的效率。原先的設計中，每個Raft Group構成一個SCM中的Pipeline控制一系列的數據Container，通過測試發現，每一個DataNode的磁盤使用率不是很充分，以後結合Ozone當前實現，設計並開發了Multi-Raft的功能，讓SCM能夠在每一個DataNode上分配多個Pipeline，更加高效地使用DataNode上的磁盤和分區，同時也利用多Raft Group自然提升了單個DataNode的寫併發，演進優化了Ozone的寫入吞吐量和性能。
Ozone的數據寫入模式
Ozone對於數據的管理主要由Pipeline和Container完成。Ozone的Storage Container Manager (SCM)負責建立數據Pipeline，而且分配Container到不一樣的Pipeline中，而每一個Container負責在不一樣的數據節點DataNode上分配Block用來存儲數據。用戶經過客戶端寫入Ozone，會經過Ozone Manager建立Key，並從SCM拿到數據能夠寫入的空間，這個空間會由Pipeline和Container分配得來。
Pipeline和Container分配寫入數據跟數據的副本數有關，Ozone如今主要支持三副本的方式，數據Pipeline建立時會關聯三個數據節點，而後相關的Container會在這三個數據節點上分配Block來完成寫入空間分配，三個數據節點會分別記住Pipeline和Container信息，異步發送Report到SCM上報Pipeline和Container的狀態。三副本的數據Pipeline是經過Raft協議保證多副本一致性，在Ozone中也叫Ratis Pipeline，相關的三個數據節點會根據Raft協議組成一個Leader和2個Follower的組合，數據寫入時會利用RaftLog把數據從leader發到Followers。因此Ozone的數據寫入的性能依賴RaftLog的寫入吞吐量和傳輸速度。
關於吞吐量的優化探索
Ozone-0.4.0版本中，Pipeline控制數據寫入是基於Single-Raft的實現，即每個數據節點只能參與一個Pipeline。咱們針對這個版本的Ozone進行了寫入性能的觀察和測試，組件了一個10節點的Ozone集羣，每臺Ozone數據節點都有12塊HDD磁盤，網絡選取了10 Gps帶寬，做爲大數據外部存儲的集羣配置。訪問Ozone的方式咱們選擇了S3協議寫入Ozone，對象大小比較離散，由內部sql query的結果組成，大部分是KB級的小對象，其中摻雜了GB級的大對象。
根據圖中時延分佈，咱們能夠看到有68%的寫入能夠在200毫秒內完成，可是依然有超過27%的文件集中於2-3秒內才能完成，同時觀察發現時延與文件大小沒有很是直接的聯繫。此外，咱們也觀察了某個數據節點的磁盤使用率。
在前臺持續併發寫入的過程當中，在所有12塊磁盤中，只有5塊數據盤有負載，而且集中於其中的3塊磁盤。經過日誌挖掘和數據統計也觀察到，有IO阻塞的現象，數據節點上RaftLog寫入磁盤的時候頗有可能有排隊的現象。因而咱們將思路放在了提升數據節點磁盤使用率和緩解Ratis持久化RaftLog排隊現象上。
在社區版本的HDFS上也有DataNode IO吞吐量不高的現象，以前有一些落地的方案會改動Linux操做文件系統的方式，增長一些相似Cache的手段幫助增大DataNode經過操做系統寫入磁盤的吞吐量。而Ozone這部分優化的思路放在了經過數據Pipeline的節點複用來加大每一個節點上Pipeline的使用量，從而經過增長使用者的方式變相增大磁盤使用率。
Multi-Raft的設計思路
若是每個DataNode，受到了Single-Raft的制約，只能參加一個數據Pipeline的寫入，那麼上面的磁盤使用率觀察能夠看到Ratis實現的RaftLog並不能將寫入IO均勻的分配到每個磁盤路徑上。
在與Ratis社區討論後，咱們提出了了Multi-Raft的方案，即容許數據節點參與多個數據Pipeline的工做，同時，Multi-Raft也須要經過新的Pipeline分配算法保證數據隔離，考慮數據locality和節點的rack awareness。
在容許數據節點DataNode參加多個數據Pipeline以後，Pipeline的節點分配就出現了很大的變化：
- SCM能在集羣不變大的狀況下分配出更多的數據Pipeline。假設配置每一個節點最多能夠承接M個數據Pipeline的寫入，在有N個數據節點的狀況下，Single-Raft下SCM最多能夠分配N/3個Pipeline，而Multi-Raft下就能夠配置M(M*N)/3個Pipeline。
- 因爲三副本備份的緣由，數據Pipeline必須有恰好3個數據節點加入才能建立成功，Multi-Raft能夠合理利用每個數據節點的能力參與Pipeline。如圖示，在有4個數據節點的時候，Single-Raft的集羣只能建立出1個數據Pipeline，而剩下的1個數據節點（4-3*1）只能做爲StandBy備用，在開啓Multi-Raft功能後，4個節點均可以參加數據Pipeline的分配，大大提升了集羣配置的靈活度。
- 從Single-Raft的磁盤使用率能看到，一個數據Pipeline使用的RaftLog並不能充分將數據寫入很好的load balance，在與Ratis社區協做以後，Multi-Raft的方案能夠有效利用節點上服務多個數據Pipeline的磁盤，從原來的一個RaftLog使用12個磁盤，變爲多個RaftLog使用12個磁盤。對於Ratis的Batch寫入和排隊機制來講，一次寫入可能會Hold某個磁盤一段時間，因而後面排隊的寫入因爲RaftLog個數的限制，會形成必定程度的排隊，這也是咱們在Single-Raft的集羣看到有超過27%的寫入須要花費2-3秒，多個RaftLog的存在會很好減小排隊的擁擠程度，由於「隊伍」變多了。
Multi-Raft優化後的寫性能表現
首先來看看一樣的大數據數據集寫入Multi-Raft集羣和Single-Raft集羣的時延分佈對比：
對比Single-Raft的集羣：
能夠看到Multi-Raft優化後的集羣，面對一樣的數據集寫入，接近98%的寫入都在200ms內完成，IO排隊致使的時延波動已經幾乎看不到了。
而後再選取一個數據節點根據節點上Pipeline分配個數觀察磁盤使用率：
單數據節點參與1條數據Pipeline時：
單數據節點參與12條數據Pipeline時：
單數據節點參與15條數據Pipeline時：
能夠很明顯地看到當數據節點上的數據Pipeline增多的時候，愈來愈多的磁盤達到了繁忙的程度，再也不出現忙碌和閒置不均勻的狀況了。
總結
Ozone的數據節點寫入磁盤的部分，必定程度上延續了HDFS單節點寫入的方式，同時也保留了一些可待優化的部分。比起單純在數據節點上作IO棧層面的優化，Multi-Raft的方案利用了數據Pipeline的節點複用和RaftLog的特色，加大了數據節點對於併發寫入數據的參與度。這樣經過元數據和管理成本的修改增大寫入帶寬的方式，對於開源社區是更好的選擇，後續能夠打開更多的優化點，當前的Ozone-0.5.0版本在HDD集羣上的寫入性能比起0.4版本也有顯著的提高。
Multi-Raft的功能已經徹底回饋給了Apache Ozone社區，也在社區中取得了不錯的評價，在合做的Cloudera技術Blog中也發佈了Multi-Raft的技術分享：
https://blog.cloudera.com/multi-raft-boost-up-write-performance-for-apache-hadoop-ozone/
與其餘友商優化DataNode單節點性能的方案相比，Multi-Raft的方案對社區融合更加友好，也給後續的進一步深度調優留下了空間，更加適合Apache Hadoop Ozone這樣還在迅速成長中的項目。
關注公衆號「騰訊大數據」，獲取更多內容。