HDFS Federation在美团点评的应用与改进
一、背景
2015年10月，經(jīng)過(guò)一段時(shí)間的優(yōu)化與改進(jìn)，美團(tuán)點(diǎn)評(píng)HDFS集群穩(wěn)定性和性能有顯著提升，保證了業(yè)務(wù)數(shù)據(jù)存儲(chǔ)量和計(jì)算量爆發(fā)式增長(zhǎng)下的存儲(chǔ)服務(wù)質(zhì)量；然而，隨著集群規(guī)模的發(fā)展，單組NameNode組成的集群也產(chǎn)生了新的瓶頸： * 擴(kuò)展性：根據(jù)HDFS NameNode內(nèi)存全景和HDFS NameNode內(nèi)存詳解這兩篇文章的說(shuō)明可知，NameNode內(nèi)存使用和元數(shù)據(jù)量正相關(guān)。180GB堆內(nèi)存配置下，元數(shù)據(jù)量紅線約為7億，而隨著集群規(guī)模和業(yè)務(wù)的發(fā)展，即使經(jīng)過(guò)小文件合并與數(shù)據(jù)壓縮，仍然無(wú)法阻止元數(shù)據(jù)量逐漸接近紅線。 * 可用性：隨著元數(shù)據(jù)量越來(lái)越接近7億，CMS GC頻率也越來(lái)越高，期間也曾發(fā)生過(guò)一次在CMS GC過(guò)程中由于大文件getBlocklocation并發(fā)過(guò)高導(dǎo)致的promotion fail。 * 性能：隨著業(yè)務(wù)的發(fā)展，集群規(guī)模接近2000臺(tái)，NameNode響應(yīng)的RPC QPS也在逐漸提高。越來(lái)越高并發(fā)的讀寫，與NameNode的粗粒度元數(shù)據(jù)鎖，使NameNode RPC響應(yīng)延遲和平均RPC隊(duì)列長(zhǎng)度都在慢慢提高。 * 隔離性：由于NameNode沒(méi)有隔離性設(shè)計(jì)，單一對(duì)NameNode負(fù)載過(guò)高的應(yīng)用，會(huì)影響到整個(gè)集群的服務(wù)能力。
HDFS Federation是Hadoop-0.23.0中為解決HDFS單點(diǎn)故障而提出的NameNode水平擴(kuò)展方案。該方案可以為HDFS服務(wù)創(chuàng)建多個(gè)namespace，從而提高集群的擴(kuò)展性和隔離性。基于以上背景，我們?cè)?015年10月發(fā)起了HDFS Federation改造項(xiàng)目。
HDFS Federation是以客戶端為核心的解決方案，對(duì)Hadoop客戶端影響較大，在落地應(yīng)用時(shí)也有較多的限制，對(duì)上層應(yīng)用模式有較強(qiáng)的依賴。本文分享了在此次改造的過(guò)程中，基于美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)背景，我們對(duì)HDFS Federation本身做出的改進(jìn)和對(duì)拆分過(guò)程的流程化處理，希望能為需要落地HDFS Federation的同學(xué)提供一個(gè)參考。
二、上層應(yīng)用與業(yè)務(wù)
基礎(chǔ)架構(gòu)方面，美團(tuán)點(diǎn)評(píng)Hadoop版本為2.4.1，使用了Kerberos作為認(rèn)證支持。相關(guān)技術(shù)棧中，Spark應(yīng)用版本包含1.1、1.3、1.4、1.5，同時(shí)使用了Zeppelin作為Spark Notebook的開發(fā)工具。在查詢引擎方面Hive有0.13和1.2兩個(gè)版本，同時(shí)重度依賴Presto和Kylin，除此之外，也對(duì)DMLC提供了平臺(tái)性支持。
工具鏈建設(shè)方面，基于Hadoop生態(tài)，數(shù)據(jù)平臺(tái)組自研了各類平臺(tái)工具，其中受Federation影響的部分工具有： * 數(shù)倉(cāng)管理：滿足各類Hive表的DDL需求，同時(shí)支持UDF和文件上傳建表。 * 原始數(shù)據(jù)接入：支持日志抓取和MySQL數(shù)據(jù)接入數(shù)據(jù)倉(cāng)庫(kù)。 * 非結(jié)構(gòu)數(shù)據(jù)開發(fā)：支持作業(yè)托管，提供MR/Spark作業(yè)編譯、管理、測(cè)試、部署一站式服務(wù)。 * 數(shù)倉(cāng)開發(fā)：支持ETL的一站式開發(fā)和管理，同時(shí)在任務(wù)狀態(tài)、診斷、SLA保證方面也有強(qiáng)力的支持；針對(duì)流程測(cè)試以及數(shù)據(jù)回收進(jìn)行了隔離，使用統(tǒng)一的test.db和backup.db。 * 調(diào)度系統(tǒng)：自研的調(diào)度系統(tǒng)支撐了每天數(shù)萬(wàn)個(gè)調(diào)度作業(yè)，準(zhǔn)確的處理作業(yè)間的強(qiáng)弱依賴關(guān)系，有效的保證了按天數(shù)據(jù)生產(chǎn)。 * 查詢平臺(tái)：統(tǒng)一了Hive和Presto的查詢?nèi)肟凇?/p>
自研的數(shù)據(jù)平臺(tái)基本覆蓋了90%的數(shù)據(jù)開發(fā)需求，一方面有效的控制了Hadoop客戶端的數(shù)量，收緊了用戶入口，對(duì)于發(fā)放的客戶端，配合Kerberos，也具有很高的掌控力，另一方面實(shí)現(xiàn)了對(duì)用戶行為的源碼級(jí)掌控力。
數(shù)據(jù)開發(fā)方面，美團(tuán)點(diǎn)評(píng)業(yè)務(wù)一直持續(xù)著爆發(fā)式增長(zhǎng)，整體集群規(guī)模和數(shù)據(jù)生產(chǎn)流程增量每年都接近double。業(yè)務(wù)發(fā)展也推動(dòng)了組織結(jié)構(gòu)的發(fā)展，進(jìn)而也影響到了相應(yīng)的大數(shù)據(jù)資產(chǎn)： * 一個(gè)Hadoop賬號(hào)可能經(jīng)歷過(guò)多個(gè)業(yè)務(wù)線，用戶應(yīng)用中，對(duì)其他Hadoop賬號(hào)的數(shù)據(jù)進(jìn)行讀寫、move較為常見(jiàn)，對(duì)這類行為也沒(méi)有進(jìn)行過(guò)梳理和限制。 * 完成平臺(tái)接入后，對(duì)生產(chǎn)流程管理的規(guī)范較多，但對(duì)用戶代碼的規(guī)范較少，用戶代碼風(fēng)格多樣。
三、應(yīng)用與改進(jìn)
3.1 Federation的局限性
在解決NameNode擴(kuò)展能力方面，社區(qū)雖然提供了Federation，但這個(gè)方案有很強(qiáng)的局限性： 1. HDFS路徑Scheme需要變?yōu)閂iewFs，ViewFs路徑和其他Scheme路徑互不兼容，比如DistributedFileSystem無(wú)法處理ViewFs為Scheme的路徑，也就是說(shuō)如果啟用，則需要將Hive meta、ETL腳本、MR/Spark作業(yè)中的所有HDFS路徑均的scheme改為viewfs。 2. 如果將fs.defaultFS的配置從hdfs://ns1/變?yōu)関iewfs://ns/，將導(dǎo)致舊代碼異常，通過(guò)腳本對(duì)用戶上萬(wàn)個(gè)源碼文件的分析，常用的HDFS路徑風(fēng)格多樣，包括hdfs:///user、hdfs://ns1/user、/user等，如果fs.defaultFS有所更改，hdfs:///user將會(huì)由于缺失nameservice變?yōu)榉欠℉DFS路徑。 3. ViewFs路徑的掛載方式與Linux有所區(qū)別： * 如果一個(gè)路徑聲明了掛載，那么其同級(jí)目錄都需要進(jìn)行掛載，比如/user/path_one掛載到了hdfs://ns1/user/path_one上，那么/user/path_two也需要在配置中聲明其掛載到哪個(gè)具體的路徑上。 * 如果一個(gè)路徑聲明了掛載，那么其子路徑不能再聲明掛載，比如/user/path_one掛載到了hdfs://ns1/user/path_one上，那么其子路徑也自動(dòng)并且必須掛載到hdfs://ns1/user/path_one上。 4. 一次路徑請(qǐng)求不能跨多個(gè)掛載點(diǎn)： * 由于HDFS客戶端原有的機(jī)制，一個(gè)DFSClient只對(duì)應(yīng)一個(gè)nameservice，所以一次路徑處理不能轉(zhuǎn)為多個(gè)nameservice的多次RPC。 * 對(duì)于跨掛載點(diǎn)的讀操作，只根據(jù)掛載配置返回假結(jié)果。 * 對(duì)于跨掛載點(diǎn)的rename（move路徑）操作，會(huì)拋出異常。 5. Federation架構(gòu)中，NameNode相互獨(dú)立，NameNode元數(shù)據(jù)、DataNode中塊文件都沒(méi)有進(jìn)行共享，如果要進(jìn)行拆分，需要使用DistCp，將數(shù)據(jù)完整的拷貝一份，存儲(chǔ)成本較高；數(shù)據(jù)先被讀出再寫入三備份的過(guò)程，也導(dǎo)致了拷貝效率的低效。 6. Federation是改造了客戶端的解決方案，重度依賴客戶端行為。方案中NameNode相互獨(dú)立，對(duì)Federation沒(méi)有感知。另外HDFS為Scheme的路徑，不受Federation掛載點(diǎn)影響，也就是說(shuō)如果對(duì)路徑進(jìn)行了namespace拆分后，如果因?yàn)榇a中的路徑或客戶端配置沒(méi)有及時(shí)更新，導(dǎo)致流程數(shù)據(jù)寫入老數(shù)據(jù)路徑，那么請(qǐng)求依然是合法但不符合預(yù)期的。
對(duì)其中一些名詞的解釋：
|
3.2 局限性帶來(lái)的問(wèn)題和解決
3.2.1 Scheme兼容性問(wèn)題
Scheme的兼容問(wèn)題要求在上線時(shí)全量替換業(yè)務(wù)方代碼中的路徑，雖然對(duì)業(yè)務(wù)方大多數(shù)源碼具有掌控力，但是由于不可灰度帶來(lái)的全量修改帶來(lái)的測(cè)試、上線、修復(fù)工作的成本，全量操作帶來(lái)的運(yùn)維時(shí)間，以及對(duì)數(shù)據(jù)生產(chǎn)穩(wěn)定性的影響都是不能接受的。為此，以能灰度啟用Federation特性為目標(biāo)，對(duì)HDFS客戶端進(jìn)行了修改： * 增加了ViewFs和HDFS兩種Scheme路徑的兼容性： * 修改了org.apache.hadoop.fs.FileSystem.fixRelativePart(Path)，該函數(shù)在DistributedFileSystem各類請(qǐng)求處理中均有調(diào)用，原本用于處理相對(duì)路徑，而ViewFileSystem不會(huì)調(diào)用。在這里，如果遇到了ViewFs為Scheme的路徑，則利用ViewFileSystem中的掛載信息返回真正的HDFS路徑。 * 修改了org.apache.hadoop.fs.viewfs.ViewFileSystem.getUriPath(Path)，該函數(shù)在ViewFileSystem各類請(qǐng)求處理中均有調(diào)用，原本用作判斷路徑Scheme為ViewFs，同時(shí)處理相對(duì)路徑。一方面，由于Federation的掛載配置中，只有通過(guò)掛載點(diǎn)查詢真實(shí)路徑的數(shù)據(jù)結(jié)構(gòu)，逆向查詢比較復(fù)雜，改動(dòng)也比較大，另一方面，從運(yùn)營(yíng)角度看我們也不希望維持非常復(fù)雜的掛載配置。所以在這里，做了一個(gè)限定，對(duì)于HSFS為Scheme的路徑與其在Federation的掛載點(diǎn)路徑相同，所以在此函數(shù)中如果遇到了HDFS為Scheme的路徑，直接使用org.apache.hadoop.fs.Path.getPathWithoutSchemeAndAuthority(Path)去掉Scheme即可。 * fs.defaultFS變更會(huì)對(duì)原有代碼帶來(lái)影響，但是將其配置為ViewFs為Scheme的路徑才能使HDFS Scheme的應(yīng)用逐漸收斂，因此，我們?cè)黾恿擞糜谥付J(rèn)namespace的配置fs.defaultNS，使hdfs:///user這樣即使沒(méi)有提供Authority的路徑也能路由到正確的NameNode。
針對(duì)Scheme局限性的改造，雖然提高了兼容性，使方案能夠進(jìn)行灰度，但卻使DistributedFileSystem和ViewFileSystem耦合，又增加了一條ViewFileSystem掛載限制，因此只適合在過(guò)度期間應(yīng)用。
3.2.2 掛載配置限制
ViewFs的掛載方式與Linux有所區(qū)別，如果完全繼承現(xiàn)有HDFS不變，則需要非常多的掛在配置項(xiàng)，并且后續(xù)每次增加Hive庫(kù)、用戶目錄，初期我們使用了運(yùn)營(yíng)手段解決了這個(gè)問(wèn)題： 1. 將遷移路徑放到獨(dú)立的目錄下，比如/user/hivedata/xx.db，遷移到/ns2/hivedata/xx.db，這樣掛載聲明則不會(huì)太過(guò)復(fù)雜。 2. 由于用戶組路徑大都應(yīng)用于MR、Spark作業(yè)中，修改路徑需要重新編譯，因此初期應(yīng)用時(shí)，只對(duì)Hive庫(kù)路徑。 3. 由于跨namespace不能進(jìn)行rename，所以分析NameNode審計(jì)日志，得到Hive庫(kù)路徑和用戶組路徑?jīng)]有rename關(guān)系的庫(kù)，只對(duì)這些庫(kù)進(jìn)行遷移。
通過(guò)以上三種手段，對(duì)于ETL流程這種不需要編譯的代碼，可以直接替換，對(duì)于MR、Spark作業(yè)來(lái)說(shuō)推動(dòng)修改的成本也有所降低。
為了進(jìn)一步降低后續(xù)拆分成本，我們?cè)贓TL和作業(yè)開發(fā)兩個(gè)方面提供并推廣了根據(jù)庫(kù)表信息從Hive meta中取得庫(kù)表HDFS路徑的工具，減少了代碼中對(duì)庫(kù)表路徑的硬編碼。
以上的運(yùn)維手段，能滿足美團(tuán)側(cè)常規(guī)的拆分需求，但是隨著點(diǎn)評(píng)側(cè)數(shù)據(jù)融合，點(diǎn)評(píng)側(cè)數(shù)據(jù)也作為整體集群的一個(gè)namespace加入進(jìn)來(lái)。然而，我們對(duì)點(diǎn)評(píng)側(cè)平臺(tái)的掌控力沒(méi)有深入到源碼級(jí)別，因此無(wú)法統(tǒng)一推動(dòng)更改HDFS路徑。如果不對(duì)掛載邏輯進(jìn)行修改，在合并重復(fù)路徑時(shí)，需要將美團(tuán)側(cè)/user路徑合并到點(diǎn)評(píng)側(cè)/user路徑中，但是由于跨namespace無(wú)法進(jìn)行rename，勢(shì)必會(huì)造成用戶作業(yè)的失敗。因此，我們對(duì)掛載邏輯進(jìn)行了修改，使其同Linux的掛載方式相同。
3.2.3 同namespace，不同掛載點(diǎn)不能rename
業(yè)務(wù)方很多Hive庫(kù)表數(shù)據(jù)會(huì)先生成在測(cè)試庫(kù)表或用戶目錄中，驗(yàn)證完成后將數(shù)據(jù)加載到對(duì)應(yīng)時(shí)間分區(qū)中。在掛載配置中，業(yè)務(wù)方Hive庫(kù)、Hive測(cè)試庫(kù)、用戶組目錄一般不會(huì)掛載到同一目錄下，即使三者在同一namespace下，由于不同掛載點(diǎn)間不能rename的限制，也無(wú)法進(jìn)行加載。在源碼分析的過(guò)程中，發(fā)現(xiàn)以下注釋：
// Note we compare the URIs. the URIs include the link targets. // hence we allow renames across mount links as long as the mount links // point to the same target. if (!resSrc.targetFileSystem.getUri().equals(resDst.targetFileSystem.getUri())) {throw new IOException("Renames across Mount points not supported"); } */ // // Alternate 3 : renames ONLY within the the same mount links. // if (resSrc.targetFileSystem !=resDst.targetFileSystem) {throw new IOException("Renames across Mount points not supported"); }可以發(fā)現(xiàn)社區(qū)是有考慮相同namespace路徑可以進(jìn)行rename操作的（注釋掉的原因沒(méi)有找到），因此，我們將這段邏輯打開，替換掉了“renames ONLY within the the same mount links”。
3.2.4 存儲(chǔ)成本與拷貝效率問(wèn)題
使用Federation方案時(shí)，集群節(jié)點(diǎn)規(guī)模為2000多臺(tái)，元數(shù)據(jù)已達(dá)6億，存儲(chǔ)使用已近80%。按照規(guī)劃，存儲(chǔ)容量將不足以支撐全部待遷移數(shù)據(jù)，但是拆成多次操作，周期和運(yùn)維成本都比較高，因此我們開始調(diào)研FastCopy。
FastCopy是Facebook開源的數(shù)據(jù)拷貝方案，它通過(guò)以下方式在不增加存儲(chǔ)成本的情況下對(duì)數(shù)據(jù)進(jìn)行拷貝： 1. 通過(guò)getBlockLocation獲取源文件塊分布。 2. 通過(guò)ClientProtocol（HDFS包中的接口，下同）創(chuàng)建目標(biāo)文件。 3. 通過(guò)ClientProtocol addBlock，在參數(shù)中，指定源塊分布作為favoredNodes，常規(guī)情況下NameNode會(huì)優(yōu)先選擇favoredNodes中的DataNode作為塊的保存位置，特殊情況下（比如存儲(chǔ)空間不足，DataNode負(fù)載過(guò)高等）也有可能返回不同位置。 4. 整理源和目標(biāo)塊位置，使相同DataNode的位置能一一對(duì)應(yīng)。 5. 通過(guò)ClientDatanodeProtocol向源DataNode發(fā)送copyBlock請(qǐng)求。 6. 在DataNode中，如果copyBlock請(qǐng)求中的源和目標(biāo)相同，則通過(guò)在Linux文件系統(tǒng)中建立硬鏈的方式完成拷貝，否則通過(guò)原有邏輯完成拷貝。
但是，在計(jì)劃合入時(shí)，該方案也有自身的問(wèn)題：
- 社區(qū)path為HDFS-2139，一直處于未合入狀態(tài)，且當(dāng)時(shí)Patch內(nèi)容相對(duì)Facebook的方案來(lái)說(shuō)，部分細(xì)節(jié)沒(méi)有考慮，例如文件lease，無(wú)法構(gòu)造硬鏈時(shí)的降級(jí)，DFS Used的統(tǒng)計(jì)問(wèn)題等。
- Facebook的源碼相對(duì)成熟，但其源碼基于0.20（facebookarchive/hadoop-20），已有四年沒(méi)有更新，很多源碼發(fā)生變化，DFS Used的統(tǒng)計(jì)問(wèn)題也沒(méi)有解決。
- 雖然Facebook將FastCopy合入DistCp，但也有部分缺陷：
- 每個(gè)路徑生成一個(gè)mapper，每個(gè)mapper只處理一個(gè)路徑，如果目錄層次過(guò)高，容易導(dǎo)致數(shù)據(jù)傾斜，如果目錄層次太低，容易產(chǎn)生過(guò)多mapper。
- 只對(duì)遷移路徑進(jìn)行屬主同步，其父目錄沒(méi)有處理。
- 與DistCp耦合定制比較復(fù)雜。
所以，綜合以上內(nèi)容，我們完善了HDFS-2139，并更新了issue，在合入Facebook實(shí)現(xiàn)的基礎(chǔ)上解決了DFS Used的統(tǒng)計(jì)問(wèn)題；除了這個(gè)Patch，我們也實(shí)現(xiàn)了獨(dú)立的FastCopy MR作業(yè)，解決了上述問(wèn)題。最終，在拆分時(shí)15小時(shí)完成14+PB數(shù)據(jù)拷貝，保證了方案的可行性。
另外需要注意的是，對(duì)于HDFS來(lái)說(shuō)，無(wú)法感知哪個(gè)塊是通過(guò)硬鏈構(gòu)造的，因此，一旦源和目標(biāo)文件同時(shí)存在時(shí)，開啟balancer，會(huì)因?yàn)閴K的遷移導(dǎo)致存儲(chǔ)使用的增加。因此，遷移期間，一般建議暫停相關(guān)namespace的balancer。
3.2.5 重度依賴客戶端
基于以上幾點(diǎn)改進(jìn)，雖然降低了拆分成本和兼容性，使Federation的應(yīng)用成為可迭代方案，但是如果沒(méi)有對(duì)客戶端強(qiáng)大的掌控力，客戶端實(shí)例不能完全更新，HDFS路徑硬編碼不能得到徹底梳理，反而會(huì)造成數(shù)據(jù)生產(chǎn)方面的混亂，成為此方案的掣肘。
經(jīng)過(guò)美團(tuán)側(cè)數(shù)據(jù)平臺(tái)的多年運(yùn)營(yíng)，對(duì)客戶端以及業(yè)務(wù)代碼有非常強(qiáng)的掌控力，有效避免了上述問(wèn)題的發(fā)生。
3.3 計(jì)算和查詢引擎的問(wèn)題和解決
一方面，雖然Federation已出現(xiàn)了多年，但Hive、Spark等上層應(yīng)用對(duì)Federation的支持仍然存在問(wèn)題，另一方面，隨著應(yīng)用的逐漸加深，雖然有些問(wèn)題并不是代碼bug，但在美團(tuán)點(diǎn)評(píng)的應(yīng)用場(chǎng)景下，仍然產(chǎn)生了一定問(wèn)題。我們針對(duì)這些問(wèn)題，進(jìn)行了探索和改進(jìn)。
3.3.1 安全問(wèn)題
安全方面，計(jì)算引擎（包括MapReduce和Spark）在提交作業(yè)時(shí)，會(huì)向NameNode發(fā)送RPC，獲取HDFS Token。在ViewFileSystem中，會(huì)向所有namespace串行的申請(qǐng)Token，如果某個(gè)namespace的NameNode負(fù)載很高，或者發(fā)生故障，則任務(wù)無(wú)法提交，YARN的ResourceManager在renew Token時(shí)，也會(huì)受此影響。隨著美團(tuán)點(diǎn)評(píng)的發(fā)展YARN作業(yè)并發(fā)量也在逐漸提高，保存在HDFS上的YARN log由于QPS過(guò)高，被拆分為獨(dú)立的namespace。但由于其并發(fā)和YARN container并發(fā)相同，NameNode讀寫壓力還是非常大，經(jīng)常導(dǎo)致其RPC隊(duì)列打滿，請(qǐng)求超時(shí)，進(jìn)而影響了作業(yè)的提交。針對(duì)此問(wèn)題，我們做出了一下改進(jìn)： * container日志由NodeManager通過(guò)impersonate寫入HDFS，這樣客戶端在提交Job時(shí)，就不需要YARN log所在namespace的Token。 * ViewFileSystem在獲取Token時(shí)，增加了參數(shù)，用于指定不獲取哪些namespace的Token。 * 由于作業(yè)并不總是需要所有namespace中的數(shù)據(jù)，因此當(dāng)單個(gè)namespace故障時(shí)，不應(yīng)當(dāng)影響其他namespace數(shù)據(jù)的讀寫，否則會(huì)降低整個(gè)集群的分區(qū)容忍性和可用性，ViewFileSystem在獲取Token時(shí)，即使失敗，也不影響作業(yè)提交，而是在真正訪問(wèn)數(shù)據(jù)時(shí)作業(yè)失敗，這樣在不需要的Token獲取失敗時(shí)，不影響作業(yè)的運(yùn)行。
另外，客戶端獲取到的Token會(huì)以namespace為key，保存在一個(gè)自定義數(shù)據(jù)結(jié)構(gòu)中（Credentials）。ResourceManager renew時(shí)，遍歷這個(gè)數(shù)據(jù)結(jié)構(gòu)。而NodeManager在拉取JAR包時(shí)，根據(jù)本地配置中的namespace名去該數(shù)據(jù)結(jié)構(gòu)中獲取對(duì)應(yīng)Token。因此需要注意的是，雖然namespace配置和服務(wù)端不同不影響普通HDFS讀寫，但提交作業(yè)所使用的namespace配置需要與NodeManager相同，至少會(huì)用到的namespace配置需要是一致的。
3.3.2 已存在Patch問(wèn)題
- https://issues.apache.org/jira/browse/HADOOP-12253
- https://issues.apache.org/jira/browse/TEZ-2600
- https://issues.apache.org/jira/browse/HIVE-11364
- https://issues.apache.org/jira/browse/HIVE-10790
- https://issues.apache.org/jira/browse/HIVE-6152
- https://issues.apache.org/jira/browse/HIVE-11920
- https://issues.apache.org/jira/browse/HIVE-7529
3.3.3 其他問(wèn)題
- Hive create table .. as .. 會(huì)導(dǎo)致臨時(shí)文件所在目錄和表目錄不在同一namespace，導(dǎo)致move結(jié)果失敗，目前已修復(fù)，思路同HIVE-6152，將臨時(shí)文件生成在表目錄中。
- Hive表的元數(shù)據(jù)中，SERDEPROPERTIES中，可能會(huì)存在對(duì)HDFS路徑的依賴，在梳理路徑硬編碼時(shí)，容易忽略掉。
- Spark 1.1在啟用viewfs時(shí)，會(huì)產(chǎn)生不兼容問(wèn)題。
- 開源分布式機(jī)器學(xué)習(xí)項(xiàng)目DMLC目前也尚不兼容ViewFs。
四、拆分流程與自動(dòng)化
隨著namespace拆分經(jīng)驗(yàn)的積累，其流程也逐漸清晰和明確： 1. 當(dāng)namespace的NameNode逐漸接近瓶頸（包括RPC和元數(shù)據(jù)量）時(shí)，對(duì)Hadoop用戶對(duì)應(yīng)的用戶組目錄和Hive庫(kù)目錄進(jìn)行分析，得出元數(shù)據(jù)量（通過(guò)分析fsimage）和一天內(nèi)RPC量（通過(guò)分析審計(jì)日志），進(jìn)而得出需要拆分的用戶數(shù)據(jù)。 2. 對(duì)于需要拆分的數(shù)據(jù)，分析其和不需要拆分?jǐn)?shù)據(jù)的rename關(guān)系，如果存在rename關(guān)系，則需要重新選擇拆分?jǐn)?shù)據(jù)。 3. 如果需要，則搭建新namespace環(huán)境。 4. 關(guān)閉相關(guān)namespace balancer。 5. 根據(jù)fsimage，分析出待拆分路徑元數(shù)據(jù)分布，得出一個(gè)路徑列表，使列表中每個(gè)路徑下的文件塊數(shù)基本接近。 6. 基于第四步的結(jié)果進(jìn)行首輪拷貝，首輪拷貝中針對(duì)不需要比較驗(yàn)證的情況作出了優(yōu)化：FastCopy MR工具會(huì)遞歸的拷貝路徑，如果目標(biāo)路徑已存在說(shuō)明之前已拷貝成功過(guò)，則不進(jìn)行拷貝。 7. 之后進(jìn)行多輪補(bǔ)充拷貝：通過(guò)ls -r得到文件和目錄列表；拷貝過(guò)程中開啟-delete -update，非遞歸的進(jìn)行檢測(cè)與拷貝，這樣對(duì)于源目錄有更新的文件和目錄會(huì)進(jìn)行覆蓋（包括權(quán)限和屬主的更新），源目錄新增的目錄和文件會(huì)進(jìn)行拷貝，源目錄刪除的文件和目錄會(huì)進(jìn)行刪除；這樣，可以會(huì)每一層的目錄進(jìn)行檢測(cè)，可以同步目錄權(quán)限和屬主發(fā)生的變化，同時(shí)也不會(huì)產(chǎn)生較大的數(shù)據(jù)傾斜。 8. 準(zhǔn)備好新掛載配置，找一個(gè)非工作時(shí)間，進(jìn)行最終一輪的操作： a. 禁止源目錄的權(quán)限（FastCopy使用hdfs身份運(yùn)行不受影響）。 b. 進(jìn)行最后一輪補(bǔ)充拷貝。 c. 由于數(shù)據(jù)大多數(shù)情況下基于硬鏈進(jìn)行拷貝，所以存在文件長(zhǎng)度相同，但內(nèi)容有問(wèn)題的可能性極低，拷貝完成后，可以通過(guò)du路徑，校驗(yàn)并逐漸找到數(shù)據(jù)長(zhǎng)度不一致的文件，進(jìn)行重考。 d. 對(duì)客戶端分發(fā)新掛載配置。 e. 對(duì)NodeManager分發(fā) 新掛載配置，并進(jìn)行decommission，重啟（YARN已支持recovery）。 f. 更新Hive meta。 g. 開放目標(biāo)目錄權(quán)限。 9. 觀察一周，如果沒(méi)有問(wèn)題則刪除源目錄。 10. 重啟balancer。
以上是已經(jīng)固定下來(lái)的步驟，其中第1、2、5、6、7步，第8步中的a~c是可以進(jìn)行自動(dòng)化的，這也是后續(xù)工作過(guò)程中，有待完善的部分。
五、總結(jié)
HDFS Federation作為以客戶端配置為核心的NameNode橫向擴(kuò)容解決方案，對(duì)業(yè)務(wù)背景有較強(qiáng)的依賴，另一方面方案本身也有較多的局限性。本文以美團(tuán)點(diǎn)評(píng)實(shí)際應(yīng)用場(chǎng)景出發(fā)，介紹了方案局限性在業(yè)務(wù)背景下的影響，分享了對(duì)局限性的解決和實(shí)施經(jīng)驗(yàn)。對(duì)HDFS Federation應(yīng)用到已運(yùn)營(yíng)較長(zhǎng)時(shí)間的大規(guī)模HDFS集群有一定的借鑒意義。
六 參考文獻(xiàn)
- HDFS NameNode內(nèi)存全景
- HDFS NameNode內(nèi)存詳解
- HDFS Federation
- HDFS scalability with multiple namenodes
- AN INTRODUCTION TO HDFS FEDERATION
- HDFS Federation設(shè)計(jì)動(dòng)機(jī)與基本原理
七 作者簡(jiǎn)介
俊宏，美團(tuán)點(diǎn)評(píng)離線存儲(chǔ)團(tuán)隊(duì)高級(jí)開發(fā)工程師，2013年畢業(yè)于哈爾濱工程大學(xué)，2015年加入美團(tuán)，負(fù)責(zé)美團(tuán)點(diǎn)評(píng)HDFS、HBase服務(wù)的開發(fā)和運(yùn)維，HBase服務(wù)負(fù)責(zé)人。
美團(tuán)點(diǎn)評(píng)離線團(tuán)隊(duì)，深耕Hadoop生態(tài)中HDFS、HBase、CarbonData、Alluxio等泛存儲(chǔ)領(lǐng)域，尤其在HDFS、HBase方面有大量的源碼和架構(gòu)改造經(jīng)驗(yàn)，致力于為美團(tuán)點(diǎn)評(píng)提供穩(wěn)定、高效、易用的大數(shù)據(jù)存儲(chǔ)服務(wù)。
最后發(fā)個(gè)廣告，美團(tuán)點(diǎn)評(píng)數(shù)據(jù)平臺(tái)中心長(zhǎng)期招聘離線計(jì)算平臺(tái)、實(shí)時(shí)計(jì)算平臺(tái)、數(shù)據(jù)平臺(tái)工具鏈與服務(wù)等方向的技術(shù)專家，有興趣的同學(xué)可以發(fā)送簡(jiǎn)歷到liujunhong02#meituan.com。
總結(jié)
以上是生活随笔為你收集整理的HDFS Federation在美团点评的应用与改进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Redis系列教程(六)：Redis缓存
- 下一篇： 【萌味】小夕说,不了解动态空间增长的程序