林意群：eBay HDFS架構的演進優化實踐

　　本文根據林意群在【第十二屆中國資料庫技術大會(DTCC2021)】現場演講內容整理而成。

　　 講師介紹：

　　林意群，億貝軟體工程（上海）有限公司大資料開發工程師，擁有多年大資料從業經驗，2019年加入eBay，主要負責eBay HDFS叢集效能優化方面的工作。平時也活躍於開源社群，擁有多年參與開源社群的經驗。目前主要專注於儲存領域的研究和學習，同時也樂於總結分享，在eBay技術公眾號，Alluxio官方公眾號上發表過多篇技術文章。著有《深度剖析Hadoop HDFS》一書。

　　 本文摘要：

　　HDFS作為大資料的底層儲存系統，能夠儲存海量的資料並能夠對外提供穩定的資料讀寫服務。eBay HDFS叢集發展至今已達到PB規模量級的資料儲存，同時目前在支援公司越來越多業務的發展。同樣，業務的快速發展對我們的HDFS叢集提出了更高的要求和挑戰。

　　eBay HDFS架構經過多年的演進優化，在效能和穩定性上得到了極大的提升。在早期的時候，HDFS叢集是以獨立叢集服務的模式對外提供資料服務。伴隨著業務資料規模的快速增長，我們很快遇到了HDFS NameNode的效能瓶頸問題。

　　隨後我們進行了HDFS Federation架構模式的嘗試。我們將主叢集NameNode的後設資料進行了多namespace的拆分，形成多Federation NameNode共同服務的方式。同時在此期間我們持續地在進行HDFS自身的效能調優，使得NameNode的處理效能能夠得到進一步地提升。

　　HDFS Federation架構橫向擴充套件了HDFS叢集的整體處理能力，但是不斷增多的Federation namespace也加大了我們對此的管理和使用難度。如何更加有效地使用和管理這些namespace的資料成了我們又一個新的需要解決的難題。我們採用了社群RBF（Router-Based Federation）的架構模式來統一管理HDFS Federation。

　　在RBF架構模式下，引入了中間服務Router來做客戶端和NameNode服務端的中間層，底層Federation NameNode對於客戶端來說完全透明。基於Router服務的Federation方案使得我們能夠更加靈活透明地擴充套件底層HDFS的服務能力。 本文我們將詳細講述eBay HDFS叢集架構從單獨叢集到Federation模式，再到RBF架構模式的演進歷程，以及在此期間我們遇到的許多難題和相應的解決方案。

　　分享大綱：

　　a.介紹HDFS在ebay的使用現狀

　　b.介紹ebay在生產中遇到的問題，以及我們應對和優化的策略。

　　c.介紹HDFS Rouer-based federation在ebay的應用。

　　 演講正文：

　　eBay Hadoop發展了很多年，目前擁有10+叢集，總數在2W+節點以上，其中最大的一個叢集HDFS超過5000臺機器，總儲存達到800PB+，日均Job數在100K+。

　　隨著叢集的不斷擴大，會面臨各種問題與挑戰，在eBay HDFS叢集演進方面，2019年之前是獨立叢集模式，隨著資料量的增長，在2019年引入Viewfs Federation方案，在2020年遇到了NameNode單點瓶頸問題，我們做了很多叢集效能優化，拆分更多Federation叢集，在2021年，RBF方案逐步取代Viewfs Federation方式。

　　在單叢集模式時，初始HDFS架構模式是非常簡單的。上面是Namespace層，下面是BlockStorage層，各個叢集相互獨立，在資料量少時，這種部署模式是沒有問題的。

　　HDFS內部結構設計如下：HDFS有三副本的機制，通過將三個副本分佈在兩個Rack上。

　　隨著資料量的不斷增長，HDFS叢集面臨的挑戰也越來越大，如：持續增長的資料儲存壓力，包括檔案資料和後設資料；NameNode服務的單點效能瓶頸；多叢集的運維管理，資料管理。

　　在HDFS效能優化方面，我們做了很多嘗試，如：

　　減少HDFS繁重API操作影響：Balancer從Standby NameNode獲取blocks操作；Delete操作按照batch size執行的限制；ListStatus操作忽略block location的獲取；Snapshot操作拆分為多子目錄的管理。

