3年前，Uber采用了Hadoop作為大資料分析的存儲（HDFS）和計算（YARN）基礎設施。借助于這套系統，Uber的服務能力得到了增強，使用者體驗也得到了提升。
Uber将基于Hadoop的批量和流式分析應用在了廣泛的場景中，例如反作弊、機器學習和ETA計算等。随着過去幾年的業務增長，Uber的資料容量和通路負載也呈現了指數級增長的趨勢，如：僅2017年，存儲在HDFS中的資料量就增加了超過400%。
同時保證系統擴充能力和高性能并不是一件容易的事情。Uber的資料基礎設施團隊采用了多種方式來擴充HDFS系統，例如視圖檔案系統（ViewFS）、頻繁的HDFS版本更新、NameNode的垃圾回收調優、減少小檔案的數量、HDFS負載管理服務、隻讀的NameNode副本等。下面将詳細介紹，Uber是如何通過這些改進措施來保證存儲系統的持續增長、穩定和可靠的。
一．擴充帶來的挑戰
HDFS被設計成在單一叢集上部署的、能夠包含數千個節點的、可擴充的分布式檔案系統。隻要硬體配置滿足，單一叢集可以友善又快速的擴充到超過100PB的存儲容量。
可是在Uber，由于業務的快速增長，每周都有成千上萬個使用者進行百萬次的Hive和Presto查詢，在這種情況下，既要可靠的擴充系統，又要不影響資料分析業務是很難的。
目前，一半的HDFS通路都來自Presto，90%的Presto查詢需要約100秒的時間。如果我們的HDFS系統過載，Presto查詢就會因為在隊列中長時間等待而延遲。除此之外，當一個查詢來到時，我們還需要保證HDFS中的資料是立即可用的。
在之前的存儲系統中，為了減少資料複制導緻的延遲，資料抽取、轉換、加載（ETL）和使用者查詢都在同一個叢集中進行。為了适應這種頻繁寫入和更新，系統産生了很多的小檔案，這進一步導緻了隊列的阻塞。
此外，每個業務方都需要使用到大部分的存儲資料，如果按照場景用例群組織架構來拆分叢集，勢必會增加資料的備援存儲、降低效率和增加成本。
擴充HDFS和使用者體驗之間的主要沖突和瓶頸在于NameNode的性能和吞吐能力。NameNode儲存了整個系統的目錄樹以及資料的位置資訊。正是因為NameNode儲存了所有的中繼資料資訊，所有的客戶請求都必須先通路它。而且，NameNode對整個命名空間隻使用一把讀寫鎖，使得任何寫請求都會阻塞其它請求，這進一步限制了NameNode的吞吐量。
2016年下半年，我們開始遇到上述原因帶來的問題 - 超長的NameNode RPC請求排隊時間。有時候，NameNode的請求排隊時間會超過500毫秒（最長的排隊時間達到了1秒），這就意味着每個HDFS請求都需要在隊列中至少等待半秒鐘 。相比起常态10毫秒的處理時間，這無疑是巨大的性能下降。
圖1. 2016年，NamoNode單個請求的RPC排隊時間超過了0.5秒
二．擴充系統 & 提升性能
為了保證HDFS的持續擴充能力和高性能，我們同時開發了多個方案。它們既避免了短期内資料增長可能導緻的服務中斷，也為我們長期建立一個更可靠、擴充性更強的系統來應對未來的業務發展提供了支援。
下面将詳細講述這些改進方案，它們不僅把HDFS系統的容量增加了400%，還提高了系統的整體性能。
2.1 使用ViewFs來進行橫向擴充
受到Twitter的一些相似工作的啟發，我們使用視圖檔案系統将HDFS拆分到多個命名空間中，并且使用ViewFs的挂載點來給使用者呈現一個虛拟的命名空間。
HBase從Yarn和Presto所在的HDFS叢集中分離了出來，這個調整不僅大大降低了主叢集上的負載，而且使得HBase更加的穩定，将HBase叢集的啟動時間從幾小時縮減到了幾分鐘。
我們還為Yarn上的作業彙聚日志建立了專有的HDFS叢集（彙聚日志要支援ViewFS，需要包含YARN-3269，）。Hive的scratch目錄也被放在了這個專有叢集上。現在，新的叢集服務了大概40%的寫請求，而且這個叢集上的大部分檔案都是小檔案，這樣也減輕了檔案數量給主叢集帶來的壓力。該方案不需要用戶端的代碼改動，是以整個遷移過程很平滑。
我們最終選擇在ViewFS的下層部署獨立的HDFS叢集，而不是HDFS聯邦叢集。這樣，每個HDFS叢集都可以單獨更新，減少了大規模故障的風險。此外，叢集隔離也提高了系統的可靠性。這個方案的一個缺點是，維護多個獨立的HDFS叢集，會帶來更高的運維成本。
圖2. 我們在多個資料中心部署了ViewFS來管理多個HDFS命名空間
2.2 HDFS更新
第二個方案就是保持HDFS更新到最新的釋出版本。我們一年内，進行了兩次大版本更新，先從CDH 5.7.2 (HDFS 2.6.0的基礎上打了很多更新檔)更新到Apache 2.7.3，然後更新到2.8.2。為了進行更新，我們還在Puppet和Jenkins的基礎上，重新建構了部署架構，來取代第三方的叢集管理工具。
更新（HDFS-9710, HDFS-9198,和HDFS-9412）能夠顯著提升HDFS叢集的擴充能力。例如，更新到Apache 2.7.3後，增量資料塊的報告減少了，NameNode的負載也降低了。
更新HDFS是有風險的，因為可能導緻停機、性能下降或者資料丢失。為了避免這些情況，我們在部署到生産環境前，花費了數個月的時間來驗證2.8.2版本。可是在更新我們最大的叢集時，還是意外的發現了一個bug（HDFS-12800）。叢集隔離、分階段更新流程和緊急復原計劃幫助我們減輕了影響。
在我們的擴充過程中，在同一個叢集上采用不同版本的YARN和HDFS也是非常關鍵的決定。YARN和HDFS是Hadoop的組成部分，通常是一起更新的。但是，YARN的大版本更新可能導緻API的變更和JAR包沖突，使得生産環境中的作業失敗，是以需要很長的驗證和實施時間。因為我們不需要對YARN叢集進行擴容，我們也不希望HDFS的關鍵更新被YARN阻塞住，是以我們目前部署的YARN版本要老于HDFS。在我們的場景中，這種模式運作良好。（可是，如果要使用Erasure Coding特性的話，會涉及到用戶端API的變更，這種模式就不适用了。）
2.3 NameNode垃圾回收調優
垃圾回收調優在我們的擴容過程中，也扮演了很重要的角色，給了我們更多的緩沖時間來進行後續存儲系統的橫向擴充。
我們通過參數調整（CMSInitiatingOccupancyFraction、UseCMSInitiatingOccupancyOnly和CMSParallelRemarkEnabled），促使CMS更加主動的進行老生代的垃圾回收，進而避免長時間的GC停頓。雖然這樣會增加CPU的使用率，但我們CPU的配置足夠支撐。
當RPC處于高負載時，新生代會産生大量的臨時對象，新生代的垃圾回收器會進行頻繁的stop-the-world回收操作。通過把新生代的空間從1.5GB增加到16GB，同時調整ParGCCardsPerStrideChunk（設定成32768）,生産環境NameNode的GC停頓時間占比從13%降低到了1.7%，吞吐量也增加了超過10%。圖3的基準測試曲線，展示了隻讀場景下NameNode的GC優化結果。
圖3. 通過把新生代的空間從1.5G增加到16G以及調整ParGCCardsPerStrideChunk的值，NameNode的GC停頓時間占比從13%降到了1.7%
我們NamNode的堆記憶體是160G，以下是配置的參數。
· XX:+UnlockDiagnosticVMOptions
· XX:ParGCCardsPerStrideChunk=32768 -XX:+UseParNewGC
· XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled
· XX:CMSInitiatingOccupancyFraction=40
· XX:+UseCMSInitiatingOccupancyOnly
· XX:+CMSParallelRemarkEnabled -XX:+UseCondCardMark
· XX:+DisableExplicitGC
我們還評估了是否要使用G1垃圾回收器。盡管我們在過去的G1使用經驗中，沒有發現明顯的優點，但是新版本的JVM總會帶來額外的GC性能提升，未來替換我們的垃圾回收機制也是有可能的。
2.4 控制小檔案的數量
NameNode會把所有檔案的中繼資料資訊存在記憶體中，存儲小檔案會給NameNode帶來巨大的記憶體壓力。讀取和新增同樣資料量的情況下，小檔案也會導緻更大量的RPC請求。是以，我們采用了兩種方法來減少小檔案的數量。
首先，Hadoop資料平台組基于Hoodie建構了新的資料攝取管道，可以生成比原來的資料管道更大的檔案。在此之前，我們使用了一個臨時方案，就是建構了一個工具（内部叫做stitcher）來合并小檔案，大部分都被合并成大于1GB的檔案。
其次，我們給Hive資料庫和各個應用目錄設定了更加嚴格的命名空間配額。我們還提供了一個自服務的工具，來幫助使用者管理各自組織下的配額。配額是以256MB為基本機關配置設定給檔案的，這可以促使使用者優化他們的輸出檔案大小。Hadoop組還提供了優化指南和檔案合并工具給使用者。例如：在Hive上開啟自動合并機制，并且調優reducer的數目，可以大大減少Hive插入複寫請求所生成的檔案數。
2.5 HDFS負載管理工具
運維一個像HDFS這樣大型多租戶分布式平台的最大挑戰之一，就是快速檢測出哪個應用導緻了異常的高負載，并且能夠迅速解決問題。為此，我們建構了一個HDFS負載管理服務，名字叫做Spotlight。
Spotlight目前的實作是通過Kafka擷取Active NameNode上的審計日志，并通過Flink實時處理。分析結果會通過大盤方式顯示出來，并且會自動封禁或殺死導緻HDFS變慢的賬号和作業。
圖4. Splotlight可以幫助識别和封禁導緻HDFS性能問題的賬号
2.6 Observer NameNode
我們目前在開發Observer NameNode（HDFS-12975），這是一個新的特性，旨在通過隻讀的NameNode副本來降低Active NameNode的負載。由于有一半以上的HDFS RPC請求來自于隻讀的Presto請求，我們希望第一次釋出的Observer NameNode可以把NameNode吞吐量增加100%。目前驗證已經完成，并且正在部署到生産環境中。
圖5. Uber目前的HDFS架構內建了HA和Observer NameNodes
2.7 要點
通過HDFS的擴充經驗，我們總結了以下一些最佳實踐，希望對其它面對相似問題的同行有幫助。
- 對解決方案分層：實作Observer NameNode和拆分HDFS叢集都需要大量的工作，短期的舉措例如GC調優、合并小檔案等給了我們很多的緩沖時間來開發長期解決方案。
- 越大越好：小檔案對HDFS是個危險，越早處理越好。為使用者提供工具、文檔和教育訓練，都是有效的幫助使用者采取最佳實踐的好方法，尤其是在多租戶系統中。
- 參與到社群中：Hadoop已經有十幾年的曆史，它的社群也比以往更加活躍，今年的每一個新版本釋出都帶來了擴充性和功能的提升。參與到社群中，提供你的發現和工具，這對于你的大資料基礎設施的持續擴充很重要。
三．繼續前進
盡管過去幾年，我們在改進HDFS基礎設施上取得了很大的進步，但是依然很多東西需要繼續去做。
如圖6，我們準備把更多的新服務內建到存儲系統中來，這樣可以進一步擴充我們的基礎設施，并且使得Uber的存儲生态更加高效和易用。
圖6. Uber近期的HDFS架構将會增加多個特性，有助于擴充存儲系統容量
下面介紹一下我們準備做的兩個主要項目 - 基于路由的HDFS聯邦叢集和分層存儲。
3.1基于路由的HDFS聯邦叢集（Router-based HDFS Federation）
我們目前是使用ViewFs來擴充HDFS叢集。這種方式的問題是，每次增加或者替換ViewFs的某個挂載點時，都需要對用戶端的配置進行更改，是以想要對生産環境無損的進行調整是非常困難的。這也導緻了我們目前隻對不需要進行大範圍客戶側改動的資料進行了拆分，例如Yarn的作業聚合日志。
微軟的 new initiative and implementation 和Router-based Federation （HDFS-10467, HDFS-12615)是對基于ViewFs的分區聯邦系統的自然延伸。整個系統增加了一個聯邦層來內建各個命名空間。聯邦層通過提供HDFS相容的接口（RPC和WebHDFS），可以使得使用者透明的通路子叢集，同時又能夠讓子叢集獨立管理各自的資料。
通過提供一個rebalancing工具，聯邦層還支援叢集之間資料的透明遷移，進而實作負載均衡和存儲分層。聯邦層在一個中心化的狀态存儲中，維護了一個全局的命名空間，通過運作多個路由器将使用者的請求路由到正确的子叢集中。
我們目前正在嘗試把基于路由的聯邦叢集部署到Uber的生産環境中，同時在一些開源的改進點上和Hadoop社群保持着密切的合作，例如WebHDFS support。
3.2 分層存儲
随着基礎設施規模的擴大，縮減存儲成本也變得十分重要。我們的技術小組所做的研究表明，使用者通路新資料（熱資料）比通路老資料（溫資料）要頻繁的多。将老資料轉存到獨立的，資源更不密集的分層可以顯著降低存儲成本。HDFS Erasure Coding、Router-based Federation、高密度（大于250TB）硬體存儲，資料遷移服務（在hot層和warm層進行資料遷移）是我們将來分層存儲設計的關鍵元件。我們将在後續的文章分享分層存儲的經驗。
原文連結：
https://eng.uber.com/scaling-hdfs/阿裡巴巴開源大資料技術團隊成立Apache Spark中國技術社群，定期推送精彩案例，技術專家直播，問答區近萬人Spark技術同學線上提問答疑，隻為營造純粹的Spark氛圍，歡迎釘釘掃碼加入！
對開源大資料和感興趣的同學可以加小編微信（下圖二維碼，備注“進群”）進入技術交流微信群。