據(jù)IDC預(yù)測(cè)，到2021年，至少50%的全球GDP將由數(shù)字化驅(qū)動(dòng)。面對(duì)海量數(shù)據(jù)，企業(yè)亟需通過更加現(xiàn)代化、敏捷、高性能的IT基礎(chǔ)設(shè)施來推進(jìn)業(yè)務(wù)持續(xù)發(fā)展。
當(dāng)今世界，只有很少的數(shù)據(jù)得到了分析，還有巨大的待開發(fā)潛能，在高達(dá)3000億美元的以數(shù)據(jù)為驅(qū)動(dòng)的市場(chǎng)中，中國(guó)在人工智能、物聯(lián)網(wǎng)和5G等技術(shù)方面已經(jīng)逐漸成熟，為中國(guó)數(shù)字經(jīng)濟(jì)蓬勃發(fā)展奠定了基礎(chǔ)，而那些尚未被充分利用的數(shù)據(jù)，就是新商業(yè)價(jià)值的關(guān)鍵元素。
01
數(shù)據(jù)湖的價(jià)值
數(shù)據(jù)湖支持以其本機(jī)或接近本機(jī)的格式存儲(chǔ)數(shù)據(jù)，從而為高技能的數(shù)據(jù)科學(xué)家和分析師提供了未完善的數(shù)據(jù)視圖。數(shù)據(jù)湖提供了一個(gè)沒有折衷的環(huán)境，以及相應(yīng)的記錄分析系統(tǒng)所共有的保證和利益，即語義一致性，治理和安全性。
因此，數(shù)據(jù)湖特別適合科學(xué)家對(duì)未知數(shù)據(jù)和未知問題的探索。很多暫時(shí)得不到分析的數(shù)據(jù)，可以暫時(shí)統(tǒng)一保存在數(shù)據(jù)湖里。
02
Hadoop是數(shù)據(jù)湖最常用的解決方案
Hadoop的一個(gè)主要優(yōu)勢(shì)是支持圍繞未知數(shù)據(jù)和未知問題的這些探索性用例。它在LDW（邏輯數(shù)據(jù)倉(cāng)庫(kù)）中扮演的角色在基于數(shù)據(jù)管理基礎(chǔ)設(shè)施模型的右上象限 - 未知數(shù)據(jù)領(lǐng)域和未知問題。由于Hadoop技術(shù)針對(duì)語義靈活性進(jìn)行了優(yōu)化，因此它可以與傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)倉(cāng)庫(kù)并列，從而實(shí)現(xiàn)更廣泛的數(shù)據(jù)類型，最終用戶和用例。
雖然現(xiàn)在Hadoop沒有前幾年那么熱，但是，它依然是數(shù)據(jù)湖最常用的解決方案。最近的Gartner研究數(shù)據(jù)表明，Hadoop的部署和需求仍然很大并且正在增長(zhǎng)。在最近的一項(xiàng)調(diào)查中，有235名受訪者表示，34％的受訪者目前正在使用Hadoop進(jìn)行數(shù)據(jù)和分析工作，另有55％的受訪者計(jì)劃在未來24個(gè)月內(nèi)進(jìn)行調(diào)查，總計(jì)達(dá)到89％。這是Gartner 2016年研究以來的需求最大幅度增加。
03
HDFS的局限
Apache Hadoop是一個(gè)高度可擴(kuò)展的系統(tǒng)，廣泛應(yīng)用于大數(shù)據(jù)存儲(chǔ)和分析。Hadoop分布式文件系統(tǒng)(HDFS)被設(shè)計(jì)成適合運(yùn)行在通用硬件上的分布式文件系統(tǒng)。
HDFS主要由三部分構(gòu)成：
NameNode：NameNode 上保存著整個(gè)HDFS的命名空間和數(shù)據(jù)塊映射關(guān)系。所有的元數(shù)據(jù)操作都將在NameNode中處理；
DataNode：DataNode將HDFS數(shù)據(jù)以文件的形式存儲(chǔ)在本地的文件系統(tǒng)中，它并不知道有關(guān)HDFS文件的信息；
DFSClient：HDFS的客戶端，在Hadoop文件系統(tǒng)中，它封裝了和HDFS其他實(shí)體的復(fù)雜交互關(guān)系，為應(yīng)用提供了一個(gè)標(biāo)準(zhǔn)的、簡(jiǎn)單的接口。
Hadoop為大數(shù)據(jù)分析帶來便利的同時(shí)，也面臨著一些挑戰(zhàn)：
1、Hadoop 的擴(kuò)展受限
NameNode是HDFS中的管理者，主要負(fù)責(zé)文件系統(tǒng)的命名空間、集群配置信息和數(shù)據(jù)塊的復(fù)制等。NameNode在內(nèi)存中保存文件系統(tǒng)中每個(gè)文件和每個(gè)數(shù)據(jù)塊的引用關(guān)系，也就是元數(shù)據(jù)。
在運(yùn)行時(shí)，HDFS中每個(gè)文件、目錄和數(shù)據(jù)塊的元數(shù)據(jù)信息（大約150字節(jié)）必須存儲(chǔ)在NameNode的內(nèi)存中。根據(jù)Cloudera的描述，默認(rèn)情況下，會(huì)為每一百萬個(gè)數(shù)據(jù)塊分配一個(gè)最大的堆空間1GB (但絕不小于1GB)。這導(dǎo)致實(shí)際限制了HDFS中可以存儲(chǔ)的對(duì)象數(shù)量，也就意味著對(duì)于一個(gè)擁有大量文件的超大集群來說，內(nèi)存將成為限制系統(tǒng)橫向擴(kuò)展的瓶頸。
同時(shí)，作為一個(gè)可擴(kuò)展的文件系統(tǒng)，單個(gè)集群中支持?jǐn)?shù)千個(gè)節(jié)點(diǎn)。在單個(gè)命名空間中DataNode可以擴(kuò)展的很好，但是NameNode并不能在單個(gè)命名空間進(jìn)行橫向擴(kuò)展。通常情況下，HDFS集群的性能瓶頸在單個(gè)NameNode上。
在Hadoop 2.x發(fā)行版中引入了聯(lián)邦HDFS功能，允許系統(tǒng)通過添加多個(gè)NameNode來實(shí)現(xiàn)擴(kuò)展，其中每個(gè)NameNode管理文件系統(tǒng)命名空間中的一部分。但是，系統(tǒng)管理員需要維護(hù)多個(gè)NameNodes和負(fù)載均衡服務(wù)，這又增加了管理成本。
2、計(jì)算和存儲(chǔ)綁定
在傳統(tǒng)的Apache Hadoop集群系統(tǒng)中，計(jì)算和存儲(chǔ)資源是緊密耦合的。在這樣的集群中，當(dāng)存儲(chǔ)空間或計(jì)算資源不足時(shí)，只能同時(shí)對(duì)兩者進(jìn)行擴(kuò)容。假設(shè)用戶對(duì)存儲(chǔ)資源的需求遠(yuǎn)大于對(duì)計(jì)算資源的需求，那么用戶同時(shí)擴(kuò)容計(jì)算和存儲(chǔ)后，新擴(kuò)容的計(jì)算資源就被浪費(fèi)了，反之，存儲(chǔ)資源被浪費(fèi)。這導(dǎo)致擴(kuò)容的經(jīng)濟(jì)效率較低，增加成本。
獨(dú)立擴(kuò)展的計(jì)算和存儲(chǔ)更加靈活，同時(shí)可顯著降低成本。因此，現(xiàn)在Hadoop采用存算分離的架構(gòu)的趨勢(shì)越來越明顯，Hadoop社區(qū)普遍采用S3A客戶端來對(duì)接外部對(duì)象存儲(chǔ)。
3、HDFS的性能問題
HDFS核心組件NameNode的全局鎖問題一直是制約HDFS性能，尤其是NameNode處理能力的主要因素。
HDFS在鎖機(jī)制上使用粒度較粗的全局鎖來統(tǒng)一來控制并發(fā)讀寫，這樣處理的優(yōu)勢(shì)比較明顯，全局鎖可以簡(jiǎn)化鎖模型，降低復(fù)雜度。但是由全局鎖的一個(gè)比較大的負(fù)面影響是容易造產(chǎn)生性能瓶頸。
NameNode核心處理邏輯上涉及到兩個(gè)鎖：FSNamesystemLock（HDFS把所有請(qǐng)求抽象為全局讀鎖和全局寫鎖）和FSEditLogLock（主要控制關(guān)鍵元數(shù)據(jù)的修改，用于高可用），一次RPC請(qǐng)求處理流程經(jīng)過了兩次獲取鎖階段，雖然兩個(gè)鎖之間相互獨(dú)立，但如果在兩處中的任意一處不能及時(shí)獲取到鎖，RPC都將處于排隊(duì)等待狀態(tài)。等鎖時(shí)間直接影響請(qǐng)求響應(yīng)性能。
再有，因?yàn)閷戞i具有排他性，所以對(duì)性能影響更加明顯。當(dāng)有寫請(qǐng)求正在被處理，則其他所有請(qǐng)求都必須排隊(duì)等待，直到當(dāng)前寫請(qǐng)求被處理完成釋放鎖。當(dāng)集群規(guī)模增加和負(fù)載增高后，全局鎖將逐漸成為NameNode性能瓶頸。
04
S3A的不足
原生的Hadoop中包含一個(gè)的S3A連接器，基于Amazon Web Services (AWS) SDK實(shí)現(xiàn)的。Hadoop S3A允許Hadoop集群連接到任何與S3兼容的對(duì)象存儲(chǔ)。
XSKY的對(duì)象存儲(chǔ)產(chǎn)品XEOS兼容S3協(xié)議，所以可以通過S3A連接器與Hadoop應(yīng)用進(jìn)行交互，但這種方式存在比較大的局限性。
通過上圖，可以看到Hadoop應(yīng)用通過S3A客戶端上傳數(shù)據(jù)時(shí)，需要調(diào)用S3 SDK把請(qǐng)求封裝成HTTP然后發(fā)送給XEOS對(duì)象路由，然后再由對(duì)象路由轉(zhuǎn)發(fā)到XEOS的S3網(wǎng)關(guān)，最后通過S3網(wǎng)關(guān)將數(shù)據(jù)寫入XEOS存儲(chǔ)集群，從而達(dá)到數(shù)據(jù)上傳的目的。下載文件也是一樣的道理。
S3A雖然同樣可以實(shí)現(xiàn)計(jì)算和存儲(chǔ)分離，但基本架構(gòu)和協(xié)議兼容性上還是存在一些問題：
由于所有的數(shù)據(jù)都需要先經(jīng)過對(duì)象路由和S3網(wǎng)關(guān)，所以在IO路徑上就會(huì)多了對(duì)象路由和S3網(wǎng)關(guān)這一跳；
S3A因?yàn)橥ㄟ^S3 SDK來實(shí)現(xiàn)，所以并不支持標(biāo)準(zhǔn)Hadoop文件系統(tǒng)的追加寫操作；
S3A 因?yàn)槭褂脴?biāo)準(zhǔn)的S3協(xié)議，所以勢(shì)必會(huì)在一些偏文件風(fēng)格的接口上做更多的判斷，導(dǎo)致客戶端邏輯復(fù)雜。如判斷一個(gè)目錄，需要多次REST請(qǐng)求才能完成，同時(shí)過多的REST請(qǐng)求將會(huì)對(duì)性能造成影響。
05
XSKY HDFS Client應(yīng)運(yùn)而生
為了解決S3A的問題，XSKY開發(fā)了XSKY HDFS Client——XEOS存儲(chǔ)集群和Hadoop計(jì)算集群量身打造的連接器。
通過XSKY HDFS Client（簡(jiǎn)稱“XHC”），Hadoop應(yīng)用可以訪問存儲(chǔ)在XEOS中的所有數(shù)據(jù)，這就避免了傳統(tǒng)的Hadoop應(yīng)用在進(jìn)行數(shù)據(jù)分析前，還要將數(shù)據(jù)由業(yè)務(wù)存儲(chǔ)移動(dòng)到分析存儲(chǔ)HDFS中，也就是常見的ETL過程。
XSKY HDFS Client相當(dāng)于HDFS的DFSClient，為Hadoop應(yīng)用提供了標(biāo)準(zhǔn)的 Hadoop文件系統(tǒng)API。在每個(gè)計(jì)算節(jié)點(diǎn)上，Hadoop應(yīng)用都將使用XSKY HDFS Client (JAR) 執(zhí)行 Hadoop文件系統(tǒng)的操作，并且屏蔽了Hadoop應(yīng)用與XEOS集群交互的復(fù)雜性。在XEOS集群中，每一個(gè)存儲(chǔ)節(jié)點(diǎn)都等效于HDFS的NameNode和DataNode。
06
XSKY HDFS Client 的架構(gòu)與實(shí)現(xiàn)
相比于S3A通過S3 SDK封裝HTTP請(qǐng)求的方式訪問XEOS不同，XSKY HDFS Client可以直接訪問存儲(chǔ)集群的OSD，IO路徑上要短得多。
XSKY HDFS Client通過XEOS提供的NFS風(fēng)格的接口與XEOS集群進(jìn)行交互，這種實(shí)現(xiàn)方式的優(yōu)勢(shì)主要體現(xiàn)在：
由于省掉了對(duì)象路由和S3網(wǎng)關(guān)這一層，所以性能會(huì)好于S3A；
XEOS的NFS網(wǎng)關(guān)庫(kù)的write接口具有追加寫的功能，可以匹配Hadoop文件系統(tǒng)對(duì)追加寫的需求。
XSKY HDFS Client本身是一個(gè)由Java實(shí)現(xiàn)的JAR包。作為Hadoop兼容的文件系統(tǒng)，XSKY HDFS Client需要按照Hadoop FileSystem API規(guī)范來實(shí)現(xiàn)，也就是實(shí)現(xiàn)抽象的Hadoop FileSystem、OutputStream和InputStream。其中，XSKY HDFS Client的FileSystem主要實(shí)現(xiàn)了Hadoop FileSystem的list、delete、rename、mkdir等接口，而InputStream和OutputStream主要實(shí)現(xiàn)了對(duì)XEOS對(duì)象的讀寫功能。
XSKY HDFS Client會(huì)將Hadoop應(yīng)用的Java調(diào)用，通過JNI (Java Native Interface) 技術(shù)轉(zhuǎn)換為本地librgw.so的調(diào)用，并最終訪問到XEOS集群。在計(jì)算節(jié)點(diǎn)上，需要部署XSKY HDFS Client JAR包、librgw.so及其依賴的so庫(kù)和配置文件。
07
XSKY HDFS Client的自動(dòng)化部署
XSKY HDFS Client應(yīng)該在所有需要訪問XEOS存儲(chǔ)的計(jì)算節(jié)點(diǎn)部署。XSKY提供了自動(dòng)化部署工具，用于簡(jiǎn)化部署的過程。
在使用時(shí)，需要將XSKY HDFS Client配置到計(jì)算節(jié)點(diǎn)的core-site.xml文件中。Hadoop應(yīng)用加載core-site.xml配置后，便會(huì)獲得scheme與XSKY HDFS Client的映射關(guān)系。如訪問時(shí)使用“eos://localhost/user/dir/”，Hadoop會(huì)獲取到“eos”這個(gè)scheme并通過映射關(guān)系，選擇XSKY HDFS Client來處理請(qǐng)求。最終XSKY HDFS Client調(diào)用XEOS的NFS接口來處理完成與XEOS的通訊。
以YARN（MapReduce2）為例，在Hadoop中使用XEOS的示例如下。JobClient將Job提交給YARN，YARN將Job拆分成多個(gè)Map和Reduce子任務(wù)并執(zhí)行。在Map或Reduce階段均可通過XSKY HDFS Client訪問XEOS，進(jìn)行讀寫等操作。
XSKY MergeCommitter文件秒合技術(shù)
Output Committer 是 Hadoop 中 MapReduce 的提交協(xié)議。實(shí)際是一組抽象接口，包括 Job Setup、Task Setup、Task Commit、Task Abort、Job Commit、Job Abort、Job Cleanup、Job Recovery。
Hadoop 中 MapReduce 將用戶提交的 job 拆分成多個(gè) task （分別是 map task 和 reduce task）并在多個(gè)節(jié)點(diǎn)上執(zhí)行這些 task，task 在執(zhí)行完成后，將執(zhí)行結(jié)果的輸出通過 output commit 協(xié)議存儲(chǔ)于最終的結(jié)果目錄。
任何 job 端提交工作都將跨集群中的節(jié)點(diǎn)執(zhí)行，并且可能發(fā)生在 job 執(zhí)行的關(guān)鍵部分之外。然而，除非 output commit 協(xié)議要求所有 task 等待 job driver 的信號(hào)，否則 task 的提交不能在最終目錄中實(shí)例化它們的輸出，可用于將成功 task 的輸出提升到可以提交 job 的狀態(tài)，解決投機(jī)性執(zhí)行和失敗問題。
因此 output commit 需要能夠處理當(dāng) job driver 出現(xiàn)故障并且重新啟動(dòng)時(shí)，重新啟動(dòng)的 job driver 僅重新運(yùn)行未完成的 task；當(dāng)重新啟動(dòng)的 job 完成時(shí)，將恢復(fù)已完成 task 的輸出以供提交。
FileOuptputCommitter 是 Hadoop 中 MapReduce 默認(rèn)的 committer。它的算法分為兩個(gè)版本，分別是 “V1” 和 “V2”。
“V2” 算法與“V1”算法大體流程相似，不同之處是“V2”直接將任務(wù)輸出由taskAttemptPath 提交到$dest目錄。在執(zhí)行期間，中間數(shù)據(jù)變得可見。Job失敗時(shí)，必須刪除所有輸出并重新啟動(dòng) job。
與 “真正的” 文件系統(tǒng)相比，S3A 對(duì)象存儲(chǔ) (與大多數(shù)其他對(duì)象類似) 根本不支持 rename()。為了模擬 rename，Hadoop S3A connector 必須將數(shù)據(jù)復(fù)制到目標(biāo)文件名的新對(duì)象中，然后刪除原始條目。這個(gè)復(fù)制可以在服務(wù)器端執(zhí)行，但是由于它要等到集群內(nèi)的復(fù)制完成后才會(huì)完成，所以它所花費(fèi)的時(shí)間與數(shù)據(jù)量成正比。
Rename 開銷是最明顯的問題，但最危險(xiǎn)的是路徑列表沒有一致性保證。S3對(duì)象存儲(chǔ)是弱一致性的，是異步操作，所以 copy 操作雖然返回執(zhí)行成功，但 client 在執(zhí)行 list 目錄時(shí)，是有可能看不到這個(gè)文件的。如果沒有列出文件，commit 操作將不會(huì)復(fù)制它們，因此它們不會(huì)出現(xiàn)在最終輸出中。
對(duì)于 S3 協(xié)議兼容的對(duì)象存儲(chǔ)的 committer 主要有兩種開源實(shí)現(xiàn)：Staging Committer 和 Magic Committer。
S3 協(xié)議兼容的對(duì)象存儲(chǔ)在一致性的表現(xiàn)上，大致分為最終一致性（弱一致性）和強(qiáng)一致性兩種。Staging Committer 和 Magic Committer 都是偏重于對(duì)弱一致性的存儲(chǔ)系統(tǒng)的支持。而對(duì)于強(qiáng)一致性的 S3 協(xié)議兼容的對(duì)象存儲(chǔ)，是不需要引入一致性組件的。
Staging Committer：該 committer 在是用過程中需要先將數(shù)據(jù)寫入本地，再提交到 S3 對(duì)象存儲(chǔ)中，效率低下。而且需要引入第三方的強(qiáng)一致性存儲(chǔ)系統(tǒng)（如 HDFS），所以會(huì)帶來架構(gòu)的復(fù)雜性，提高運(yùn)維難度。
Magic Committer：該 committer 使用分段上傳來提交 task 的輸出文件，但是并不會(huì)區(qū)分文件大小，一般情況下建議在對(duì)大文件（如 100M以上）使用分段上傳來提高上傳效率，而 Magic Committer 無論多小的文件都使用分段上傳，造成 IO 效率低下。在 task commit 和 job commit 階段需要不停的讀、寫、合并 .pendingset 文件，影響 IO 效率。該 Committer 是在 Hadoop3 版本中發(fā)布的，并不支持當(dāng)前市場(chǎng)主流的 Hadoop2 版本。
XSKY Merge Committer，通過使用對(duì)象存儲(chǔ)的自定義元數(shù)據(jù)，與文件秒合功能解決上述問題。文件秒合可以將一個(gè)或多個(gè)對(duì)象合并為一個(gè)新對(duì)象，并保存到指定的目錄中。這個(gè)新對(duì)象的內(nèi)容，是被合并的所有文件內(nèi)容的集合，按照輸入文件列表的順序組織。并且秒合是一個(gè)時(shí)間復(fù)雜度 O(1) 的原子操作。
09
小結(jié)
XSKY HDFS Client從原理上看，功能和性能都要比S3A的要強(qiáng)大很多，在某金融機(jī)構(gòu)的實(shí)際測(cè)試表現(xiàn)也沒有令人失望。
1、性能測(cè)試
根據(jù)中國(guó)信息通信研究院的《Hadoop平臺(tái)性能測(cè)試方法》，一般情況下大數(shù)據(jù)平臺(tái)性能測(cè)試主要考慮四個(gè)方面：SQL任務(wù)、NoSQL任務(wù)、機(jī)器學(xué)習(xí)、批處理。這里主要選擇在SQL任務(wù)、NoSQL任務(wù)、批處理與開源Hadoop平臺(tái)進(jìn)行對(duì)比測(cè)試。
2、用例說明
其中批處理用例主要選擇了1T數(shù)據(jù)排序的TeraSort標(biāo)準(zhǔn)測(cè)試工具；NoSQL任務(wù)選擇了使用HBase Blukload工具對(duì)400G .csv文件進(jìn)行數(shù)據(jù)導(dǎo)入測(cè)試；Hive Join的測(cè)試使用了500G+500G大表join，500M+500G大小表join，及500M+500G大小表MapJoin幾個(gè)子測(cè)試用例。
3、測(cè)試結(jié)果
XEOS不僅在DFSIO上面表現(xiàn)優(yōu)異，在SQL、NoSQL、批處理上的性能都有部分提升。
結(jié)果如下：
而采用XEOS對(duì)象存儲(chǔ)代替HDFS還具有存算分離的好處，配合XEOS強(qiáng)大的企業(yè)特性和災(zāi)備能力，XEOS必將成為企業(yè)數(shù)據(jù)湖的理想底座。