　　非同步化RPC response ：RPC的response階段需要做加密操作，會造成一定的效能損耗，將此過程進行非同步化地處理來提前釋放NameNode的Handler資源(相關JIRA: HDFS-15486)。

　　NN鎖優化處理：冗餘目錄鎖的去除；SetTimes操作寫鎖轉讀鎖；ReadWrite callqueue實現(相關JIRA: HDFS-15553)。

　　接下來，我們從單叢集模式向多叢集Federation模式進行了演變。基於Viewfs的Federation模式。但是在Federation模式下，我們需要能夠對資料進行快速的遷移，這裡我們使用的是fastcopy的方式來做。

　　我們基於Fastcopy的資料遷移流程如下：1，收回目錄許可權；2，關閉open中的檔案；3，使用Fastcopy進行資料的遷移；4，如果3步驟失敗，進行retry；5，恢復許可權；6，更新mount table資訊。

　　在資料遷移時，資料量是非常大的，分享一下Fastcopy原理：1，Client向源NameNode查詢檔案block資訊；2，在目標NameNode上建立相應檔案，block資訊；3，傳送copy block請求到block所屬DataNode；4，DataNode建立block，hard link到源block檔案；5，彙報block到目標NameNode。這就完成了Fastcopy的過程。

　　只靠Fastcopy還不夠，還需要將Fastcopy功能整合進DistCp工具裡。我們進一步對DistCp進行了改進優化，包括：統一化大檔案小檔案的長度，避免出現長尾任務影響；目錄ACL preserve操作的前置；DistCp支援whitelist/exclude list的拷貝；DistCp job的引數調優。這樣的結果就使效能提升近7倍。

　　在叢集RPC流量遷移方面，我們是如何做的呢？首先分析使用者資料訪問行為，主要檢查是否有rename操作的行為；其次將Fastcopy資料從源cluster到目標cluster，最後使用者重定向到新cluster進行資料的訪問。

　　Viewfs Federation也不是完美的方式，它存在兩大問題：

　　第一，維護成本高。隨著Federation叢集變多，Viewfs的更新維護成本過高，需要在每個client端做更新。

　　第二，對客戶端不透明，Viewfs對客戶端不透明，涉及到底層資料的遷移需要客戶端的調整。

　　接下來，我們從多叢集Federation模式向基於Router的Federation模式的演變。

　　HDFS Router-based Federation架構如下：

　　以下是RBF請求處理的過程：

　　RBF架構模式的優勢如下：

　　第一，無狀態的服務，cloud-native化部署，方便進行橫向擴充套件；

　　第二，Federation路徑更新對使用者完全透明，使用者無需進行任何更新；

　　第三，可基於RBF架構做資料split拆分的方案。

　　RBF的功能特性如下：

　　eBay針對RBF進行了很多優化，在RBF的平滑部署方面，我們提高了Viewfs到RBF的相容性支援，同時針對YARN RM Security模式補token邏輯的改造。

　　在RBF的效能改造方面，我們把Router服務支援更大的RPC吞吐量，解決Router內部的連線複用問題，去掉Router和NameNode之間的Sasl加密操作；Router支援客戶端ip地址，clientId的保留，不會影響到任務data locality的讀寫；多掛載點模式下，moveToTrash檔案刪除問題的解決。

　　以下是Viewfs到RBF的相容性改造：

　　在RBF補token改造方面，主要有五步：

　　1，Client從NameNode獲取token；2，Client提交Job到RM（攜帶token）；3，RM額外向Router獲取Router token，隨後token通過任務排程下發到work node上；4，Work node上跑的任務通過token來做HDFS認證，以此進行HDFS資料和Router服務的訪問；5，Job執行結束，RM進行token的刪除操作。

　　關於RBF的未來展望

　　我們希望在RBF模式上做更多的內容，如：RBF非同步化RPC處理來進一步提升RPC吞吐量；基於RBF做更為自動化的資料split拆分；基於RBF模式下做Tiered Storage，提升叢集儲存的效率；RBF對底層namespace間RPC處理的隔離。